cs.AI提交于 2026-10-27已译

CTXAgent：LLM 智能体的自主上下文管理

CTXAgent - Self-Controlled Context Management of LLM Agents

Matthias Busch · Marius Tacke · Roland C. Aydin · Christian Feiler · Christian J. Cyron

中文摘要

智能体框架通常在 token 达到阈值时压缩历史记录，以维持长会话。CTXAgent 研究由模型自主管理上下文：模型借助两个工具和一段简短指引，决定何时压缩、保留哪些内容，以及如何撰写交接摘要。研究比较了 7 个前沿模型在相同条件下使用或不使用上下文工具时的 token 成本与基准分数，并在其中两个模型上将该框架与 3 种常用框架对比。基准由编程练习、多步 SciCode 问题、SWE-bench Pro 和 Terminal-Bench 4.0 任务组成，并穿插植入事实、临时观察与长期指令，全部采用确定性检查；会话长度为 35–212 轮，模拟用户在同一聊天中处理不同任务。大多数强模型能够管理上下文，会定期压缩和整理信息，混合会话的实时上下文大多低于 100k token，基准分数通常没有显著下降。表现良好的模型可显著降低成本，但幅度因模型而异，过度频繁的压缩可能推高其他成本。使用 Claude Opus 5.5 时，自主管理框架在任务成功率上与 Claude Code 相当：相较显式 200k 窗口配置成本低 34%，相较默认配置低 49%，且无需选择上下文窗口。智能体、基准及全部结果记录均已发布。

关键要点

01问题：长会话智能体框架通常依靠固定阈值压缩历史，模型自身尚缺乏上下文管理能力。
02方法：仅提供两个上下文工具和一段指引，让模型决定压缩时机、保留内容与交接摘要。
03评测：在 35–212 轮混合任务中比较 7 个前沿模型、两种工具配置及 3 种常用框架。
04结果：多数强模型能持续整理上下文，实时上下文大多低于 100k token，分数通常无显著下降。
05局限：降本幅度因模型而异，过于频繁的压缩可能增加其他成本。

解读

在 GitHub 查看

1. 问题与价值

这篇论文解决的核心问题是：长会话 LLM Agent 的上下文窗口管理应该由谁来决定。现有生产级 harness（如 Claude Code、Codex、OpenCode）都在 token 阈值触发时按固定配方压缩历史，但模型本身——唯一知道「某个任务刚结束、之前读的文件不再需要」的一方——从不参与这个决策。

为什么重要：长会话的主要成本是每次请求都重发的 prefix，主要风险是窗口溢出或关键信息被埋在无关 token 里。压缩时机和压缩内容直接决定成本与任务成功率。如果模型能自己判断何时压缩、保留什么、交接摘要写什么，就能在任务边界处精准压缩，而不是等到窗口快满时被动切割。

受益者：使用长会话 coding agent 的开发者（成本下降）、需要多任务混合会话的用户（信息保留更可靠）、以及 harness 设计者（不再需要为所有任务统一选一个窗口大小）。论文报告的量化收益是：Claude Opus 5.5 在自管理 harness 下，成本比显式 200k 窗口配置低 34%，比默认配置低 49%，且任务成功率与 Claude Code 持平。

2. 已有工作的不足

在本文之前，最好的做法分两类：

生产 harness 的阈值压缩：Claude Code 在窗口接近时用结构化摘要替换历史，Codex 在配置上限（约窗口的 90%）处服务端压缩并保留最近用户消息，OpenCode 在配置窗口到达时压缩。共同缺陷是：压缩时刻由 token 阈值决定，压缩内容由固定配方决定，模型不参与。操作者必须选一个适合所有任务的窗口，而实际上不同任务的上下文需求差异很大。

模型自管理的前沿尝试：Li et al. 的 SelfCompact 给开放权重模型（Qwen3、Qwen3.5、GLM-4.7-Flash、MiniMax-M2.5、MiMo-V2-Flash）压缩工具，发现这些模型在没有脚手架时不会主动识别上下文退化，必须加 rubric、admission gates 和强制 backstop。SelfCompact 的局限性部分明确提到 GPT-5.5、Claude Opus 4.7、Gemini 3 Pro 可能不需要 rubric 就能检测上下文退化——这正是本文要检验的猜想。

具体不足：SelfCompact 的结论基于开放权重模型，不能回答「更强的闭源前沿模型是否具备零样本自管理能力」；同时，已有工作没有把「模型自管理 harness」和「阈值 harness」放在字节相同的会话上、用统一的 prompt-cache 计费口径做成本对比。Context Language Models 虽然零样本暴露上下文为文件，但也没有做跨 harness 的美元成本对比。

3. 重建作者的思考路径

从旧方法出发：生产 harness 用阈值触发压缩，SelfCompact 发现开放权重模型需要 rubric 和 gates 才能自管理。如果我是作者，第一步会想：更强的模型是不是不需要这些脚手架？ 这直接对应 SelfCompact 局限性里点名的模型。于是设计一个对照实验：同一批模型，开/关上下文管理工具，看它们是否自发使用、用了之后成本和分数怎么变。

撞上的第一个矛盾：如果只测「模型会不会调用压缩工具」，无法区分「模型能力」和「工具设计」的贡献。模型不调用可能是因为它判断不需要，也可能是因为提示不够清楚。解决思路是给最简提示——一段话的 guidance，不加 rubric、不加 gates、不加 backstop，让工具本身成为唯一变量。

第二个矛盾：光有模型对比不够。即使模型能自管理，如果最终成本比 Claude Code 还高，这个能力就没有工程价值。所以必须把自管理 harness 和三个生产 harness 放在字节相同的会话上对比。但不同 harness 的窗口配置不同、计费口径不同，直接比不公平。解决思路：所有请求过一个 logging proxy，记录每类 token（uncached、cache write、cache read、output）和按 OpenRouter 价格表计算的账单，这样成本可以在同一口径下比较。

第三个矛盾：怎么证明「信息在压缩中丢失」会造成真实任务失败？如果只是跑独立 coding 题，压缩丢不丢信息根本不影响分数，因为每题自包含。解决思路：在会话里植入依赖边——stated facts（后面直接提问）、ephemeral observations（文件被删，只有对话里留着值）、standing rules（每条回复都要带特定 token）。这些依赖边的距离是受控变量，从 3 到 200 轮不等。如果压缩发生在 fact 和 probe 之间，probe 就被标记为「有压缩介入」。

第四个矛盾：如果所有模型在记忆 probe 上都满分，这个 instrument 就区分不了 harness。论文确实报告 retention 在所有 cell 都是 1.000，说明这个担心成真了——记忆 probe 是下界而非排序工具。真正区分模型和 harness 的是 SciCode 依赖步骤（后续步骤调用前面写的函数）和 hard sessions 里的容器任务。

与论文实际路径的差异：我猜的路径是先做模型对比、再做 harness 对比、最后补记忆 probe。论文实际是把 benchmark 设计（植入依赖边）放在方法最前面，作为整个评估的基石，然后同时跑模型对比和 harness 对比。另一个差异是：我没想到 cache 经济学对结论的干扰会这么大——Astra 的 cache read 价格是 input 的十分之一，Fable 是四十分之一，同样的压缩行为在不同价格表下成本变化从约 50% 到约 0%。论文把「调整 cache-read 价格到二十分之一」作为敏感性分析，这是我不会预先想到的。

4. 核心 intuition

类比：整理办公桌的两种方式。

阈值压缩像一个定时闹钟：每过两小时，不管你在做什么，就把桌面上所有东西扫进一个盒子，只留最近用的几样。问题是，闹钟响的时候你可能正做到一半，刚铺开的文件被扫走了，下次还得翻盒子找回来。

模型自管理像一个有判断力的助理：它知道「这个 bug 修完了，相关文件可以归档，写个便签说清楚改了什么、为什么这么改、还有哪些没做完」。它在任务边界归档，而不是在时间边界归档。便签（hand-off summary）比原始文件小得多，但保留了「下次需要时该知道什么」和「去哪找细节」（segment ids）。

为什么有效：任务边界处压缩，意味着压缩后紧接着的是新任务的开始，旧任务的细节大概率不再被需要。这比在窗口快满时被迫压缩更安全，因为那时可能正处在任务中间。同时，模型写的 hand-off summary 是语义选择——它知道哪些信息对未来有用——而不是固定配方（如「保留最近 N 条用户消息」）的机械截断。

5. 方法 pipeline 举例

输入：一个混合会话，包含 Python 练习、SciCode 多步科学计算题、植入的 fact 和 ephemeral observation、standing rule（每条回复以 REF: <token> 结尾）。

流程：

用户给出第一个任务（Python 练习），模型正常执行，工具结果累积在上下文里。
每 25 个 tool batches 或 20k 新 token 后，engine 在最新工具结果后追加一行提示「a context review is due」。
模型完成一个 SciCode 步骤后，判断这是一个任务边界，调用 compact_context(summary="完成了 Ewald summation 的 step 3，实现了 k-space 能量计算函数 ewald_energy，通过了测试。关键决策：截断半径取 10 Å，因为更大半径不改变结果但耗时翻倍。未解决问题：step 4 需要实空间项。值得回忆的 segment ids: 47, 52", keep_from=<当前步骤起点>)。
Engine 把 keep_from 之前的所有内容替换为这一个 summary segment，并附上被归档工具结果的索引。上下文从约 70k token 降到约 20k token。
后续步骤需要调用之前写的函数时，模型通过 recall(segment_id=47) 恢复被归档的函数定义。
会话继续，植入的 fact「用户的服务器 IP 是 10.0.0.7」在压缩前被模型写进 summary 的「facts the user stated」部分，因此压缩后 probe 提问时模型仍能正确回答。
Standing rule 不是写在 system prompt 里，而是作为会话内容被植入的（原文：planted among the filler tasks）；它能存活下来，是因为压缩器把边界内的一切都归档、而它落在被保留的窗口内，不是因为它不受压缩影响。每条回复末尾的 REF: token 仍然被正则检查通过。

中间结果：以 Opus 5.5 为例，混合会话中压缩 3-4 次，每次在练习或问题边界，hand-off summary 1-2k token，峰值上下文 72-80k token（对比 arm B 无管理的 244k token 峰值）。

6. 核心数学推导

论文的核心量化关系不是单一公式，而是成本分解。设一次会话的总成本 C 为：

C = C_uncached + C_cache_write + C_cache_read + C_output

其中每一项是 token 数乘以对应单价。关键机制是：每次压缩（compact 或 curate）都会 invalidate 从切割点开始的 prompt cache。设压缩前上下文长度为 L，压缩后为 L'，压缩发生在第 t 轮。压缩后第 t+1 轮的请求中，前 L' 个 token 如果与压缩前的前缀相同，则命中 cache read；从切割点开始的新 summary 是 cache write；后续所有轮次中，summary 之前的部分持续命中 cache read。

成本变化的方向取决于两个对抗效应：

节省效应：压缩后每轮重发的 prefix 从 L 降到 L'，cache read token 数减少。如果 L - L' 很大且后续轮次多，节省显著。
代价效应：压缩本身产生 cache write（新 summary 的 token 数），且如果模型压缩太频繁，每次压缩都 invalidate 一段本可复用的 cache，cache read 变成 cache write 或 uncached input。此外，如果模型写很长的 summary（如 Sol 6.1 的情况），output token 增加。

论文用这个框架解释了为什么同样的压缩行为在不同模型上成本变化不同：Astra 的 cache read 单价是 input 的十分之一，所以 arm B 里大量 cache read 的权重是 arm A 节省的 cache read 的十分之一；Fable 的 cache read 是 input 的四十分之一，cache read 的节省几乎可以忽略，所以成本比约 1.02（19.46/19.14）。

一句话总结：这个成本分解在算「压缩省下的 prefix 重发成本」减去「压缩引入的 cache write 和额外 output 成本」，净效果取决于压缩频率、summary 长度和提供商的 cache-read 定价比。

7. 实验设计

数据集：Aider polyglot 练习（Python 34 题、JavaScript 48 题、Go 36 题）、SciCode dev split（15 题 50 步，其中 46 步可解）、SWE-bench Pro hard subset（51 实例中每 seed 取 3 个仓库）、Terminal-Bench 4.0（66 任务中选 22 个单容器可运行的，每 seed 取 3 个）、SciCode-Verified（每 seed 取 3 个 3-5 步问题）。四个会话家族：Mixed（3 seeds，101-115 轮）、Clean chains（5 chats × 2 reps）、Marathon（1 个 212 轮会话）、Hard（3 seeds，35-36 轮）。

基线：Claude Code 2.1.301（native、1M、200k 三种窗口）、Codex CLI 0.163.0（native、1M、200k）、OpenCode 1.19.3（200k）、CTXAGENT 开/关上下文管理（1M 窗口）。模型对比用 7 个模型（Haiku 5.5、Sonnet 5.5、Opus 5.5、Fable 5.1、Sol 6.1、Astra 6、Muse Wonder），harness 对比用 Opus 5.5 和 Sol 6.1。

指标：任务成功率（tests passed、verifier passed、probe correct、rule adhered）、SciCode 可解步骤通过数（80 步/arm）、hard sessions 的 SciCode-Verified 步骤和容器任务通过数（51/arm）、retention（按距离和是否有压缩介入分层）、每会话成本（按 token 类别分解）、压缩次数、峰值和平均 prompt 大小、请求数、工具调用数、墙钟时间。

消融：arm A（自管理开）vs arm B（自管理关）是核心消融，隔离了上下文管理工具的贡献。harness 对比中，同一模型跑不同 harness 隔离了 harness 的贡献。cache-read 价格调整到 input 的二十分之一是价格敏感性分析。

能否支撑结论：能支撑「模型自管理能力差异大」和「Opus 5.5 在 CTXAGENT 下成本显著低于 Claude Code 且分数持平」这两个核心结论。但有几个缺口：记忆 probe 全部满分，无法区分 harness 在信息保留上的差异；harness 对比中 vendor CLI 只用 vendor 模型（Claude Code 只跑 Opus，Codex 只跑 Sol），harness 和模型混淆；每个 cell 只有 3 个 seeds，成本方差大（论文自己引用了 Ariño de la Rubia 和 Pafka 的发现：同模型同 harness 的 run-to-run 成本方差可能超过 harness 间差异）。

8. take-aways

模型能力分层明显：7 个模型中，Opus 5.5 和 Sol 6.1 在混合会话上成本降低 43% 和 31%（arm A vs arm B），分数损失仅 4% 和 1%；Haiku 5.5 和 Muse Wonder 从不调用 compact_context，成本比分别为 0.99 和 1.20。
压缩时机比阈值更早：Opus、Sol、Astra 在 50k-80k token 处主动压缩，约为 Claude Code/Codex 200k 窗口切割点（约 168k/145k）的三分之一到一半。
成本节省高度依赖 cache-read 定价：同样的压缩行为，Astra（cache read 为 input 的十分之一）成本降低约 52%，Fable（cache read 为 input 的四十分之一）成本比约 1.02，几乎无节省。
过度压缩有代价：Sol 6.1 在 CTXAGENT 下压缩约 8 次/会话，写 2.4 倍 output token，混合会话成本比 Codex 200k 高 16%；马拉松上 output token 是 Codex 的 5 倍，成本 26.29 美元对 12.14 美元。
记忆 probe 全部满分：retention 在所有距离和所有「是否有压缩介入」的 cell 都是 1.000，说明当前 instrument 对信息保留只能给下界，不能排序 harness。

9. 最脆弱的假设

最脆弱的假设是：模型在任务边界处写的 hand-off summary 能保留所有对未来任务关键的信息，且模型能正确判断哪些信息未来会需要。

这个假设一倒，整个自管理方案的优势就消失——如果 summary 丢失了关键事实或函数定义，后续任务会失败，而成本节省无法弥补任务失败。论文给出的证据是：混合会话中 memory probes 全部满分（包括有压缩介入的 507 个 Opus-CTXAGENT 观测和 552 个 Sol-CTXAGENT 观测），SciCode 依赖步骤在 Opus 上分数损失仅 4%（77/80 vs 80/80）。但这些证据有局限：记忆 probe 是直接提问，模型可能把 fact 写进 summary 是因为 guidance 明确说了「facts the user stated must survive」；真实场景中「哪些信息未来会需要」的判断远比「记住用户说过的事实」更难。论文没有测试「模型错误判断某信息不需要、后来证明需要」的场景——因为 benchmark 里的依赖边都是预先设计的，模型可以通过「把所有 fact 都写进 summary」这种保守策略通过测试，而这在真实场景中不可扩展。

10. 一周最小复现

目标：复现「Opus 5.5 在自管理下成本显著低于无管理、分数基本持平」这一核心结论。

步骤：

用论文公开的 CTXAGENT 代码和 benchmark 脚本（GitHub 仓库已公开），选 Mixed sessions 的 1 个 seed（约 101-115 轮），不要跑 3 个 seeds。
模型用 Claude Opus 5.5，通过 OpenRouter API，跑两个 arm：arm A（自管理开）和 arm B（自管理关）。
记录每请求的 token 分类和成本，用 OpenRouter 价格表计算会话总成本。
预期指标：arm A 成本约为 arm B 的 0.57（论文报告 Opus 5.5 的 A/B 成本比为 0.57，即 4.80/8.37 美元），SciCode 可解步骤通过数 arm A 约 77/80、arm B 约 80/80（单 seed 会有波动，但方向应一致）。
如果时间允许，加跑 Claude Code 200k 窗口同 seed 会话，验证 CTXAGENT 成本比 Claude Code 200k 低约 34%。

资源：24GB 显卡足够，因为模型推理在 API 端，本地只跑 harness 和 benchmark 脚本。1 周内 2 个 arm × 1 seed × 约 2 小时墙钟时间（论文报告 Opus arm A 约 21 分钟、arm B 约 24 分钟/会话）完全可行。主要成本是 API 费用，单会话约 5-8 美元。

11. 反例设计

实验：构造一个会话，其中植入的 fact 与后续任务的关系是间接的、非显式的。具体做法：在会话早期，用户提到「我们的数据库 schema 里 users 表的 email 字段有唯一索引」。这个信息不是以「请记住」的形式给出的，而是嵌在一个已完成的调试任务的工具输出里。20 轮后，用户要求「写一个函数，检查新用户注册时 email 是否重复，如果重复就返回错误」。正确的实现需要知道唯一索引的存在（可以直接依赖数据库报错，也可以显式检查）。如果模型在早期任务边界压缩时，把这条信息当作「已完成的调试任务的无关细节」丢弃了，后续写出的函数就会缺少重复检查逻辑。

判据：如果 CTXAGENT 自管理 arm 在这个任务上的通过率显著低于 arm B（无压缩），且失败原因是「模型不知道唯一索引存在」而非代码错误，则说明模型对「哪些信息未来会需要」的判断不可靠，本文的核心主张——模型能在任务边界安全地自管理上下文——被推翻。

为什么现有 benchmark 测不出这个：论文的 fact probe 是直接提问（「用户之前说的服务器 IP 是什么？」），模型可以通过「把所有用户陈述都写进 summary」的保守策略通过。上述反例要求模型理解工具输出中隐含的、对未来任务有约束力的信息，这更接近真实场景中「判断相关性」的难度。

12. 落地判断

能否用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：不能直接套用，但可以借鉴架构。

原因：论文的核心发现是「自管理能力高度依赖模型」。7 个前沿闭源模型中，只有 Opus 5.5 和 Sol 6.1 表现一致，Haiku 5.5 和 Muse Wonder 从不调用压缩工具，Sonnet 5.5 只在 3 个 session 中的 1 个里压缩。27B 开放权重模型的能力大概率更接近 SelfCompact 测试的 Qwen3 级别——Li et al. 的结论是这些模型需要 rubric、gates 和 backstop 才能自管理。直接给 27B 模型两个工具和一段 guidance，预期它会像 Haiku 一样从不压缩，或者压缩了但 summary 质量差导致任务失败。

如果要用，怎么改：把 CTXAGENT 的 prompt-only 方案降级为 SelfCompact 式的 scaffolded 方案——加一个固定间隔的 rubric 检查（「当前上下文是否退化？是否需要压缩？」），加 admission gate（压缩前先让模型列出「哪些信息必须保留」，检查后再执行），加 backstop（窗口的 30% 处强制压缩）。这牺牲了「模型自主判断」的纯粹性，但换来了 27B 模型上的可用性。

成本量级：自托管 27B 模型的推理成本主要是 GPU 时间而非 API 费用，所以「cache read 比 input 便宜多少」的定价逻辑不直接适用。但压缩带来的 prefix 缩短仍然有效——如果 27B 模型在 8k 上下文处压缩，每轮重发的 token 从 8k 降到 2k，在 100 轮会话中节省约 600k token 的推理量，对应约 1-2 小时的 24GB GPU 时间。

最大的坑：27B 模型的 summary 质量。如果模型写的 hand-off summary 丢失了多智能体脚手架需要的状态信息（如「agent A 正在等待 agent B 的哪个输出」），压缩后整个多智能体协调会崩溃。建议在 27B 模型上先做一个小规模 probe：给它 10 个「任务边界 + 后续依赖」的会话，看 summary 后依赖任务的通过率是否显著低于无压缩基线。如果通过率下降超过 10%，就不要用模型自管理，退回固定阈值压缩。

内容由 AI 生成，仅供参考。如发现错误，欢迎反馈。

原始英文摘要

arXiv:2610.34425v1 Announce Type: new Abstract: Agent harnesses keep long sessions inside the context window by compacting the history when a token threshold is crossed. We study an alternative in which the model manages its own context: it decides when to compact, what to keep and what to write as the hand-off, given two tools and one paragraph of guidance. Since earlier work found that open-weight models cannot manage their own context without scaffolding, we compare seven frontier models under identical conditions, with and without the context tools, on token cost and benchmark score, and we compare our harness with three widely used harnesses on two of these models. The benchmark is assembled from existing ones: coding exercises, multi-step SciCode problems and SWE-bench Pro and Terminal-Bench 4.0 tasks are interleaved with planted facts, ephemeral observations and standing instructions, all checked deterministically, in sessions of 35-212 turns that resemble a user working through different tasks in one chat. Most of the strongest models manage their context: they compact and curate regularly, the live context of the mixed sessions stays mostly below 100k tokens, and their benchmark scores mostly do not drop significantly. For the models that manage their context well, the cost reduction is substantial but varies between models, because some models compact so often that other costs increase. With Claude Opus 5.5, the self-managed harness matches Claude Code on task success at 34% lower cost than its explicit 200k-window configuration and 49% lower than its default, with no context window to choose. We release the agent, the benchmark and all result rows.