长程 Agent 为什么会失效：数据、训练与评估

Agent 经常出现一种反差：单步看起来很聪明，任务一长却会逐渐失去方向。它可能正确读懂每一次报错，却在几十轮之后忘记最初目标；也可能已经找到关键文件，却始终做不出正确修改。

这篇接着组件和中控系统两篇往下写。和单次代码生成相比，能不能完成一个长任务更接近真实工程的要求。很多失败并不是模型不会写那几行代码，而是它在前面读错了文件、保留了过期信息，或者没有把测试反馈转成下一步动作。

这类任务通常需要几十甚至上百次“观察—行动—反馈”，研究中称为长程任务（Long-Horizon Tasks）。旅行规划、网页操作和科学调研都有这个问题，代码开发尤其典型：一次仓库级修复往往要经过定位、阅读、修改、测试和多轮回退，而且结果还能用编译器和测试客观验证。

图 1：代码 Agent 修复 Bug 时的多轮调试循环。

下面围绕四个问题整理近期工作：训练轨迹从哪里来，模型怎样从长序列中学习，运行时如何控制风险，以及失败后怎样定位出错的步骤。文中引用的多数是 2025—2026 年的 arXiv 预印本，数字均为论文自己报告的结果。

长任务为什么容易失控

任务变长后，麻烦不只是上下文变长，至少还有三个问题：

误差会沿轨迹传播：控制变量研究表明，只增加完成任务所需的步数，就会让训练更不稳定 ¹。如果把每一步粗略看成独立事件，单步成功率为 $p$，连续 $N$ 步都正确的概率是 $p^N$；当 $p=0.95, N=50$ 时只有约 $7.7\%$。真实任务当然并不独立，也允许纠错，但这个简单计算解释了为什么早期误判会迅速放大。
上下文会被旧信息占满：如果每次工具返回、完整报错和重复文件内容都留在 Prompt 里，Token 成本会持续增长，关键证据反而更难找到 ²。代码 Agent 反复读取大文件、保存多轮 traceback，就是很常见的上下文浪费。
最终分数无法解释中间过程：Agent 执行几十步后只收到“测试通过/不通过”，训练系统很难判断是哪一个决策造成了结果。这就是奖励稀疏和信用分配问题：最终反馈是可靠的，却不足以指导每一个中间动作 ¹³。

轨迹数据：真实、多样，还要能验证

训练长程 Agent 缺少高质量的多轮演示数据。以代码场景为例，SWE-bench 提供的是真实 PR 的最终补丁，并不包含工程师从定位到验证的完整过程；要人工录下一条这样的修复轨迹，往往要花几个小时。近期工作主要从数据合成和数据处理两头想办法。

让轨迹来自真实执行

ISE（Intent → Simulate → Execute） ⁴：很多合成数据里的工具返回是模型想象出来的，没有经过真实环境。ISE 面向操作系统 Agent，分三步生成数据：先按用户画像、领域、任务和复杂度四个维度采样出约 5 万个结构化意图；再用一个角色锁定的用户模拟器驱动多轮对话，每一轮用户发言都基于实际执行结果；最后在隔离的真实 OS 工作区里执行每一次工具调用。这样得到的轨迹保留了真实的失败和恢复过程，而不是模型编出来的工具输出。
WRIT（读写密集型轨迹合成） ⁵：WRIT 面向需要和用户多轮交互的 Agent。它的出发点是，很多合成管线靠拼接多个用户请求来加长任务，训练的是按顺序执行多次写操作；但单次写操作本身也可能很难，因为 Agent 要先读取、比对大量工具返回的证据，才能确定参数。WRIT 同时控制两个维度：一个任务里写操作的数量，以及每次写操作需要的证据量。代码 Agent 也有类似情况：一次修改之前，往往要在多个文件之间跳转阅读、理解调用链。

切分超长轨迹

KLong 的轨迹切分 SFT ⁶：针对“复现一篇科研论文”这类耗时很长、动辄数百步的任务，KLong 把一条轨迹切成多个子序列：保留早期的任务描述等关键上下文，逐步截断较晚的历史，相邻子轨迹之间保留重叠。这样模型可以在标准上下文窗口内学习极长的轨迹。需要注意的是，作者已申请撤回这篇论文，理由是数据中发现了影响结论的严重错误；这里只介绍切分思路，不引用它的实验结果。

统一数据格式

Agent Data Protocol (ADP) ⁷：各家 Agent 数据集的格式、工具接口各不相同。ADP 提出一种轻量的中间表示，把不同格式的数据集统一起来，再转换成下游训练框架需要的格式，目标是降低跨数据集混合训练的转换成本。

合成多样但可验证的数据

另一条路线是从少量已验证的种子轨迹出发，通过可验证的机制批量合成多样化的训练数据。这对代码 Agent 尤其有意义：一条成功修复 Bug 的轨迹，改变 Bug 的触发条件、目录结构或依赖版本，就能派生出结构类似但细节不同的样本。

TDScaling（轨迹多样性缩放） ⁸：论文报告，在固定训练预算下，提高轨迹多样性比增加轨迹数量收益更大。它用领域熵（覆盖了多少不同的业务场景）、推理模式熵（是否覆盖了检索、编辑、执行等不同动作模式）和累积动作复杂度衡量训练集的多样性，再通过自适应演化机制往长尾场景合成数据。实验覆盖通用工具调用基准（BFCL、τ²-Bench）和编码任务（SWE-rebench 等），多样性缩放达到的性能上限高于数量缩放。
COVERT（可控可验证工具调用合成） ⁹：COVERT 的核心是保真变换（Oracle-Preserving Augmentation）。给定一条已验证的基础轨迹，它对环境施加三类扰动：(1) 在工具列表中加入无关的干扰工具，模拟真实 MCP Server 中工具很多的情况；(2) 把用户查询改写得更间接，比如把“删除 user 表中 id=5 的记录”改成“帮我清理那个刚注册但没验证邮箱的用户”；(3) 在工具输出里加入格式噪声，如多余的空行、不规范的 JSON。扰动过程中参考答案保持不变，奖励可以通过确定性匹配自动计算，不需要额外的人工标注。
LOGIGEN（逻辑驱动的可验证任务生成） ¹⁰：LOGIGEN 用三个 Agent 协作合成任务：Architect 把自然语言业务规则编译成数据库硬约束（如“余额不足时不得转账”）；Set Designer 初始化容易触发规则冲突的边界状态；Explorer 在这个环境中搜索因果解路径。任务是否完成，通过比较期望的数据库状态和实际状态来判断，不依赖 LLM 打分。在 τ²-Bench 上，LOGIGEN-32B(RL) 的成功率为 79.5%，基础模型为 40.7%。
AgentHER（失败轨迹的后见重标注） ¹¹：思路来自强化学习中的 Hindsight Experience Replay：没有完成任务 A 的轨迹，换一个目标看，可能是完成任务 B 的正确示范。比如 Agent 本来要修复模块 A 的 Bug，却修改了模块 B 的代码，这条轨迹作为“修复模块 A”的数据是失败的，作为“修改模块 B”的示范却可能成立。AgentHER 用四个阶段（失败分类、结果提取、LLM 引导的重标注、数据打包）把通常被丢弃的失败轨迹（约占收集数据的 60%–75%）转成 SFT/DPO 训练数据。在 WebArena 和 ToolBench 上，它比只用成功轨迹做 SFT 提升 7.6%–11.4%，只用一半成功示范就能达到原来的效果。
图 2：AgentHER 的数据重标注管线，把失败轨迹转成可用的训练数据。
LATR 与 MARTI（在 Rollout 中分叉探索） ¹² ¹³：训练阶段的标准做法是让模型自由采样整条轨迹，但采样结果很容易同质化，比如模型总用同一种策略解题。LATR 在模型不确定的步骤（按 token 级 entropy 判断）强制分叉，往后多模拟几步，再用归一化编辑距离剪掉和已有分支过于相似的路径。在数学和逻辑推理任务上，LATR 让策略学习平均加快 131%，pass@1 平均提升 4.2%。MARTI-v2 引入多 Agent 协作的蒙特卡洛树搜索（MCTS），通过自适应节点扩展系统地探索解空间，论文报告它缓解了训练后期的性能饱和。

方法	核心思路	多样性来源	验证机制
TDScaling	多样性优先于数量	领域熵 + 推理模式熵 + 动作复杂度	沙盒执行
COVERT	保真环境扰动	干扰工具 / 间接查询 / 噪声输出	参考答案确定性匹配
LOGIGEN	逻辑驱动正向合成	边界状态初始化 + 因果路径搜索	精确状态等价检查
AgentHER	失败轨迹目标重标注	后见目标替换	跨模型多 Judge 验证
LATR/MARTI	训练期树搜索分叉	不确定性分支 + 多 Agent 探索	可验证奖励（RLVR）

后训练：先学会，再探索

SFT 打基础，RL 找上限

SFT 和 RL 应该串行还是混合，目前没有对所有任务都成立的答案。一项近期工作给出了比较系统的对比：

Plasticity-Ceiling 框架 ¹⁴：论文把最终性能上限拆成两部分：SFT 打下的基础性能，以及之后 RL 还能带来的提升空间（称为可塑性）。在数学推理任务上的实验显示，先 SFT、后 RL 的串行流程优于把两者同步混合的方案，后者的问题是训练不稳定、容易过早收敛。最佳切换点是 SFT 验证损失进入饱和（稳定或轻度过拟合）的阶段。这个结论来自数学推理，放到 Agent 任务上还需要验证。
调整环境而不只是模型 ¹⁵：除了微调模型，还可以调整训练环境：用课程式的难度安排、能给出纠正性反馈的环境增强，以及细粒度的进度奖励，让 Agent 在没有专家轨迹的情况下也能稳定探索。放到代码 Agent 上，进度奖励可以是：定位到目标文件（虽然没修好）给部分奖励，通过一部分测试用例也给部分奖励。

给不同质量的轨迹分配权重

合成的长轨迹质量参差不齐。有些虽然最终成功了，但路径非常冗余，比如绕了很多弯路才找到文件；有些包含错误的中间步骤，却恰好通过了测试。不加区分地混在一起训练，模型会被低质量数据带偏。

BOOST 双层优化框架 ¹⁶：内层在加权后的合成轨迹上训练模型（标准的 offline RL 目标）；外层在真实的少量验证任务上训练一个轻量的重加权头，为每条轨迹输出训练权重。两层交替更新后，BOOST 会给高质量轨迹更高权重、压低低质量轨迹的影响，不需要外部大模型来当质量裁判。

把搜索放进 Rollout

在线强化学习的标准做法是让 Agent 对每个 prompt 独立采样一条完整轨迹，再计算奖励和梯度。环境有随机性、奖励又稀疏时，朴素采样容易卡住（Agent 在错误状态反复重试）或模式崩溃（总是采到相同的路径）。

TSR (Trajectory-Search Rollouts) ³：它把测试期搜索放进训练 Rollout。在每个 action step，系统采样 $k$ 个候选动作，分别执行并读取环境反馈，再根据 step-level reward 选择分支继续，近似在状态空间中进行浅层 beam search。搜索改变的是训练数据分布，不要求替换底层策略优化器。论文报告其在 WebShop、Sokoban 等任务上最高带来约 15% 提升，但代价是每一步都要执行更多候选动作。

运行时：控制风险，保留经验

当多轮 Agent 获得文件删除、代码推送或数据库写入权限后，安全监控和记忆管理就不再是附加功能，而是运行条件。

提前发现过程风险

长轨迹中的危险操作往往是组合出来的：单独看每一步都是合法的 API 调用，连起来却构成一次未授权操作。只检查当前这一步的拦截机制（比如只看有没有敏感关键词），在长任务里很容易漏掉这类风险。

TRACES ¹⁷：TRACES 用两阶段结构做安全审计。Compressor 从观察者大模型的隐藏层表示中提取每一步的风险特征；Reader 是一个轻量的 GRU，对这串特征做时序建模，输出截至当前步的累积风险分数。它的关键设计是弱监督：不需要逐步的安全标注，只需要知道整条轨迹最终是否造成危害，就能学会在轨迹早期估计风险。在代码场景中，这意味着当 Agent 开始组合 chmod 777、curl 外部地址、bash -c 这类操作时，系统有机会在最终的恶意命令执行前预警。在 ATBench 上，TRACES 把早期风险排序指标 EAUPC 从最强基线的 62.9 提升到 82.2。
图 3：TRACES 的前瞻性安全预警结构，基于隐藏层特征和时序建模估计早期风险。

给上下文减负

AgentDiet ²：交互轮数增加后，上下文里会堆满没用、重复和过期的信息，比如已经修复的旧报错、前几轮读过且没有变化的文件内容。AgentDiet 在 Agent 运行过程中自动删掉这些内容。在一个代码 Agent 上的实验显示，任务表现保持不变，输入 token 减少 39.9%–59.7%，总计算成本降低 21.1%–35.9%。

从轨迹中提炼经验

代码 Agent 的很多操作是重复的，比如“遇到 import error 时先检查依赖版本、再检查虚拟环境”这类调试套路。每次都从零推理，既浪费算力，也丢掉了已有经验。

H-EPM 框架 ¹⁸：它把情景记忆和程序记忆结合起来。系统从积累的轨迹中构建一张工具图：反复出现的工具调用依赖（比如“调用 A 之前必须先调用 B”）构成程序记忆；每条边上附带相关上下文的简短摘要，构成情景记忆（比如上次遇到类似的 ModuleNotFoundError 是怎么解决的）。推理时，Agent 对常规步骤直接按程序记忆执行，需要结合上下文判断时再调用情景记忆。

评估：不要只看最终分数

最终测试仍然是最重要的验收信号，但它无法解释失败原因。如果一条轨迹失败了，是早期搜索方向错误、中间推理断裂，还是最后一次编辑出现了语法问题？这些区别会决定系统应该改数据、改搜索，还是改验证器。

过程信号：定位错在哪一步

过程奖励模型（Process Reward Model, PRM）尝试为轨迹中的中间步骤打分，例如是否定位了正确文件、是否根据测试反馈调整计划。它适合做诊断和搜索引导，但不应取代最终测试：过程分数通常来自近似模型，仍可能被迎合或误判。

ASTRA ¹⁹ 提出的轨迹级指标里，有两个很适合诊断代码 Agent：工具响应上下文理解（TCU）衡量模型是否正确理解了上一步的工具返回，比如 grep 结果出来后，是否读懂了匹配行的含义；工具响应条件规划（TCP）衡量下一步计划是否真正用上了这次返回，而不是不管返回什么都执行预设的下一步。

除了单步是否正确，一条好的长轨迹还可以从下面几个维度评估：

评估维度	核心关注点	代码场景的典型体现
执行效率	完成任务所需的步骤数与 Token 消耗	同样修复一个 Bug，A 路径用了 15 步，B 路径用了 80 步（充斥重复读取、无效测试）²
连贯性与依赖	多步操作间的逻辑一致性	修改了函数签名但没更新调用方，导致后续所有步骤基于错误假设
鲁棒性与纠错	面对报错或意外反馈时的恢复能力	遇到 flaky test 或环境配置问题时，能诊断出“这不是代码的 Bug”而非无限重试

能力拆解：受控任务与长周期任务

Agentick ²⁰：用 37 个程序生成的网格世界任务，把能力拆成导航、规划、推理、记忆、泛化和多智能体协作六类，同一个状态同时提供 ASCII 网格、自然语言描述、像素图等五种观测形式。它的一个发现是：对 LLM Agent 来说，紧凑的 ASCII 网格在空间推理上持续优于自然语言描述。这是网格世界里的结果。放到代码 Agent 上，我的推测是，用紧凑的目录树而不是大段文字来描述项目结构，可能同样更有效，但这需要单独验证。
SWE-EVO ²¹：多数代码基准只考察修一个 Bug 或加一个小功能。SWE-EVO 从 7 个成熟 Python 项目的发布说明出发构建了 48 个任务，每个任务平均要改 21 个文件，要求 Agent 理解较高层的需求，并在多轮迭代中持续修改代码库。论文报告，GPT-5.4 配合 OpenHands 在 SWE-EVO 上只有 25%，而 GPT-5.2 在 SWE-bench Verified 上达到 72.8%。

失败归因：错在哪里，为什么错

任务步数增加后，即使是强模型，成功率也会明显下降 ²²。

HORIZON ²²：收集了 3100 多条跨 Web、OS、具身和数据库四个领域的轨迹，用基于轨迹的 LLM-as-a-Judge 管线做失败归因（在 40 条失败轨迹上与人工标注的一致性为 $\kappa=0.84$）。按风险层级看，72.5% 的失败发生在执行过程中（环境交互、指令理解、规划错误、错误累积），27.5% 来自 Agent 设计层面的限制（记忆、遗忘约束、错误假设）。各领域最常见的失败类型都是规划错误。
CodeTracer ²³：它对代码 Agent 轨迹做层次化分析，发现了一种系统性的失败模式，称为“证据到动作的鸿沟”（Evidence-to-Action Gap）：Agent 经常已经检索到解决问题所需的信息，却没能把它转成正确的代码修改。成功轨迹中无效步骤约占 22%，失败轨迹中升到 40%；而探索的有效程度只是略有下降。论文据此认为，瓶颈更多出在从理解到执行的转化，而不是信息检索。

落到工程里，我会先做什么

长程任务不是把上下文窗口做大就能解决的问题。它同时涉及探索、状态管理、信用分配和环境可靠性。模型需要记住关键证据，也要主动忘掉旧信息；需要尝试不同方案，也要在高风险动作前停下来。

从这些论文中，我认为最值得带回工程实践的是四点：

先缩短有效 Horizon。 把长任务拆成有验收条件的子目标，比要求模型一次规划几十步更可靠 ¹。
训练数据必须经过真实执行。 没有环境验证的“漂亮轨迹”，很可能只是在学习模型自己编出的工具反馈。
过程指标用于诊断，最终结果用于验收。 PRM、轨迹评审和 LLM Judge 可以帮助找问题，但不能替代测试和权威状态。
安全要监控动作组合。 单个命令可能无害，连续多个合法动作却可能产生不可逆后果，长程 Agent 必须保留审计和人工接管点。

短期内，长程 Agent 的进步不会只来自更强的基础模型，也会来自更好的任务切分、更干净的上下文、更可信的环境和更细的失败归因。