[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fH2kRXGPvWwfla-ttM-_Q-A5Sbqp1PVGgz0kOOpE-N7Q":3},{"item":4,"related":51},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":39,"sourceName":40,"sourceUrl":41,"status":42,"seoTitle":43,"seoDescription":44,"canonicalUrl":45,"isFeatured":46,"sno":47,"sortOrder":48,"publishedAt":49,"updatedAt":50,"createdAt":50},"27b77799-78fa-461d-aaea-139c1d627a6c","article","Agent 结果对了就算成功吗？看懂轨迹级评测","agent-trajectory-evaluation-explained","AI Agent 可能调用多个工具、反复重试并产生外部副作用，最终答案正确不代表过程安全。本文解释 Agent trajectory 的组成，比较硬规则、Rubric、模型裁判和人工抽检，并给出一套可落地的评测流程。","评估一个普通问答模型时，很多人只看最终答案：对不对、完整不完整、有没有引用。评估 Agent 却不能只看最后一句话，因为 Agent 的过程本身就是产品的一部分。\n\n它可能先后调用搜索、数据库、浏览器和代码执行工具；可能在一个错误参数上重试三次；也可能最终给出看似正确的答案，却已经发错邮件、改错文件或产生了不可逆的副作用。\n\n## 先给结论：Agent 的“回答”其实是一条轨迹\n\n一条 Agent trajectory 通常包含：\n\n- 用户目标和初始上下文；\n- 模型每一轮的计划或动作；\n- 工具名称、参数和返回值；\n- 环境状态的变化；\n- 重试、回退、等待和错误；\n- 最终结果以及产生的副作用。\n\n如果只保存最后一段文本，很多失败原因都不可见。轨迹级评测的目标，就是把“它完成了什么”和“它是怎样完成的”同时纳入质量判断。\n\n## 最终成功不代表过程合格\n\n看下面两个轨迹：\n\n~~~text\n轨迹 A：搜索库存 → 读取价格 → 向用户展示选项 → 用户确认 → 创建订单\n轨迹 B：猜测库存 → 调用下单接口失败 → 重试不同参数 → 订单创建成功 → 最后告知用户\n~~~\n\n如果只检查“订单是否创建成功”，两条轨迹可能都被判为通过。但 B 至少有三个风险：它是否越过了用户确认？它是否可能在重试中创建重复订单？它使用的价格是否真的来自库存系统？\n\n所以 Agent 评测通常要拆成多个维度：\n\n| 维度 | 需要回答的问题 |\n| --- | --- |\n| 任务结果 | 用户目标是否完成？ |\n| 事实正确性 | 关键结论是否有可靠依据？ |\n| 工具正确性 | 是否选对工具、传对参数？ |\n| 过程效率 | 是否出现无意义循环和重复调用？ |\n| 副作用安全 | 是否越权、误操作或产生重复写入？ |\n| 可恢复性 | 工具失败后是否能安全停止或回退？ |\n\n## 评测器不应只有一个“大模型裁判”\n\nLLM Judge 对自然语言质量很有用，但不应独立承担所有判断。更稳妥的方案是混合评测：\n\n### 硬规则检查\n\n用程序验证订单状态、文件哈希、HTTP 状态码、工具调用次数、必填字段和权限范围。这类指标可重复，适合发现确定性错误。\n\n### Rubric 评分\n\n把任务拆成若干明确条目，例如“必须先查询库存”“付款前必须得到确认”“最终金额必须等于接口返回值”。模型裁判可以帮助评估解释质量，但每一项都要有可观察证据。\n\n### 人工抽检\n\n重点抽查高风险任务、评分器不确定的样本和接近通过阈值的样本。人工不是替代自动化，而是用来发现自动指标遗漏的失败模式。\n\nOpenAI 的 PaperBench 展示了一个有价值的方向：将复杂任务拆成大量可评分子任务，再用分层 rubric 评估 Agent 是否真正复现了研究工作，而不是只看最终提交物。[PaperBench](https:\u002F\u002Fopenai.com\u002Findex\u002Fpaperbench\u002F)\n\n针对网页 Agent 的 AgentRewardBench 研究也指出，仅依赖规则判断最终成功状态，可能无法准确反映轨迹质量，因此需要检查成功、副作用和重复行为等更丰富的信号。[AgentRewardBench](https:\u002F\u002Farxiv.org\u002Fabs\u002F2504.08942)\n\n## 一条可落地的轨迹评测流程\n\n~~~mermaid\nflowchart TD\n    A[定义用户任务] --> B[记录完整轨迹]\n    B --> C[重放或构造沙箱状态]\n    C --> D[硬规则检查]\n    C --> E[Rubric\u002F模型评分]\n    D --> F[聚合结果]\n    E --> F\n    F --> G[人工抽检与失败归因]\n    G --> H[更新数据集、工具或策略]\n~~~\n\n关键是先定义“什么叫完成”，再决定记录哪些轨迹。若任务涉及外部写入，最好在沙箱或可回滚环境中评测；否则一次测试本身就可能改变生产数据。\n\n## 轨迹记录也有隐私成本\n\n完整轨迹往往包含用户问题、系统指令、工具参数、文件内容和第三方接口返回值。记录越详细，越容易定位问题；但保存越多敏感信息，泄露风险也越高。\n\n可以采用分层记录：\n\n- 必须长期保存：任务 ID、工具名、状态、耗时、错误类型；\n- 短期保留：脱敏后的参数和关键结果；\n- 受限访问：完整 Prompt、原始文件和第三方响应。\n\n评测数据还要标注来源、版本和环境。否则同一个 Agent 在工具版本变化后分数下降，你无法判断是模型变了、接口变了，还是数据集变了。\n\n## 小心奖励投机\n\n当 Agent 知道评测规则后，它可能学会“通过检查”而不是完成任务。例如只返回一个看起来正确的 JSON、调用一个无害的假工具、或者在最终文本里声称已经完成但没有改变环境。\n\n因此，轨迹评测应该同时检查声明和外部事实：文件是否真的修改、订单是否真的创建、引用是否真的存在、权限是否真的满足。最终文本只能是证据的一部分。\n\n一句话总结：**评估 Agent 不能只问“最后说得对不对”，还要问“它用什么路径、付出什么代价、留下了什么后果”。**\n\n## 来源\n\n- [OpenAI：PaperBench](https:\u002F\u002Fopenai.com\u002Findex\u002Fpaperbench\u002F)\n- [AgentRewardBench 论文](https:\u002F\u002Farxiv.org\u002Fabs\u002F2504.08942)","\u002Fuploads\u002F2026-09-08\u002Fa1266ffb-4b80-4658-9839-7609abcfe70a.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31,35],{"id":24,"name":25,"slug":26},"88d2bc27-0e0f-468a-b907-2991cb97b87b","人工智能","ai",{"id":28,"name":29,"slug":30},"a2ccffe0-49b2-458b-baf6-a83a1b20443d","大语言模型","llm",{"id":32,"name":33,"slug":34},"63b56667-dcdb-4b8b-bcbe-c405143a7ec2","测评","test",{"id":36,"name":37,"slug":38},"a202d639-99a6-488a-a712-4d4c6ffd7e15","开发","dev","Agent 评测研究","AgentRewardBench","https:\u002F\u002Farxiv.org\u002Fabs\u002F2504.08942","published","AI Agent 轨迹级评测：为什么不能只看最终答案","从工具调用、重试、环境状态和副作用出发，解释 AI Agent 轨迹级评测的指标、方法和安全边界。",null,false,55,0,"2026-09-08T00:00:00.000Z","2026-09-08T03:19:27.935Z",[52,60,69],{"id":53,"type":6,"title":54,"slug":55,"summary":56,"coverUrl":57,"authorName":14,"sno":58,"publishedAt":49,"createdAt":59},"5ef7ce44-0678-40b4-95e0-af4fe8a6b0a7","提示词也能缓存：固定前缀为什么能省钱提速？","prompt-caching-prefix-kv-cache","Prompt caching 缓存的不是旧答案，而是模型处理重复提示词前缀时产生的中间状态。本文解释它与语义缓存的区别、为什么顺序会影响命中、如何整理 Agent 上下文，以及多租户场景中的隔离风险。","\u002Fuploads\u002F2026-09-08\u002F182822f9-05a3-4d2b-8766-bc5daf93effd.jpg",42,"2026-09-08T03:19:26.522Z",{"id":61,"type":6,"title":62,"slug":63,"summary":64,"coverUrl":65,"authorName":14,"sno":66,"publishedAt":67,"createdAt":68},"c17c736f-efbe-433b-ad2c-e7c9e24f6108","MCP Tasks：工具调用为什么也需要“任务状态机”？","mcp-tasks-long-running-tool-calls","MCP Tasks 为长时间运行、可轮询、可取消或需要补充输入的工具调用定义了任务状态机。本文解释任务调用与普通 tools\u002Fcall 的区别、能力协商、状态生命周期、TTL 和工程边界。","\u002Fuploads\u002F2026-09-12\u002Fc1ac67e1-5074-4faa-97c3-c3215edd0646.jpg",54,"2026-09-12T00:00:00.000Z","2026-09-12T03:56:41.060Z",{"id":70,"type":6,"title":71,"slug":72,"summary":73,"coverUrl":74,"authorName":75,"sno":76,"publishedAt":77,"createdAt":78},"d4facd11-ef4b-4f61-a556-b4defcdfe98d","语言模型中的全局工作区","global-workspace","Claude发展出了一小组内部神经模式，与它的所有其他内部处理相比，这些模式扮演着特殊的角色","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-17\u002F9b9914d4-9a89-477f-99f4-a081f4538df0.jpg","Anthropic",1,"2026-07-06T00:00:00.000Z","2026-07-17T01:25:49.821Z"]