传统模型评测，经常只看最终输出。
但 Agent 的问题在于，最终输出只是整个过程的最后一层表象。
如果只看结果，你会漏掉大量系统性错误：
- 工具调用路线错了
- 参数提取错了
- 状态在中途污染了
- 升级时机错了
- 审批链路被跳过了
因此，Agent 评测必须从“结果评测”升级成“轨迹评测”。
轨迹评测的意思是，不只问最终答案对不对，还要问：
- 它是怎么走到这个结果的
- 中间每一步是否合理
- 哪一步开始发生偏移
- 偏移后是否有自我修正
这会把评测从“像不像”变成“到底发生了什么”。
但第 29 章真正要强调的，不只是多记几条日志。
更根本的变化在于：当对象从“单次回答”变成“多步执行系统”之后，评测的对象本身已经变了。
过去很多评测，默认对象是输出。 现在 Agent 评测的真实对象，其实是策略。
也就是说，我们真正想知道的，不只是它最后有没有得到一个可接受结果，而是它在面对观察、状态、工具和约束时，是否沿着一条可靠、稳定、可解释、可恢复的路径行动。
所以，第 29 章第一条结论应该是：
Agent 评测的核心对象，不再只是最终答案，而是生成这个答案的整条执行轨迹。只要理解了这一点，就会立刻明白为什么“只看结果”会系统性误判。
第一种误判，是幸运成功。
系统可能最后答对了，但中间路径一塌糊涂。它也许调错了若干工具，误用了若干参数，跳过了本应经过的校验，最后靠偶然命中了正确结果。若只看最终答案，这种系统会被误判为可靠；一旦环境稍有波动，它就会立刻崩掉。
第二种误判，是隐藏失败。
系统可能最后看起来可接受，但中途已经发生了危险偏移，例如读取了不该读取的内容、跳过了审批、把污染状态写回了 memory、在错误前提上继续规划。用户如果只看到最后一句话，甚至根本意识不到系统已经越界。
第三种误判，是错误归因。
当一个任务失败时，只看最终结果很难知道问题究竟出在模型推理、工具选择、参数组装、状态污染、环境噪声，还是恢复逻辑。没有轨迹，就无法定位偏移起点；无法定位偏移起点，就无法真正修系统。
第四种误判，是恢复能力被忽略。
真实 Agent 系统不可能每一步都对。一个成熟系统的重要能力之一，是在发现中间偏移后回退、改道、重试、升级或求助于人。只看最后结果，你看不到它是“一路正确”还是“中途失误后成功修复”。但这两种系统的工程价值完全不同。
所以，轨迹评测的意义，不只是“多看一些中间信息”，而是把评测单位从结果样本升级为行为样本。
因此，第 29 章第二条结论应该是：
对 Agent 来说，结果是否正确只是一个指标；路径是否可靠，才决定这个结果能不能被持续复现。一旦进入这个视角，评测维度也会发生明显变化。
以前很多团队会主要看：
- 最终答对率
- 用户满意度
- 输出格式是否正确
这些指标当然仍然重要，但已经不够。
Agent 系统至少还要补上六类轨迹指标：
- 每一步决策是否符合上下文
- 工具是否在正确时机被调用
- 参数和 schema 是否被正确组装
- 状态是否被正确读取与写入
- 异常后是否采取了合理恢复动作
- 全程是否遵守审批、安全和权限约束
只有这样，评测才真正贴近系统的真实运行逻辑。
这也是为什么今天越来越多官方文档和生产框架开始强调 tracing、trace grading、session replay、offline replay eval、online eval 和 LLM-as-judge。它们不是因为“可观测性很流行”，而是因为如果没有轨迹，你根本无法规模化理解 Agent 在做什么。
这里还要再往前走一步。
轨迹评测的价值，并不只在 debug，更在迭代。
一个团队如果只有结果评测，那么它的改进方式通常会非常粗糙：换模型、加提示词、加样本、再看整体成功率有没有上升。这样做往往成本很高，而且很难知道为什么变好了或为什么变差了。
但如果有轨迹评测，团队就可以开始做更精细的改进：
- 单独看工具选择是否退化
- 单独看某一步参数提取是否变差
- 单独看某类任务里审批是否经常被跳过
- 单独看某个恢复策略是否确实降低了失败扩散
换句话说，轨迹评测把“整体运气”拆成了“局部能力画像”。
这一步，恰恰是 Agent 能否真正工程化的分水岭。
因为工程化不只是让系统跑起来，而是让系统可以被诊断、被比较、被回归测试、被稳定改进。没有轨迹，很多改动都像在黑箱上敲一下再看看灯亮不亮；有了轨迹，团队才能知道到底是哪一个齿轮出了问题。
当然，这并不意味着最终结果不重要。
真正成熟的做法，从来不是用轨迹评测替代结果评测，而是把两者叠起来：
- 结果评测回答“用户最终得到了什么”
- 轨迹评测回答“系统究竟是怎么做到的”
前者决定用户感知，后者决定系统可运营性。
所以，本章最后要落下的判断是：
如果结果评测回答的是“这次像不像成功”，那么轨迹评测回答的才是“这个 Agent 是否值得被持续信任和持续放量”。