Agent 与工具调用评测 Agent & Tool-Use Evaluation
所属：01-fundamentals / 05-agent-evaluation
面试权重：★★
来源：通用领域知识；未做一手考证
相关知识点：01-fundamentals/04-agent-architecture/agent-react.md、tool-use.md、06-agent-infra/observability.md
一句话#
Agent 评测有两个层级 —— outcome-level（任务最终做成了吗）和 trajectory-level（过程走的对不对）；只看 outcome 会把「运气好走对了」「走对了但代价离谱」「过程违规但结果凑巧正确」全都记成成功，看不出模型哪里弱，也给不出改进方向。
为什么重要（面试角度）#
Agent 是 2026 面试的热区，但「怎么评」比「怎么搭」更能区分深度。面试官想听：
- 你知不知道 outcome-only 的具体失效场景（不是笼统说"要看过程"）
- 能不能给出工具选择准确性和多步成功率的可操作定义（分子分母是什么）
- 懂不懂 pass@k 与 pass^k 的区别 —— 一个测能力上限，一个测可靠性
- 能不能主动指出多条有效轨迹这个根本困难：agent 不像分类任务有唯一正确答案，"过程对不对"本身没有唯一定义
这部分你没有大段一手经验，所以答的深度要来自思维的严密性：把指标定义说准、把困难主动摆出来，比编造经验强得多。
核心内容#
为什么 outcome-only 不够#
| 失效场景 | 具体表现 | 为什么 outcome 看不出来 |
|---|---|---|
| 侥幸成功 | 中间调错了工具、猜错参数，碰巧环境返回了能用的结果 | 最终状态对，记成成功 |
| 绕路成功 | 用了 3 倍的步数和 token 才做成 | 成功，但成本与延迟指标被掩盖 |
| 违规成功 | 走了不该走的路径（越权、跳过确认、调了不该调的工具） | 结果对，但安全与合规风险不可见 |
| 碰巧失败 | 过程完全正确，最后一步被环境抖动/超时打断 | 记成失败，误判模型能力 |
| 无法归因 | 一个 60% 的成功率，不知道是工具选择错了、参数填错了、还是恢复能力差 | 没有改进方向 |
核心论点：outcome-level 告诉你「好不好」，trajectory-level 才告诉你「为什么」和「怎么改」。两者都要，不是二选一。
两个层级分别看什么#
| 层级 | 评什么 | 典型指标 | 优点 | 缺点 |
|---|---|---|---|---|
| Outcome-level | 任务是否达成（环境终态） | task success rate、pass@k、pass^k | 客观、可自动判定、参考无关 | 无法归因，掩盖过程问题 |
| Trajectory-level | 过程质量 | 工具选择准确率、参数正确率、步数、成本、违规率、错误恢复率 | 可归因、可定位、能做 credit assignment | 需要标注或 judge，"正确过程"不唯一 |
工具调用评测：指标怎么定#
工具调用是 agent 最可客观化的部分，值得单独评：
- Tool selection accuracy：该调 A 却调了 B 的比例。可以做成多分类问题（在给定状态下，正确工具是哪个）—— 分子分母要写清：是按调用次数算还是按决策点算。
- Argument correctness：工具选对了但参数填错（字段缺失、类型错、值幻觉）同样致命。按字段级判，比"整次调用对/错"更有信息量。
- Invalid call rate：schema 校验失败、调用不存在的工具、参数类型错误。这是最容易自动化的一档，也是最先该压到接近 0 的一档。
- 冗余/循环调用：重复调用同一工具、在无新信息的情况下打转（loop 检测）。直接对应成本与超时。
- 工具顺序：某些任务有依赖关系（先查再改），顺序错会导致失败。但注意：很多任务的工具顺序不唯一，强制匹配参考顺序会误判（见下文）。
关键认知：工具本身正确是前提。如果工具实现有 bug、返回格式不稳定，再好的 agent 也是白搭 —— 所以工具的单测与契约测试应当先于 agent 评测。
多步成功率与误差累积#
- Step-wise accuracy（单步正确率）：给定正确的前序状态，这一步做对的比例。这是最可归因的指标。
- Task success rate（任务成功率）：整条轨迹做成的比例。
- 误差累积：如果每步独立地有 的概率做对， 步任务全部正确的概率量级是 。这意味着 长任务对单步准确率极其敏感：单步 95% 的模型在 10 步任务上只剩约 60%，在 30 步任务上会崩到很低。这是"为什么长程 agent 难"的最简洁解释，也是为什么提升单步可靠性比提升单步能力更重要。
- pass@k（能力上限）：同一任务采样 k 次，至少一次成功的比例。衡量模型"能不能做到"，用采样换能力。
- pass^k（可靠性）：同一任务采样 k 次，全部成功的比例（也叫 success^all 之类的口径）。衡量模型"能不能稳定做到"。产品上线看的是这个 —— 一个 pass@10 很高但 pass^10 很低的 agent，在用户手里就是不可用的。
- 方差：agent 采样方差大，评测必须多次运行并报告置信区间；单次跑出来的成功率没有意义。
怎么评一条轨迹#
三种方法，可靠性递减：
- 环境终态断言（最可靠）：在沙箱里跑任务，直接检查环境最终状态 —— 数据库里那行改对了没、文件生成了没、接口返回对不对。参考无关、客观、可自动化，是应该优先采用的形态。代价是要为每个任务搭建可重置的沙箱环境。
- LLM-as-a-Judge 评轨迹：把整条轨迹（每一步的思考、工具调用、返回）交给裁判，按 rubric 判"过程是否合理、是否高效、有无违规"。能覆盖无法用终态断言的维度，但引入 judge 的全部偏置，必须校准（→ 见
llm-as-judge.md）。 - 参考轨迹匹配（最脆弱）：和人工写的标准轨迹逐步比对。问题在于 agent 任务的正确路径不唯一 —— 换个合法的工具顺序、多说一步思考，都会判错。所以只适合比对关键节点（必须调用某个工具、必须包含某个参数），不要做完整序列的严格匹配。
环境式评测（目前最靠谱的形态）#
设计原则：任务有客观终态 + 环境可重置 + 判定确定性。
- 每个任务是一个沙箱（容器/数据库快照/模拟服务），跑完销毁重建，保证任务间隔离与可复现。
- 判定用状态断言或测试，而不是文本比对。
- 需要覆盖：成功路径、需要多步纠错的路径、上下文不足时应弃权/询问的路径、以及诱导越权/危险动作的对抗路径。
- 业界有 SWE-bench（代码修复）、WebArena（网页操作）这类环境式 benchmark 可以借鉴任务形态与判定方式；不同 benchmark 的判定口径差异很大，引用具体分数前请以各自官方说明为准。
最容易漏掉的一类评测：不该动手时是否收手。 一个永远"努力完成任务"的 agent，在信息不足或越权场景下会造成真实伤害。要专门构造"期望它拒绝/提问/升级给人工"的任务，把过度行动率当成一个指标。
评测自身的成本与噪声#
- Agent 评测贵：每跑一次要多次 LLM 调用 + 多次工具调用，沙箱也有成本。所以要分层：小规模、高信息量的核心集用于每次迭代；大规模集用于发版前。
- 环境不稳定（网络、第三方 API 限流）会污染结果，要区分"模型失败"与"环境失败"，前者才是信号。
- 记录完整轨迹（每一步的输入输出、token、成本、耗时）是评测的前提 —— 没有 trace 就做不了 trajectory-level 评测（→ 见
06-agent-infra/observability.md）。
本文讲的这套东西，业界叫 Harness。 ⚠️ 但先别把 Harness 定义成「评测框架」 —— 那是它三个用法里最不主流的那个。主流定义是
Agent = Model + Harness，Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正，在 Agent 边界之内；本文这种「把 Agent 跑起来、批量评它」的设施是评测语境下的用法（在 Agent 外面）。第三个用法是训练/生产一致性 —— 那里有个独立失效模式：训练时的 harness ≠ 上线时的 harness 会导致部署后退化（详见02-post-training/08-agentic-rl.md，案例是阿里那篇 arXiv 2512.24873）。三个用法的对照、以及它在整个 Agent 技术栈里处于哪一层，见04-agent-architecture/08-agent-stack.md。评测这一轮真正缺的是方法，不只是框架：本文多次提到「要报置信区间」「几分差距落在噪声内」，但置信区间怎么算、配对检验怎么做，在
05-statistical-significance.md。
常见面试问法#
Q：agent 怎么评测？ A：分两层。outcome-level 用环境终态断言判任务是否达成（客观、参考无关），trajectory-level 评过程质量 —— 工具选择准确率、参数正确率、无效调用率、冗余调用、错误恢复率、违规动作率。只有 outcome 会掩盖侥幸成功、绕路成功和违规成功，无法归因。优先采用"任务有客观终态 + 沙箱可重置 + 判定确定性"的环境式评测，过程维度用校准过的 LLM judge 补。
Q：pass@k 和 pass^k 有什么区别？产品该看哪个？ A：pass@k 表示 k 次采样中至少一次成功，衡量能力上限（"能不能做到"）；pass^k 表示 k 次采样全部成功，衡量可靠性（"能不能稳定做到"）。产品体验看 pass^k —— 用户不会重试 10 次等你成功一次。长程任务还要看误差累积：单步 95% 在 10 步任务上只剩约 60%，这解释了为什么长任务对单步可靠性极度敏感。
Q：怎么定义"工具选择准确率"？ A：在给定的对话状态/决策点上，所有可选工具中最优的那个是否被选中。分子分母要写清口径：按决策点算（每个该做决策的位置算一次）还是按调用次数算（同一名字重复调用算多次）。更细的还有参数正确率 —— 工具选对但字段填错同样导致失败，应按字段级统计，比整次调用对/错更能定位问题。
Q：为什么"和标准轨迹比对"这种做法不好用？ A：因为 agent 任务的正确路径不唯一：合法的工具顺序可以互换、可以多一次探索性调用、可以有不同的思考表述。严格序列匹配会产生大量假阴性，把正确的 agent 判成失败。替代方案是只比对关键约束（是否调用了必需的工具、是否包含必需参数、是否触发了危险动作），或者直接用环境终态断言 —— 后者根本不关心你怎么走到的。
Q：一个 agent 成功率 90%，能上线吗？ A：信息不够。至少还要看：① 是 pass@k 还是 pass^k（一次采样还是多次全成功）；② 在哪类任务上失败（分桶，看失败是否集中在高风险桶）；③ 过程指标 —— 无效调用率、平均步数/成本、违规动作率、该弃权时是否弃权；④ 失败是可恢复的还是硬失败；⑤ 评测集的分布是否贴近真实流量；⑥ 跑了几次、置信区间多宽。只报一个成功率而不给这些，等于没有评测。
易错点#
- ❌ 只报一个任务成功率，不提是 pass@k 还是 pass^k，也不给采样次数和方差。
- ❌ 用严格轨迹匹配评过程，把多路径的正确 agent 判成失败。
- ❌ 忽略参数正确率，只看工具名字选对没选对。
- ❌ 忘记评「该弃权/该提问时有没有收手」，只评"任务完成"。
- ❌ 把环境抖动导致的失败算成模型失败（或反过来），污染结论。
- ❌ 忘了先给工具做单测 —— 工具本身有 bug 时，agent 评测结论毫无意义。
- ❌ 用单次运行的成功率下结论；agent 非确定性很强，必须多次采样。
- ❌ 只做 outcome 评测却宣称能定位问题 —— 没有 trajectory 就没有 credit assignment。
自测#
1. 为什么"outcome-only 评测会掩盖坏过程"？举三个具体例子。
答案
① 侥幸成功：中间选错工具或猜错参数，环境恰好返回可用结果，终态正确 → 记成功；② 绕路成功：用 3 倍步数和 token 完成任务 → 记成功，成本与延迟问题被掩盖；③ 违规成功：走了跳过人工确认、越权调用、调用了不该调的工具的路径 → 记成功，安全风险不可见。所以 outcome 层告诉你"好不好"，trajectory 层才告诉你"为什么"和"怎么改"，两者都要。
2. pass@k 和 pass^k 分别测什么？一个 pass@10 = 0.9、pass^10 = 0.3 的 agent 意味着什么？
答案
pass@k 测能力上限（k 次采样至少一次成功），pass^k 测可靠性（k 次全部成功）。pass@10=0.9 / pass^10=0.3 说明这个 agent 有能力做成（给它 10 次机会，九成任务能做成至少一次），但极不稳定 —— 十次全成功的概率只有 30%。对用户来说，重试 10 次不是可接受的交互，所以这个 agent 目前不适合直接面向用户；改善方向是提升单步可靠性、减少轨迹方差，而不是刷能力上限。
3. 为什么"和人工标准轨迹逐步比对"不是好做法？更好的替代是什么？
答案
agent 任务的正确路径不唯一：合法工具顺序可互换、允许探索性调用、思考措辞多样，严格逐步匹配会产生大量假阴性，把正确 agent 判失败，指标失真。替代方案：① 优先用环境终态断言（判定与路径无关，最客观）；② 若必须看过程，只比对关键约束（必需工具是否调用、必需参数是否出现、是否触发危险动作），而不是完整序列；③ 无法断言的过程维度用校准过的 LLM judge 按 rubric 评。
4. 为什么长程 agent 任务特别难？用误差累积解释。
答案
若每步独立地有概率 p 做对，n 步任务全对的概率量级约为 p^n。单步 95% 的模型在 10 步任务上约剩 60%，在 30 步任务上会崩到很低。所以长任务对单步可靠性极度敏感，提升单步正确率的收益是指数级的。工程含义：① 缩短任务长度（更好的任务分解）；② 在关键步骤加验证/校验（把错误就地拦住，不让它传播）；③ 允许重试与自我纠错（把 p 的幂次换成"有纠错的机会"）；④ 评测必须分步统计，否则只看端到端成功率无法知道该优化哪一步。
5. 你要给一个工具调用 agent 建评测，列出至少五个你会上报的指标，并说明各自的目的是什么。
答案
① 任务成功率（pass^k） —— 可靠性的主指标，看产品可用性；② 工具选择准确率 —— 定位"选错工具"这类决策错误；③ 参数/字段正确率 —— 工具选对但填错参数同样失败，字段级更能定位；④ 无效调用率（schema 校验失败、调用不存在的工具）—— 最易自动化压到接近 0 的一档；⑤ 平均步数与 token 成本 —— 折算绕路与冗余（同样的成功率，成本可能差几倍）；⑥ 错误恢复率 —— 工具报错后能否自行纠正，这是长程鲁棒性的关键；⑦ 该弃权/该提问时的正确收手率 —— 防"永远努力完成任务"造成的过度行动与越权伤害。前四个用于定位与门禁，后三个用于刻画成本、鲁棒性与安全性。