智能体调一次搜索工具,返回的网页内容动辄上千 token,而下一步决策真正用得上的,可能只是一个人名、一个年份。清华 AI Agent Group 本周挂上 arXiv:2611.06500 的论文先算了一笔账:到第 4 步工具调用时,原始工具返回已经吃掉智能体上下文的 96.7%。这些又长又吵的"观察"不仅烧钱,还会稀释模型对关键证据的注意力。他们的方案叫 Coca-Cola(Context Compression via Continuous Latent Tokens),思路相当激进:工具输出根本不必是人能读懂的文字。
现有压缩方法的隐形天花板
主流上下文压缩分两派。token 剪枝一族(如 LLMLingua 系列)让模型判断哪些 token 信息量低,直接删掉;文本摘要一派(RECOMP、Search-o1 的 Reason-in-Documents 模块、ACON)用辅助 LLM 把工具返回缩写成短文。论文指出它们共享同一个软肋:压缩结果仍是离散文本序列,必须保持语义连贯,压缩比天然有上限。连续潜 token 不受这个约束——单个向量可以在多个数值维度上联合编码信息,理论容量可以超过同等输入位置上的词表符号,论文还专门用码本容量给这个直觉做了形式化论证。
128 个潜 token 换掉整段返回
Coca-Cola 的结构是"小模型编码器 + 潜在适配器":作为压缩器的 Qwen3.5-4B 或 GLM-Z1-9B 把任务指令、当前推理轨迹、工具返回三者拼在一起编码,latent adapter 再把隐状态映射成固定数量的潜 token,直接插进目标大模型的输入嵌入序列,两侧用特殊边界标记隔开。推理时每条工具返回固定压成 128 个潜 token;搜索场景每次最多取 5 条结果、每个问题最多 5 次工具调用。目标大模型可以是 Qwen3.5-35B-A3B 或 GLM-4.7-Flash。
训练目标只有一个:别改变下一步动作
最关键的设计叫 Action-Preserving Training。压缩器不需要重建原文,而是把完整返回和潜 token 版本分别喂给同一个冻结的大模型,用 KL 散度对齐两者的下一步动作分布(损失权重 0.3),再用轨迹里记录的真实下一步动作做交叉熵监督(权重 1.0)。潜 token 连续可微,梯度能穿过冻结的大模型直接训到压缩器,实际只更新编码器的 LoRA 参数(rank 16)和 adapter。训练数据 3,927 对(另留 436 对验证),4 张 A100-80G 里 3 张放冻结的 agent、1 张放压缩器,学习率 1.5e-4 线性衰减到 5e-5,KL 项在前 20% 步数里热身。
省下最多 89% 的 token,分数反而涨
在 NQ、TriviaQA、2WikiMultiHopQA、HotpotQA 四个问答基准、两个目标模型上,效率提升是碾压级的:输入 token 方面,Qwen 组 NQ 从 14,362 降到 1,766(降 87.7%),GLM 组 2Wiki 从 31,693 降到 3,003(降 90.5%);端到端耗时最多降 56.0%(GLM 组 2Wiki 从 106 秒到 47 秒)。压缩率整体落在 70.01% 到 89.24% 之间。更反直觉的是质量:压缩后 EM 和 F1 全面超过不压缩的 Vanilla 基线,Qwen 组 HotpotQA 的 EM 从 11.00 提到 25.70,F1 从 16.41 提到 33.75;GLM 组 TriviaQA 的 EM 从 41.50 提到 51.50。八个模型-数据组合里六个拿到全部方法中的最优 EM 和 F1。也有例外:Qwen 组 TriviaQA 上,以文本重建为目标的 ICAE 在 EM 上更高(61.80 对 59.20)——论文没有回避这一点。
所以呢
论文明确说压缩器没有任何搜索专属设计,换个工具不用改架构。这意味着"工具返回用潜表示"可以做成一层通用接口。我的看法:上下文是智能体最贵的资源,大多数工作在优化"往上下文里塞什么",这篇把问题改写成"上下文里的东西必须是文字吗",这一步跨得比多数压缩工作都远。代价也明摆着:潜 token 人读不了,智能体出错时排查链路会更痛苦;压缩器本身还要单独占一张 GPU。论文自称(to our knowledge)是第一个把工具输出压成潜 token 的工作,这个方向值得持续盯——如果哪天工具协议层开始原生输出潜表示,智能体的成本结构会整个改写。代码在 GitHub: THU-Agent/Coca-cola,中文 README 直接给出 Vanilla、LLMSummary、LLMLingua 三条基线的复现路径,网页检索默认走 Exa,训练与评测脚本齐全。