压缩图解

和 Claude Code 对齐，分两类：

常规操作（每轮 LLM 调用前都做，和上下文长度无关）：Budget Reduction

级联压缩（按 Tier 1→2→3→4→5 顺序升级，成本低的先做，前一级不够才上后一级）：

	名称	做什么	触发条件	调 LLM	破缓存	状态
常规	Budget Reduction	截断超大单个输出	单个 tool_result > 4000 字符	否	否	✅
Tier 1	Microcompact	旧工具输出清理	工具调用 ≥ 50 次（之后每 25 次）/ 空闲 90 分钟	否	cache-aware 不破	✅
Tier 2	Snip	删最旧几轮	Tier 1 后仍超预算	否	是	✅
Tier 3	Context Collapse	分段摘要	Tier 2 后仍超，~90%	是（每段一次）	是	⏳
Tier 4	Auto-Compact	全量摘要	Tier 3 后仍超 / 用户 /compact	是（一次）	是	✅
Tier 5	Reactive	紧急压缩	API 返回 413	是	是	⏳

级联逻辑：每轮 LLM 调用前，从 Tier 1 开始检查。满足条件就执行，执行完重新检查是否还超。还超就进入下一个 Tier。

注：Tier 3 和 Tier 4 在 Claude Code 逆向分析中被描述为"overlapping strategies"，不一定严格级联。/compact 手动命令直接触发 Tier 4，跳过 Tier 1-3。

Claude Code 是线性对话没有 DAG，不需要这一层。我们有函数调用节点（🟢），需要额外处理。

2.1 函数运行中

触发

函数被调用，status="running"

做什么

内部子树完整展开在上下文中

可见范围

由 render_context 的 callers/subcalls/expose 控制

节点状态

内部视角：子节点 full。外部视角：默认 expose=io，调用方只看到输入+输出

和压缩的关系

函数运行中，内部的 🟡 工具输出照常走 Budget Reduction（§3）和 Microcompact（Tier 1）。不参与 Snip（不能删正在用的）

2.2 函数结束 → expose=io，走常规级联

触发

函数返回，status="completed"/"error"

做什么

expose=io 天然隐藏内部子树。不需要额外操作。子节点保留在 DAG 中（可查）

后续

函数节点（输入+输出）进入 §3-§4 的常规级联，和 🔵 对话节点 一视同仁。不需要单独的策略

和 Claude Code 一致。每轮 LLM 调用前都做，和上下文长度无关。

做什么

截断超大的单个 🟡 工具输出。不处理 🔵 user/assistant 消息

阈值

4000 字符（约 1000 tokens）

截断方式

保留前 2400 字符（60%）+ 后 1600 字符（40%），中间丢弃

代码

context/tool_aging/truncate.py: middle_truncate、context/tool_aging/policy.py: MAX_TOOL_RESULT_CHARS = 4000

Budget Reduction 之后，按 Tier 顺序检查。前一级做完仍超阈值才上后一级。

第 1 层：微压缩 ✅ 已实现

和 Claude Code 一致。清理旧 🟡 工具输出。

触发

Cache-aware: 50 次工具调用后首次，之后每 25 次。Time-based: 空闲 ~90 分钟

只处理

FileRead、Shell、Grep、Glob、WebSearch、WebFetch、FileEdit、FileWrite

两条路径

Cache-aware（Anthropic provider）：通过 Context Editing API（cache_edits，beta header context-management-2025-06-27）服务端清除旧 tool_result。客户端消息不变，缓存不破。sentinel 做了字节级归一化（byte-stable），重复操作不改变已缓存内容
Time-based（其他 provider / 空闲 90 分钟）：客户端替换为占位文本（~20 tokens）。会破缓存

压缩效果

每个工具输出：原始大小 → 0 tokens（cache-aware）或 ~20 tokens（time-based）

代码

context/microcompact.py、context/rules/microcompact.py

第 2 层：截减 ✅ 已实现

和 Claude Code 一致。直接删最旧的几轮对话。不做摘要，不调 LLM。

触发

Tier 1 做完后仍超预算

删除粒度

整轮（user + assistant + 该轮所有工具调用一起删）

删多少

从最旧的开始逐轮删，每删一轮重新算 token 数，删到阈值以下为止（不是固定 N 轮）

代价

信息完全丢失，缓存前缀被破坏。但免费（不调 LLM）

函数节点

已完成的 🟢 函数节点按时间参与 Snip。运行中的不删

代码

context/snip.py

第 3 层：上下文折叠 ⏳ 待实现

和 Claude Code 一致。分段 LLM 摘要，原始消息保留（可回滚）。

触发

Tier 2 Snip 后仍超（约 90%，95% 阻塞强制）

分段

5-10 轮一段，每段独立 LLM 摘要（每段约 100-300 tokens）

LLM 调用

次数 = 段数（例：30 轮分 3 段 = 3 次 LLM 调用）

可回滚

原始消息保留在 collapse store 中（读时投影 / read-time projection）

第 4 层：自动压缩 ✅ 已实现

和 Claude Code 一致。全量 LLM 摘要，替换所有旧消息。不可回滚。

触发

Tier 3 后仍超。或用户手动 /compact（直接跳到这里）

LLM 调用

1 次（全量摘要）

摘要大小

约 2000-5000 tokens

保留

最近 1-2 轮完整。system prompt 从配置文件重新加载（不依赖摘要）

/compact 命令

/compact 或 /compact 保留数据库迁移的讨论。建议在 60% 时手动做

链式压缩

压缩后继续聊，再次满了在上一次摘要基础上再压。信息逐层衰减

代码

context/engine.py: compact()

第 5 层：响应式压缩 ⏳ 待实现

API 返回 413（prompt too long）时的紧急压缩。每轮至多触发一次。都失败则终止。

每轮 LLM 调用前：

1. Budget Reduction → 截断超大工具输出（每轮都做）

2. 级联检查（按 Tier 顺序）：
   Tier 1: Microcompact 条件满足？→ 清旧工具输出
   Tier 2: 仍超阈值？→ Snip 删旧轮
   Tier 3: 仍超阈值？→ Context Collapse 分段摘要
   Tier 4: 仍超阈值？→ Auto-Compact 全量摘要

3. 调 LLM

4. 如果 API 返回 413：
   Tier 5: Reactive → 紧急压缩 → 重试
   → 失败则终止

场景：200K context，持续工作几小时，中间调用了 research_agent。

我们	Claude Code	说明
§2 函数节点生命周期	无	我们独有（DAG + expose=io）
§3 Budget Reduction	Budget Reduction	一致（4000 字符阈值，60/40 截断）
Tier 1 Microcompact	Tier 1 Microcompact	一致。Anthropic provider 用 cache-aware path
Tier 2 Snip	Tier 2 Snip	一致（整轮删）
第 3 层上下文折叠	第 3 层上下文折叠	一致（分段摘要，可回滚）
第 4 层自动压缩 / /compact	第 4 层自动压缩 / /compact	一致（全量摘要）
Tier 5 Reactive	Tier 5 Reactive	一致（413 紧急压缩）

来源：Claude Code 压缩参考（基于逆向分析，非官方文档）

步骤	做什么	状态	代码
1	Budget Reduction — 截断超大输出（§3）	✅	context/tool_aging/truncate.py
2	Tier 1 Microcompact — 旧工具输出清理	✅	context/microcompact.py
3	Tier 2 Snip — 删最旧几轮	✅	context/snip.py
4	Tier 3 Context Collapse — 分段 LLM 摘要	⏳
5	Tier 4 Auto-Compact — 全量 LLM 摘要	✅	context/engine.py
6	Tier 5 Reactive — 413 紧急压缩	⏳
7	/compact 命令	⏳
8	/context 命令（token 分布）	✅	cli/repl/handlers.py
9	Anthropic Context Editing API 集成	⏳