同一个任务，要求 Agent 搜索某个 API 的最新用法并写成摘要，可能跑出三条轨迹：

search -> summarize
search -> read -> summarize
webfetch -> summarize

哪一条才算对？

答案可能是，三条都对。只要 Agent 读取了权威来源，先拿到证据再写摘要，最终引用了官方文档，就没有必要规定它必须调用同一个工具、走同一条路径。

如果评测只认一条预先写死的 golden path，两次本来合理的执行会被误判失败。可如果完全不看过程，只验收摘要，又可能放过没有读取来源、直接凭记忆生成的答案。

这个小例子把 Agent 评测里最关键的对象暴露了出来。

评测的最小单元不是 prompt，而是一次完整的 task run。

从 prompt 到 task run，评测对象变大了

一次 prompt 只描述模型收到的一段输入。一次 task run 则要装下用户目标、输入、成功标准、运行环境、可用工具与权限、执行 trace、最终结果和评分。后面讨论 Context、Plan、Tool、State、Memory、安全和回归时，都要回到这个完整单元，看模块怎样影响任务成功，以及证据能不能证明它没有破坏任务。

可以把 task run 想成一个证据盒。盒子里不是只有答案，而是一组彼此有关联的对象：

• Task，用户目标、输入、约束和成功标准，通常由 case、task brief 与 rubric 留证。
• Context，当前任务可见的 prompt、文件、检索片段和 memory。
• Plan，中间步骤与执行策略，可从 plan message、todo 和 stage plan 中检查。
• Tool Call，工具名、参数、返回、错误和权限，证据来自 tool span 或 tool ledger。
• Observe，工具返回后模型实际看到的事实，例如 stdout、stderr、API result 或 observation 摘要。
• State，本次任务的进度和中间结果，需要 state snapshot 与 checkpoint。
• Memory，跨任务保留的信息，例如 CLAUDE.md、memory record 和 memory diff。
• Result，最终回答或业务状态，包括 answer、artifact、diff 和 report。
• Score，自动评分与人工复核，通常落在 score JSON 和 review note。
• Trace，用 trace id、span id 和 artifact refs 把这些对象串成可复盘的证据链。

这些对象的边界很重要。Context 是这一步能看到什么，State 是这次任务进行到哪里，Memory 是哪些信息会跨任务留下来。混在一起记录，问题出现时就很难判断是信息选错、进度丢失，还是旧记忆污染。

同一次运行，要从八个层级看

证据盒装的是对象，指标回答的是怎样评价这些对象。一个总分很容易掩盖问题，所以总指标模型可以拆成八层：

• 任务级看任务是否完成，例如 bug 是否修复、报告是否生成、工单是否关闭。
• 结果级看输出的正确性、完整性、格式、引用和业务约束是否达标。
• 轨迹级看过程是否合理，例如有没有先收集证据、有没有验证、是否明显绕路。
• 工具级看工具是否正确、安全、有效，包括工具选择、参数和结果使用。
• 状态级看任务进度是否一致，例如有没有重复执行或丢失 checkpoint。
• 记忆级看跨任务信息是否正确使用，也就是该记的记住，不该记的不写入。
• 安全级看是否发生越权、泄露或注入，包括 prompt injection、tool output poisoning 和过度代理。
• 成本级看 token、耗时、重试次数和失败率是否可接受。

同一条运行完全可能出现「任务级通过，安全级失败」。也可能结果正确、工具调用略多，因此只扣成本分而不判任务失败。分层的价值正在这里，团队看到的不是一个模糊的高低分，而是问题落在哪个对象、哪个层级。

反过来看，很多所谓 Agent 失败，其实是评测定义先出了问题。Task 没写清什么算成功，case 和 rubric 就无从判断；最终答案看着正确却没有引用工具结果或业务状态，这是 grounding 证据缺失；只统计工具调用数量，会把必要探索误判成低效；人工判断没有 rubric，评分也无法复现。

最常见的两个极端，一个是只看最终答案，危险调用和越权读取全部隐身；另一个是把黄金路径写得过死，多条合理轨迹反而被判错。

Agent 评测要约束关键节点，不要规定每一步脚印。

Trace 不是录像，而是可查询的事件模型

为了让不同模块的证据能对齐，可以先约定一个简单的统一模型：

trace = one task run
span = one meaningful operation

一次完整任务对应一个 trace，一次有意义的操作对应一个 span。常用 span 类型包括：

• context.load
• plan.create
• tool.call
• tool.observe
• state.update
• memory.read
• memory.write
• permission.decision
• checkpoint.create
• failure.recover
• score.compute
• review.human

每个 span 至少记录 span_id、parent_span_id、type、start_time、end_time、status、input_ref、output_ref、error、cost 和 evidence_ref。

有了父子关系和证据引用，测试人员才能回答一组真正有用的问题。摘要之前读了什么？工具报错后是谁触发了重试？某次 state update 依据哪条 observation？最终结论又引用了哪份 artifact？

Trace 的作用不是逼所有 Agent 走同一条路，而是让每一条被接受的路都能说清依据。

评分规则，要适配开放轨迹

一套实用的评分通常由三部分组成：

1. 规则评分，检查格式、字段、工具参数、权限和测试是否通过。
2. Rubric 评分，判断开放结果、计划质量、解释质量与轨迹合理性。
3. 人工复核，处理高风险样本、争议样本和裁判低置信度样本。

对 Agent 任务，不建议把「最终答案相似度」当作主指标。更稳的方式，是把任务拆成关键检查点：

• 是否拿到必要 Context。
• 是否制定合理 Plan。
• 是否调用必要工具，并避开禁止工具。
• 是否正确解释工具返回。
• 是否完成验证。
• 是否在失败时停止或恢复。

检查点可以约束先后关系，也可以设置必须出现和禁止出现的证据，却不用指定唯一序列。这样既容纳 Agent 的路径多样性，也没有放弃可验证性。

样本集要让每个对象都有机会出错

只有正常成功样本，很难验证这套指标能不能归因。第一批数据可以按风险铺开：

• 正常成功样本，验证主流程能力。
• 困难样本，覆盖长上下文、多步骤和模糊目标。
• 负例样本，验证 Agent 会拒绝不该做的事。
• 工具失败样本，覆盖超时、空结果和权限不足。
• 状态恢复样本，覆盖中断、resume 与 checkpoint。
• 记忆污染样本，验证旧任务不会影响新任务。
• 安全边界样本，覆盖 prompt injection、越权和泄露。
• 成本压力样本，验证 token、turn 和预算限制。

这些样本跑完后，失败应当能归因到模型、工具、数据、权限、状态或流程，而不是只留下一句「Agent 没做好」。

再看那三条 API 搜索轨迹

回到开头。这里不该固定唯一 golden path，更合理的是定义四类约束：

• accepted trace pattern，必须出现权威来源读取。
• partial order，摘要必须发生在读取证据之后。
• must-have evidence，最终答案必须引用官方文档。
• cost-risk scoring，多余搜索可以扣成本分，但不直接判失败。

这样评测的就不再是 Agent 有没有模仿某条标准动作，而是它有没有在明确约束下完成任务，并留下足以证明结果的证据。

落地前再核对一次，task run 是否真的是评测单元，成功标准是否写进 rubric，八层指标是否分开，tool call 与 observation 是否都保留，多条合理轨迹是否被允许，人工复核与裁判校准是否有入口。

这些定义站稳以后，后面的上下文、规划、工具、状态、记忆、安全和回归，才不会停留在概念解释，而能继续落到样本、span 字段、评分规则和发布准出。