别让 Agent 越用越"脑雾"：ContextPilot 用细粒度 RL 教模型主动整理自己的工作上下文
上周读了一篇让我眼前一亮的论文（arXiv: 2608.28476，EMNLP 2026 主会接收）。说实话，这两年"上下文管理"这个词被说得很多，但大多数工作要么停留在 prompt 工程层面，要么就是把轨迹级奖励粗暴地平均分给每一个中间动作——后者其实是个挺隐蔽的坑：模型答对了一道题，可能纯粹是运气好，而它在过程中那些乱删上下文的操作反而被正奖励强化了。ContextPilot 这篇论文把这个坑摆到了台面上，并且给了一个我觉得相当漂亮的解法。
核心摘要：长程 Agent 任务中，模型需要在几十上百轮交互里不断检索、整合信息，工作上下文越滚越大，最后不是爆窗口就是"脑雾"——早期关键信息被淹没。ContextPilot 给 Agent 配了一套 16 个工具的上下文管理工具箱（新增规划、长期记忆、软卸载三类），更关键的是提出了一套专门为上下文管理设计的 RL 方法：用"上下文变化量 + 熵变化量"识别出哪些编辑动作真正影响结局，在这些关键动作处做分支采样，再用所有经过该动作的分支轨迹的平均奖励来估计动作级优势。结果很能打：8B 模型只用 32K 上下文窗口，平均分反超 128K 窗口的原模型 23 个点以上，比此前的 StateLM-8B-RL 高出 3.55 分。我的判断：这是上下文管理方向把"信用分配"问题真正认真对待的第一批工作，值得细读。
论文信息 - 标题：ContextPilot: Teaching Agents for Proactive Context Management via Fine-grained RL - 作者：Zhuoshi Pan, Qizhi Pei, Junru Lu, Honglin Lin, H. Vicky Zhao, Di Yin, Xing Sun - arXiv：https://arxiv.org/abs/2608.28476 （2026 年 8 月 28 日提交，EMNLP 2026 Main Track） - 代码：https://github.com/Tencent/ContextPilot
🎯 问题：上下文越攒越多，Agent 越用越糊涂
先说场景。你让一个 Agent 去做深度搜索，比如"找一位 70 年代在高中组了支乐队的吉他手，乐队以多语言良知音乐闻名，他 2003 年去世"。这种题要搜十几轮、访问几十个网页，每一轮的搜索结果、网页内容都堆在上下文里。跑到 60 轮的时候，上下文早就爆了。
传统的解法大概三类：直接截断早期的消息（丢信息）、定期让外部模型做摘要（信息有损且打断推理）、或者干脆把窗口开大（贵且慢，而且长上下文本身就会让模型"迷失在中间"）。
最近兴起的思路是让模型自己管理自己的上下文——给它 search、delete、summarize 这些工具，让它主动清理工作区。StateLM 就是这条路的代表。但论文指出这条路有三个没解决好的问题：
- 工具太少：只有搜索、删除、摘要，没有全局规划能力，没有长期记忆，删除是不可逆的硬删除；
- 探索效率低：RL 训练时对所有上下文管理动作一视同仁，但一次"删掉关键证据"和一次"删掉无关网页"对最终结局的影响天差地别；
- 信用分配太粗：整条轨迹最后拿一个奖励，然后所有中间动作共享这个奖励——这就是典型的粗粒度信用分配问题。
第三个问题我觉得是最要命的。论文里举了两个真实案例，都是 StateLM-8B 在 BrowseComp+ 上的轨迹：
- 案例一：模型答对了，但全程几乎没做上下文管理，就是暴力地 search、readChunk 重复检索了十几次。按轨迹级奖励，这种"躺赢"行为会被强化；
- 案例二：模型答错了，但过程中规规矩矩地 note、updateNote、delete、readNote，上下文管理做得相当漂亮。按轨迹级奖励，这些好动作反而被惩罚。
奖励和行为质量完全错位。你想想看，用这种信号训练，模型学到的只能是"别碰上下文管理工具，闷头搜就完事了"。
🏗️ 方法：一手扩建工具箱，一手改造 RL 算法
图 1：ContextPilot 框架总览，三个面板正好对应论文的三块核心贡献——工具集、分支采样策略、动作级信用分配
整个框架分两半：工具箱扩建和 RL 算法改造。
工具箱：从 3 个工具扩到 16 个
ContextPilot 在 StateLM 的基础上把工具集扩到四大类 16 个，新增 8 个（标 🆕）：
| 类别 | 工具 | 作用 |
|---|---|---|
| 感知与规划 | analyzeText、checkBudget、plan 🆕 | 量上下文长度、查 token 预算、制定计划 |
| 信息检索 | buildIndex、searchContext、readChunk、readMultiChunks | 建索引、搜索、读单个/多个上下文块 |
| 记忆管理 | note、updateNote、readNote、memorize 🆕、updateMemory 🆕、readMemory 🆕 | 临时笔记 + 结构化长期记忆 |
| 上下文卸载 | deleteContext、summarizeContext 🆕、compressContext 🆕、foldHistory 🆕 | 删除、摘要替换、压缩、折叠全部历史 |
这里面有几个设计我觉得挺讲究的：
软卸载（soft offloading）。老工具集的 deleteContext 是硬删除，删了就没了。新增的 foldHistory 是把全部历史折叠成"关键词 + 摘要"，之后还能通过 searchContext 用关键词把原文捞回来。这相当于给 Agent 一个"后悔药"——先扔出去腾地方，真需要的时候再检索恢复。compressContext 则接了一个轻量压缩模型（LLMLingua-2）做无损感更强的压缩。
结构化长期记忆。memorize 不只是记一句话，它提取实体、时间戳、事件片段这些结构化信息，并且在相关记忆项之间建边——readMemory 取回目标记忆时会连带把邻居也捞出来。这其实就是一个小型记忆图，比扁平的 note 列表表达力强不少。
规划工具。plan 让模型在开工前先写个简洁计划，配合 checkBudget 查预算，让上下文管理从"被动应急"变成"主动规划"。
消融实验（后面细说）证明这三类新工具不是摆设：在 Qwen3.5-397B 这样的强模型上，光靠工具集扩建就把 BrowseComp+ 从 63.49% 拉到 80.96%。
RL 改造：把钱花在刀刃上
工具再好，模型得会用。这里就是 RL 的部分，也是我觉得这篇论文最值钱的地方。
问题设定是：一条轨迹在上下文编辑动作处被切成若干快照（snapshot），每个快照是一个独立的训练实例。传统做法（包括 StateLM）是整条轨迹跑完拿一个奖励，所有快照共享。
ContextPilot 的解法分两步。
第一步：找到关键动作，在那里多采样。对每一个上下文管理动作，算两个量：
上下文变化量，就是这个动作让上下文长度变了多少：
熵变化量，看这个动作之后模型生成 token 的不确定性比轨迹开头变化了多少：
这里 \(H_t^{cm}\) 是第 \(t\) 步观测之后生成的 \(k\) 个 token 的平均熵，\(H_{initial}\) 是轨迹开头前 \(k\) 个 token 的平均熵。有个细节值得注意：参照点用的是初始熵而不是上一步的熵。作者的考虑是，他们要识别的是"相对初始查询状态引起显著不确定性变化"的动作，而不是相邻步之间的局部抖动。说实话这个设计动机我觉得是合理的，但多少也有点工程拍脑袋的味道——好在消融里验证了它比纯熵方案稳。
两个量加权合成敏感度得分（实验中 \(\alpha = 1, \beta = 1\)）：
然后进入分支采样：每个 query 的预算是 128 个快照。先跑 8 条完整轨迹，切成最多 64 个快照；剩下的预算，把动作按敏感度降序排，挑 top 的动作作为分支点，从它们的父节点重新采样子轨迹，把快照池补满。直觉就是：影响大的岔路口，多走几遍看看不同走法的后果。
第二步：动作级优势估计。终端快照的奖励由结果奖励、格式奖励和惩罚项（惩罚无效工具调用和上下文超长）组成。关键在中间快照：一个中间快照 \(S_i\) 的奖励，取所有以它为前缀的终端轨迹的奖励均值：
然后在组内做 GRPO 式的均值-标准差归一化得到优势，每个快照当独立样本优化。
附录里给了一个简洁的理论支撑：把信用估计看成一个条件期望 \(Q(S) = \mathbb{E}[R(T) \mid S \preceq T]\)，传统方法用单条轨迹的奖励做估计，条件方差是 \(\sigma^2(S)\)；而用 \(n_S\) 条分支轨迹的均值做估计，方差降到 \(\sigma^2(S)/n_S\)。两者都无偏，但后者均方误差严格更小。这个分析不复杂，但把"为什么要分支采样"讲清楚了——说到底就是方差缩减，而且敏感度导向的分支采样恰好让影响大的动作获得更大的 \(n_S\)。
SFT 数据怎么造
RL 之前还有一步 SFT 冷启动（仅长上下文 QA 任务用，深度搜索任务因为基座模型已有搜索能力，直接 RL）。数据合成用了一个"脚手架"机制：教师模型（Qwen3.5-397B-A17B，thinking 模式）在生成时被规则引导——比如上下文超阈值时只允许用卸载工具、没建记忆前 readMemory 不可用、参数错了要返回针对性提示重试。这些脚手架只存在于生成过程，不进最终轨迹。3,196 个问题经过结果过滤、过程过滤（GPT-OSS-120B 把关管理行为质量）、峰值长度过滤（卡 32K），剩 3,068 条轨迹，切成 51,469 个 SFT 快照。
顺带一提，训练沿用了 StateLM 的 token 级损失掩码：前面快照里已经出现过的输出不再重复计算损失，避免对早期工具调用的重复优化。
📊 实验：32K 窗口打赢 128K，还不是险胜
长上下文 QA
四个基准：NovelQA、∞Bench（都超 100K token 的超长文档）、LongMemEval-S、BrowseComp+（平均输入 552K token，最狠的一个）。
| 方法 | 窗口 | NovelQA | ∞Bench | LongMemEval-S | BrowseComp+ | 平均 |
|---|---|---|---|---|---|---|
| Qwen3-8B（无工具） | 128K | 65.74 | 66.96 | 45.20 | 5.82 | 45.93 |
| Qwen3-8B（给工具，不训练） | 32K | 38.09 | 39.59 | 24.47 | 8.28 | 27.61 |
| StateLM-8B-RL | 32K | 84.15 | 73.07 | 59.73 | 46.44 | 65.85 |
| ContextPilot-8B（仅 SFT） | 32K | 82.56 | 71.03 | 60.67 | 48.84 | 65.78 |
| ContextPilot-8B-RL | 32K | 83.88 | 75.25 | 64.27 | 54.18 | 69.40 |
| Qwen3-14B（无工具） | 128K | 78.03 | 74.53 | 54.20 | 6.27 | 53.26 |
| ContextPilot-14B-RL | 32K | 84.81 | 81.08 | 67.40 | 55.50 | 72.20 |
| Gemma4-E4B-it（无工具） | 128K | 48.75 | 39.74 | 28.50 | 7.03 | 31.01 |
| ContextPilot-E4B-RL | 32K | 72.92 | 60.99 | 62.47 | 47.47 | 60.96 |
几个数字值得停下来看。
8B 模型、32K 窗口，平均分 69.40，比同模型开 128K 窗口的 45.93 高出 23 个多点。这不是小修小补，是量级差异。
还有个很扎眼的对比：Qwen3-8B 直接给同样的工具但不训练，平均分反而从 45.93 掉到 27.61。工具给了不会用，比没有还糟——模型被工具调用搞得手忙脚乱。这个结果反过来说明了 SFT + RL 训练的必要性，也堵住了"是不是工具本身厉害"的质疑。
对 StateLM 的超越幅度是平均 3.55 分（8B）和 2.09 分（14B）。说实话，如果只看 NovelQA，StateLM-8B-RL 的 84.15 还略高于 ContextPilot-8B-RL 的 83.88——优势主要来自更难的任务，BrowseComp+ 上 54.18 对 46.44，差了快 8 分。论文自己也点了这个规律：任务越复杂、输入越长，细粒度 RL 的收益越大。这个 pattern 是符合直觉的，短任务里上下文管理本来就没什么发挥空间。
深度搜索
基座换成 WebSailor-7B 和 WebExplorer-8B，基线包括 ReAct、截断版 ReAct、ReSum（外部模型做摘要）、SUPO（RL 联合训练摘要能力）、OpenSeeker（同样 RL 但无管理工具）。
| WebSailor-7B | BrowseComp | BrowseComp-ZH | GAIA | xBench-DS | 平均 |
|---|---|---|---|---|---|
| ReAct | 11.33 | 25.47 | 31.07 | 34.00 | 25.47 |
| ReSum | 15.83 | 38.99 | 38.19 | 35.33 | 32.09 |
| SUPO | 18.50 | 42.68 | 42.07 | 42.00 | 36.31 |
| OpenSeeker | 16.50 | 41.87 | 41.42 | 43.33 | 35.78 |
| ContextPilot | 21.17 | 43.14 | 45.31 | 43.67 | 38.32 |
WebExplorer-8B 上同样是全面领先（平均 50.10 对 SUPO 的 49.09）。两个基座上平均比最强的 SUPO 高 1.51 分。幅度不算爆炸，但要注意 SUPO 已经是这条赛道上很强的基线了，而且 ContextPilot 在四个基准上全部第一，没有短板项。
token 效率
这个分析我很喜欢：取交互轮数超过 15 轮的轨迹，看每轮平均输入 token 数。WebExplorer-8B 基线的输入长度随轮数近乎线性增长，最终到每轮 30K token 左右；ContextPilot-8B 稳定在每轮 8K–10K。也就是说性能提升不是靠偷偷多看内容换来的，工作上下文反而压缩了三分之二以上。
消融：每个组件都在干活
工具消融（在 Qwen3.5-397B 上逐级加工具）：原始工具 77.89 → 加规划 80.29 → 加软卸载 83.08 → 加长期记忆 87.16。单调上涨，尤其是长期记忆在 BrowseComp+ 上从 71.20 拉到 80.96，涨了近 10 分。
RL 算法消融（Qwen3-8B）：SFT 65.78 → 普通 GRPO 66.84 → 只用熵做 partial rollout 66.84 → 加上下文变化量 67.37 → 加细粒度信用分配 69.40。有个细节：只用熵的方案在 BrowseComp+ 上反而掉了 1.32 分，说明纯熵信号不稳；加入上下文变化量之后才稳下来。而最后的细粒度信用分配贡献最大，平均直接加了 2.03 分——这验证了论文的核心论点：信用分配粒度才是这类任务的命门。
另外训练动态的分析也有意思：RL 初期大约一半工具调用是检索类，训到后面检索类占比下降，规划、记忆、卸载类占比上升，同时记忆类和卸载类工具的调用失败率大幅下降。模型是真的在学"怎么管"，不只是"多管"。
🤔 我的判断
亮点：
一是问题定义得准。上下文管理的 RL 训练里信用分配错位，这个问题之前大家都隐约知道，但这篇用"答对但管理差 / 答错但管理好"两个案例把它钉死了，然后给了一个理论上有方差缩减保证、工程上可落地的解法。
二是敏感度得分的双信号设计。上下文变化量管"这个动作客观上动了多少"，熵变化量管"这个动作让模型主观上多纠结"，两个互补。消融证明缺一个都不稳。
三是工具集本身就有独立价值。foldHistory 的可恢复折叠、带边的记忆图，这些设计即使不训练，接在强模型上就能拿到明显收益。
值得泼点冷水的地方：
SFT 数据完全靠 Qwen3.5-397B 教师蒸馏，过程过滤又用 GPT-OSS-120B—— pipeline 对强教师模型的依赖不轻，小模型团队复现成本不低。另外敏感度得分里 \(\alpha = \beta = 1\) 的等权设定看起来没仔细调过，\(\Delta C\) 和 \(\Delta H\) 量纲完全不同，简单相加的理论依据偏弱，这块或许还有调参空间。深度搜索上 1.5 分的领先幅度，坦白说也不算压倒性。
但总的来说，这篇论文把"主动上下文管理"从 prompt 技巧推进到了有理论支撑的 RL 训练范式，而且工具、算法、数据三块都开源了。如果你在做长程 Agent——不管是深度搜索、代码 Agent 还是多轮任务——这个"在关键编辑动作处分支采样 + 快照级优势"的思路基本可以直接搬。我的判断是：这类细粒度信用分配会成为 Agent RL 的标配组件，就像当年 GRPO 之于推理模型一样。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我