Trajectory Review 是一个面向智能体运行质量审查的技能。它强调：通过的结果可能掩盖脆弱的流程，例如某个假设恰好成立、一次幸运的重试，或者本可两步完成却花了十次往返；而失败的结果，其根因通常出现在报错之前的若干步骤。因此，审查应关注路径本身，而不只看终点。
主要能力与使用方式：
-
获取真实轨迹。使用运行的实际记录，例如会话转录、工具调用日志或评测 trace，并记录模型、设置与仓库状态。文档明确要求不要凭记忆重建运行过程。
-
逐步走查。构建紧凑时间线，对每一步记录：智能体的意图、调用的工具及关键参数、返回内容、以及随后做出的决定。走查过程中需要标记以下几类问题：未经验证的假设，即智能体陈述或基于从未检查过的事实行动；绕路，包括循环、反复更换关键词搜索、重复读取同一文件、不改变思路的重试；工具或参数错误，包括找不到工具；上下文浪费，例如拉取大量输出却从未使用、以轮询代替等待通知；被忽略的信号，包括看到却未处理的错误、警告或测试失败；指令漂移，即早先的约束在后续被打破，常见于上下文压缩之后。
-
定位最早出错点。对于失败，找出成功概率开始显著下降的最早步骤；对于通过，找出风险最高的步骤，即输入稍有不同就可能失败的环节。
-
将发现转化为修复。文档给出映射关系：从未检查的假设可通过技能或项目规则中的验证步骤修复；找不到或选错工具可通过改进工具描述、命名或分组修复，并提及 tool-budget-audit；丢失早先约束可写入智能体会重新加载的文件，并提及 long-session-check；轮询或空等可改用带通知的后台任务，并提及 long-command-check；每轮重复开销可通过上下文注入审查处理，并提及 context-tax-audit；模型能力限制则记录在案，待下次模型升级后复查。文档还提醒，不要把一次性怪癖写入项目级规则，只有重复发生或造成实际损害的问题才值得提出规则。
-
确认修复。修复属于 harness 变更，应通过 harness-experiment 验证：多次重跑同一任务并比较轨迹，而不只是比较结果。
适用场景：智能体评测复盘、失败根因分析、上下文与工具使用效率审查、项目规则和技能改进。
限制与缺失信息：该资料未提供具体安装命令、平台要求、收费方式或量化指标；相关细节暂未提供。