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

Apr 11, 2026·
夏 伟
夏 伟

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

沿着 Code Agent 从组件到中控系统继续往下看，我越来越觉得，“能不能完成一个长任务”是比单次代码生成更接近真实工程的试金石。很多失败并不是模型不会写那几行代码，而是它在前面读错了文件、保留了过期信息，或者没有把测试反馈转成下一步动作。

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

graph LR locate[定位
问题] --> understand[理解
上下文] understand --> readFile[读取
相关文件] readFile --> planFix[制定
修复方案] planFix --> writeCode[编写
代码] writeCode --> runTest[执行
测试] runTest -->|报错
或失败| understand runTest -->|测试
通过| finish[任务
完成]

图 1：代码智能体在修复 Bug 等长轨迹任务中的多轮调试循环。

这篇文章不追求把每篇论文都排成时间线，而是围绕四个问题整理近期工作：训练轨迹从哪里来，模型怎样从长序列中学习，运行过程中如何控制风险，以及失败后怎样知道究竟错在哪一步。

长任务为什么容易失控

在长程多轮交互中，大模型不仅仅是面临「上下文变长了」这么简单的问题，而是遭遇了结构性与算法上的本质瓶颈：

  1. 误差会沿轨迹传播：控制变量研究表明，仅仅增加任务的 Horizon Length，就会让训练更不稳定 1。如果把每一步粗略看成独立事件，单步成功率为 $p$，连续 $N$ 步都正确的概率是 $p^N$；当 $p=0.95, N=50$ 时只有约 $7.7\%$。真实任务当然并不独立，也允许纠错，但这个简单计算解释了为什么早期误判会迅速放大。

  2. 上下文会被旧信息占满：如果每次工具返回、完整报错和重复文件内容都留在 Prompt 里，Token 成本会持续增长，关键证据反而更难找到 2。代码 Agent 反复读取大文件、保存多轮 traceback，就是很常见的上下文浪费。

  3. 最终分数无法解释中间过程：Agent 执行几十步后只收到“测试通过/不通过”，训练系统很难判断是哪一个决策造成了结果。这就是奖励稀疏和信用分配问题：最终反馈是可靠的，却不足以指导每一个中间动作 34。

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

缺乏高质量的多轮演示数据，是训练长程 Agent 的最大痛点。以代码场景为例，SWE-bench 上的「金标准」轨迹需要人类工程师花费数小时完成一个 issue 的完整修复流程，这种标注成本极其高昂。为了解决这个问题，研究者们在数据合成与处理链路上玩出了不少新花样。

让轨迹来自真实执行

  • ISE (Intent-Simulate-Execute) 执行接地范式 3：以前很多合成数据都是靠大模型自己「脑补」出来的——模型假装执行了一个命令，然后自己想象出命令的返回结果。这缺乏真实环境的验证。ISE 框架提出了三阶段管线：(1) Intent——由强模型根据代码库状态生成多样化的任务意图；(2) Simulate——让 Agent 在隔离的沙盒中实际执行每一步工具调用（bash、file_edit、search）；(3) Execute——由真实 OS 状态下的 Completion Gate（如单测是否通过、文件变更是否匹配 diff）来裁定这条轨迹是否保留。只有通过了真实环境验证的轨迹才会进入训练集，自然过滤掉了模型的「幻觉数据」。

  • WRIT (读写密集型轨迹合成) 4：在代码 Agent 的实际操作中，Agent 花在「读」上的时间往往远超「写」的时间——它需要在数十个文件间跳转阅读、理解调用链、比对不同版本的实现。WRIT 框架专门针对这种高信息负载场景，合成需要大量信息检索与比对才能支撑最终写入操作的长轨迹，迫使模型学会在海量信息中回溯和精准定位。

切分超长轨迹

  • KLong 的轨迹切分 (Trajectory-Splitting SFT) 5：针对诸如「复现一篇科研论文」或「从零搭建一个完整项目」这种耗时十几个小时、长达数百步的极端任务，KLong 提出了轨迹切分技术。核心思路是：将轨迹切成多个子序列，每个子序列将核心参考信息（如任务描述、关键约束）固定在上下文前端，随着交互推进逐渐截断太老的历史记录，同时相邻子轨迹间保留重叠以确保连贯性。这让模型能在标准的上下文窗口限制下，稳稳地学习极长的序列步骤。

  • Agent Data Protocol (ADP) 6：目前各家 Agent 的数据集格式五花八门——有的用 JSON Lines，有的用自定义 XML，工具调用的 schema 也各不相同。ADP 提出了一套标准化的数据协议，统一任务描述、Agent 角色、轨迹步骤和质量评分，目标是降低跨数据集混合训练的转换成本。

合成多样但可验证的数据

当前最具前瞻性的趋势之一，是从少量高质量的「种子轨迹」出发，通过可验证的机制，批量合成出大规模、多样化的长轨迹训练数据。这对代码 Agent 尤其有意义——一个成功修复 Bug 的轨迹，只要改变 Bug 的触发条件、代码库的目录结构、或者依赖版本，就能派生出无数个结构类似但细节不同的有效训练样本。

  • TDScaling（轨迹多样性缩放） 7：这项工作强调，多样性不能只用样本数量替代。

    核心洞察：TDScaling 证明，在固定算力下，把精力花在提升轨迹的多样性上，比单纯堆数量收益大得多。

    它通过三个熵指标——领域熵（覆盖了多少不同的业务场景）、推理模式熵（是否覆盖了检索、编辑、执行等不同的动作模式）和累积动作复杂度——来衡量当前训练集的多样性，并通过自适应演化机制主动向长尾、罕见的场景合成。在代码 Agent 的 BFCL 和 τ²-Bench 基准上，TDScaling 达到了远高于数量缩放的性能天花板。

  • COVERT（可控可验证工具调用合成） 8：COVERT 的核心思路是保真变换（Oracle-Preserving Augmentation）。给定一条已验证的基础轨迹，它对环境组件施加系统性扰动：(1) 在工具列表中注入无关的干扰工具（模拟真实 MCP Server 中 Agent 需要在众多工具中选择的情况）；(2) 将用户查询改写为更间接的表述（比如把「删除 user 表中 id=5 的记录」改写为「帮我清理那个刚注册但没验证邮箱的用户」）；(3) 向工具输出注入格式噪声（如多余的空行、不规范的 JSON）。但严格保证 oracle 答案不变，从而奖励信号可通过确定性匹配自动计算，实现了「增加训练难度和多样性，但不引入任何人工标注成本」。

  • LOGIGEN（逻辑驱动的可验证任务生成） 9：LOGIGEN 通过三个 Agent 协作来合成任务——Architect 将自然语言业务规则编译为数据库硬约束（如「余额不足时不得转账」）；Set Designer 初始化触发关键规则冲突的边界状态；Explorer 在该环境中搜索因果解路径。最终任务的正确性通过精确的数据库状态等价检查来验证（期望状态 == 实际状态），而非依赖任何模糊的 LLM 判断。在 τ²-Bench 上，LOGIGEN-32B(RL) 达到了 79.5% 的成功率（基础模型仅 40.7%）。

  • AgentHER（变废为宝的后见重标注） 10：这是一个非常巧妙的思路，源自强化学习中经典的 Hindsight Experience Replay。

    一条没有完成任务 A 的轨迹，换一个目标看，可能包含完成任务 B 的有效步骤。

    比如，Agent 本来要修复模块 A 的 Bug，但误操作修改了模块 B 的代码——这条轨迹作为「修复模块 A」的训练数据是失败的，但作为「修改模块 B」的示范却可能是成功的。AgentHER 通过四阶段管线（失败分类→结果提取→LLM 引导的提示重标注→数据打包），将通常被丢弃的 60-75% 的失败轨迹转化为了 SFT/DPO 训练对，在 WebArena 和 ToolBench 上带来 +7.1-11.7% 的提升，并实现了 2 倍的样本效率。

    graph LR failTraj[失败轨迹] --> classify[失败分类] classify --> extract[结果提取] extract --> relabel[LLM引导
    重标注] relabel --> pack[数据打包] pack --> trainData[SFT或DPO
    训练数据]

    图 2：AgentHER 的数据重标注管线，将失败的轨迹“变废为宝”转化为有效的训练数据。

  • LATR 与 MARTI（多想几步再落子） 11 12：在训练阶段的 Rollout 环节，标准做法是让模型自由采样一整条轨迹。但这很容易产生大量同质化的轨迹（比如模型总是用同一个策略解题）。LATR 在模型感到「不确定」的步骤（通过 token 级 entropy 判断）强制分叉，往后多模拟几步（lookahead），然后用归一化编辑距离修剪掉和已有分支过于相似的路径，只保留真正多样化的分支。MARTI-v2 则引入了多 Agent 协作的蒙特卡洛树搜索（MCTS），通过自适应节点扩展在解空间中系统性探索。LATR 使策略学习效率提升了 131%，MARTI 的多 Agent 设定有效解决了训练后期的性能饱和问题。

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

给上下文减负

  • AgentDiet 2：随着交互轮数增加，Agent 的上下文中充斥着无效信息——比如一条已经被修复的旧报错、前几轮已经读过但没变化的文件内容。AgentDiet 通过动态过滤机制，根据「信息的时效性」和「与当前子目标的相关性」果断删掉这些冗余上下文。实验表明，在保持模型成功率几乎不变（波动 -1% 到 +2%）的前提下，Token 消耗降低了 21%-36%，这对代码 Agent 的推理成本和延迟有直接的工程价值。

后训练：先学会，再探索

如何科学地协调监督微调（SFT）和强化学习（RL），是解锁 Agent 复杂长程推理的核心架构问题。

SFT 打基础，RL 找上限

SFT 和 RL 应该串行还是混合，并没有对所有任务都成立的统一答案。一项近期工作给出的经验是：

  • 最佳实践：Plasticity-Ceiling 框架 13 通过严格的消融实验证明，「先用 SFT 让模型学会基础操作模式（如文件搜索→读取→编辑→测试的标准流程），直至 SFT loss 饱和，再启动 RL 通过探索来突破能力上限」的串行模式，显著优于将两者混合的同步训练方案。

    核心洞察：SFT 阶段建立了「可塑性（Plasticity）」——模型学会了动作空间中的合理模式；RL 阶段则在此基础上探索「天花板（Ceiling）」——寻找更优的策略组合。如果混着来，RL 的随机探索会破坏 SFT 建立的稳定模式。

  • 环境渐进式调节：除了微调模型本身，我们还可以调整环境的难度 14。具体做法是引入阶段性的进度奖励（Progress Reward）：比如，代码 Agent 成功定位到了目标文件（虽然没修好）也能获得部分奖励，成功通过了一部分测试用例也获得部分奖励。这种稠密的中间信号引导 Agent 从简单的基础调用逐步适应充满噪声和缺失依赖的复杂长视野场景。

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

长轨迹合成数据往往良莠不齐。有些合成轨迹虽然最终成功了，但路径极其冗余（比如绕了很多弯路才找到文件）；有些则包含错误的中间步骤但恰好通过了测试。直接一锅炖会导致模型被低质量数据带偏。

  • BOOST 双层优化框架 15：BOOST 将训练形式化为双层优化问题。内层在加权后的合成轨迹上更新策略（标准的 offline RL 目标，如 MC return 或 ILQL loss）；外层则在真实的少样本验证集上优化一个轻量级的「轨迹重加权头」（一个小型 MLP，输入轨迹的统计特征，输出该轨迹的训练权重）。通过 bi-level optimization 的交替更新，BOOST 能自动学会给高质量轨迹更高权重、抑制低质量轨迹的影响，且不需要外部大模型来做质量裁判。

把搜索放进 Rollout

在在线强化学习阶段，标准做法是让 Agent 对每个 prompt 独立采样一条完整轨迹，然后计算奖励和梯度。但由于环境的随机性和奖励的稀疏性，朴素采样极易陷入死锁（Agent 卡在一个错误状态反复重试）或模式崩溃（总是采样到相同的路径）。

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

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

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

提前发现过程风险

在长轨迹中，恶意攻击或危险操作往往是「隐蔽且组合式」的——单独看任何一步都是合法的 API 调用，但组合起来就构成了一次未授权操作。传统的单轮拦截机制（比如只检查当前这一步有没有出现敏感关键词）在长视野下很容易变成「瞎子」。

  • Compressor-Reader 架构 17：TRACES 框架引入了两阶段的安全审计。Compressor 从大模型的中间隐藏层中提取每一步的「风险表征向量」；Reader 则是一个轻量的 GRU 网络，对这个时序的风险向量序列进行建模，输出「截至当前步的累积风险分数」。关键创新是前缀感知的弱监督：它不需要昂贵的每一步安全标注，只需要知道整条轨迹是否最终产生了危害结果，就能通过前缀级别的损失函数学会在轨迹早期检测风险。在代码场景中，这意味着当 Agent 开始组合 chmod 777 + curl 外部地址 + bash -c 这类模式时，系统能在最终的恶意命令执行前发出预警。TRACES 在 ATBench 上将 EAUPC（早期检测面积指标）从 62.9 提升至 82.2。

    graph LR hiddenLayer[大模型
    中间隐藏层] --> compressor[Compressor
    提取特征] compressor --> reader[Reader
    时序建模] reader --> checkRisk{"风险分数>阈值?"} checkRisk -->|是| alert[拦截预警] checkRisk -->|否| continueRun[继续执行]

    图 3：TRACES 前瞻性安全预警架构，通过提取大模型隐藏层特征和时序建模实现早期风险拦截。

从轨迹中提炼经验

对于代码 Agent，很多操作模式是高度重复的——比如「遇到 import error 时先检查依赖版本、再检查虚拟环境」这类调试套路。如果每次都从零开始推理，不仅浪费算力，还容易丢失经验。

  • H-EPM 框架 18：提出了一种「混合情景-程序记忆」系统。情景记忆（Episodic Memory） 检索与当前任务状态有高重叠度的历史轨迹片段（比如上次遇到类似的 ModuleNotFoundError 是怎么解决的）；程序记忆（Procedural Memory） 则从多次重复的工具调用序列中抽象出稳定的依赖图（Tool Graph），比如「调用 A 之前必须先调用 B」的固化模式。这样，Agent 在面对连续演进的任务时，能把过去积累的调试经验变成高效可复用的「肌肉记忆」。

评估：不要只看最终分数

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

用过程奖励定位问题

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

一条好轨迹应该看什么

一条高质量的长轨迹不仅仅是「做对了」，还需要在以下维度表现优异：

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

用受控任务拆开能力

  • 六大能力维度解构 19：Agentick 基准摒弃了单一分数，设计了涵盖导航（在文件系统中定位目标）、规划（将复杂任务分解为子步骤）、推理（理解代码逻辑和依赖关系）、记忆（跨轮次保持上下文一致性）、泛化（从已知模式迁移到未知场景）与多智能体协调六个核心维度的 37 个受控任务。
  • 一个令人意外的发现：对于大语言模型，紧凑的 ASCII 文本模态（如目录树结构 src/utils/helper.py）在空间推理上，持续优于冗长的自然语言描述（如「在 src 目录下的 utils 子目录中有一个名为 helper 的 Python 文件」）。这对代码 Agent 的 prompt 设计有直接启发——用结构化的树形表示而非自然语言来呈现项目结构。

失败发生在哪里

即使能力较强的模型，在需要 20 步以上决策的任务中也常出现明显衰退。

  • HORIZON 诊断基准 20：收集了 3100 多条多轮交互轨迹，通过 LLM-as-a-Judge 管线进行自动化失败归因（与人类专家判断的一致性达到 $\kappa=0.84$）。核心发现是：长轨迹衰退的主因不是模型「不懂」（领域知识缺失占比很小），而是探索失败（Agent 找不到正确的下一步应该做什么，陷入无效循环）和复合性逻辑错误（前面一个小错误导致后面一连串错误决策的多米诺效应）。

从证据到动作的鸿沟

这是对代码 Agent 最扎心也最深刻的诊断。

  • Evidence-to-Action Gap 21：CodeTracer 通过层次化的轨迹结构分析，发现了一个系统性的失败模式。

    核心洞察：Agent 经常能成功检索到解决问题所需的正确信息，但却无法将这些「证据」转化为正确的代码修改动作。这说明当前模型的核心瓶颈不在「信息检索」阶段，而在「从理解到执行」的最后一步转化能力上。

    量化数据表明，从成功轨迹到失败轨迹，无效动作的比例从 22% 飙升至 40%。Agent 在积累了大量环境反馈后迷失了焦点，无法在众多信息中抽取出关键的行动指导。

从单次修复到持续演进

  • 微观认知深度 22：ASTRA 提出了四个认知轨迹级指标，其中最关键的是「工具响应上下文理解（TCU）」和「工具响应条件规划（TCP）」。TCU 衡量模型是否真正消化了上一步的工具返回结果（比如 grep 搜索结果出来了，模型是否正确理解了匹配行的含义）；TCP 衡量模型是否据此动态调整了下一步的计划（而非不管工具返回什么都执行预设的下一步）。这从根本上区分了「真推理」和「背答案」。
  • 宏观持续演进 23：SWE-EVO 基准将视野拉长到了跨版本的软件演进。它不再局限于修复单个 Bug，而是要求 Agent 能够理解高层级的需求变更（如「把认证方式从 Session 迁移到 JWT」），并在多个迭代中对代码库进行持续的、跨模块的重构和升级。这考验的是 Agent 在长视野下维护系统架构一致性的能力——与真实世界中软件工程师面对的挑战最为接近。

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

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

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

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

短期内，长程 Agent 的进步不会只来自更强的基础模型，也会来自更好的任务切分、更干净的上下文、更可信的环境和更细的失败归因。谁能把这四部分连成稳定闭环，谁才更接近真正可用的“数字工程师”。

参考资料

  1. On Training Large Language Models for Long-Horizon Tasks: An Empirical Study of Horizon Length ↩︎

  2. AgentDiet: Reducing Cost of LLM Agents with Trajectory Reduction ↩︎ ↩︎ ↩︎

  3. ISE: An Execution-Grounded Recipe for Multi-Turn OS-Agent Trajectories ↩︎ ↩︎

  4. WRIT: Write-Read Intensive Trajectory Synthesis for Multi-Turn User-Facing Agents ↩︎ ↩︎

  5. KLong: Training LLM Agent for Extremely Long-horizon Tasks ↩︎

  6. Agent Data Protocol: Unifying Datasets for Diverse, Effective Fine-tuning of LLM Agents ↩︎

  7. TDScaling: Beyond Quantity — Trajectory Diversity Scaling for Code Agents ↩︎

  8. COVERT: Controllable and Verifiable Tool-Use Data Synthesis for Agentic Reinforcement Learning ↩︎

  9. LOGIGEN: Logic-Driven Generation of Verifiable Agentic Tasks ↩︎

  10. AgentHER: Hindsight Experience Replay for LLM Agent Trajectory Relabeling ↩︎

  11. LATR: Lookahead Tree-Based Rollouts for Enhanced Trajectory-Level Exploration in Reinforcement Learning with Verifiable Rewards, ICLR 2026 ↩︎

  12. MARTI: Scaling Multi-Agent Self-Search via Reinforcement Learning for Code Generation ↩︎

  13. Rethinking Expert Trajectory Utilization in LLM Post-training ↩︎

  14. Don't Just Fine-tune the Agent, Tune the Environment ↩︎

  15. BOOST: Bilevel Optimization of Synthetic Trajectories for Multi-Turn LLM Fine-Tuning ↩︎

  16. TSR: Trajectory-Search Rollouts for Multi-Turn RL of LLM Agents ↩︎ ↩︎ ↩︎

  17. TRACES: Proactive Safety Auditing for Multi-Turn LLM Agents via Trajectory-State Modeling ↩︎

  18. H-EPM: Experience-Evolving Multi-Turn Tool-Use Agent with Hybrid Episodic-Procedural Memory ↩︎

  19. Agentick: A Unified Benchmark for General Sequential Decision-Making Agents ↩︎ ↩︎

  20. HORIZON: The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break ↩︎

  21. CodeTracer: Towards Traceable Agent States ↩︎

  22. ASTRA: Automated Synthesis of Agentic Trajectories and Reinforcement Arenas ↩︎

  23. SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios ↩︎

LLM Agent Long Trajectory 强化学习 Agent
夏 伟
Authors
夏 伟
Senior Applied Researcher
AI Coding · LLM Agent · Research & Product

Related