AI Agent 监控的实战教训：空输出比报错更难发现

我们把监控系统嵌入了自己的 AI Agent。在尝试用现有工具监控它时，发现自己在很多方面都陷入了盲区，而且这些盲区出乎意料。

我们未曾察觉的问题

三个月前，我们的营销 Agent 应该每天早晨起草社交媒体帖子。某个周二，它没有执行。我们查了日志。没有错误。LLM 调用成功了。HTTP 200。响应也返回了。然而：没有草稿。只有一片空白。

这就是大多数可观测性工具无法捕捉的失败模式。Agent 执行了。基础设施显示"成功"。但 Agent 什么都没产生——零输出 tokens、空响应、一个返回 200 OK 但什么都没完成的请求。

我们只能手动检查执行历史才能发现问题。那时候，已经有人注意到了这个空缺。

那时候我们才意识到：我们无法实时看到自己 Agent 里实际发生了什么。我们需要从零开始构建可视化能力。

从第一性原理出发

我们问自己：关于 AI Agent 的执行，我们到底需要知道什么？

不仅仅是"出错了没有"——因为错误不是 Agent 失败的唯一方式。我们需要：

它有没有运行？（HTTP 状态、延迟）

它消耗了预期的内容吗？（tokens、成本）

它产生任何输出了吗？（输出长度，不只是"成功"状态）

它做对了吗？（更难的那个——我们稍后会回来讨论）

大多数 APM 工具监控的是基础设施：请求延迟、错误率、依赖项。这些没有一个能回答"输出是否为空？"它们监控的是外壳，而不是内部发生了什么。

所以我们为 Agent 写了一个 SDK 包装器。简单的设计：

拦截 LLM 客户端调用（OpenAI、Anthropic 等）

采集遥测数据：输入/输出 tokens、成本、延迟，以及——关键——输出本身

发送到我们可以查询和告警的地方

这个 SDK 运行在我们自己的环境里，不是在我们和 LLM 提供商之间。你的 API 密钥留在你的进程里。我们只看到遥测数据。

这个设计选择很重要：这意味着我们可以捕获模型实际返回的内容，但看不到你的专有提示词或系统指令。只读的可观测性。

我们构建了什么（以及为什么）

第一个版本只是捕获原始指标。我们记录了消耗的 tokens（输入/输出）、根据每个模型的定价计算的成本、延迟、状态（成功/失败/超时）、模型名称（这样我们就可以从内置费率表自动计算成本），以及输出的摘要。

我们把它推送到仪表板并设置了基本告警：如果成本飙升，标记它。如果延迟超过阈值，标记它。

这捕获了基础设施问题。但无法捕获静默失败。

所以我们添加了静默失败检测：如果状态是"成功"但 output_tokens 等于 0，那就是一条告警。Agent 运行了。它返回了 200。它什么都没产生。

仅凭这条规则，我们在一周内又捕获了三个这样的案例。

然后是更难的问题：如果输出看起来正常但实际上是错的呢？

Agent 返回了一个格式正确的响应。Tokens 正常流动。成本符合预期。但输出是垃圾——一个与输入不匹配的推荐、一个错误的计算、一个根本不是所要求的回复。

没有任何指标能捕获这个。没有任何基线能。你需要一个人（或者另一个模型）来评分。

正确性问题

我们构建了一个"正确性检查"功能：你用纯英文写一份评分标准，描述正确的输出应该是什么样的（"回复必须包含一个特定名称和一个推荐。推荐必须是可操作的。"）。然后我们把每个执行的输出通过 AI 评分器对照该评分标准进行评估。

评分器不是完美的。这正是让它可审查的意义所在。每当有告警时，我们让你给出赞成或反对："评分器这次对了吗？"随着时间推移，这些反馈成为准确性的记录。

如果评分器在某方面系统性地出错，你可以标记一个分歧，并将其作为评分器学习的例子添加进去。纠正是始终手动的——我们不会从反馈中自动添加例子——所以一个糟糕的评分标准无法自学失败。

这捕获了"200 OK 但完全错误"的情况。它没有解决评分器不完美的问题。它只是让不完美变得可见和可审查，而不是隐藏起来。

基础设施会骗你。HTTP 200 不是工作完成的保证。延迟不是有用性的保证。错误率不能告诉你静默失败的情况。你需要对实际输出有眼睛。

秘密保持秘密。你可以有可观测性而无需分享你的 API 密钥或提示词逻辑。一个运行在你自己的环境里的 SDK 看到你的代码所看到的一切，但只发送给我们聚合和摘要。这就是让我们能够在不破坏你的安全模型的前提下帮助你的设计。

最容易错过的失败是不报错的那些。超时的 Agent、500 的 API——这些很明显。返回 200 但没有响应的 Agent？那就是直到客户告诉你之前一直无人注意地躺在队列里的东西。

正确性是一个需要 AI 辅助的人类问题。你无法写出一个"正确性"的指标。你可以写一个评分标准并让另一个模型来评分，你可以让人来纠正评分器。当纠正循环紧密且透明时，系统才变得有用。

在我们构建这个的时候，我们看了看现有的方案：

应用性能监控工具监控延迟、错误和基础设施——不是 AI 特有的问题，如静默失败或成本异常。

LLM 可观测性工具（较新的那些）监控 tokens 和成本，这更接近——但大多数不区分"Agent 返回成功但没有输出"和"Agent 返回成功且有输出"。指标看起来是一样的。

日志框架让你可以记录任何你想要的东西，但它们不会自动标记模式。你要么手动翻日志，要么写自定义规则。

我们需要的是：

自动检测你使用的是哪个模型（这样成本自动计算，无需配置）

专门标记静默失败（不只是错误）

不需要你与我们分享 API 密钥

让你定义什么是"正确"并在违反时告警

给你实时可见性而不拖慢你的 Agent

这就是我们构建的东西。而且我们自己在吃自己的狗粮：这个营销系统本身就运行在一个我们用自己产品监控的 AI Agent 上。

我们正在使用中学习。静默失败检测是可靠的——它捕获了基础设施看不到的东西。成本异常检测有助于捕获失控循环。正确性检查有用但设计上不完美：我们不声称知道你的用例中"正确"是什么意思，只是帮助你定义和执行它。

我们仍在摸索的事情：如何让正确性反馈循环更加紧密。现在，如果评分器与你意见不一致，你可以将这个分歧提升为一个训练样本。但评分器实际上需要多少样本才能改进？一个评分标准要准确到足以信任需要多少时间？你怎么知道你已经教得够多了？

这些都是开放性问题。我们正在用真实的 Agent、真实的失败和真实用户的反馈来 live 回答这些问题。

如果你正在构建 AI Agent 并且想知道你的监控是否足够好，问你自己：你能现在就发现你自己的 Agent 中的静默失败吗？不是错误——只是一次返回成功但什么都没产生的执行？

如果答案是"不手动检查日志就发现不了"，你就找到了我们试图填补的空白。