轨迹评估——评判过程，而不只是评判答案
对 agent 而言，只看最终输出的打分会漏掉大多数失败：agent 可能靠一条不可接受的路径撞出正确答案（跳过了验证、把一个付费 API 调了 40 次、把数据泄露给了某个工具），也可能在每一步都表现完美的情况下仍然失败。基于轨迹的评估记录完整的运行轨迹——每一次工具调用连同参数和结果，每一步中间推理——评判的是这条路径：
- 工具选择是否正确——在每个节点是否调用了对的工具（该查数据库时就查，而不是凭空编出答案）？
- 参数是否有效——逐次调用做 schema 校验（轨迹内部的一个确定性打分器）。
- 步骤效率——实际步数相对参考解的对比；绕路和循环是一个指标，不是一则轶事。
- 端到端任务完成度——一个裁决型 judge 通读整条轨迹，对照任务的 spec 打分（用户的目标是否达成，且副作用可接受？）。
基础设施与竞技场
LangSmith、Langfuse（开源）、Arize Phoenix 会持久化每一条生产轨迹和评估轨迹——可回放、可标注、可转化为 golden case。公开的 benchmark 提供了经过校准的竞技场：τ-bench（带模拟用户的客服类工具 agent）、SWE-bench（仓库级代码修复）、OSWorld 一类的电脑操作套件。模拟用户环境很关键：多轮 agent 无法用固定的单次输入来评估。
与 um 的关系： um 里与轨迹对等的东西是ledger entry——那些被声明的组成部分（T/C/A/K/J/P/I/M/S）就是一份结构化的轨迹 schema：scout 的输出、context manifest、draft、checks、verdicts、publish token，全部被提交记录。um 用确定性方式（lint）和对抗性方式（T1）审计这份轨迹。um 目前还没做到的，是对编排本身打分（哪些子 agent 跑了、每个花了多少、循环在哪里绕了远路）——2026-07-18 加入的 loop-metering 规则正是朝这个方向迈出的第一步。
来源: evals 主流实践（Confident-AI agent-eval 指南、LangSmith/Langfuse/Phoenix 的 tracing、τ-bench/SWE-bench，2026-07 的一次现状盘点）