Agent 多轮长轨迹（Long Trajectory）技术概要

Apr 11, 2026·
夏 伟
夏 伟

我们正在见证 AI Agent 的一次关键蜕变。过去，我们总是惊叹于大语言模型（LLM）在 一问一答 中的惊艳表现；但如今，我们对 Agent 提出了更苛刻的要求——去完成复杂的开放式任务。比如，规划一次包含订票与比价的复杂旅行，在庞大的代码库中定位 Bug 并持续修复，或者进行需要反复交叉验证的深度科学调研。

这些任务往往需要几十甚至上百步的 多轮长轨迹（Long-Horizon Trajectories） 交互。然而，当把习惯了「单线程作答」的 LLM 扔进这种需要长线决策的环境时，它们往往会暴露出严重的短板。

代码软件开发正是这种长轨迹、多轮交互的典型场景。软件代码支持多个功能的迭代演进与多文件结构的分层，并具备一套非常自洽的规则体系。大白话说，软件代码可以写得很长，并且前后高度关联、可进行客观的执行验证。 一个现实的 repo-level 任务——比如修复一个涉及多文件依赖的 Bug——通常需要 Agent 经历「定位问题→理解上下文→读取相关文件→制定修复方案→编写代码→执行测试→根据报错迭代」的完整循环，每一步的决策都依赖于前几步的环境反馈。这种多文件层级管理、调试-报错-修复的循环往复，使得代码智能体成为理解长轨迹技术的最佳切入点。

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

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

本文将基于最新的前沿学术论文，系统拆解多轮长轨迹背后的核心技术瓶颈、数据工程方法论、后训练架构范式、前瞻性安全审计机制，以及多维度质量评估体系。

一、为什么多轮长轨迹这么难？核心挑战与理论边界

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

  1. 步数越多，错得越离谱（误差累积）：学术界的实证研究发现，仅仅是把任务的「步数（Horizon Length）」拉长，就会让模型的训练变得极不稳定 1。这就像走钢丝——大模型在单步决策时可能只有 1% 的错误率，但如果一个任务需要 50 步，早期一个极其微小的失误（比如代码 Agent 在第一步定位错了文件），会在后续的长线操作中被无限放大（后续所有的修改都基于错误的文件），最终导致任务成功率呈指数级暴跌。形式化地看，假设单步成功率为 $p$，则 $N$ 步的整体成功率上界为 $p^N$，当 $p=0.95, N=50$ 时，整体成功率仅约 $0.95^{50} \approx 7.7\%$。

  2. 记性太好反而成了负担（上下文爆炸）：传统的 Agent 架构非常「老实」，它会把每一次的 API 返回结果、报错日志一股脑塞进上下文窗口里。结果就是 Token 消耗直线上升，模型被大量无用、冗余和过期的垃圾信息淹没 2。以代码 Agent 为例，一个典型的 SWE-bench 任务中，Agent 可能连续读取同一个 2000 行的源文件 3 次（因为中间改了几行想确认），加上每次 pytest 输出的完整 traceback 和 warning 信息，一条轨迹的 token 数可轻松突破 100K。这不仅拖慢推理速度、增加成本，更关键的是——模型的注意力被稀释了，真正重要的上下文信息（如关键报错行号）被淹没在噪音中。

  3. 干了半天，不知道哪步做对了（奖励稀疏与信用分配）：在强化学习中，Agent 往往忙活了半小时、执行了上百步操作，最后只得到一个「测试通过/不通过」的二元反馈 3。到底是因为第一步搜错了文件，还是第 50 步写错了参数？模型根本无从知晓。这在代码场景中尤其严重：一个 pytest failure 可能是因为 Agent 在第 3 步漏掉了一个 import，但整条轨迹后面 47 步的代码修改其实都是正确的。这种延迟且稀疏的奖励，使得梯度估计的方差极高（因为策略梯度方法需要将最终奖励归因到每一步），容易引发模式崩溃 4。

二、高质量长轨迹数据的合成、统一与「瘦身」

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

2.1 别在真空里想象：让 Agent 在真实环境里跑（执行接地）

  • 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 框架专门针对这种高信息负载场景，合成需要大量信息检索与比对才能支撑最终写入操作的长轨迹，迫使模型学会在海量信息中回溯和精准定位。

2.2 应对超长任务：轨迹切分与数据协议统一

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

  • Agent Data Protocol (ADP) 6：目前各家 Agent 的数据集格式五花八门——有的用 JSON Lines，有的用自定义 XML，工具调用的 schema 也各不相同。ADP 提出了一套标准化的数据协议，统一了任务描述、Agent 角色定义、轨迹步骤（含 Thought/Action/Observation 三元组）和质量评分的表示形式。这使得来自不同领域（代码、Web、OS）的异构数据集可以无缝混合训练，大幅降低了数据工程的成本。

2.3 从「抄答案」到「举一反三」：可验证的多样性合成

当前最具前瞻性的趋势之一，是从少量高质量的「种子轨迹」出发，通过可验证的机制，批量合成出大规模、多样化的长轨迹训练数据。这对代码 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）

2.4 给 Prompt 减负：推理期的轨迹瘦身

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

三、后训练范式跃迁与 RL 算法的进化

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

3.1 先打好基础，再追求上限（串行 SFT-then-RL）

业界关于 SFT 和 RL 是该「混着练」还是「串行练」的争论已有了答案：

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

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

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

3.2 驯服参差不齐的数据（双层优化）

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

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

3.3 边想边试错：把树搜索引入训练期（TSR）

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

  • TSR (Trajectory-Search Rollouts) 16：创新性地将测试期的搜索算法搬到了训练期的 Rollout 阶段。具体来说，在每个 action step，TSR 不是只采样一个动作继续执行，而是采样 $k$ 个候选动作，分别执行并获取环境反馈（如执行结果、测试输出），然后用一个 step-level reward signal（比如测试通过数是否增加）来选择最优的那个分支继续。这等价于在环境状态空间中做了一个浅层的 beam search。关键设计是：搜索只影响数据的生成分布，完全不修改底层的策略优化器（PPO/GRPO/DPO 均兼容）。实验表明，在 WebShop、Sokoban 等多轮任务中，TSR 带来了最高达 15% 的稳定性能提升，且计算开销仅增加了采样 $k$ 个动作的推理成本。

四、走向生产环境的长程安全审计与经验记忆

当多轮 Agent 真正落地到生产环境——比如一个拥有 rm -rf、git push --force、数据库写入权限的代码 Agent——长程安全性与记忆机制就成了最后一道护城河。

4.1 别等出事了才报警：前瞻性安全预警（TRACES）

在长轨迹中，恶意攻击或危险操作往往是「隐蔽且组合式」的——单独看任何一步都是合法的 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 前瞻性安全预警架构，通过提取大模型隐藏层特征和时序建模实现早期风险拦截。

4.2 把经验变成肌肉记忆（H-EPM）

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

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

五、多维度、多粒度的轨迹质量诊断与评估体系

当我们把 Agent 投入到长达数十步的交互中，传统的只看「最终测试是否通过」的单一打分方式已经彻底失效了。如果一条轨迹失败了，是因为搜索策略错误（早期探索不够）、逻辑推理断裂（中间步骤矛盾）、还是仅仅因为语法拼写错误？

5.1 不仅看结果，更要看过程（PRM）

因为长轨迹的最终奖励太稀疏（代码跑不通 = 0 分，但不告诉你哪步错了），业界正从结果级奖励模型（Outcome Reward Model, ORM）转向过程级奖励模型（Process Reward Model, PRM） 16。PRM 对轨迹中的每一个推理步骤独立打分（比如：「这一步 Agent 决定搜索 utils.py 文件」得到一个 0-1 的合理性分数），从而精确定位 Agent 到底在哪一步发生了「逻辑断裂」。在代码场景中，这可以具化为：定位了正确的文件（+0.2）→读取了关键函数（+0.1）→理解了 Bug 根因（+0.3）→编写了正确的修复（+0.3）→测试通过（+0.1），每一步都有可归因的信号。

5.2 评估维度的多维切面

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

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

5.3 统一的「考场」：多维度能力解构（Agentick）

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

5.4 为什么会崩溃？长视野失效溯源（HORIZON）

即使是当前最强的前沿模型，在遇到需要 20+ 步的长决策链时也会迅速崩溃。

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

5.5 看懂了报错，但改不对代码：证据到动作的鸿沟（CodeTracer）

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

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

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

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

5.6 认知深度与持续演进（ASTRA & SWE-EVO）

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

六、结语与研究展望

从让大模型「说对话」，到让大模型「做对事」，多轮长轨迹技术标志着 AI 正式从文本生成器蜕变为序列决策系统。代码智能体作为这一转变的前沿阵地，其面临的长轨迹挑战——跨文件依赖管理、调试循环的深度回溯、不可逆操作的安全控制——正在驱动整个 Agent 技术栈的快速进化。

从技术研究的视角，以下方向值得持续关注：

  1. 可验证多样性合成的规模化：将 COVERT、LOGIGEN 等框架从单轮工具调用扩展到真正的数十步长视野序列；构建「轨迹编译器」——输入少量种子轨迹和环境规范（如 repo 结构 + 测试用例），自动输出覆盖长尾场景的大规模训练集；探索跨领域的结构迁移——一个成功的代码调试轨迹模式，能否经保真变换后迁移至数据分析或 DevOps 场景。
  2. 从单步推理到层次化规划：未来的代码 Agent 需要在动手前进行全局规划——先理解高层需求，分解为模块级子目标（如「先修改接口定义→再更新调用方→最后补充测试」），再在每个子目标内进行细粒度操作，而不是像无头苍蝇一样「走一步看一步」。
  3. 自适应记忆与上下文管理：如何在有限的上下文窗口中，动态记住最重要的历史信息（如关键的报错信息、已确认的代码修改），同时果断忘掉过期信息（如旧版本的文件内容），是工程落地的关键瓶颈。
  4. 确定性与创造力的平衡：生产环境中的代码 Agent 要求输出稳定可靠（同样的 Bug 每次都能修），而探索性任务（如技术选型、架构设计）需要一定程度的「脑洞大开」——如何在推理期动态调整确定性与探索性的权衡，仍需进一步研究。
  5. 安全性的前置化：从事后代码审查转向实时的过程监控。在代码 Agent 执行关键的不可逆操作（如 git push --force、DROP TABLE、修改生产环境配置）前，TRACES 类架构需要提供可靠的干预窗口，并在不显著增加推理延迟的前提下实现前瞻性安全保障。

未来的代码 Agent 将不再是只能做一行补全的「自动打字机」，而是能够跨越数十步调试循环、自主规划与纠错的「数字工程师」。

References

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

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

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

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

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

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

  7. TDScaling: Beyond Quantity: Trajectory Diversity Scaling for Code Agents, arXiv:2602.03219 ↩︎

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

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

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

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

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

  13. Rethinking Expert Trajectory Utilization in LLM Post-training, arXiv:2512.11470 ↩︎

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

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

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

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

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

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

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

  21. CodeTracer: Towards Traceable Agent States, arXiv:2604.11641 ↩︎

  22. ASTRA: Automated Synthesis of agentic Trajectories and Reinforcement Arenas, arXiv:2601.21558 ↩︎

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

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

Related