别再给 Agent 写脚手架了：阿里这篇论文想直接把"越用越聪明"训进模型里

你有没有这种体验：刚部署的 AI Agent 第一周还挺机灵，结果用着用着就开始反复踩同一个坑。同样的命令报错，它换个姿势再报一遍；同样的环境特性，它每次都得从头试探一遍。你忍不住想——它怎么就记不住呢？

我们现在的解法基本都是绕过去：给它套一层精心设计的脚手架（agent scaffold），手动维护一份记忆库，写一堆规则告诉它"上次失败了别再这么干"。说实话，这些东西能 work，但本质上是人在替模型连点成线。模型自己并没有学会"在一个陌生环境里持续探索、从经验里提炼认知、然后越做越好"这件事。

阿里这篇 6 月刚挂出来的 CoD（Connect the Dots，arXiv:2606.20002）就是冲着这个问题去的——他们想把这种"连点成线"的能力，当成一个可以被强化学习直接训练出来的元能力，而不是靠外挂脚手架硬凑。

一句话核心摘要

这篇论文提出 CoD（Connect the Dots）框架：把"持续探索环境 → 从自己的经验里学习 → 迭代更新对环境的上下文认知 → 在后续任务上越做越好"这一整套行为，定义为长生命周期 Agent 必备的元能力，并用端到端强化学习直接把它训进 LLM 权重里。技术上的关键是一条超长 rollout——把多个"解任务 episode"和"更新上下文 episode"交错串成一条轨迹，配合 GRPO 风格的细粒度信用分配来训练。在 FrozenLake-Obscure 上，从零解题成功率从 18% 提到 45%，而序列中第 4 个任务（基于自己更新的上下文）的成功率从 28% 直接干到 76%。更值钱的是：这套元能力展现出了跨域泛化潜力——训练域之外的 Alchemy、终端模拟器、甚至 Ralph-loop 设定下都看到了提升。

我的判断先放这儿：这是一篇定义问题比解决问题更重要的论文。它的实验规模其实不大，环境也偏玩具，但它把"长生命周期 Agent 该怎么训"这件事的 RL 抽象讲清楚了，这个抽象本身就有价值。下面细聊。

论文信息

  • 标题：Connect the Dots: Training LLMs for Long-Lifecycle Agents with Cross-Domain Generalization Via Reinforcement Learning
  • 作者：Yanxi Chen, Weijie Shi, Yuexiang Xie, Boyi Hu, Yaliang Li, Bolin Ding, Jingren Zhou（阿里巴巴团队）
  • 链接：https://arxiv.org/abs/2606.20002 （提交于 2026 年 6 月 18 日）
  • 开源：基于 Trinity-RFT 框架，代码已放出（agentscope-ai/Trinity-RFT 的 research/cod 分支）

🎯 先把问题讲清楚：什么叫"连点成线"

作者对 CoD 的定义其实挺干净的：

在某个环境里长期部署期间，AI Agent 持续解决一系列不同但相关的任务，同时主动且有意识地探索环境、自我更新它关于这个环境的上下文，从而在未来更高效地解决同一环境里的任务。

注意三个词：环境、任务序列、上下文。

拆开看就是这么个循环：Agent 进入一个陌生环境 → 解第一个任务（大概率磕磕绊绊，因为啥都不知道）→ 把这次的经验提炼成"上下文"（论文里管它叫 hint）→ 带着这份上下文去解第二个任务 → 再更新上下文 → 解第三个……越往后，它对这个环境的认知越完整，解题就越顺。

这事儿听起来像在线学习（online learning），但有个关键区别：整个过程是无梯度的。模型权重不变，靠的是上下文（文本）的迭代来"学习"。这就是为什么它能在测试时持续进步——它不需要重新训练，只需要不断改写自己手里的那份"环境笔记"。

那问题来了：现在的 LLM 不是已经有 in-context learning 能力了吗？为什么还要专门训？

作者的观察是——现成的前沿 LLM 在这件事上做得并不好。在那些"欠规约"（underspecification，即环境信息不完整、规则需要自己摸索）的场景里，CoD 元能力弱的 Agent 很容易迷失方向，必须靠人工脚手架兜底。换句话说，"主动探索 + 提炼经验 + 复用认知"这套组合拳，现在的模型是被动会一点，但不会主动、不会做好。所以得显式地训。

这里我得说句公道话：作者这个痛点不是伪命题。任何做过 Agent 长程任务落地的人都知道，记忆和经验复用是真痛点，现在主流方案确实是外挂 memory + 人工 prompt 工程。把它端到端训进模型，方向上我是认同的。

🏗️ 框架：把 rollout 的"颗粒度"再往上抬一层

这张图是整篇论文的灵魂，值得多看两眼：

图1：CoD-Deploy 与 CoD-Train 的对比，以及与标准逐任务 RL 的区别

图1：上半部分是 CoD-Deploy——实际部署时 Agent 在环境 M 中的行为：解任务 \(x_0^M\) → 更新上下文 \(z_1^M\) → 解 \(x_1^M\) → 更新 \(z_2^M\)……交错进行。左下角是标准的逐任务 RL，每个任务从零单独解，块与块之间没有联系（红叉表示与长生命周期目标"不对齐"）。右下角是 CoD-Train，rollout 模式和 CoD-Deploy 完全一样，跨 A、B 等多个不同环境训练以求泛化（绿箭头表示"对齐"）。

框架分两块，名字起得很直白：

CoD-Deploy 是部署侧的抽象，就是 Agent 在真实环境里跑的那个循环——解任务和更新上下文两类 episode 交错。可以理解成通过试错进行的、无梯度的在线学习。

CoD-Train 是训练侧的 RL 后训练机制。它的 rollout 模式跟 CoD-Deploy 一模一样，区别只是它会覆盖多个不同环境（图里的 A、B），目的是逼出能泛化的元能力。

这里有个我觉得特别漂亮的视角——rollout 轨迹定义的层级演进：

层级 轨迹是什么 对应场景
第一层 token 序列 单轮任务（RLHF、RLVR）
第二层 轮次序列（sequence of turns） 长程多轮 Agent 任务
第三层 任务序列（sequence of tasks） CoD-Train：长生命周期部署

你看，RLHF 时代我们优化的是一个 token 序列；Agent 时代我们优化的是一串多轮交互；而 CoD 直接把颗粒度抬到了一整串任务。一条 rollout 不再是"解一道题"，而是"在一个环境里连续解好几道题、中间还穿插着更新认知"。这个抬升非常自然，但也带来了一个棘手的新问题——

信用分配（credit assignment）该怎么做？

🔧 核心难点：跨 episode 的信用怎么分

想象一条 rollout：解任务0 → 更新上下文1 → 解任务1 → 更新上下文2 → 解任务2……

现在解任务2 成功了，奖励很高。这个功劳该记给谁？记给"解任务2"这个 episode 本身，还是记给前面那次"更新上下文"——正是因为它把环境笔记记好了，任务2才解得顺？

这就是经典的时序信用分配问题。作者搬出了动态规划的老祖宗 Bellman（1957）的原则：每个 episode 不光要最大化当下的即时奖励，还要最大化它对未来的贡献。

具体怎么算？看这张图：

图2：CoD-Train 定制 RL 算法的优势计算示意

图2：信用分配与优势计算的可视化。同一个任务序列跑 G 条轨迹（Trajectory 1 到 G）。粉色虚线框表示某个 episode 的回报 = 当前及未来所有奖励的平均（average of current & future rewards）；蓝色虚线框表示基线 = 同一位置所有轨迹回报的平均（baseline = average return at the same position）。

我把核心公式拎出来。设任务序列有 \(S\) 个任务，每个序列跑 \(G\) 条 rollout，\(r^x_{i,j}\) 是第 \(i\) 条轨迹里解任务 \(j\) 的奖励。

回报（return）= 当前及未来所有解任务奖励的均值（也就是 reward-to-go 取平均）：

\[R^x_{i,j} = \frac{1}{S-j}\sum_{j\leq\ell\leq S-1} r^x_{i,\ell}\]

更新上下文那个 episode 的回报也类似，把它自己的格式奖励和后续解任务奖励一起平均进来。

基线（baseline）= 同一位置上所有 G 条轨迹的平均回报：

\[\overline{R}^x_j = \frac{1}{G}\sum_{1\leq i\leq G} R^x_{i,j}\]

优势（advantage）= 回报减基线：

\[A^x_{i,j} = R^x_{i,j} - \overline{R}^x_j\]

这套设计的精妙之处在哪？它没有引入 critic 模型（GRPO 的传统优点），而是把同一序列位置上的多条轨迹当成一组来算基线。也就是说，"在第 3 个位置上，你这条轨迹比同组其他轨迹的平均表现好多少"——这个相对量就是优势。这样一来，那次记笔记记得好的 update-context episode，会因为它带来的后续高回报而拿到正优势，被强化。

说到 GRPO，这里和原始版本有个本质区别值得点一下：原始 GRPO 假设每条轨迹只有一个结果奖励，而 CoD 这里每条轨迹是一串 episode、一串奖励。所以不能直接套 GRPO，得做这套细粒度的 reward-to-go 改造。这也是论文相比 Orbit（用 GRPO 但粗粒度信用分配）等同期工作的差异化所在——不假设 anchor states，细粒度分配支持更广的训练设置。

训练不稳定，和它的解法

光有信用分配还不够。作者在实践中踩了个坑：在 Alchemy-Random 这个域上，去掉重要性采样权重的那版算法（他们叫 REC-OneSide-NoIS）训练不稳定——平均优势指标 \(\sum_i A_i/N\) 从负值开始持续往下掉，正负梯度严重失衡。

等等，平均优势为什么会是负的、还一直掉？这地方论文没展开太细，我的理解是：当大部分采样轨迹都偏差时，组内基线被拉低，但梯度更新的方向被少数负优势 token 主导，越训越偏。

他们的解法是给梯度加一个自适应的 token 级重加权（公式3），当批次平均优势为负时启动：

\[\bm{g} = \frac{1}{N}\sum_{1\leq i\leq N}\nabla_{\bm{\theta}}\log\pi_{\bm{\theta}}(i)\cdot A_i\cdot\exp\Big(\frac{A_i}{T}\Big)\cdot M_i\]

温度 \(T\) 用二分法自适应选取，让重加权后的平均优势大致归零，同时硬约束 \(T>0.8\) 防止数值爆炸。思路上类似 RED-Weight，但目的不同。实测下来，这版是三种方案里训练最稳的。

我对这块的态度是：这是个工程补丁，不算优雅的理论突破。它解决了具体的不稳定问题，但"为什么会不稳定"的根因分析还不够深。不过对于一篇 work in progress 的论文，能把坑填上、把曲线跑稳，已经够诚实了。

🧪 实验：玩具环境，但讲清楚了故事

先说环境设计，这块其实是论文很用心的地方——标准 RL 数据集和 LLM benchmark 不一定适合 CoD，因为它们大多是逐题独立的，激励不了"更新上下文"这个行为。所以作者自己造了三个环境：

FrozenLake-Obscure：经典冰湖的变体，但动作变成了 A/B/C/D，每个新环境里 A/B/C/D 到上下左右的映射随机打乱且事先不告诉你。这就施加了一个信息论硬限制——单独解一道题，成功率有天花板（比如起点被三个洞围着，第一步乱走平均 75% 概率掉坑）。好的 hint 应该包含 Agent 自己推出来的"A/B/C/D 到底对应哪个方向"。这是 CoD 的最小健全性测试。

Alchemy-Random：炼金术变体，每个环境有自己的元素和配方（哪两个能合成哪个），随机初始化后固定。任务是限定步数内合成目标元素，一开始啥配方都不知道。好的 hint 应该记下有效配方、失败组合和解题技巧。比冰湖更丰富、难度范围更广。

TerminalSimulator：模拟 Linux/Mac/Windows 终端的日常文件操作任务，只用于跨域评估。

每个数据集 5 万训练实例 + 4 千测试实例，分 Easy/Hard 两档。

主结果：第 4 个任务从 28% 干到 76%

核心实验有两个设置：Setting A 只在 FrozenLake-Obscure 上训，Setting B 在 FrozenLake-Obscure + Alchemy-Random 混合域上训。都从 Qwen3-8B-Instruct（关掉 thinking）起步，任务序列训练时长度 4、评估时拉长到 8。

先看 Setting A：

图3：Setting A 在 FrozenLake-Obscure 上的训练 reward 曲线

图3：Setting A 训练过程中四个位置（pos 0 到 pos 3）的 reward 曲线，窗口大小 17 滑动平均。pos 0 是没有任何上下文、从零解初始任务；pos 3 是基于已经更新了三轮的上下文来解第 4 个任务。可以清楚看到 pos 3（黄色）始终高于 pos 0（紫色），且差距随训练拉大。

关键数字：

指标 训练前 训练后
位置 0（无上下文，从零解题） 0.18 0.45
位置 3（基于自更新上下文解第 4 个任务） 0.28 0.76

读这张图我的第一反应是：pos 0 能从 0.18 涨到 0.45 其实已经说明模型本身解题能力变强了（即使没上下文）；但真正的看点是 pos 3 涨到了 0.76——这 0.76 减去 pos 0 的 0.45，那 0.31 的差距，就是"连点成线"这个元能力的净贡献。模型确实学会了利用自己积累的笔记。这个 gap 才是论文想证明的东西。

更进一步，作者验证了几种泛化：

  • 域内 OOD：用更难的环境实例 + 更长的序列评估，结论一致；
  • 跨域：在 Alchemy-Random 和 TerminalSimulator 上也看到提升——这是从 FrozenLake 训出来的能力迁移过去的；
  • CoD → Ralph-loop：在"重复尝试同一任务"的 Ralph-loop 设定下后期 episode 拿到更高奖励。

Setting B（混合域训练）的曲线：

图4：Setting B 在混合域上的训练结果

图4：Setting B 在 FrozenLake-Obscure 与 Alchemy-Random 混合域上的训练 reward 曲线，同样窗口 17 平滑，评估曲线 step 0 对应初始 Qwen3-8B-Instruct。

老实说 Setting B 的曲线不如 Setting A 干净——Alchemy-Random 那条训练曲线出现了轻微的性能退化，评估奖励早期窜得快、后期开始抖。作者也没藏着掖着，直接承认了。混合域训练更难稳定，这个结果我反而觉得真实。

一个有意思的细节：终端任务的"两面性"

TerminalSimulator 的评估里藏了个我觉得很值得玩味的现象：

  • 在 CoD-Deploy 设定（序列里是不同任务）下，后期任务相比早期没有性能提升——因为当前实现里同一序列的不同终端任务之间没啥关联，更新上下文帮不上忙；
  • 但在 Ralph-loop 设定（反复尝试同一个任务）下，后期 episode 确实拿到了更高奖励。

作者由此推测：通过 CoD-Train 学到的"更新并利用上下文"这个元能力，在单个 solve-task episode 内部也是有用的。这个推测我挺买账的——它暗示 CoD 训出来的不只是"跨任务记笔记"，而是一种更底层的"边做边总结"的习惯。

消融：三版算法谁更稳

图5：三种 RL 算法的对比

图5（附录A）：三种 RL 算法在 Alchemy-Random 上的训练 reward 对比，窗口 17 平滑。Vanilla GRPO（公式1）和 REC-OneSide-NoIS（公式2）都出现不稳定/退化，最终的自适应重加权算法（公式3）最稳。

消融比的不是"加不加某个组件涨多少点"，而是三版梯度估计哪个训得稳。结论是公式3（自适应重加权）胜出。这其实回扣了前面"训练不稳定"那节——消融的核心是稳定性，不是绝对性能。

🤔 我的判断：这论文到底值不值得读

先说亮点：

  1. 问题抽象漂亮。把 rollout 颗粒度从 token → turns → tasks 抬升这个视角，是真的提供了新的思考框架。"长生命周期 Agent 该怎么训"这个问题，被它讲成了一个干净的 RL 问题。
  2. 诚实。Setting B 不稳就说不稳，终端任务没提升就说没提升，训练踩坑就把坑和补丁都写出来。这种 work in progress 的坦诚比那些"全面 SOTA"的论文舒服多了。
  3. 细粒度信用分配的工程价值。不假设 anchor states、基于 reward-to-go + 同位置组内基线的设计，确实比粗粒度信用分配更通用。

再说我皱眉的地方：

  1. 环境太玩具。FrozenLake、炼金术、终端模拟器——都是高度受控的合成环境。从 18% 到 76% 这种数字在玩具环境里很好看，但离真实的长程 Agent 落地（代码库维护、多轮客服、科研助手）还有相当距离。跨域泛化的"域"也都还在合成环境内部。
  2. 上下文实现太简化。当前的"上下文"就是一段贴到 system prompt 里的 hint 文本。作者自己也说未来要做持久记忆库、Markdown 形式的 Agent Skills。所以现在验证的更像是"概念能不能 work"，而不是"工程上够不够强"。
  3. 规模有限。单模型 Qwen3-8B，没有更大规模或多模型的对比，泛化结论的说服力会打点折扣。

所以我的定位是：这是一篇"插旗"性质的论文，价值在于定义和框架，而非碾压式的实验结果。如果你在做 Agent 的记忆/经验复用、或者在思考"怎么把 in-context learning 能力训进模型"，这篇值得精读，尤其是信用分配那部分的设计。如果你想找一个能直接上生产的方案，那它还没到那一步——但它指的方向，我觉得是对的。

💡 给工程实践的一点启发

如果你也在做长程 Agent，CoD 这套思路有两个点可以直接借鉴：

第一，把"更新记忆"也当成一个可被优化的动作，而不是固定的后处理。 现在很多 Agent 的 memory 写入是规则化的、或者用一个独立模型干的。CoD 提醒我们：记笔记这件事本身的质量，会反过来影响后续解题表现，所以它值得被纳入 reward 信号一起优化。

第二，rollout 设计可以往上抬一层。 别只盯着单任务的轨迹，试试把一串相关任务串成一条长 rollout 来训，用 reward-to-go 做跨任务的信用分配。哪怕你不做完整的 CoD，这个思路对"让模型学会跨任务复用经验"也有帮助。

当然前提是——你得先有一个能激励"更新上下文"行为的环境。这恰恰是 CoD 花了大力气设计 FrozenLake-Obscure 这类环境的原因。标准 benchmark 大多激励不了这个，得自己造。

最后留个开放问题给大家想想：CoD 现在的"上下文"是纯文本 hint，本质还是在 prompt 里塞东西。当任务序列足够长、环境足够复杂时，这份 hint 迟早会爆 context window。到那时候，是该上结构化记忆、向量检索，还是干脆把学到的东西蒸馏回权重？这可能才是"长生命周期"真正的终极拷问。

arXiv:2606.20002，感兴趣的可以去翻原文和它的开源实现。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我