8.0
热点
AI SCORE
技术实践2026-08-01 09:48
Agent 评估为何比模型评估难得多
dev.to · AI#Agent#评估
Editor brief · 编辑速览
Agent 的复杂交互和外部依赖导致评估难度远超模型；作者通过开源项目 AgentEval Forge 系统化这一问题，提供可复用的评估框架。
Agent 的复杂交互和外部依赖导致评估难度远超模型；作者通过开源项目 AgentEval Forge 系统化这一问题，提供可复用的评估框架。
我的这个观点不是来自某篇论文。
我得出这个结论，是因为我正在围绕这个问题开发一个开源项目，而这个项目的构建过程不断对我的想法进行反驳。
我现在正在开发 AgentEval Forge，一个用于 Agent 的开源评估平台。最初的想法听起来够直接：场景包、对抗性用例、轨迹评分、回归追踪、成本和延迟分析。在我的想象中，它会是一个更严肃、更结构化的版本，类似于我之前在其他地方做过的评估工作。
那是第一个错误。
我已经花时间构建过模型评估和工作负载评估风格的系统。我知道如何真实地比较模型在实际任务中的表现，如何设计评分标准，如何权衡速度和成本，以及当评估框架不够完善时一个漂亮的分数会多快地变得具有误导性。我以为 Agent 评估会是同一世界的延伸。
但我越深入 AgentEval Forge，这个假设就越不成立。
模型评估问的是答案是否好。
Agent 评估必须问的是这个系统是否表现得足够好值得信任。
这两个问题不是同一回事。
一个完善的模型评估设置，我知道如何去理解。你有输入、输出，以及某种评分质量的方式。有时是精确匹配。有时是评分标准。有时是 LLM 评委。有时是基准测试框架。不管设置有多花哨，重心始终相当稳定：模型是否为这个任务产生了好的答案？
这本身已经足够困难了。我见过足够多的脆弱评分和虚假的信心，足以知道即使是模型评估也会以看起来科学的方式出错。评分标准可能会奖励错误的东西。二元检查可能会遗漏明显有用的东西。基准测试可能看起来客观，但仍会把你推向错误的优化方向。所以我不是在声称模型评估已经解决了。
但对于 Agent，问题的形状改变了。
被评估的东西不再仅仅是答案。它是一个工作流。它是一系列决策。它是工具选择、重试、中间状态、成本、恢复行为，有时还有策略遵守。一旦你让一个系统做超过一次的响应，最终输出就不再是整个故事了。
说得那样直白时，这听起来很明显。但在实践中，我认为很多团队仍然在已经超越那个范畴的系统上使用答案评分的习惯。
真正的转变发生在我尝试定义 AgentEval Forge 实际上必须评分什么的时候。
起初，我认为答案会很简单：运行场景包，评分输出，比较版本，完成。
但我越看真实的 Agent 行为，这就越显得天真。一个 Agent 可以在路上表现得很糟的情况下产生一个还不错的最终答案。它可以先选择错误的工具，然后碰巧通过恢复。它可能循环得比应该的多。它可能花费五倍的 token，而更好的路径会花费更少。它可能采取一个人类审查者永远不会批准的风险步骤，然后仍然回到看起来在最后还可以接受的东西。
如果我只评分最终答案，我可能会将那个运行标记为成功。
这是我在构建这个时不断回到的句子。路径与终点一样重要，有时更重要，因为路径是成本、安全和信任真正存在的地方。
这个挑战以非常实际的方式出现。我不仅仅是在尝试评分 Agent 是否得到了正确的答案。我在考虑它首先选择了错误工具的情况、它仅因为后期恢复而通过任务的情况、它越过了不应该越过的边界的情况、它在简单的事情上花费了太多步骤的情况，或者它仅在一个狭隘的场景族内回归而平均分数看起来仍然很好的情况。这就是让 Agent 评估感觉更像系统工作而不是答案评分的那种混乱。
这不是我第一次感受到这个问题的边界。
在早期的框架和实地研究工作中，尤其是当对真实工作负载而不是玩具示例运行系统时，我不断发现失败，那些在一个完善的 prompt 评估设置中永远不会显现的失败。那段经历让我对演示路径的信心少了很多。
一个系统在受控评估中看起来可能很强，然后一旦环境变得不规律就变得不稳定。真实的仓库。真实的日志。真实的提交历史。真实的命名混乱。真实的歧义。
那是边界情况出现的地方。那是工具滥用出现的地方。那是"技术上正确"和"安全推送"开始漂移的地方。
我认为那段历史是 AgentEval Forge 在我脑子里采取它所采取的形态的部分原因。我不是在尝试构建一个排行榜生成器。我在尝试构建更接近 Agent 发布规范的东西。
不是：这个运行看起来好吗？
更像是：如果我改变这个系统，什么改善了，什么恶化了，什么变得更贵了，什么变得更风险了，即使顶级分数提高了？
这感觉更像工程而不是基准测试。
我越思考这个问题，越回到五个维度。
首先，你仍然需要最终的正确性。如果 Agent 没有解决任务，其他的也就不那么重要了。
其次，你需要轨迹质量。它是如何到达那里的？一系列决策是否合理、高效和稳定？还是说它成功了，但成功的方式是你在生产中永远不会想重复的？
第三，你需要评估工具行为。它选择了正确的工具吗？它过度使用它们吗？它是否不必要地采取了昂贵或风险的行动？它是否依赖于意外的恢复？
第四，你需要安全和策略遵守。通过不安全的路径达到的成功输出不应该算作干净的胜利。
第五，你需要成本、延迟和回归。新版本是否变得更慢了？更贵了？更不稳定了？它提高了准确性，同时让运营行为变得更糟吗？它只改变了风格，但仍然被庆祝为进步吗？
最后一个对我来说很重要，因为我认为这是团队最容易欺骗自己的地方。他们看到差异并称之为改进。这两个不是同一回事。
我不是在说当前的评估生态系统是无用的。远非如此。
LangChain 关于评估驱动开发的文章抓住了一个核心问题：一旦你在生产中看到失败，那些失败需要反馈到离线评估中，每个变化都应该对它们进行测试。这个循环是健康的。它正是我想看到更多团队采用的那种规范。
从另一个角度，Birgitta Böckeler 关于 Agent 编码的文章捕捉了我认为也很重要的东西：最危险的失败往往存在于更长的反馈循环中。可维护性。团队摩擦。蛮力修复。误诊。过度构建的解决方案。这些成本不总是在立即的输出中显现，但它们绝对会在后来显现。
这就是为什么我不认为问题在于现有工具很糟。我认为问题是我们许多评估习惯是在一个 prompt-and-answer 的世界中形成的。Agent 系统更加混乱。它们的行为更像编排软件而不是隔离的文本生成。一旦你接受了这一点，你的评估系统也必须成长。
这是我不想过度整理的部分。
你的评估设置可能以看起来严谨的方式出错。
我在模型评估和框架工作中已经看到过足够多的这种情况，足以警惕任何听起来比实际更确定的系统。你可能会低估有用的行为。你可能会让你的二元检查过于脆弱。你可能会针对容易评分的东西而不是真正重要的东西进行优化。
所以现在挑战有两层。Agent 很难评估，评估系统本身变成了另一个你必须小心设计、诚实校准和略微不信任的系统。
这不是避免认真评估的理由。如果有的话，这恰恰相反。这意味着评估必须被当作产品和工程工作，而不仅仅是报告。
尽管有这一切，我对这个问题的看法并不悲观。
如果有的话，构建 AgentEval Forge 让我更确信这是值得好好去做的事情。我想要场景包。我想要对抗性用例。我想要轨迹评分。我想要能告诉我哪个变化使系统更有用、哪个变化只是在演示中让它看起来更干净的回归追踪。
我想要一个帮助回答发布问题的评估系统，而不仅仅是研究问题。
这个版本是否得到了改进？
以及即使顶级分数上升了，什么变得更风险了？
这就是我想要工具帮助回答的那种问题。
我怀疑许多团队仍在用 Agent 评估做许多团队在 AI 辅助编码更广泛上做过的事情：从早期问题借用习惯，并希望它们能扩展。
然后账单在后来显现，以回归、奇怪的生产行为、昂贵的路径、不安全的工具使用，或一个不断改变系统但永远无法说出它是否真的改进了的团队的形式。
这就是为什么这个主题在我仍在构建 OSS 的时候值得写。构建过程本身在为我磨锐这个论点。每个设计决策都不断把我推向同样的结论：模型评估问的是答案是否好。Agent 评估必须问的是这个系统是否表现得足够好值得信任。
这是一个更困难的问题。我也认为它即将成为认真 Agent 工作的定义工程问题之一。
一旦 OSS 公开，我会写更多关于这个的内容。其中一些挑战已经变成了 AgentEval Forge 中的具体设计决策，在接下来的几周内我想分享我们哪些部分解决得很干净，哪些部分仍然混乱，以及一旦代码必须作为真实系统而不是想法工作时权衡如何改变。当准备好时我会公开分享 GitHub 仓库。
这对我来说仍然是一个积极的构建和一条积极的思维线，所以我真诚地欢迎对它的反驳。
你在哪里发现答案评分对你的 Agent 工作来说不再足够？
你正在评估路径吗，还是仍然主要评估最终输出？
什么最难评分好：工具使用、回归、安全、成本，还是别的什么？
以及大问题：我们在构建能改进发布信心的评估系统，还是只是更好的感到严谨的方式？