AI Agent 上线前必检的 6 个隐形失败模式

在向生产环境部署 AI agent 之前，你需要知道当它无声地失败时会发生什么，大多数团队直到客户投诉才会发现这一点。

原因是结构性的：你的 agent 可能返回 HTTP 200，你的日志显示成功，你的测试通过了，而 agent 其实什么都没做。没有消耗 token，没有输出，没有执行任何操作。你要求它生成摘要，它给了你一个空字符串。你要求它对一封邮件进行分类，它返回了 null。调用成功了。Agent 失败了。

这与错误不同。错误是显而易见的，你的监控能捕捉到它们，你的告警会尖叫，你去修复它们。无声失败更加隐蔽，也更加昂贵，因为它们隐藏起来了。

你需要的是一个检查清单，一组在投入生产前需要进行的检测项，可以捕捉到真正重要的失败。不是每个指标，只是那些能预示 agent 出问题的指标。

要监控的 6 种失败模式

1. 零输出 token

LLM 调用消耗了输入 token 但生成零输出 token 是一个红旗信号。模型被调用了，它运行了，但什么都没有产生。可能是触发了长度限制，可能是陷入循环并在生成过程中超时，也可能是完全拒绝了 prompt。

检查很简单：output_tokens 等于 0，input_tokens 大于 0，且 status 为 success。如果这种情况只发生一次，可能是噪声。如果连续发生两次，说明有问题。

按 agent、按模型、按日期跟踪这个指标。如果你的 agent 在某个周三的零输出率爬升到 5% 以上，你会在客户发现问题之前就知道了。

2. 输出摘要为空或明显错误

你的 agent 返回了文本，但文本为空，或者它是一个幻觉出来的占位符，比如"[No response]"或"ERROR: could not generate output"。Agent 没有失败运行，它运行了但产生了垃圾数据。

捕捉输出的简短摘要，前 50 到 100 个字符，或者如果你的 agent 返回结构化数据则捕捉一个关键字段。然后设置一个告警：如果连续 2 次以上的运行产生空白或明显为空的摘要，就通知某人。

这是一个启发式方法，不是法律。但它的区别在于是在凌晨 3 点因为你客户的支持队列卡住而发现问题，还是在下午的站会上发现问题。

3. 延迟尖峰（模型超时或进入循环）

Agent 调用通常需要 2 秒，但现在需要 60 秒，这是一个症状。通常意味着两种情况之一：模型陷入了重试循环，或者它卡在生成 token 上并触发了你的超时。

按 agent 跟踪 p50 和 p95 延迟。如果 p95 突然增长 10 倍，这不是噪声。发生了什么变化。

4. Token 消耗远高于预期

你部署的 agent 通常每次运行消耗 500 个 token。周二那天，同一个 agent 每次运行消耗 15,000 个 token，相同的输入，相同的查询，相同的模型。但 token 消耗爆炸式增长了。

这通常意味着 agent 陷入了循环，它在单次运行中多次调用模型，或者它把自己的输出反馈给自己，或者 prompt 被注入了对抗性内容导致生成大量 token。

跟踪每次运行的输入和输出 token。设置一个上限：如果单次运行超过该 agent 正常 token 使用量的第 90 百分位的 10 倍，那就是一个调查信号。

5. 成功率低于基线

你知道 agent 大部分时间的成功率是多少。也许是 97%，也许是 87%。无论是什么，那就是你的基线。如果跌到 70%，你就有问题了。

大多数监控工具测量错误、异常、500 错误、超时。但 agent 可以有很高的"成功"率（所有调用都返回 200），同时有很低的"有用"率（一半的调用产生空输出）。两者都要跟踪。

成功率应该定义为返回非空、非幻觉结果的调用数除以总调用数。如果逐日下降 10 个百分点或更多，就要告警。

6. 每次运行的成本激增

上周你的 agent 每次运行成本 $0.02。这周是 $0.50 每次运行，相同的输入分布，相同的模型。某些东西膨胀了 token 使用量。

通常又是循环问题，agent 在单次运行中多次调用模型，使用了更贵的模型，或者 prompt 膨胀了。但你在有数据之前不会知道。

从输入 token 加输出 token 乘以模型定价来计算每次运行的成本。如果每次运行的成本增长 5 倍，那就是你的警报信号。

如何进行这些检测

你不需要一个花哨的平台来捕捉这些。你需要：

按每次运行捕捉这些字段：status（success、error、timeout）、input_tokens 和 output_tokens、latency_ms、输出的简短摘要（前 100 个字符，或如果为空则为 null）、cost_usd（从 token 乘以模型定价计算）和 timestamp。

将其存储在任何地方，数据库、日志聚合、监控工具都可以。甚至每 5 分钟更新一次的 CSV 文件开始也可以。

设置四个告警：过去一小时内零输出率超过 5%、连续两次运行的摘要为空、p95 延迟超过基线 10 倍，以及每次运行成本超过第 90 百分位的 5 倍。

每天检查它们，或在发布周期间设置一个仪表板来监控它们。

就这些。你不需要机器学习，你不需要异常检测，你不需要复杂的告警。你需要一个检查清单和在客户的错误预算耗尽之前查看它的纪律。

为什么这在生产前很重要

无声失败在早期修复成本很低，在后期修复成本很高。在生产前捕捉到零输出循环，你只需调整 prompt 并重新部署。在凌晨 2 点才捕捉到，因为你的客户无法处理他们的数据，你就陷入了消防模式。

区别在于可观测性。不仅仅是知道 agent 运行了，而是知道它运行时做了什么。

在你发布前阅读这个检查清单。进行这六个信号的检测。在你发布那天检查它们。你会发现一些你不知道的问题，你会睡得更好，因为你知道在问题变成事件之前你会发现它们。

无声失败的 agent 不是你进行了检测的那个，而是你在没有查看的情况下发布的那个。