Agent 评测通过仍可能线上失效

你构建了一个 AI Agent。它的推理经得住检验——你的 eval suite 会检查它是否为每项任务选择了正确的工具、能否以合理的方式串联这些工具，以及能否从错误步骤中恢复。评分很高。于是你把它发布了。

三天后，一位客户反馈：Agent 返回了成功响应，却什么也没做。日志里没有错误。不过，监控发现了一个异常：输入 token 看起来完全正常，输出 token 却降到了零。这是一次静默故障，而你的 eval 根本没有机会捕获它。

这并不是你的 eval 策略存在漏洞，而是一个完全不同类别的问题。

Eval 测试的是受控环境中的推理能力。它是否选择了正确的工具？能否正确组合多个工具？发现异常时能否恢复？大多数情况下可以——因为它运行时拥有全新的上下文、干净的输入，也没有其他事情争夺它的注意力。

可靠性技术栈测试的，则是同一个 Agent 真正进入现实世界之后会发生什么。它是否确实执行了自己决定要做的事？实际输出是否与模型声称的一致？工具失败时，它是否悄无声息地陷入了循环？这些不是推理问题，而是运行时问题，eval 从一开始就不是为回答这些问题而设计的。

Eval 的运行条件接近理想状态——全新的上下文、已知的输入、行为符合 mock 设定的工具，以及一条干净的执行路径。

生产环境完全不是这样。API 会随机超时。Rate limit 会在执行途中突然出现。真实用户会提交训练数据从未见过的内容。经过数百次运行后，上下文会不断膨胀。有时，Agent 只是默默地反复重试一个失败的工具调用，却没有任何内容被记录为错误。

来看一个具体例子：你的 eval 测试了一个 Agent，它会从 API 获取用户数据并进行总结。测试顺利通过。可到了生产环境，某一天这个 API 变慢了。超时机制被触发，模型将其理解为调用失败，于是决定重试，然后再次重试。30 次尝试、消耗 120,000 个 token 之后，它终于放弃并且什么也没返回——但在整个过程中，日志始终记录为“成功”，因为从技术上来说，并没有发生错误。

你的 eval 从未遇到过响应缓慢的 API，也从未见过第三次重试，更不可能记录 Agent 最终放弃时究竟会做什么。

可靠性技术栈究竟监控什么

有几类信号可以填补这一空白，而且它们都不来自 eval suite：

静默故障会表现为输入 token 与输出 token 不匹配——输入正常、输出接近于零，意味着 Agent 处理了请求，却没有生成任何内容。

延迟异常会表现为成功状态依然保持绿色，但耗时突然飙升。这几乎总是因为后台循环或重试正在持续消耗时间。

Token 漂移会表现为：同一个 Agent 执行同一项任务时，消耗的 token 随时间推移不断增加——通常是 prompt 膨胀，或者状态在不知不觉中持续累积。

成本飙升是最明显的预警信号。单次运行成本突然增长 10 倍，几乎不可能只是巧合。

执行路径——实际调用了哪些工具、调用顺序如何、是否全部成功——则能告诉你，Agent 的恢复逻辑在真实故障下是否有效，而不只是在你测试过的 happy path 上有效。

从“已经发布”到“能够安全运行”之间的差距，并不是代码质量问题，而是可观测性问题。

一个推理能力良好、eval 得分也很漂亮的 Agent，仍然可能因为一次超时而永远循环；可能返回成功状态却什么也没做；也可能因为一次糟糕的重试级联，让成本暴涨 100 倍。这些都不是逻辑错误——它们只会在 Agent 遭遇混乱而真实的执行环境后暴露出来。

你的 eval 已经证明它能够推理。还需要别的东西来证明它能够安全运行。

你不需要重构 Agent，也不需要重建 eval suite。你需要的是对执行过程本身的可见性：封装 LLM client，让每次运行都记录 token、延迟、成本和输出长度。让它运行足够长的时间，从而确定正常基线。当指标偏离基线时发出告警。记录实际调用了哪些工具，以及某个工具失败后发生了什么。

Eval 与可靠性技术栈并不是彼此竞争的关系。前者证明 Agent 能够思考，后者证明这种思考能力在接触生产环境之后依然能够可靠运行。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。