Agent评估分数陷阱：理想eval环境vs生产故障模式

这周，我用同一套 eval harness 对同一个 Agent 运行了两次评估。唯一的变量是：网络表现得像演示环境，还是像生产环境。

在网络稳定、没有故障的情况下：50/50 通过，通过率 100%。

还是同一个 Agent、同一份代码，只改变一个条件：现在 22% 的调用会遇到任何 LLM 提供商在真实负载下都可能出现的 rate limit。最终 36/50 通过，通过率 72%。

这并不是 Agent 的 bug。问题在于，eval 从一开始就没有测试过这种情况。

大多数 eval harness 使用的服务提供商从不丢弃请求、从不超时，也从不返回格式错误的响应。因此，评估分数是真实的，只不过它衡量的是一种你的 Agent 在实际运行中永远不会遇到的环境。生产环境中，会有无法正确触发的重试、层层传导的超时，以及在对话进行到一半时突然出现的 rate limit。所有这些问题，都不会出现在一次无故障的评估运行中。

解决办法不是获得更高的 eval 分数，而是在生产环境实际存在的故障模式下运行 eval，并报告经受住这些故障考验后剩下的分数。

我正在构建 thaghr，目的正是实现这一点：注入故障、运行测试，并报告最终还能通过多少。等它准备就绪后，我会分享更多信息。

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

这里是程序员分享知识、了解最新动态并推动职业发展的社区。