写在前面
我做 Agent 评测的时候，一开始也只看最终答案对不对。后来发现这个思路有大问题：Agent 做了很多步决策，还调用了各种工具，只看结果根本不知道哪里出错了。
更麻烦的是，就算 Runtime 显示 completed，也不代表这个结果真的能用。我踩过这个坑之后，开始研究"过程评测"——不只看结果，还要看执行过程的证据。
这篇文章是我整理的一套分层评测方法，包含：
- 为什么 Agent 评测必须看执行过程
- 从"只看结果"到"看过程"的演进
- Outcome、Decision、Action、Reliability 四层分别评什么
- Case Contract、证据采集、Validator、Judge 和 Hard Gate 怎么组合
- 三类常见问题的验证，以及接入研发流程的建议
一、为什么 Agent 评测必须看执行过程
Agent 的最终答案来自一整条执行链：先识别任务，然后选 Skill，调用工具，处理工具返回的结果，最后生成产物。
问题是，最终文本只保留了这条链路的一部分信息。想知道结果可不可信，得同时看结果和执行过程的证据。
1.1 最终答案解释不了完整执行链
我见过一次 Agent 运行同时出现这些信号：
- Runtime 返回 completed；
- 最终文本结构完整、语言流畅；
- 工具调用成功，但参数或数据口径有误；
- Agent 选对了工具，但环境没有执行权限；
- 结果看似合理，却没有满足业务断言。
这些问题看起来结果差不多，但修复方向完全不同。只看最终文本，只能判断"回答像不像正确答案"；加上结构化断言、工具状态和环境错误，才能判断"结果是否可信、失败发生在哪里"。
1.2 三种完成信号不是一回事
我后来明白了一个道理：
Completed ≠ Correct ≠ Ready for Release
Runtime 的 completed 只能说明系统认为这次执行已经结束，它不能自动证明数据正确、业务口径正确、结果完整，更不能证明结果已经满足发布条件。
这也是我开始讨论"过程评测"的起点。
二、从结果评分到过程归因
上一节说明了只看最终状态和最终文本可能遗漏关键错误。这一节我沿着近期研究和工程实践的发展，解释评测对象为什么会从 Final Answer 扩展到可观察执行轨迹，并进一步走向失败归因。
2.1 第一阶段：只检查最终结果
传统 LLM 评测通常把一次运行抽象成"输入—输出"，再通过参考答案、规则或 LLM-as-a-Judge 判断最终回答是否正确。
这种方式适合短问答，却会压掉 Agent 在调用外部工具时产生的重要证据：
- 是否选择了正确的 Skill；
- 是否调用了必需工具；
- 工具参数和调用顺序是否正确；
- 外部环境是否返回了权限错误；
- 最终答案引用的是哪一份中间结果。
最终答案是整条执行链的压缩结果。只看它，很难区分"模型不会""工具不可用""SQL 写错"和"输出格式不稳定"。
2.2 第二阶段：把执行轨迹纳入评测
TRAJECT-Bench 不再只报告最终准确率，还检查工具选择、参数正确性以及调用依赖和顺序。EnConda-Bench 则把环境配置任务拆成规划、错误诊断、反馈修复和最终执行，用过程指标说明 Agent 究竟卡在哪一步。
这类工作的共同变化是：
- 评测对象从 Final Answer 扩展为 Final Answer + Observable Trajectory。
- 这里的 Trajectory 不等于模型私有思维链。真正适合保存和审计的是可观察证据，例如 Skill 路由、工具名、参数摘要、状态码、产物引用和外部错误。
2.3 第三阶段：从"判错"走向"归因"
Agent-as-a-Judge 让评测 Agent 主动检查产物和过程证据；AgentRx 尝试从失败轨迹中定位关键失败步骤和根因；SWE-Together 则把用户纠正次数也纳入多轮 Agent 的效果判断。
这些工作带来的工程启发是：一个有用的评测结果不应该只有"73 分"，而应至少回答：
- 结果是否可交付？
- 如果不可交付，失败发生在哪一层？
- 证据是什么？
- 应该修改模型、Skill、Tool、数据逻辑还是运行环境？
三、Agent 应该评什么
在明确"需要看过程"以后，下一步是把过程拆成可判断、可归因的层级。我把这类 Agent 的评测拆成 Outcome、Decision、Action、Reliability 四层；四层不是为了增加指标数量，而是为了对应不同的问题类型和修复对象。
| 层级 | 回答的问题 | 典型检查 | 失败后优先修改 |
|---|---|---|---|
| Outcome | 最终做成了吗？ | 结果、数值、格式、业务护栏 | 数据逻辑、产物生成 |
| Decision | 选对了吗？ | Skill、工具、执行路线 | 路由、指令、Skill 描述 |
| Action | 做对了吗？ | 参数、顺序、状态处理、副作用 | Tool Schema、执行器 |
| Reliability | 多跑几次还可靠吗？ | 成功率、P90、成本、人工纠正 | 模型配置、重试、预算 |
3.1 Outcome：是否可以交付
Outcome 不只检查"有没有答案"，还要检查：
- 输出是否满足 JSON Schema 或报告模板；
- 必需字段是否存在；
- 关键数值是否落在允许误差内；
- 样本量、统计口径和业务护栏是否满足要求；
- 最终产物是否真实存在。
例如关键数值超出业务容差、报告缺失必需字段，都属于 Outcome 失败。
3.2 Decision：是否选对路线
即使结果碰巧正确，Agent 也可能选择了高风险或不可复现的路线。例如本应调用权威数据源，却用模型记忆直接回答；本应进入外部因素分析 Skill，却路由到普通归因 Skill。
Decision 关注的是：
- 任务识别是否正确；
- 选择的 Skill 是否适配；
- 必需工具是否进入计划；
- 是否违反"必须查询""禁止写入"等约束。
3.3 Action：是否正确执行
Decision 正确不代表执行正确。Action 需要检查：
- 参数是否完整、类型是否正确；
- 工具调用顺序是否满足依赖；
- 工具失败后有没有被错误地当成成功；
- 写库、通知、投放等副作用是否具备幂等保护；
- Agent 是否反复执行同一动作。
3.4 Reliability：是否稳定复现
Agent 具有随机性，同一个 Case 单次通过不能证明它稳定。Reliability 应在多次真实运行上统计：
- 通过率和连续通过率；
- P50/P90 延迟；
- Token 与工具调用成本；
- 用户纠正次数；
- 超时、限流和工具错误率。
我这里用的确定性示例不用于证明 Reliability；真正的 Reliability 必须来自同一 Case 的多次独立 Agent 运行。
四、分层评测如何实现
四层框架回答了"评什么"，这一节继续回答"怎样评"。完整流程从运行前冻结 Case Contract 开始，经过证据采集、确定性校验与语义判断，最终形成发布结论和根因定位。
4.1 运行前定义 Case Contract
评测标准应在 Agent 运行前确定。一个 Eval Case 至少需要写清：
{
"case_id": "numeric-golden-001",
"input": "脱敏任务输入",
"required_skills": ["core-analysis"],
"required_tools": ["warehouse-query"],
"output_contract": "json",
"assertions": [
{"field": "metrics.absolute_value", "expected": 250, "tolerance": 0.01}
],
"risk": "critical"
}
这里最重要的不是 JSON 写法，而是四类约束必须在运行前确定：输入、必需能力、结果断言和风险等级。
4.2 采集可观察证据
一次 Run 可以保留：
- 最终输出
- 所选 Skill
- Tool Call 与参数摘要
- 工具状态和错误码
- 中间/最终产物引用
- 模型与版本
- 时延、Token、成本
这组证据已经足以定位大量工程失败，不需要读取或保存模型私有思维链。
4.3 确定性规则优先
我建议按以下顺序执行评测：
- 确定性 Validator：Schema、字段、数值、必需工具、参数范围和状态码；
- Agent/LLM Judge：解释完整性、证据是否支持结论、开放式业务判断；
- 人工复核：高风险发布、Judge 分歧、新型失败和抽样校准。
能由程序精确判断的事实，不应交给概率裁判。Judge 应处理规则难以覆盖的语义维度，而且必须看到证据，而不是只看到最终答案。
4.4 Hard Gate 独立判断发布条件
关键数值错误、权限越界、输出 Contract 失败和高风险副作用，不能因为"文案很好"而被平均成一个及格总分。
发布条件可以用一句话表达：
所有 Hard Gate 通过，并且 Outcome、Decision、Action 均达到最低阈值，结果才允许发布。
数值字段可以使用相对误差：
相对误差 = |实际值 − 参考值| / max(|参考值|, ε)
如果该字段是 Hard Gate，只要误差超过业务容差，就直接 BLOCK。
4.5 将失败映射到修复对象
| 根因 | 可观察证据 | 优先修复对象 |
|---|---|---|
| 数据或指标逻辑 | 查询成功但关键数值断言失败 | SQL、数据路由、统计口径 |
| Skill 或策略 | 选错 Skill，或违反任务约束 | 路由、系统指令、Skill 描述 |
| Tool 参数或顺序 | 漏调用、参数错误、依赖顺序错误 | Tool Schema、计划、执行器 |
| 输出契约 | 内容可读但 Schema/字段不满足接口 | Contract、确定性序列化 |
| 环境或权限 | 必需工具不存在或 permission denied | Runtime、白名单、部署配置 |
| 模型语义 | 证据完整，但解释或归纳仍然错误 | 模型、Prompt、上下文 |
这张表的意义是：评测不再只负责"判卷"，还负责把问题送到正确的修改层。
五、三类问题的机制验证
前一节给出了完整方法，这一节我选择三类常见工程问题进行机制验证。示例被编码为 3 个 Case、5 条 Run，用确定性评分器检查规则、Hard Gate 和根因输出是否按预期工作。
需要明确：这是一份可执行机制示例，作用类似评测器的回归测试；它不是对真实线上分布的效果证明，也不能据此比较模型或平台能力。
5.1 数值与口径错误
- Runtime：completed
- Tool：warehouse-query success
- 趋势和比例：正确
- 关键值：实际 100，参考 250
如果只看 Runtime 或最终描述，这条记录可能通过。数值 Validator 计算出 60% 的相对误差，超过 1% 容差，因此 Outcome Hard Gate 失败。
归因：data_or_metric_logic。
修复对象：查询模板、过滤条件和指标口径，而不是模型表达能力。
5.2 输出契约错误
程序调用模式要求稳定 JSON，但 Agent 有时返回 Markdown 报告。对人来说内容可读，对下游程序来说却无法解析。
- 预期：
{"status":"success","data":{...},"request_id":"..."} - 实际：
## 分析完成\n\n下面是一份 Markdown 报告
Schema 和必需字段 Validator 直接失败。
归因：output_contract。
修复对象：输出 Contract、Schema 校验和确定性序列化，而不是继续堆 Prompt。
5.3 环境与权限错误
外部因素分析必须调用 Web Search。Agent 的 Skill 路由正确，也发起了工具调用，但目标环境返回：
web-search: unavailable
error_code: permission_denied
这时不能笼统归因为"模型能力不行"。
归因：environment_or_permission。
修复对象：工具安装、权限白名单或部署环境。
5.4 验证结果
把三个问题放在一起看，会出现一个很有代表性的现象：五条 Run 的 Runtime 都是 completed，但它们在业务结果、工具执行和发布条件上并不相同。
| Run | Runtime | 失败层 | 发布 | 根因 |
|---|---|---|---|---|
| 数值修复前 | completed | Outcome | BLOCK | 数据/指标逻辑 |
| 数值修复后 | completed | — | PASS | — |
| Contract 修复前 | completed | Outcome | BLOCK | 输出契约 |
| Contract 修复后 | completed | — | PASS | — |
| 必需工具被阻断 | completed | Outcome + Action | BLOCK | 环境/权限 |
这张表能证明评分器对三个已知问题按预期工作，但不能证明其在未知失败上的准确率。Decision 在这组示例中也没有区分度，Reliability 尚未被实验覆盖。
六、从机制验证走向真实评测
第五节验证的是评测机制能否识别已知问题，但它还不能证明真实任务中的覆盖率和稳定性。这一节明确当前证据边界，并说明怎样通过历史回填与重复运行，把"可执行示例"逐步升级为真实评测证据。
6.1 历史回填
先冻结 Validator，再对一批历史真实产物回填运行，并与人工核验结论比较：
| 人工结论 / Validator | BLOCK | PASS |
|---|---|---|
| 实际有问题 | True Positive | False Negative |
| 实际无问题 | False Positive | True Negative |
这一步需要报告命中数、误报、漏报，以及是否发现此前人工未注意的问题。它才能回答"这套门禁在真实分布上是否有用"。
6.2 重复运行
选择若干真实 Case，让 Agent 独立运行多次：
- 加入相似 Skill 的路由任务，检查 Decision 是否能区分错路由；
- 对同一 Case 至少运行 3 次，统计连续通过率与 P90；
- 保留模型、Skill、Tool 和环境版本，避免把环境变化误判为模型波动。
这部分是我尚未完成的工作，也是后续最值得补充的实证。
七、工程实施参考
这一节我把前述方法整理一下，为建立一条可重复运行、可比较、可审计的评测链路提供通用实施参考。
7.1 最小评测闭环
一个最小闭环包含五个环节：
- 从业务 Golden、历史失败、人工纠正和风险清单中沉淀 Case；
- 用版本化 Case Contract 固定输入、预期、断言和风险等级；
- 通过 Trace Adapter 将不同 Agent 的输出与轨迹转换为统一证据；
- 使用 Validator、Judge 和 Hard Gate 形成分层判定；
- 输出包含发布结论、证据、根因和修复对象的 Scorecard，并将修复结果回归到同一 Case。
7.2 记录完整版上下文
Agent 的输出会同时受到模型、Prompt、Skill、Tool 和运行环境影响。为了让不同 Run 可比较、可复现，每条记录应绑定完整版本上下文。
| 对象 | 建议记录 | 作用 |
|---|---|---|
| Case | case_id、版本、输入摘要、风险等级 | 确认比较的是同一评测问题 |
| Agent 配置 | 模型、Prompt、Skill 与 Tool 版本 | 定位能力或策略变化 |
| 运行环境 | 权限、依赖、数据快照或时间窗口 | 区分模型问题与环境问题 |
| Evaluator | Validator、Judge、Gate 版本 | 解释判定标准变化 |
| Run | 轨迹、产物、时延、成本与最终状态 | 支持回放、审计和统计 |
7.3 常见运行模式
同一套 Case 和判定规则可以用于不同阶段：
| 模式 | 典型用途 | 主要输出 |
|---|---|---|
| Offline Replay | 回放历史产物，验证规则覆盖率 | 命中、误报、漏报 |
| PR Regression | 检查代码、Prompt、Skill 或 Tool 变更 | 回归差异与阻断项 |
| Scheduled Evaluation | 定期重复运行固定 Case | 通过率、P90 与成本趋势 |
| Online Shadow | 在真实流量旁路观察，不影响主链路 | 新型失败与规则校准数据 |
| Release Gate | 对稳定且高风险的规则执行发布控制 | PASS、BLOCK 与证据引用 |
7.4 渐进式发布门禁
评测规则可以采用"观察—提醒—阻断"的渐进方式：
- Shadow：只记录命中，不影响结果，统计误报和漏报；
- Warning：向研发展示证据和根因，但仍允许人工确认后发布；
- Blocking：只把稳定、可解释且高风险的规则升级为 Hard Gate；
- 持续维护：规则、Golden 和容差都要版本化，例外放行必须记录原因。
这种方式先观察规则在真实任务中的命中情况，再决定是否升级为发布门禁，也为容差调整和误报校准留下空间。
7.5 不同 Agent 的评测重点
| Agent 类型 | 优先建设的检查 |
|---|---|
| 数据分析 Agent | 数值、口径、样本量、结果引用 |
| 检索与研究 Agent | 必需来源、证据覆盖、引用一致性 |
| 工具执行 Agent | 参数、顺序、状态处理、幂等 |
| 多 Skill Agent | 路由准确率、相似 Skill 混淆 |
| 高风险写操作 Agent | 权限、审批、审计和副作用 Hard Gate |
八、总结
我从评测对象、判定机制和工程闭环三个层面，整理了一套面向 Agent 的分层评测方法。
8.1 评测对象：从最终答案扩展到完整链路
对于包含多步决策和工具调用的 Agent，更适合将一次 Run 作为基本分析单元。Run 不仅包含最终输出，还包括 Skill 路由、Tool Call、状态与错误码、产物引用和运行元数据。
因此，Completed、Correct 与 Ready for Release 应分别判定：Runtime 说明执行是否结束，Outcome 判断结果是否正确，发布门禁判断结果是否满足交付条件。
8.2 判定机制：确定性校验与语义判断分工
数值、Schema、必需工具、权限和副作用等事实性条件，适合由确定性 Validator 判断；解释完整性、证据是否支持结论等开放语义，适合由 Agent/LLM Judge 补充；高风险或存在分歧的结果再进入人工复核。
Hard Gate 独立于综合得分，可以防止关键错误被其他高分项抵消。这种分工有助于提高评测的一致性、可解释性与可审计性。
8.3 工程闭环：从判定结果到修复与回归
可执行的 Scorecard 至少应包含发布结论、失败层级、证据引用、根因和修复对象。将线上失败与人工纠正沉淀为版本化 Case，再结合统一 Trace 和发布门禁，可以形成 Case → Run → Evaluation → Fix → Regression 的持续闭环。
评测的工程价值由此从"给出分数"扩展为"支持发布决策并缩短故障修复路径"。
8.4 验证边界
我完成的是 3 个 Case、5 条 Run 的机制验证，证明分层规则、Hard Gate 和根因输出可以按预期执行；它尚未覆盖未知失败上的识别准确率，也没有完成 Decision 与 Reliability 的真实效果验证。后续需要通过历史回填、多次独立运行和人工抽样复核补充证据。
Agent 评测的核心产物不只是一个分数，而是一份包含发布结论、过程证据、失败归因和修复方向的可审计记录。
参考资料
- He, P. et al. TRAJECT-Bench: A Trajectory-Aware Benchmark for Evaluating Agentic Tool Use, 2025.
- Kuang, J. et al. Process-Level Trajectory Evaluation for Environment Configuration in Software Engineering Agents, 2025.
- Zhuge, M. et al. Agent-as-a-Judge: Evaluate Agents with Agents, 2024.
- Barke, S. et al. AgentRx: Diagnosing AI Agent Failures from Execution Trajectories, 2026.
- Wu, Y. et al. SWE-Together: Evaluating Coding Agents in Interactive User Sessions, 2026.
- Zheng, L. et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, 2023.
- Confident AI. DeepEval.
- He, P. et al. TRAJECT-Bench Reference Implementation.
有任何问题，欢迎评论区留言交流。
