我的智能体在 Slack 上显示“成功”，实则静默无操作——以下是捕捉到该问题的监控技术栈

免费领取国家顶级域名（.cn/.中国）

欢迎加入国家域名信源站点导航

站点智能：AI搭建 AI辅助运营独立站，把生意做到全世界

我的 Slack 机器人不断发送成功消息，而 D1 数据库的行数却完全停滞不动。代理程序并没有崩溃——它完成了 Slack 通知步骤，却跳过了所有实际工作。仅靠警报永远无法发现这个问题。

解决方案是将 Slack、D1 日志记录和成本跟踪视为一个连接的管道，而不是三个独立的工具。我最终确定的架构刻意保持精简——只有 7 列，其中 tokens_used（使用的令牌数）是最关键的一列：

CREATE TABLE agent_runs (
  id          TEXT PRIMARY KEY,
  agent_name  TEXT NOT NULL,
  run_at      INTEGER NOT NULL,
  status      TEXT NOT NULL,  -- 'ok' | 'error' | 'timeout'
  duration_ms INTEGER,
  tokens_used INTEGER,
  error_msg   TEXT
);

如果 D1 数据库中没有 tokens_used（使用的令牌数），你的成本仪表板只能告诉你今天花了多少钱，而无法告诉你是哪个代理消耗了这些资源。我之前凭直觉估算我的分析工具每月在 Claude 上的花费约为 20 美元。实际数字却是 38 美元。直到我对日志运行聚合查询后，我才得知真相。

另一个让我吃亏的问题是：MCP 标准输入输出传输超时。我花了几天时间，坚信这是 OAuth 配置错误。其实并非如此。有一个工具在调用外部应用程序接口，该接口偶尔需要 30 秒以上才能响应。标准输入输出传输的读取超时时间短于此，而 Workers 的 30 秒墙钟限制使情况更糟——子进程被强制终止，并返回了一个具有误导性的退出代码 1 错误。正是 D1 数据库中堆积的 timeout（超时）状态行揭示了这一模式。如果没有这些日志，这只会是一个模糊的“有时很慢”的抱怨。

在 Workers 方面：如果你使用普通的 await 发送 Slack 通知，而不是将其包裹在 ctx.waitUntil 中，那么一旦你的 Worker 返回响应，获取请求就会被终止。这就是为什么网络钩子看起来会随机失败——它们并不是失败了，而是被终止了。另外值得了解的是：如果你的负载超过 4,000 个字符，Slack 会返回 400 错误，而原始错误堆栈跟踪会悄无声息地超出此限制。

我在 riversealab.com 上写了完整的细分分析——包括在 2 分钟内达到 1.2 万次写入的键值存储写入激增，以及我如何使用 D1 数据库将其追踪到特定代理，还有针对缓慢工具的持久对象重构。

完整文章 →