12. Trajectory 与 Planning Evaluation
高级 Evaluator · 3～5 小时
学习目标
- 理解什么时候需要评执行轨迹
- 区分严格轨迹匹配与约束式评测
- 识别循环、冗余、违规和恢复行为
前置知识
- 第 11 章
本章产物： 为一个长任务定义 Trajectory Constraints 和 Failure Tags。
12.1 最终成功并不能覆盖过程质量
场景：
必须先获得用户确认
↓
才能执行转账Agent 如果先转账再问“确认吗？”，最终状态可能正确，但过程违反政策。
所以需要：
Outcome Eval + Trajectory Eval12.2 不要过度规定“唯一正确路径”
错误：
expected:
search → read → calculate → answer实际另一条路径：
read cached data → calculate → answer也可能完全正确。
更好的方式是约束：
must:
- verify_permission before transfer
must_not:
- use_admin_tool
max:
tool_calls: 1212.3 Trajectory Event Model
建议统一事件：
Message
ToolCall
ToolResult
StateChange
Retry
Approval
Error
SubAgentStart
SubAgentEnd
Artifact这样 Evaluator 不依赖某个 Agent Framework 的内部对象。
12.4 典型指标
Loop Rate
连续重复相同/等价动作。
Redundant Tool Call Rate
可复用已有信息，却重复请求。
Policy Violation
动作顺序或工具违反政策。
Recovery Success
故障后是否进入正确替代路径。
Progress
是否逐渐接近目标。
12.5 Planning Quality 的陷阱
不要把“写出来的计划看起来漂亮”当作规划能力。
真正的 Planning Eval 应关心：
- 计划是否可执行；
- 是否覆盖关键约束；
- 是否在环境变化后更新；
- 计划与动作是否一致。
12.6 Trajectory Judge
当规则难以编码时，可以用 Judge 看：
- 是否绕路；
- 是否忽略明显证据；
- 是否合理恢复。
但必须给 Judge 结构化事件和明确 Rubric，而不是整段超长 transcript + “请打分”。
12.7 Failure Attribution
建议 Failure Taxonomy：
goal_understanding
planning
tool_selection
argument_grounding
tool_execution
result_interpretation
policy
recovery
loop
answer
environment一条 Run 可以多标签。
12.8 验收问题
- 为什么不应要求唯一 Expected Trajectory？
- 哪些过程要求应该写成 Hard Constraint？
- 计划文本与真实 Planning 能力有什么差别？