I stopped trusting app dashboards and used a browser automation AI agent to rebuild the numbers from scratch - DEV Community
我不再信任应用仪表盘，转而使用浏览器自动化AI代理从头重建数据
ai #生产力 #devops #自动化
仪表盘很棒，直到它们悄无声息地对你撒谎。
我和所有人一样喜欢整洁的管理界面。绿色对勾、漂亮的合计、一条向上攀升的图表，仿佛数据库从未出现过重复行。
但我见过的某些最糟糕的运维错误，都始于同一句话：
"仪表盘显示一切正常。"
这就是为什么一个Reddit上的小例子让我印象深刻。在r/openclaw的一个讨论串中，有人说他们使用OpenClaw根据自己的活动历史填写Garmin的设备同步工作表，而不是信任应用界面。
这是一个很小的用例。但这也是AI代理真正擅长的最清晰的例子之一。
不是写推文。
不是扮演你的同事。
不是总结一份摘要。
有用的做法是：
让代理回到源记录，自己重建答案。
这会把代理从一个聊天机器人变成验证层。
对于构建自动化的开发者来说，这要有趣得多。
聊天部分是最无趣的部分
大多数人依然把代理想象成一个附带几个工具的聊天界面。
这种框架忽略了真正的价值。
重要的不是GPT-5或Claude能用自然语言回答。重要的是代理可以检查：
- Gmail线程
- Slack消息
- SQLite或PostgreSQL行
- CSV导出文件
- Google Sheets
- 应用活动日志
- 日历事件
然后，它可以将这些记录与你仪表盘所声称的情况进行比较。
这就是架构上的转变。
如果代理能直接访问底层记录，它就不需要信任某个应用的摘要界面。
对于验证工作流，这就是以下两者之间的区别：
- "读取页面上的数字"
- "根据证据计算数字"
我更信任第二个。
为什么仪表盘常常是错误的真相来源
仪表盘是为可读性和速度优化的。
它们不是为取证准确性优化的。
仪表盘上的数字可能是：
- 缓存过的
- 延迟的
- 被过滤的
- 去重后的
- 四舍五入的
- 基于你忘记了存在的业务规则
当你检查一个粗略趋势时，这没问题。
但当你决定以下事情时，这就不好了：
- 客户是否被联系过
- 同步任务是否真正完成
- CRM是否与收件箱匹配
- 支持积压是否在增加
- 计费报告是否可以安全发送
Garmin的例子之所以贴切，是因为它令人痛苦地熟悉：应用界面说了一件事，历史记录说了另一件事，于是用户从底层活动中重建了答案。
这就是模式。
不要要求AI信任仪表盘。要求AI核对收据。
让这一切运转的技术栈
在深入研究代理工作流时，我发现了另一个r/openclaw的讨论，它比大多数供应商页面更好地解释了集成问题。一位评论者将其分为几层：原生工具、MCP连接，以及像Composio这样的托管OAuth层。
这才是真正的设计问题。
不是"哪个模型最聪明？"
更好的问题是：
这个代理能多直接地访问我真正信任的记录？
这里是实用版本。
| 选项 | 最擅长什么 |
|---|---|
| OpenClaw | 本地优先的代理控制平面、模型路由、故障转移和运维可见性 |
| MCP | 连接代理到文件、数据库、日历和应用数据，使其能直接读取原始记录 |
| Composio | 托管OAuth、按用户会话、令牌刷新、触发器和庞大的应用集成层 |
我的看法：如果你关心验证，OpenClaw + MCP + Composio 比另一个托管的聊天应用更有意思。
为什么OpenClaw很适合验证工作
OpenClaw有趣是因为它更像基础设施而不是聊天玩具。
如果我要求代理核对：
- 本地导出文件
- 收件箱历史
- SQLite行
- Slack消息
- 某人三周前邮件发送的电子表格
我想要一些可检查的东西。
OpenClaw 暴露了能实现这一点的命令：
openclaw status
openclaw status --all
openclaw status --deep
openclaw health --json
openclaw health --verbose
这很重要。
验证层应该是可调试的。如果代理要告诉我仪表盘错了，我想知道它触及了什么、什么失败了、以及它信任了哪个来源。
MCP成为有用部分的地方
MCP之所以重要，是因为它为代理提供了访问真实系统的标准方式，而不是抓取一个界面然后假装那是真相。
例如，如果你的代理能连接到：
- Gmail
- Google Calendar
- PostgreSQL
- SQLite
- 本地文件
- Notion
那么它就能从源记录重建答案。
这比“打开仪表板，读取总数，重复总数”要健康得多。
一个最小的概念性示例可能如下所示：
const records = await Promise.all([
gmail.getThreads({ since: "2026-06-01" }),
slack.getMessages({ channel: "support", since: "2026-06-01" }),
postgres.query("select * from tickets where created_at >= $1", ["2026-06-01"]),
sqlite.query("select * from sync_events where ts >= ?", ["2026-06-01"])
]);
const normalized = normalize(records);
const result = reconcile(normalized);
console.log(result.mismatches);
具体的 API 可能各不相同，但模式是相同的：
- 获取源记录
- 标准化它们
- 计算结果
- 将结果与应用摘要进行比较
- 输出证据
Composio 如何帮你摆脱 OAuth 地狱
这是开发人员容易低估的部分，直到他们为认证流程浪费掉一个周末。
Composio 之所以有用，是因为它处理了丑陋的集成层：
- OAuth
- 每个用户的连接
- 令牌刷新
- 触发器
- SDK 和 CLI 访问
- 大量应用集成
这意味着你的 AI 智能体可以从团队实际使用的系统（如 Gmail、Slack、Google Sheets 和 Linear）中拉取数据，而无需你为每个连接手动编写认证代码。
它的安装路径简单得令人耳目一新：
curl -fsSL https://composio.dev/install | bash
是的，这对验证至关重要。如果你的 AI 智能体能够拉取原始的 Slack 消息，并将其与 CRM 活动或工单数量进行比较，你就能在有人转发错误报告之前发现不匹配。
一个实际的验证工作流
到这里，这个概念就不再抽象了。
一个可靠的核对流水线通常如下所示：
- 从所有涉及的系统中拉取源数据
- 标准化 ID、时间戳和重复项
- 让模型核对差异
- 将模型计算的结果与仪表板中的值进行比较
- 生成包含证据链接的不匹配报告
如果你正在使用 n8n，这会非常自然地匹配。
示例流程：
- 节点 1：获取 Gmail 邮件导出
- 节点 2：获取 Slack 消息
- 节点 3：读取 Google Sheets 行
- 节点 4：查询 PostgreSQL
- 节点 5：使用 Claude 或 GPT-5 进行核对
- 节点 6：将不匹配报告发布到 Slack 或邮件
这比让 AI 智能体在侧边栏里卖弄聪明要有用得多。
示例：将仪表板指标与源记录进行比较
下面是一个精简的 Node.js 示例，展示了工作流的形态。
```javascript
async function verifyContactCount({ dashboardCount, gmailThreads, crmRecords }) {
const contactedEmails = new Set();
for (const thread of gmailThreads) {
if (thread.direction === "outbound" && thread.customerEmail) {
contactedEmails.add(thread.customerEmail.toLowerCase());
}
}
const crmTouched = new Set();
for (const record of crmRecords) {
if (record.customerEmail && record.lastContactedAt) {
crmTouched.add(record.customerEmail.toLowerCase());
}
}
const onlyInG