评测 agent

评测单次模型调用相对容易：一个输入、一个输出，跟预期比一比。

agent 把这一点打破了。同一个结果有很多条合法路径，每次运行都不确定，失败可能发生在十几个步骤中的任何一步。单次调用的评测习惯没法直接搬过来。

评结果，不评路径

最根本的原则：评的是终态，不是轨迹。

让 agent 去修一个挂掉的测试，它可能读三个文件，也可能读十一个；可能先搜索，也可能先改代码。只要测试通过、别的没坏，它就是成功了。评路径会惩罚合理的变化，奖励的是「照抄你当初随手写下的那条路径」。

所以把成功定义成一个可检查的终态：

• 测试通过
• 数据库里存在这条记录，且字段符合要求
• 文件里包含这处改动
• 返回的答案在这几个具体事实上对得上

这要求有一个你能检查、能重置的环境——这就是为什么 agent 评测比 prompt 评测需要更多基础设施，也是为什么搭这套东西才是真正的活儿。

反复运行

agent 是不确定的。单跑一次几乎说明不了任何问题。

每个用例跑五到十次，报告成功率。这样你能看到的东西就完全不一样了：

• 10/10——这个用例稳定可靠
• 7/10——能用，但在生产环境会经常失败
• 2/10——偶尔蒙对，其实是坏的

方差本身就是一条结论。一个你以为很扎实的用例方差却很高，说明任务定义得不够清楚，或者工具描述有歧义。

这也是避免经典错误的方法：一次 demo 跑成功就上线。

追踪成本与步数

两个都成功的 agent 并不等价：一个花四步，另一个花十九步。

**每次成功的步数。**这是效率，也是问题的先行指标。步数上升，通常意味着 agent 在瞎摸索，而不是心里有数。

**每次成功的 token 数。**成本随步数按平方增长，所以步数小幅增加，成本会大幅增加。

**实际耗时。**每一步都是一次往返。

**失败的步骤分布。**失败集中在循环的哪个位置，就告诉你该修什么——早失败通常是工具选择或上下文缺失，晚失败则指向上下文耗尽或跑偏。

主动测试失效模式

那些已知的失效模式不会出现在顺利路径上。要专门去测。

**不可能完成的任务。**让它做工具根本做不到的事。表现好的 agent 会说明做不到；表现差的会一直循环，或者编造一个成功。这一个测试就能抓出一大堆问题。

**有歧义的任务。**它是来问你，还是自己猜？

**工具失败。**故意让工具返回错误，看它是能恢复，还是直接崩掉。

**对抗内容。**在检索到的文档或工具返回结果里塞入形似指令的文本。看它会不会照着做——参见提示注入。

**长任务。**推到远超平时步数的地方，找出上下文管理在哪儿崩。

单独评测工具定义

一个有用的拆法：只测工具选择，什么都不实际执行。

给模型一个任务和一套工具，然后看它挑了哪个工具、传了什么参数。选错工具直接指向工具描述的问题，而不是推理的问题——描述问题还更常见。

两个工具看起来都能用时，这种有歧义的任务在这里价值最高。

万不得已时才评轨迹

有些时候结果没法自动检查——比如研究类任务、开放式分析。

退而求其次，让模型裁判看整条对话记录，问几个具体问题：它用的工具合适吗？下结论前核实过吗？有没有做重复劳动？用这些有针对性问题胜过给一个笼统的质量分。

裁判本身的那些注意事项在这里更要紧，因为对话记录很长，裁判的注意力在长记录上分布不均。信这些数字之前，先抽样跟人工标注对一遍。

搭建评测框架

基础设施就是你要投入的东西：

**可重置的环境。**沙箱、测试数据库、临时目录。每次运行都从完全相同的状态开始。

尽量用确定性的工具桩，让变化来自模型，而不是来自外部世界。

**对话记录全程留档。**思考、调用、结果。没有这些，agent 的失败根本看不懂。

每个用例都有自动化的终态检查。

从五个用例、每个跑一次开始。等它证明有用，再扩到更多用例和更多次重复。一个能跑起来的小框架，价值远高于一个你还在设计中的完备框架。

要点回顾

• 评终态，不评路径——很多条合法轨迹都能到达同一个结果。
• 每个用例反复运行并报告成功率；单跑一次什么也证明不了，方差本身就是结论。
• 追踪步数、token 数，以及失败集中在循环的哪个位置。
• 专门去测不可能的任务、歧义、工具失败、对抗内容和长任务。
• 把工具选择和实际执行分开测——描述问题的数量远超推理问题。
• 评测框架（可重置环境、工具桩、对话记录、自动化检查）才是真正的活儿。

下一篇： 提示注入