2.2.1 · 训练式压缩与提交链

2026 年 5—7 月的一批 Long-Horizon Agent 工作分别处理训练、服务、状态表示和检索。压缩后的文本长度只是表象，真正影响任务的是状态保真度、恢复能力和运行成本。

1. 训练式上下文管理

上下文压缩已经分出几条机制不同的路线：训练模型决定何时压缩、优化并行 serving，以及直接学习与 Agent 行为兼容的状态表示。

四项工作的差别集中在压缩对象、训练信号和压缩后的继续执行方式上。

1.1. CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents

CompactionRL把压缩决策放进策略学习，而不是把摘要器当作固定预处理器。

它用任务终局信号同时训练执行与摘要，使压缩前的决策仍能从压缩后的结果获得信用。

机构: 清华大学(Yujiang Li, Zhenyu Hou, Yi Jing, Jie Tang, Yuxiao Dong), 2026.07.
动机: 长程轨迹容易超出上下文窗口, 传统压缩通常独立于 Agent 训练, 摘要质量与任务目标并不一致.
方法: 将任务执行与上下文摘要纳入同一 RL 轨迹, 通过 token-level loss normalization 和跨轨迹 GAE 联合学习行动, 压缩及压缩后的继续推理.

Parallel Context Compaction for Long-Horizon LLM Agent Serving。 Parallel Context Compaction把 serving 路径中的停顿和吞吐列为主要评测对象，摘要文本质量只是其中一项。

并行分块让输出体积更可控，同时引入跨块关系可能被切断的风险，需与顺序基线共同评测。

时间: 2026.05.
动机: 单次全局摘要会阻塞 Agent 推理, 延迟高且摘要长度难以控制.
方法: 将历史划分为多个区块并行摘要, 使系统能够控制各区块的压缩量, 在保持信息的同时降低端到端延迟.

AdaCoM: Learning Agent-Compatible Context Management。 AdaCoM的重点是让压缩表示服务于后续 Agent 动作，评价对象因而超出语言流畅度。

外部管理器可以服务冻结或闭源 Agent，但管理策略对不同能力 Agent 的迁移并非无条件成立。

时间: 2026.05.
动机: 固定压缩策略难以适配不同能力的 Agent, 且无法训练闭源模型.
方法: 训练外部 Context Manager, 在冻结 Agent 的情况下通过 RL 学习保留, 删除和改写历史, 并根据 Agent 能力调整压缩强度.

1.2. Less Context, Better Agents

减少可见历史有时会降低噪声，但收益取决于保留下来的状态是否足以继续决策。

这一路线提醒我们，更多上下文既包含证据也包含过期动作，删除策略必须以任务结果验证。

时间: 2026.06.
动机: 企业工具返回内容冗长, 全量保留会造成上下文溢出, 状态过期和高推理成本.
方法: 仅保留最近若干轮高价值工具交互, 并对更早历史进行摘要, 以同时提升任务成功率和 token 效率.

状态持久化与程序化记忆，另一组工作把重点从压缩文本转到保存可继续执行的状态。计划是否能跨窗口存活、模型能否主动压缩、程序化记忆能否替代自然语言摘要，答案并不相同。

三条路线可以沿写入时机、表示形式、验证依据和恢复能力四个坐标比较。

Plans Don't Persist，计划文本看似完整，不表示跨窗口以后仍能约束实际工具调用。

删除或改写计划后的配对轨迹可以检验计划究竟依赖显式文本，还是已经进入隐藏状态。

时间: 2026.06.
动机: 压缩方法通常假设模型已将早期计划内化, 但该假设缺少验证.
方法: 通过 replay pairing, 隐藏状态距离和 probe, 对比保留与删除计划的轨迹, 发现计划主要依赖显式上下文, 直接删除会明显损害任务表现.

1.3. Self-Compacting Language Model Agents

SelfCompact把写入时机交给模型，也把遗漏关键状态的风险交给同一个策略。

论文用 compaction tool 与触发 rubric 配合，区分子任务结束的适合时机和推导中途的不适合时机。

时间: 2026.06.
动机: 固定 token 预算下, 外部压缩容易误触上下文摘要.
方法: 提供 compaction tool 和轻量 rubric, 让 Agent 在子任务完成或搜索收敛时自主压缩, 无需微调或额外监督.

PRO-LONG: Programmatic Memory Enables Long-Horizon Reasoning。程序化记忆用可执行结构保存中间状态，代价是控制代码本身也需要验证。

完整日志降低摘要的不可逆损失，却把负担转移到按需检索、程序正确性和执行成本上。

时间: 2026.07.
动机: 自然语言摘要存在不可逆的信息损失, 完整历史又难以直接检索.
方法: 保存完整, 结构化的交互日志, 让 Coding Agent 编写程序搜索和读取历史, 实现低成本, 按需访问的程序化记忆.

横向观察，几条路线都要回答同一个问题：压缩后还能否可靠完成后续动作。

横向比较应同时报告触发者、表示形式、训练耦合、来源可追溯性和恢复成本。

压缩时机的两条路线: 外部统一压缩(1/2/3/4) vs Agent 自主压缩(6/7).
与训练耦合的探索: CompactionRL 把压缩学进 RL 轨迹, AdaCoM 用外部 RL 训练 Context Manager, 都是「摘要质量对齐任务目标」的尝试.
记忆形式之争: 自然语言摘要(1/2/3/4/6) vs 完整结构化日志 + 程序化检索(PRO-LONG), 对应信息损失与检索成本的权衡.
实证提醒: Plans Don't Persist 表明「压缩会损害计划保持」并非杞人忧天, 压缩策略需要显式保留计划类信息.

压缩对象与预算，论文方法不同，但工程系统最终都要回答两个基础问题：哪些信息能够压缩，有限 token 应该分给哪些状态。

压缩对象必须按事实、猜测、计划与日志分层。预算则应跟随未来决策价值，而不是平均分配给每一轮历史。

2. 上下文压缩究竟压缩什么

上下文压缩是一个有损的状态迁移过程. 给定原始历史 $H_t$ , 当前目标 $G_t$ 和 token 预算 $B$ , 压缩器生成可见上下文

\widetilde{H}_t=\mathcal{C}(H_t,G_t,B), \qquad |\widetilde{H}_t|\le B.

$\mathcal{C}$ 不可能在更少 token 中无条件保存原历史的全部信息, 所以它属于 lossy compression, 即有损压缩. 需要辨认的是哪些信息可以舍弃, 哪些信息决定 Agent 在当前目标下能否选出正确动作, 以及哪些证据必须能从外部日志重新取回. 评测应检查压缩结果是否保住后续决策所需的充分信息；语言流畅只能算基本要求.

原始历史至少包含五类对象, 每类对象的压缩方法不同.

对象	例子	压缩时需要保留什么
目标与约束	用户要求, 验收条件, 禁止操作	当前生效版本, 覆盖关系, 不可违反的条件
环境事实	文件哈希, 服务状态, 测试输出	来源, 时间, 对应环境版本, 验证结果
决策与计划	方案选择, 剩余步骤, 分支条件	决策依据, 未完成依赖, 重新规划触发器
工具轨迹	命令, 参数, 返回内容, 副作用	动作标识, 关键返回, 产物位置, 能否重试
推理草稿	候选假设, 已排除路径, 局部计算	仍影响后续的结论和未解决冲突

一段很长的工具输出可以只保留退出状态, 关键错误和原始日志位置; 一条只有十几个字的用户约束却可能一个字都不能丢. 因此按消息长度平均裁剪不成立. 最近消息也未必最重要: 第一步指定的许可证要求可能一直约束最终产物, 最近十轮的重复搜索却可以全部归并.

事实, 猜测与计划不能揉成一段，自然语言摘要最常见的结构性错误, 是把不同可信度的信息写成同一种陈述. 可以把压缩状态分成三层:

M_t=(F_t, U_t, P_t).

$F_t$ 是已经由环境检查支持的事实, $U_t$ 是猜测, 待验证判断与尚未解决的冲突, $P_t$ 是计划和条件分支. 三者的更新规则不同. 事实要附带来源与版本; 猜测要保留验证动作, 验证成功后才能迁移到事实层; 计划只在对应目标版本和前置条件仍有效时成立.

例如 Agent 看到一次构建失败, 推测原因是依赖版本过旧, 并计划升级依赖. 压缩后若只剩「依赖版本过旧, 下一步升级」, 一个未经验证的诊断就被提升成事实. 更安全的记录是: 「事实: 构建在错误码 X 处失败, 日志位于 L; 猜测: 依赖版本可能过旧; 计划: 先读取锁文件并核对兼容范围, 证实后再升级」. 这样恢复后的 Agent 知道哪些内容可以直接使用, 哪些内容仍要查.

计划还应记录完成状态和依赖. 修改文件 -> 运行测试 -> 提交 不能压成「完成修改和测试」, 除非测试确实执行并通过. Plans Don't Persist 所提醒的问题就在这里: 计划并不会自动进入模型的某个稳定内部状态. 如果显式计划被删掉, 后续模型可能保留目标的大意, 却忘记尚未执行的验证步骤. 压缩器应将未完成计划当作一等对象, 不依赖摘要模型顺手提到它.

Token 预算怎样分，设模型窗口为 32,000 token, 其中系统指令和工具 schema 占 6,000, 当前用户输入占 2,000, 希望至少给下一轮推理与工具返回预留 8,000. 那么可用于历史状态的上限是

B=32{,}000-6{,}000-2{,}000-8{,}000=16{,}000.

假设原始历史已有 48,000 token, 直接截断需要丢掉三分之二. 一种可检查的预算分配是: 目标与硬约束 2,000, 已验证事实 4,000, 未解决问题和当前计划 3,000, 最近原始交互 5,000, 外部证据索引 2,000, 合计 16,000. 这些数字只是手算例子的输入, 不代表通用最佳比例. 它展示的是分配过程: 先扣除不能被历史挤占的固定成本, 再按信息职责分区, 收尾阶段检查总和.

若压缩后目标区实际只用了 800 token, 空出的 1,200 可以转给最近交互或证据索引; 若未解决冲突突然增加, 应减少可以外置的原始日志, 而不是截掉冲突列表. 预算策略需要随任务阶段变化. 搜索早期可能需要更多候选与来源, 执行阶段需要更多环境状态, 临近交付时则要为验收条件和检查结果留出空间.

压缩触发也不能只靠固定阈值. token 使用率接近上限当然是一个信号, 子任务完成, 目标版本切换, 即将执行高风险副作用同样适合作为边界. 在这些位置压缩, 状态往往更容易形成闭合单元. Self-Compacting Agents 允许 Agent 主动调用 compaction tool, 就是在尝试让触发时机贴合任务进展; 外部 Context Manager 则更容易统一执行预算和安全规则. 两种方式可以组合, 但最终触发权和失败后的降级路径必须明确.

2.1. 更新、证据与失效

摘要是随任务状态增长的派生视图。每次整体重写都会增加遗漏旧约束和混入新猜测的机会。

可靠压缩需要增量更新、来源指针与失效规则，原始证据的保存方式也决定了系统能否从错误压缩中恢复。

摘要要增量更新, 不能反复覆盖，长任务不会只压缩一次. 若每次都拿「上一版摘要 + 最近消息」重新生成新摘要, 细小遗漏会逐轮累积. 第一次漏掉来源, 第二次把猜测写成事实, 第三次再依据错误事实更新计划, 最终已经很难追溯偏差从哪里出现. 因此摘要需要版本:

M^{(k+1)}=\operatorname{Merge}(M^{(k)},\Delta H_k,G^{(v)}),

$M^{(k)}$ 是第 $k$ 版压缩状态, $\Delta H_k$ 是本轮新增历史, $G^{(v)}$ 是当前目标版本. Merge 至少要产生变更集合: 新增了什么, 更新了什么, 哪些记录失效, 哪些冲突尚未解决. 旧版本留在审计层，用于出现偏差时定位具体的错误更新，无需继续占用模型上下文.

版本冲突不能靠「收尾阶段一句覆盖前面所有内容」处理. 新工具观测可能来自旧环境, 用户新消息也可能只修改一个约束. 每条状态记录应关联适用范围和来源. 如果两个来源给出不同文件版本, 摘要应保留冲突并触发重新读取; 如果用户明确撤销旧要求, 状态层则创建新目标版本并使旧约束失效. 冲突的处理动作取决于信息类型, 时间顺序只是证据之一.

分块并行压缩还会带来跨块冲突. 两个区块分别总结时, 后一块可能修改前一块中的结论, 单独摘要无法看见这种覆盖关系. 合并阶段需要以目标, 实体和版本为键重排信息, 而不是简单拼接各块摘要. Parallel Context Compaction 减少串行压缩的服务延迟, 但任何并行方案都仍需面对这个语义合并问题.

压缩后怎样恢复原始证据，有损摘要可以承担导航, 不能取代原始记录. 每条关键结论应保存能够回到证据的指针, 例如消息序号, 文件路径与哈希, 工具调用 ID, 日志区间或数据库记录版本. 当下一步需要精确参数, 完整错误栈或原始措辞时, Agent 先依据指针取回局部证据, 再行动. PRO-LONG 采用完整结构化日志与程序化检索, 正面处理的就是摘要不可逆这一限制.

恢复可以写成两级读取. 第一级始终加载压缩状态 $M_t$ , 用它确定当前目标, 事实和待办; 第二级按需执行

e=\operatorname{Retrieve}(r,H_{0:t}),

其中 $r$ 是摘要中的证据指针, $H_{0:t}$ 是外部保存的完整历史, $e$ 是取回的原始片段. 如果检索结果与摘要冲突, 不能静默选择其中一个. 系统应重新查询当前权威环境, 更新事实层, 并标记受影响的计划需要重算.

恢复测试应在正常运行期间就做. 随机选择一个压缩边界, 只提供 $M_t$ 和外部索引给新的执行体, 检查它能否回答当前目标版本, 最近一个已验证里程碑, 尚未解决的阻塞和下一项安全动作. 如果恢复必须依赖原进程中未保存的隐变量, 这份压缩状态仍然不完整.

常见失败模式，压缩结果往往依旧语句通顺，关键状态却可能在没有告警的情况下消失或过期。

故障应按遗漏、错误合并、版本残留和来源断裂分类，分别构造可触发的测试样本。

约束蒸发发生在摘要保留了任务主题, 却删除了格式, 权限或禁止操作. 最终产物可能语义正确, 仍然违反用户要求. 检查方法是把硬约束单独列出, 每次压缩前后逐项做集合差异.

猜测固化指未经验证的解释在多轮改写后变成肯定事实. 它通常来自没有区分 $F_t$ 与 $U_t$ . 检查方法是要求每项事实都有来源指针, 没有来源的判断只能留在待验证层.

计划断尾指摘要保留已经做过的工作, 丢失尚未执行的验证或清理动作. 任务看似完成, 实际停在不可交付状态. 检查方法是为计划节点保存状态与前置依赖, 压缩后重算未完成集合.

旧状态复活发生在摘要引用过期文件, 旧目标或已经撤销的方案. 最近写入不一定就是权威版本, 所以需要实体版本与失效标记. 恢复时应重新读取容易变化的外部状态.

不可追溯摘要读起来完整, 却没有任何证据指针. 一旦出现冲突, 系统无法判断结论来自用户, 工具还是自己的推测. 关键结论应保留稳定定位信息；复制全部日志只会重新挤满窗口.

压缩震荡指系统频繁在摘要与原始历史之间切换, 反复花费 token 却没有形成稳定状态. 可以记录每次压缩后的保留率, 随后的证据回读次数和下一次压缩间隔. 若刚压掉的信息很快又被大量取回, 说明预算分区或触发时机需要调整.

2.2. 评测协议与工程检查

压缩率本身不能说明任务是否仍可完成。评测必须同时观察状态保真、后续动作、恢复成本和推理资源。

评测同时覆盖执行协议、预算与保真手算，并与定义、LiveMem 和 Harness 的状态边界对齐。

一套可执行的评测协议，先准备一组具有环境检查器的长任务, 每个任务包含目标版本, 硬约束, 可验证里程碑和完整事件日志. 对同一条基础轨迹构造不同压缩预算, 例如保留原历史的 50%, 25% 和 12.5%, 并保留一组不压缩对照. 百分比只定义实验条件, 不预设结果.

然后在若干固定边界触发压缩, 将压缩状态交给新的执行体继续任务. 记录五组指标:

约束保留率: 压缩前仍生效的硬约束中, 压缩后可被准确恢复的比例.
事实精度: 摘要事实中有环境证据支持的比例, 同时统计遗漏事实与错误事实.
计划连续性: 未完成且仍有效的计划节点被保留的比例, 以及恢复后第一个动作是否满足前置依赖.
证据可恢复率: 随机抽取关键结论, 能否通过保存的指针取回对应原始证据.
任务结果与成本: 最终成功率, 约束违反数, 恢复次数, 额外检索 token, 压缩延迟和总推理 token.

还需要专门加入冲突用例. 在压缩前后修改一个用户约束, 更新一个外部文件, 让一次工具调用返回部分成功, 检查系统是否保留两版信息并选择当前权威状态. 再加入延迟验证用例: 早期步骤产生的错误只能在若干步后被测试发现, 观察压缩器是否把未验证结果错误地提升为事实.

失败轨迹还要做归因. 如果终态失败来自压缩前模型已经做出的错误决策, 不能算作压缩损失; 如果完整历史对照能够恢复, 压缩组因遗漏约束或证据而失败, 才说明 $\mathcal{C}$ 丢掉了任务充分信息. 这套协议把「摘要看起来不错」转换成可以执行的比较: 在相同任务, 相同模型和相同环境下, 不同压缩策略让哪些状态保存下来, 为此花了多少 token, 又从哪里开始失效.

一个可复算的预算与保真例子，设活动窗口预算为 8000 token，系统提示与工具 schema 固定占 1800，当前任务材料占 2600，最近动作和观测保留 2200，留给压缩历史的预算只有

B_{\mathrm{summary}}=8000-1800-2600-2200=1400. \tag{8}

若旧历史共 14000 token，文本压缩率是 $1400/14000=10%$ 。这个数字没有说明压缩是否成功，因为不同信息的未来价值不同。把旧历史拆成 20 条硬约束、30 条已验证事实、10 条未决问题和 200 条普通日志，评测应逐类计算召回，而不是对全部 token 做表面重合。

设硬约束权重为 5，事实为 3，未决问题为 2，日志为 0.2。压缩后保留 19 条约束、27 条事实、8 条未决问题和 30 条日志，则加权保真率为

F=\frac{19\times5+27\times3+8\times2+30\times0.2} {20\times5+30\times3+10\times2+200\times0.2} =\frac{198}{250}=0.792. \tag{9}

若只按条目数计算，保留率为 $84/260\approx0.323$ ，看起来很低；加权结果更高，是因为系统优先保留会影响后续决策的状态。权重必须在评测前声明，不能看完结果后调整。硬约束仍漏掉一条，所以即使 $F=0.792$ ，只要遗漏项涉及安全边界，任务也应判为约束失败。

下一步测动作影响。用相同模型、任务和随机种子，分别提供完整历史 $H$ 、压缩状态 $Z$ 与只保留最近窗口的截断输入 $W$ 。记三者成功率为 $A_H,A_Z,A_W$ ，压缩恢复率可以写成

R_{\mathrm{comp}}=\frac{A_Z-A_W}{A_H-A_W}. \tag{10}

若 $A_H=0.80,A_Z=0.68,A_W=0.40$ ，则 $R_{\mathrm{comp}}=0.70$ ，表示压缩恢复了完整历史相对纯截断优势的 70%。当 $A_H=A_W$ 时分母为零，这项指标没有定义，应直接报告三项原始结果。

还要测更新而非只测首次摘要。让任务经历五次压缩，每次加入一个新约束、修订一个旧事实并关闭一个未决问题。第 $k$ 次压缩后的状态与当时真值比较，得到 $F_k$ ；若 $F_k$ 单调下降，说明增量误差在累积。再从每次 checkpoint 恢复执行同一后续任务，记录成功率和查回原证据所需工具调用。文本看起来连贯却无法定位来源，仍然不具备可靠恢复能力。

工程检查还要记录摘要生成 token、延迟和失败回退。压缩器超时后直接丢弃旧窗口，会把基础设施错误变成永久失忆；更安全的策略是保留上一版已验证摘要与尚未压缩的增量日志，并在预算允许时重试。新摘要只有通过结构校验、关键约束对照和来源指针检查后，才替换旧版。

3. 压缩是一条状态提交链

上下文压缩常被画成「长文本进去，短摘要出来」，这张图漏掉了最重要的时间关系。运行中的 Agent 至少同时拥有上一版可信状态 $M_k$ 、尚未压缩的增量日志 $\Delta H_k$ 、压缩候选 $\tilde M_{k+1}$ 和环境版本 $E_k$ 。候选通过检查后才能成为下一版：

M_k + ΔH_k + E_k
        │
        ▼
  生成候选 M~_{k+1}
        │  schema / 约束 / 来源 / 版本检查
        ▼
  提交 M_{k+1} ──→ 释放旧窗口
        │
        └─失败→保留 M_k 与 ΔH_k

提交顺序不能反过来。若先释放旧窗口，再发现摘要缺字段，系统已经失去重建材料。压缩应像一次有验证门的状态迁移：生成候选不会改变当前权威状态，检查通过才原子替换；失败则继续使用旧摘要和增量日志，必要时暂停接收会扩大状态的新动作。

候选摘要还要绑定环境版本。设压缩开始时文件集合哈希为 $e_k$ ，摘要完成时环境已经变成 $e_{k+1}$ ，其中关于测试结果和当前文件的陈述可能过期。提交条件可以写成：

\operatorname{commit}(\tilde M)= \mathbf1[\operatorname{schema}(\tilde M)] \mathbf1[\operatorname{constraints}(\tilde M)] \mathbf1[e_{read}=e_{current}]. \tag{11}

环境版本条件失败时，无须把整段历史重新压一次。系统可以读取环境 diff，只使相关事实和计划节点失效，再把变化合入候选。这样既保留压缩结果，也不让旧环境结论悄悄升级成当前事实。

多次压缩怎样累积误差，一次摘要保留 95% 关键状态，看起来很高；连续十次若错误独立且无法恢复，全部关键状态都保真的概率约为：

0.95^{10}\approx0.599. \tag{12}

真实错误不会独立，重要约束也可能重复出现，但这个演算说明了递归摘要的危险：下一次压缩以已经有损的摘要为输入，遗漏会变成后续版本的空白，错误陈述则可能被重复强化。系统需要保留外部证据索引，使每一版摘要都能回到原始事件，而非只能引用上一版摘要。

可以为状态项记录首次来源与最近确认时间。若某项经过 $m$ 次压缩却从未重新读取环境，其新鲜度随时间下降：

q_i(k)=q_i(0)\prod_{j=1}^{k}(1-\epsilon_{ij}), \tag{13}

$\epsilon_{ij}$ 表示第 $j$ 次转换对状态项 $i$ 的估计错误率。这个值不必在产品里精确计算，它提示调度器：高风险、长期未复核的事实应优先回源；普通对话细节可以接受更高损失。

压缩触发器与延迟构成，固定每 $N$ 个 token 压缩实现简单，却可能在一次关键工具返回中间切断语义。更合适的触发器同时观察窗口占用、任务边界和可恢复点。子任务刚通过验证、环境处于稳定 checkpoint 时压缩，摘要更容易区分事实与猜测；不可逆动作执行到一半时压缩，恢复语义最复杂。

设窗口上限为 $B$ ，安全余量为 $m$ ，当前占用为 $b_t$ ，预测下一轮输入与输出需要 $\hat g_t$ ，容量触发条件为：

b_t+\hat g_t>B-m. \tag{14}

容量触发保证不会溢出，语义触发则在阶段完成、目标修订或 checkpoint 建立后主动压缩。两者结合能减少紧急压缩。预测偏小时仍可能撞线，因此系统还应保留硬截断回退，但回退只能丢低价值日志，硬约束、未决问题和当前计划有独立预算。

服务延迟由正常生成与压缩停顿共同组成。若每 $K$ 轮压缩一次，摘要耗时 $T_c$ ，普通一轮耗时 $T_g$ ，串行平均每轮时延约为：

\bar T=T_g+\frac{T_c}{K}. \tag{15}

Parallel Context Compaction 关注的正是这条 serving 路径：压缩若能与不依赖旧窗口的工作并行，用户可见停顿会下降。但并行会引入快照问题，摘要读取的历史边界必须固定，新到事件进入下一批增量，不能一边总结一边把输入继续改写。

结构化状态和自由文本各管什么，自由文本适合保存背景、原因和难以枚举的语义；结构化字段适合目标版本、硬约束、计划状态与证据指针。把所有内容都塞进 JSON，会丢掉解释上下文；只保留一段散文，程序又无法可靠判断某项是否过期。

一个混合状态可以包含：goal 与 constraints 的结构化表、verified_facts 的版本化记录、open_questions 与 plan_nodes，再附一段 narrative_context。规划器先读取结构化硬边界，再用自由文本补充背景。压缩器更新自由文本时，没有权限删除结构化硬约束；结构化字段变化时，也应在叙述里留下自然说明，避免模型只看到一堆无来源键值。

外部证据不必全部塞回窗口。摘要中保存稳定指针、内容哈希和短说明，需要时再读取原文。若一次检索成本为 $c_r$ ，状态项被再次使用的概率为 $p_i$ ，将其完整保留的 token 成本为 $c_i$ ，可以用 $p_ic_r$ 与 $c_i$ 比较。高频小状态直接保留，低频大证据使用索引，通常比统一策略更省。

3.1. 失败边界

压缩器无法凭空恢复从未记录的事实。工具只返回截断日志，摘要再优秀也看不到被截掉部分；Executor 没保存文件版本，后续摘要也无法判断测试属于哪个提交。压缩发生在观测与记录之后，它能整理状态，却不能修复上游可观测性缺口。

第二个边界是目标未知。某段历史未来是否重要取决于后续任务，压缩时无法穷尽。保留原始证据索引和低成本冷存储，可以在目标变化后重新取回；彻底删除旧信息换来的 token 节省，则要接受未来不可恢复。

第三个边界是权限与删除。摘要、向量索引、缓存和 checkpoint 都可能保存用户要求删除的信息。治理系统必须知道同一来源派生出了哪些副本，并支持使其失效或重建。只删除聊天界面上的原文，压缩状态仍可能继续影响决策。

压缩进入训练以后，固定摘要器只在推理时改变输入，CompactionRL 则把摘要生成纳入 rollout，使后续任务奖励能够影响压缩策略。官方论文报告，基于 GLM-4.5-Air 的模型在 SWE-bench Verified 达到 66.8% Pass@1，在 Terminal-Bench 2.0 达到 24.5%，相对其对照分别增加 7.0 与 3.1 个百分点；基于 GLM-4.7-Flash 的版本分别达到 56.0% 与 20.2%。这些结果属于对应模型、训练与评测配置，无法单独证明任意摘要器都会带来同样收益。

一条轨迹被压缩后，摘要 token 影响后续许多动作。若只把终局优势均匀分给全部 token，长轨迹中不同阶段的长度差异会扭曲梯度。可以把轨迹拆成压缩前动作、摘要和压缩后动作三段：

\tau=(a_{1:c},z_c,a_{c+1:T}), \tag{16}

$z_c$ 是第 $c$ 个边界生成的压缩状态。摘要质量通过后续状态分布影响回报，训练需要保留它与 continuation 的因果连接。CompactionRL 使用 token-level loss normalization 与 cross-trajectory GAE，让长短轨迹和多次压缩下的优势分配更加稳定。

训练还会学到压缩时机。太早压缩会频繁支付摘要成本，并在每次有损转换中累积误差；太晚压缩会逼近窗口上限，留不出工具返回和生成预算。若第 $c$ 步压缩的期望收益为任务回报改善 $\Delta R_c$ ，代价包含摘要 token、延迟和保真损失，可以写成：

U(c)=\mathbb E[\Delta R_c]-\lambda C_{token}(c) -\mu C_{latency}(c)-\nu L_{fidelity}(c). \tag{17}

真实训练不会精确知道四项，但这个分解说明消融应测什么：固定时机与学习时机、固定摘要器与联合训练、一次压缩与多次压缩，以及完整历史、截断和压缩三组对照。

训练分布决定压缩偏好，编码任务频繁奖励测试、文件路径和错误日志，摘要器会优先保存这些信息；换到日程安排或科研工作流，重要状态已经变化。跨领域使用前要测试约束召回、实体版本和未决计划，不能只看编码 benchmark 上的 pass rate。

摘要器还可能学习 verifier 的捷径。若训练任务只检查最终测试，它可能丢掉用户风格、安全约束或未覆盖的兼容要求，仍然获得高 reward。训练数据中的 verifier 覆盖面决定哪些信息有梯度，外部硬约束应由 Harness 独立保存，避免完全依赖策略自己学会记住。

多次压缩训练要包含恢复样本。让某一版摘要故意漏掉字段、引入版本冲突或指向失效证据，训练系统重新读取环境并修复状态。只在完美摘要上训练 continuation，部署时遇到第一次压缩错误就会一路继承。