浅谈 Agent 系统设计之轨迹与过程
以 SWE 任务为例，介绍 Agent 强化学习中的结果奖励、过程奖励与自动标注方法，并讨论执行轨迹的行为分析和评估指标。
目录
Agentic Reinforcement Learning
Agentic Reinforcement Learning，就是让 Agent 尝试完成任务，根据表现获得奖励，再用这些反馈训练模型。以软件工程（SWE）任务为例，Agent 搜索代码、修改文件、运行测试，学习哪些操作更有帮助。一次任务留下的工具调用和返回结果，就是一条执行轨迹。
面向结果的奖励
结果奖励只评价最终是否完成任务。例如，Agent 提交修复补丁后，系统运行验收测试，通过就奖励，没有通过就不奖励。这种方式比较直接，但也有一些局限：
- 金标：需要可靠的评价依据，例如验收测试或人工确认的正确修复。修复可能有多种写法，不必与参考补丁完全一致。
- 稀疏：一次任务可能调用几十次工具，却只在最后获得一次反馈，中间有没有进展难以体现。
- 信用错配：成功轨迹里的无效操作可能一起被鼓励，失败轨迹中有用的定位和调查也可能被忽略。
- 误差传播：早期理解错了问题，会影响后续修改和验证，直到最后才发现整条路径有问题。
- 学习低效：模型需要反复尝试才能获得成功样本；如果都没做成，最终结果也难以区分哪些尝试更接近完成。
面向过程的奖励
过程奖励进一步评价中间步骤有没有帮助，例如是否成功复现 Bug、找到关键代码、修复部分测试。这些判断可以由规则和执行结果给出，也可以交给模型。专门学习评价中间步骤的模型，叫过程奖励模型（Process Reward Model，PRM）。
- 信号密集：搜索、阅读、编辑和测试等步骤都可能提供反馈，帮助模型区分有效进展和无效尝试。
- 标记成本高：评价一步操作，需要理解问题、此前的历史和工具结果，比只检查最终补丁更费力。
- reward hacking：Agent 可能利用评分规则获取奖励。例如“读文件就加分”，可能鼓励它反复阅读，却没有推进任务。
- 噪声：中间步骤不总是容易判断。复现 Bug 时测试失败可能是好事，命令执行成功也可能没有帮助，模型评审同样可能误判。
自动标记方法
为了减少人工逐步标注的成本，SWE 中可以借助代码环境自动收集评分依据：
- 比较执行结果：检查修改前后修好了哪些测试、是否引入新的失败，也可以观察编译和类型检查错误的变化。SWE-MILE就利用中间测试状态的变化分配奖励。
- 比较不同选择：保存相同的仓库和对话状态，尝试不同操作，再继续执行，比较最后谁更容易完成任务。CRR采用了这种思路，代价是需要额外执行。
- 提炼关键里程碑：从参考补丁整理出需要发现的代码事实、根因和验证步骤，再检查轨迹是否通过工具结果取得了这些进展。P2T用这类信息整理训练轨迹。
- 使用启发式和模型评审：根据首次读取相关代码、重复操作、测试结果等规则生成标签，也可以让模型检查结论是否有证据。SWE-Shepherd就用动作启发式生成的标签训练 PRM。
这些信号可以直接用于训练，也可以收集成“任务上下文、操作、对应评价”的样本，让 PRM 学习评分。最终仍要检查 Agent 是否更容易解决问题，而不能只看中间分数是否更高。
轨迹分析
轨迹分析是把一次任务的执行过程展开，观察 Agent 怎样收集信息、修改代码、验证结果，以及错误如何发生和恢复。即使最终都通过验收，有的过程仍可能包含大量重复试错或缺少验证。AgentLens就进一步分析了成功轨迹之间的过程差异。
观察行为模式
分析前，先把轨迹按实际用途分成定位、修改、验证和环境处理，再关联每一步的工具输出、文件状态和资源消耗。同一个 Bash 工具既能搜索，也能编辑或测试，不能只按工具名称判断它在做什么。
- 阶段分布与顺序：分别统计各阶段的步骤、耗时和 token 占比，观察是否在了解代码后修改、最后一次修改后验证，以及是否反复在几个阶段之间切换。
- 探索与重复：观察访问了多少不同文件、重复了哪些动作、循环持续多久。Graphectory用独立动作数、循环次数和导航广度等指标描述这些特征，但它们本身不能说明探索是否值得。
- 证据与错误链：检查工具结果有没有影响后续操作，结论是否有证据支持，以及最终报错能否追溯到更早的错误判断。Thought-Action-Result 研究提供了把可见计划、实际动作与返回结果联系起来的分析方式。
- 工具与环境故障：分别记录工具格式或参数错误、环境异常，以及正常执行测试后发现的代码错误。这些情况的处理办法不同，不应仅凭非零退出码合成一个“调用失败率”。
选择评估指标
在独立验收的任务解决率之外，还可以观察以下九类指标：
- 任务进展与回退：统计已完成的子目标、修复的失败测试和新增回归，同时关注进展是否被后续修改破坏。AgentBoard提供了衡量中途进展的思路。
- 有效、中性与有害步骤：区分推进任务、合理探索和有害操作，统计各自的数量与占比。AgentProcessBench也提醒，提前结束可能抬高正确步骤占比，不能只看这个比例。
- 冗余步骤与浪费成本：统计相同状态下没有新增信息的重复操作，以及它们消耗的时间和 token。必要试错、正常轮询和有效回滚应单独识别。
- 最终版本验证率：在有代码修改的任务中，统计多少实际验证了最终提交的版本，并保留测试范围与结果。仅出现测试命令，不代表真正完成了验证。
- 错误发现与恢复：记录错误暴露、被识别和被修正的位置，观察恢复需要多少步。Wink研究的局部恢复，还应与出错后的最终任务成功分开统计。
- 需求与约束遵守：统计遗漏明确要求、进行未请求修改或其他违例的任务占比。ToolSandbox同时检查必须完成的目标与不应发生的事件。
- 资源效率：记录耗时、token 和费用，在相同预算下比较解决率。计算每次成功交付的成本时，也要计入失败尝试的消耗，可参考 HAL的成本与效果比较。
- 人工纠偏负担：统计每次任务需要多少次人工纠错、重申要求或接管。正常的需求澄清和必要授权应单独记录。
- 重复运行可靠性：在相同任务与预算下重复运行，检查能否持续成功。τ-bench强调，“多次都成功”与“多次里成功一次”是不同的能力。
比较时应固定任务、环境和预算，并单独记录超时、异常和未验收的任务。步骤更多、探索更多或路径不同，都不能直接说明过程更差；需要模型判断的部分，可以抽样交给人工核对。