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

Sat, 11 Apr 2026 00:00:00 +0000

我们正在见证 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 等长轨迹任务中的多轮调试循环。

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

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

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

步数越多，错得越离谱（误差累积）：学术界的实证研究发现，仅仅是把任务的「步数（Horizon Length）」拉长，就会让模型的训练变得极不稳定 ¹。这就像走钢丝——大模型在单步决策时可能只有 1% 的错误率，但如果一个任务需要 50 步，早期一个极其微小的失误（比如代码 Agent 在第一步定位错了文件），会在后续的长线操作中被无限放大（后续所有的修改都基于错误的文件），最终导致任务成功率呈指数级暴跌。形式化地看，假设单步成功率为 $p$，则 $N$ 步的整体成功率上界为 $p^N$，当 $p=0.95, N=50$ 时，整体成功率仅约 $0.95^{50} \approx 7.7\%$。
记性太好反而成了负担（上下文爆炸）：传统的 Agent 架构非常「老实」，它会把每一次的 API 返回结果、报错日志一股脑塞进上下文窗口里。结果就是 Token 消耗直线上升，模型被大量无用、冗余和过期的垃圾信息淹没 ²。以代码 Agent 为例，一个典型的 SWE-bench 任务中，Agent 可能连续读取同一个 2000 行的源文件 3 次（因为中间改了几行想确认），加上每次 pytest 输出的完整 traceback 和 warning 信息，一条轨迹的 token 数可轻松突破 100K。这不仅拖慢推理速度、增加成本，更关键的是——模型的注意力被稀释了，真正重要的上下文信息（如关键报错行号）被淹没在噪音中。
干了半天，不知道哪步做对了（奖励稀疏与信用分配）：在强化学习中，Agent 往往忙活了半小时、执行了上百步操作，最后只得到一个「测试通过/不通过」的二元反馈 ³。到底是因为第一步搜错了文件，还是第 50 步写错了参数？模型根本无从知晓。这在代码场景中尤其严重：一个 pytest failure 可能是因为 Agent 在第 3 步漏掉了一个 import，但整条轨迹后面 47 步的代码修改其实都是正确的。这种延迟且稀疏的奖励，使得梯度估计的方差极高（因为策略梯度方法需要将最终奖励归因到每一步），容易引发模式崩溃 ⁴。

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

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

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

ISE (Intent-Simulate-Execute) 执行接地范式 ³：以前很多合成数据都是靠大模型自己「脑补」出来的——模型假装执行了一个命令，然后自己想象出命令的返回结果。这缺乏真实环境的验证。ISE 框架提出了三阶段管线：(1) Intent——由强模型根据代码库状态生成多样化的任务意图；(2) Simulate——让 Agent 在隔离的沙盒中实际执行每一步工具调用（bash、file_edit、search）；(3) Execute——由真实 OS 状态下的 Completion Gate（如单测是否通过、文件变更是否匹配 diff）来裁定这条轨迹是否保留。只有通过了真实环境验证的轨迹才会进入训练集，自然过滤掉了模型的「幻觉数据」。
WRIT (读写密集型轨迹合成) ⁴：在代码 Agent 的实际操作中，Agent 花在「读」上的时间往往远超「写」的时间——它需要在数十个文件间跳转阅读、理解调用链、比对不同版本的实现。WRIT 框架专门针对这种高信息负载场景，合成需要大量信息检索与比对才能支撑最终写入操作的长轨迹，迫使模型学会在海量信息中回溯和精准定位。

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

KLong 的轨迹切分 (Trajectory-Splitting SFT) ⁵：针对诸如「复现一篇科研论文」或「从零搭建一个完整项目」这种耗时十几个小时、长达数百步的极端任务，KLong 提出了轨迹切分技术。核心思路是：将轨迹切成多个子序列，每个子序列将核心参考信息（如任务描述、关键约束）固定在上下文前端，随着交互推进逐渐截断太老的历史记录，同时相邻子轨迹间保留重叠以确保连贯性。这让模型能在标准的上下文窗口限制下，稳稳地学习极长的序列步骤。
Agent Data Protocol (ADP) ⁶：目前各家 Agent 的数据集格式五花八门——有的用 JSON Lines，有的用自定义 XML，工具调用的 schema 也各不相同。ADP 提出了一套标准化的数据协议，统一了任务描述、Agent 角色定义、轨迹步骤（含 Thought/Action/Observation 三元组）和质量评分的表示形式。这使得来自不同领域（代码、Web、OS）的异构数据集可以无缝混合训练，大幅降低了数据工程的成本。

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

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

TDScaling（轨迹多样性缩放） ⁷：这项工作打破了「数据越多越好」的迷信。

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

它通过三个熵指标——领域熵（覆盖了多少不同的业务场景）、推理模式熵（是否覆盖了检索、编辑、执行等不同的动作模式）和累积动作复杂度——来衡量当前训练集的多样性，并通过自适应演化机制主动向长尾、罕见的场景合成。在代码 Agent 的 BFCL 和 τ²-Bench 基准上，TDScaling 达到了远高于数量缩放的性能天花板。
COVERT（可控可验证工具调用合成） ⁸：COVERT 的核心思路是保真变换（Oracle-Preserving Augmentation）。给定一条已验证的基础轨迹，它对环境组件施加系统性扰动：(1) 在工具列表中注入无关的干扰工具（模拟真实 MCP Server 中 Agent 需要在众多工具中选择的情况）；(2) 将用户查询改写为更间接的表述（比如把「删除 user 表中 id=5 的记录」改写为「帮我清理那个刚注册但没验证邮箱的用户」）；(3) 向工具输出注入格式噪声（如多余的空行、不规范的 JSON）。但严格保证 oracle 答案不变，从而奖励信号可通过确定性匹配自动计算，实现了「增加训练难度和多样性，但不引入任何人工标注成本」。
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 上带来 +7.1-11.7% 的提升，并实现了 2 倍的样本效率。

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

图 2：AgentHER 的数据重标注管线，将失败的轨迹“变废为宝”转化为有效的训练数据。
LATR 与 MARTI（多想几步再落子） ¹¹ ¹²：在训练阶段的 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 ²：随着交互轮数增加，Agent 的上下文中充斥着无效信息——比如一条已经被修复的旧报错、前几轮已经读过但没变化的文件内容。AgentDiet 通过动态过滤机制，根据「信息的时效性」和「与当前子目标的相关性」果断删掉这些冗余上下文。实验表明，在保持模型成功率几乎不变（波动 -1% 到 +2%）的前提下，Token 消耗降低了 21%-36%，这对代码 Agent 的推理成本和延迟有直接的工程价值。

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

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

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

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

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

核心洞察：SFT 阶段建立了「可塑性（Plasticity）」——模型学会了动作空间中的合理模式；RL 阶段则在此基础上探索「天花板（Ceiling）」——寻找更优的策略组合。如果混着来，RL 的随机探索会破坏 SFT 建立的稳定模式。
环境渐进式调节：除了微调模型本身，我们还可以调整环境的难度 ¹⁴。具体做法是引入阶段性的进度奖励（Progress Reward）：比如，代码 Agent 成功定位到了目标文件（虽然没修好）也能获得部分奖励，成功通过了一部分测试用例也获得部分奖励。这种稠密的中间信号引导 Agent 从简单的基础调用逐步适应充满噪声和缺失依赖的复杂长视野场景。

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

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

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

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

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

TSR (Trajectory-Search Rollouts) ¹⁶：创新性地将测试期的搜索算法搬到了训练期的 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 架构 ¹⁷：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 框架 ¹⁸：提出了一种「混合情景-程序记忆」系统。情景记忆（Episodic Memory） 检索与当前任务状态有高重叠度的历史轨迹片段（比如上次遇到类似的 ModuleNotFoundError 是怎么解决的）；程序记忆（Procedural Memory） 则从多次重复的工具调用序列中抽象出稳定的依赖图（Tool Graph），比如「调用 A 之前必须先调用 B」的固化模式。这样，Agent 在面对连续演进的任务时，能把过去积累的调试经验变成高效可复用的「肌肉记忆」。

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

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

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

因为长轨迹的最终奖励太稀疏（代码跑不通 = 0 分，但不告诉你哪步错了），业界正从结果级奖励模型（Outcome Reward Model, ORM）转向过程级奖励模型（Process Reward Model, PRM） ¹⁶。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 步（充斥重复读取、无效测试）²
连贯性与依赖	多步操作间的逻辑一致性	修改了函数签名但没更新调用方，导致后续所有步骤基于错误假设 ¹⁹
鲁棒性与纠错	面对报错或意外反馈时的恢复能力	遇到 flaky test 或环境配置问题时，能诊断出「这不是代码的 Bug」而非无限重试 ¹⁶

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

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

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

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

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

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

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

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

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

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

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

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

六、结语与研究展望

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

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

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

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

References

On Training Large Language Models for Long-Horizon Tasks: An Empirical Study of Horizon Length, arXiv:2605.02572 ↩︎
AgentDiet: Reducing Cost of LLM Agents with Trajectory Reduction, arXiv:2509.23586 ↩︎ ↩︎ ↩︎
ISE: An Execution-Grounded Recipe for Multi-Turn OS-Agent Trajectories, arXiv:2606.11520 ↩︎ ↩︎
WRIT: Write-Read Intensive Trajectory Synthesis for Multi-Turn User-Facing Agents, arXiv:2606.02908 ↩︎ ↩︎
KLong: Training LLM Agent for Extremely Long-horizon Tasks, arXiv:2602.17547 ↩︎
Agent Data Protocol: Unifying Datasets for Diverse, Effective Fine-tuning of LLM Agents, arXiv:2510.24702 ↩︎
TDScaling: Beyond Quantity: Trajectory Diversity Scaling for Code Agents, arXiv:2602.03219 ↩︎
COVERT: Controllable and Verifiable Tool-Use Data Synthesis for Agentic Reinforcement Learning, arXiv:2604.09813 ↩︎
LOGIGEN: Logic-Driven Generation of Verifiable Agentic Tasks, arXiv:2603.00540 ↩︎
AgentHER: Hindsight Experience Replay for LLM Agent Trajectory Relabeling, arXiv:2603.21357 ↩︎
LATR: Lookahead Tree-Based Rollouts for Enhanced Trajectory-Level Exploration in Reinforcement Learning with Verifiable Rewards, arXiv:2510.24302 (ICLR 2026) ↩︎
MARTI: Scaling Multi-Agent Self-Search via Reinforcement Learning for Code Generation, arXiv:2602.07848 ↩︎
Rethinking Expert Trajectory Utilization in LLM Post-training, arXiv:2512.11470 ↩︎
Don't Just Fine-tune the Agent, Tune the Environment, arXiv:2510.10197 ↩︎
BOOST: Bilevel Optimization of Synthetic Trajectories for Multi-Turn LLM Fine-Tuning, arXiv:2605.24743 ↩︎
TSR: Trajectory-Search Rollouts for Multi-Turn RL of LLM Agents, arXiv:2602.11767 ↩︎ ↩︎ ↩︎
TRACES: Proactive Safety Auditing for Multi-Turn LLM Agents via Trajectory-State Modeling, arXiv:2605.27690 ↩︎
H-EPM: Experience-Evolving Multi-Turn Tool-Use Agent with Hybrid Episodic-Procedural Memory, arXiv:2512.07287 ↩︎
Agentick: A Unified Benchmark for General Sequential Decision-Making Agents, arXiv:2605.06869 ↩︎ ↩︎
HORIZON: The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break, arXiv:2604.11978 ↩︎
CodeTracer: Towards Traceable Agent States, arXiv:2604.11641 ↩︎
ASTRA: Automated Synthesis of agentic Trajectories and Reinforcement Arenas, arXiv:2601.21558 ↩︎
SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios, arXiv:2512.18470 ↩︎

Long Trajectory | Xwell's Blog