diff --git a/docs/comparison/context-compression-deep-dive.md b/docs/comparison/context-compression-deep-dive.md index 963fb2f8..7c104491 100644 --- a/docs/comparison/context-compression-deep-dive.md +++ b/docs/comparison/context-compression-deep-dive.md @@ -1,27 +1,66 @@ # 27. 上下文压缩算法深度对比 -> 上下文压缩决定了 AI 编程代理在长会话中的信息保留质量。从"一次失败永远放弃"到"四阶段+LLM 验证"，实现差距巨大。 +> 上下文压缩决定了 AI 编程代理在长会话中的信息保留质量。不同 Agent 在触发阈值、摘要结构、验证步骤、失败处理和可定制性上差异明显。 + +> **说明**：本文混合使用 3 类证据——开源源码、二进制/官方文档、以及分叉关系推断。对闭源工具或分叉工具，若实现细节未在本仓库证据页中直接钉住，会显式标注“未公开 / 推断 / 待复核”。 ## 总览 -| Agent | 触发阈值 | 算法阶段 | 验证 | 自定义焦点 | 递归 | 后台 | 注入防御 | -|------|---------|---------|------|-----------|------|------|---------| -| **Gemini CLI** | **50%** | **4 阶段** | ✓✓（双 LLM） | ✗ | ✗ | 异步 | **✓** | -| **Goose** | **80%** | 渐进移除 | ✗ | ✗ | ✗ | ✓ | ✗ | -| **Kimi CLI** | **85%** 或 剩余 <50K | 1（结构化 XML） | ✗ | **✓** | ✗ | 异步+重试 | ✗ | -| **Claude Code** | **~95%** | **3 层** | ✗ | **✓** | ✗ | 即时 | ✗ | -| **Aider** | `done_messages > 1024` tokens | 1（递归） | ✗ | ✗ | **✓（×3）** | **✓（线程）** | ✗ | -| **Qwen Code** | 50%（继承） | 4 阶段（继承） | ✓✓ | ✗ | ✗ | 异步 | ✓ | -| **Copilot CLI** | 可配置 | 未公开 | 未知 | ✗ | 未知 | ✓ | 未知 | -| **Codex CLI** | 可配置 | `compact_prompt` | 未知 | ✓（配置） | 未知 | 未知 | 未知 | +| Agent | 触发阈值 | 主压缩路径 | 独立二次验证 | 自定义压缩焦点能力 | 递归 | 执行方式 | 压缩阶段防注入 | +|------|---------|-----------|-------------|------------------|------|---------|---------------| +| **Gemini CLI** | **50%** | **4 阶段** | **✓（Phase 4 Probe）** | ✗ | ✗ | 异步 | **✓** | +| **Goose** | **80%** | 渐进移除 + 回退摘要 | ✗ | ✗ | ✗ | 后台自动压缩 | 未见显式 compact prompt 防注入 | +| **Kimi CLI** | **85%** 或 剩余 <50K | 带标签的结构化摘要 | ✗ | **✓（/compact [FOCUS]）** | ✗ | 异步+重试 | ✗ | +| **Claude Code** | **~95%**（版本/缓冲实现可能有差异） | **三层压缩体系** | 未见公开证据 | **✓（/compact [指令]）** | ✗ | 非阻塞 | ✗ | +| **Aider** | 总 token 数 > 1024（默认阈值） | 递归分割摘要 | ✗ | ✗ | **✓（最多 3 层）** | **后台线程** | ✗ | +| **Qwen Code** | 默认设置文档为 **70%**；框架源自 Gemini，早期资料曾写 50% | 4 阶段框架（分叉继承，待逐项复核） | 待复核 | ✗ | ✗ | 异步（继承推断） | 待复核 | +| **Copilot CLI** | 可配置 | 未公开 | 未知 | ✗ | 未知 | 后台 | 未知 | +| **Codex CLI** | 可配置 | 压缩提示可配置，具体算法未公开 | 未知 | **✓（配置级 `compact_prompt`）** | 未知 | 未知 | 未知 | + +> **表格限定**：这里的“压缩阶段防注入”仅指 compact/compression prompt 中是否存在显式的防注入指令，不代表产品整体是否具备注入检测能力；例如 Goose 在整体安全架构中仍有 `PromptInjectionScanner`。 -> **设计权衡：** 早触发（Gemini 50%）= 频繁压缩但上下文保留少；晚触发（Claude 95%）= 保留最多但接近极限风险高。 +> **设计权衡：** 早触发通常意味着更频繁压缩和更宽松的安全余量；晚触发通常意味着保留更多原始上下文，但若前置微压缩不足，接近极限时缓冲更紧张。 --- -## 一、Gemini CLI：四阶段压缩 + 双 LLM 验证（最复杂） +## 分析框架：压缩只是连续性工程的一部分 + +仅比较“几阶段压缩”容易忽略一个事实：多数 Agent 并不是等上下文满了才一次性总结历史，而是把压缩嵌入更大的连续性工程里——包括前置减载、生命周期 Hook、checkpoint、会话骨架、Prompt Caching 与 loop 控制。 + +| Agent | 压缩前减载 | 压缩后/之外的连续性补偿 | 用户可控项 | +|------|-----------|----------------------|-----------| +| **Gemini CLI** | 先截断旧工具输出（50K 预算） | `PreCompress` Hook + checkpoint / rewind + `codebase_investigator` 仓库调查 | 阈值固定；可手动 `/compress`（仓库文档多写作自动为主） | +| **Claude Code** | 微压缩（长工具输出截断/摘要） | `PreCompact` / `PostCompact` Hook + Prompt Caching | `/compact [指令]` | +| **Goose** | 以 10 个工具调用为一批进行增量摘要；超限前优先移除中间工具输出 | UI 保留完整历史，活跃模型上下文仅保留摘要结果 | 默认压缩阈值 `0.8` + 手动 compact（文档/环境变量命名待区分） | +| **Kimi CLI** | loop_control 里预留 `reserved_context_size=50000` | `CompactionBegin/End` 事件 + checkpoint 绑定的 `/compact` 入口 | `/compact [FOCUS]` | +| **Aider** | 依赖显式文件管理降低上下文噪声 | 后台线程压缩 + 极长会话退化到 `summarize_all()` | 自动为主 | +| **Qwen Code** | 分叉继承 Gemini 压缩框架；并列 `LoopDetectionService` | `PreCompact` Hook + loop 检测服务 | 当前项目设置文档默认值为 0.7，其他细节仍待统一到主证据页 | +| **Copilot CLI** | infinite sessions + 后台 compaction | checkpoint titles 作为会话骨架 | `/compact` + `infiniteSessions.*` 阈值配置 | +| **Codex CLI** | 通过 `model_context_window` 与自动 compact 阈值管理预算 | thread 级 compact 生命周期事件 | `/compact` + `compact_prompt` + `model_auto_compact_token_limit` | + +> **阅读提示**：下面各节主要比较“压缩本体”；但实际长会话体验往往同样取决于这些外围机制是否足够强。 + +### 研究背景：为什么上下文压缩仍然必要 + +从近两年的论文与工程文章看，“上下文压缩”之所以仍是 Agent 设计中的核心问题，不是因为模型没有更大的 context window，而是因为**标称窗口大小**、**有效可用上下文**与**长任务稳定性**并不等价。 + +- **长上下文不等于高质量利用**：`Lost in the Middle`（Liu et al., 2023）指出，模型在长上下文里对中间位置的信息利用明显弱于首尾位置；这意味着“尽量保留全部原始历史”不一定优于“保留更高信号的摘要或结构化状态” +- **标称窗口不等于有效工作窗口**：`RULER`（Hsieh et al., 2024）强调，模型宣称支持的长上下文长度与其在复杂任务中的稳定可用上下文并不相同；随着长度和任务复杂度上升，真实可用窗口会缩水 +- **压缩只是 context engineering 的一个子问题**：Anthropic 在 `Effective Context Engineering for AI Agents` 中将 compression、retrieval、memory、context selection 放在同一框架下讨论，核心目标不是“塞进更多 token”，而是“保留最小但高信号的上下文” +- **compaction 并不总优于 reset**：Anthropic 在 `Harness Design for Long-Running Agentic Apps` 中进一步提出 `context anxiety`——某些模型在接近上下文上限时会提前收尾。此时 compaction 虽能保留连续性，却不一定能移除导致退化的状态；结构化 handoff + context reset 反而可能更稳 +- **压缩不只等于摘要**：`Selective Context`（Li et al., 2023）说明，prompt/context compression 还可以通过选择性剪枝完成，而不仅仅是生成摘要；这对理解 Copilot CLI / Codex CLI 这类“算法细节未公开，但配置面可控”的工具尤其重要 + +因此，本文比较的重点不是“谁保留了更多 token”，而是：**谁能在有限且会退化的有效上下文中，保留更高信号的信息，并用更低成本维持任务连续性。** + +> 参考：Liu et al., *Lost in the Middle* (2023)；Hsieh et al., *RULER* (2024)；Anthropic, *Effective Context Engineering for AI Agents*；Anthropic, *Harness Design for Long-Running Agentic Apps*；Li et al., *Selective Context* (2023) + +--- + +## 一、Gemini CLI：四阶段压缩 + 双 LLM 验证（公开实现中流程最细的一类） > 源码：`packages/core/src/services/chatCompressionService.ts` +> +> 相关 prompt：`packages/core/src/prompts/snippets.ts` ### 完整流程 @@ -35,7 +74,7 @@ │ Phase 2: 分割（findCompressSplitPoint） │ ├── 保留最近 30%（COMPRESSION_PRESERVE_THRESHOLD = 0.3） - │ └── 仅在 user 消息边界分割（绝不在工具调用中间切断） + │ └── 优先在 user 消息边界分割，避免在工具调用中间切断 │ Phase 3: 摘要（压缩专用模型） │ ├── 使用 chat-compression-2.5-pro 模型 @@ -67,10 +106,12 @@ - **提示注入防御**：压缩 prompt 中内嵌安全指令，防止恶意工具输出通过压缩过程注入 - **双 LLM 验证**：Phase 4 用独立 LLM 调用批判性评估摘要完整性 - **膨胀检测**：压缩后 token 数反而更多时拒绝压缩 +- **压缩前可介入**：仓库文档可确认 `PreCompress` Hook，说明外部扩展点主要位于压缩前；压缩后的质量回补更多依赖内部 Phase 4 Probe，而不是后置 Hook +- **与 checkpoint / rewind 协同**：Gemini 的长会话连续性不只靠摘要压缩，还靠 checkpoint 和 rewind 维持状态回退能力；`codebase_investigator` 子代理也能在压缩后补偿部分仓库结构感知 --- -## 二、Aider：递归分割摘要（最优雅） +## 二、Aider：递归分割摘要（结构最简洁的一类） > 源码：`aider/history.py`（143 行） @@ -103,12 +144,16 @@ done_messages ──→ 总 token > max_tokens (1024)? - **后台线程**：压缩在独立线程运行，不阻塞用户输入 - **递归深度控制**：最多 3 层递归，超过则 `summarize_all()` - **第一人称视角**：摘要以 "I asked you..." 开头，模拟对话连续性 +- **保留/丢弃语义明确**：Aider 优先保留最近一半 tail 原文，只压缩较早的 head；但在极长会话里会逐步退化为 `summarize_all()`，即几乎全历史摘要化 +- **与显式文件管理协同**：Aider 通过 `/add`、`/drop`、`/read-only` 等显式文件管理降低无关上下文噪声，因此能以相对简洁的递归摘要机制维持可控性 --- ## 三、Claude Code：三层压缩体系 -> 来源：API 文档 `compact-2026-01-12` + 二进制分析 +> 来源：本仓库现有 Claude Code 文档对 `compact-2026-01-12` 的记载 + 二进制分析上下文；补充见 `docs/tools/claude-code/02-commands.md` 与 `docs/tools/claude-code/EVIDENCE.md` +> +> 注：本仓库 `Claude Code` 证据页目前未系统收录压缩实现细节；`compact-2026-01-12` 这一标识符在仓库内多篇文档中被用于描述 compact 相关接口，但其公开 API 文档溯源仍应继续独立复核。因此，以下若涉及阈值、小版本行为或 prompt 细节，应理解为“基于仓库现有文档与二进制分析的整理”，而非完整源码级钉证。 ### 三层设计 @@ -132,13 +177,26 @@ done_messages ──→ 总 token > max_tokens (1024)? /compact 保留数据库迁移相关讨论 ``` -自 v2.0.64 起压缩即时完成（非阻塞）。 +按本仓库现有 API 文档与二进制分析整理，当前资料将其描述为非阻塞体验。 + +除三层压缩外，Claude Code 还通过 Prompt Caching 降低系统提示与稳定前缀的重复开销。这意味着 Claude 的长会话续航不能仅归因于“~95% 晚触发”，还应把缓存视为压缩之外的重要减载手段。 --- -## 四、Goose：渐进移除策略（最独特） +## 四、Goose：渐进移除策略（策略差异最明显的一类） + +> 源码位置见 `crates/goose/src/context_mgmt/mod.rs`；当前可稳定引用的是默认压缩阈值 **0.8**，文档名、环境变量名与实现常量名在仓库交叉文档中尚未完全统一。 +> +> 注：本仓库 `Goose` 证据页当前更侧重遥测 / 安全 / MCP 架构，压缩实现细节主要见官方 smart-context-management 文档与仓库内其他二次分析文档。 + +### 两层体系：增量后台摘要 + 超限 compact -> 源码：`context_mgmt/mod.rs`，阈值：`GOOSE_AUTO_COMPACT_THRESHOLD`（默认 0.8） +仓库内二次分析与 Goose 官方 smart-context-management 文档共同指向一个更完整的流程： + +1. **增量后台摘要**：按 10 个工具调用为一批，对较旧的工具输出做增量摘要，降低一次性压缩负载 +2. **超限 compact**：当会话继续逼近 context limit，再启动“中间向外”的渐进移除与 full compact 回退链路 + +这说明 Goose 的设计重点不是“等到 80% 再一次性大总结”，而是尽量把历史工具输出持续折叠，保留头尾骨架与近期现场。 ### "中间向外"策略 @@ -156,11 +214,15 @@ done_messages ──→ 总 token > max_tokens (1024)? 9 段结构化 Markdown，使用 `` 标签包裹推理过程，核心指令："不引入新想法"。 +> 注：这里关于“9 段 Markdown + ``”的细节，当前主要依据官方文档与仓库二次分析整理，证据强度弱于 Gemini / Aider / Kimi 这类可直接在本仓库源码分析文档中钉到实现细节的对象。 + --- -## 五、Kimi CLI：结构化 XML + 自定义焦点 +## 五、Kimi CLI：带标签的结构化摘要 + 自定义焦点 -> 源码：`soul/compaction.py`、`prompts/compact.md` +> 源码：`src/kimi_cli/soul/compaction.py`、`src/kimi_cli/prompts/compact.md` +> +> 注：当前仓库文档体系一致将其描述为 6 段、带标签的结构化摘要；但主证据页尚未摘录足够长的 prompt/源码原文来逐项钉住具体标签命名，因此这里有意不再把它写死为“6 段结构化 XML”。 ### 双触发条件 @@ -171,7 +233,7 @@ done_messages ──→ 总 token > max_tokens (1024)? 1. 保留最后 `max_preserved_messages=2` 轮用户/助手交互 2. 格式化旧消息为编号条目 -3. 输出 6 段结构化 XML：``、``、``、``、``、`` +3. 输出 6 段、带标签的结构化摘要，核心围绕当前焦点、环境、已完成事项、活跃问题、代码状态与重要上下文展开 ### 压缩优先级层次 @@ -191,21 +253,64 @@ done_messages ──→ 总 token > max_tokens (1024)? 使用 `tenacity` 库指数退避：初始 0.3s，最大 5s，抖动 0.5，最多 3 次。 +### 命令入口与事件可观测性 + +- `/compact [FOCUS]` 在执行前会先检查 checkpoint 数；若为 0 则直接返回，不发起无意义压缩 +- 压缩生命周期在 Wire 事件流中可观测：`CompactionBegin/End` +- `compaction_trigger_ratio = 0.85` 与 `reserved_context_size = 50000` 位于同一 `loop_control` 区块，说明 Kimi 把压缩视为主循环预算治理的一部分，而不是单独的会话后处理器 + --- -## 六、摘要 Prompt 哲学对比 +## 六、Qwen Code：分叉继承 Gemini 压缩框架，但常量细节待统一 + +> 来源：`docs/tools/qwen-code/EVIDENCE.md`（确认基于 Gemini CLI 分叉）+ 本仓库其他对比分档 + +Qwen Code 的上下文压缩框架总体上沿袭 Gemini CLI：包括 `ChatCompressionService`、Hook 事件里的 `PreCompact`、以及整体的权限 / 沙箱 / telemetry 基础设施继承关系。 + +但就“当前默认阈值”与“早期资料中的继承表述”而言，本仓库现有证据需要分层处理： + +- `docs/tools/qwen-code/05-settings.md` 已将 `model.chatCompression.contextPercentageThreshold` 的默认值写为 **0.7（70%）** +- 多篇更早的对比文档仍把其概括为 **50%（沿袭 Gemini 默认阈值）** +- `docs/comparison/qwen-code-feature-gaps.md` 还记录了一个更具体的失败处理线索：`hasFailedCompressionAttempt` 布尔断路器——一次压缩失败后，后续非强制压缩会跳过 + +因此，更稳妥的结论是： + +- **架构层面**：Qwen Code 继承了 Gemini 的压缩框架 +- **当前设置层面**：项目内可直接引用的设置文档默认值为 **70%**；“50%”更适合视为早期继承关系或旧文档表述 +- **实现细节层面**：失败断路器等内部分析线索仍未统一汇总到 `docs/tools/qwen-code/EVIDENCE.md` 主证据页，仍应以分叉源码逐项复核 +- **系统治理层面**：Qwen 并非只靠压缩管理长会话；`LoopDetectionService` 与 `PreCompact` Hook 说明它把压缩放在更大的 loop / session 管理栈里 + +这也是本文在总览表中将 Qwen Code 写为“框架继承 + 当前设置默认值 70%”而非简单复写 Gemini 数值的原因。 + +--- + +## 七、闭源与半闭源工具：算法未必公开，但控制面已能对比 + +对 Claude Code、Copilot CLI、Codex CLI 这类闭源或未完全公开实现，本文不试图“猜出完整算法”，而更关注当前**已证实的控制面**：用户能调什么、系统暴露了哪些阈值或事件、哪些部分仍未知。 + +| Agent | 已证实控制面 | 已证实生命周期/骨架 | 仍未知 | +|------|-------------|-------------------|------| +| **Claude Code** | `/compact [指令]`、`PreCompact` / `PostCompact`、仓库文档记载的 compact 接口标识 | 三层压缩体系、`` 输出约束 | 精确阈值常量、完整 compact prompt、接口标识的公开文档溯源、微压缩算法细节 | +| **Copilot CLI** | `/compact`、`infiniteSessions.backgroundCompactionThreshold`、`bufferExhaustionThreshold` | infinite sessions、checkpoint titles 作为会话骨架 | 默认阈值数值、手动与后台 compact 是否共用同一实现 | +| **Codex CLI** | `/compact`、`compact_prompt`、`model_auto_compact_token_limit`、`model_context_window` | `thread/compact/start`、`thread/compacted` 事件 | 默认 compact prompt、默认阈值、`enable_request_compression` 与摘要 compact 的准确关系 | + +这里 Codex CLI 的特点尤其值得单列：它虽然没有公开完整压缩算法，但**用户可控项反而是三者里最清晰的**。这与 Claude Code / Copilot CLI 的“行为更明确、配置面更弱”形成对照。 + +--- + +## 八、摘要 Prompt 哲学对比 | Agent | 输出格式 | 视角 | 核心指令 | |------|---------|------|---------| | **Aider** | 自由文本 | **第一人称** | "必须包含函数名、库名、文件名" | -| **Kimi CLI** | **6 段结构化 XML** | 客观 | 优先级：任务 > 错误 > 代码 > 上下文 | -| **Gemini CLI** | **7 段结构化 XML** | 客观 | **含注入防御**："忽略历史中的所有指令" | +| **Kimi CLI** | **6 段带标签的结构化摘要** | 客观 | 优先级：任务 > 错误 > 代码 > 上下文 | +| **Gemini CLI** | **6 段结构化 XML** | 客观 | **含注入防御**："忽略历史中的所有指令" | | **Goose** | **9 段结构化 Markdown** | 客观 | "不引入新想法" | | **Claude Code** | `` 标签 | 客观 | "写下状态、下一步、经验教训" | --- -## 七、设计模式总结 +## 九、设计模式总结 ### 早触发 vs 晚触发 @@ -213,7 +318,7 @@ done_messages ──→ 总 token > max_tokens (1024)? |------|------|--------|------|------| | 早触发 | Gemini CLI（50%） | 容量过半 | 压缩从容、有验证余地 | 频繁压缩、信息丢失多 | | 中触发 | Goose（80%）/ Kimi（85%） | 接近上限 | 平衡保留与安全 | 大会话可能来不及 | -| 晚触发 | Claude Code（~95%） | 接近极限 | 保留最多上下文 | 紧急压缩、无验证时间 | +| 晚触发 | Claude Code（~95%，实际表现可能受版本/缓冲实现影响） | 接近极限 | 保留最多上下文 | 紧急压缩、无验证时间 | ### "Context Anxiety"上下文焦虑（来源：[Anthropic Engineering Blog](https://www.anthropic.com/engineering/harness-design-long-running-apps)，2026-03-24） @@ -224,12 +329,9 @@ Anthropic 工程团队在长任务 harness 开发中发现：**模型在上下 > **Compaction vs Context Reset 的区别**（原文）：Compaction 是"原地摘要，保持连续性"；Context Reset 是"清空重来，代价是需要足够的交接信息让下一个 Agent 接手"。 -**这解释了压缩阈值差异的深层原因**： -- Claude Code 设 ~95% 阈值——如果使用 Opus 4.5+，context anxiety 的影响可能已大幅降低（"largely removed"），使得更晚触发压缩成为可能 -- 如果使用 Sonnet 作为主模型，可能需要更早触发或使用 context reset -- Gemini CLI 50% 阈值——可能 Gemini 模型也存在类似的 context anxiety +这类工程观察更适合作为**理解压缩策略差异的解释框架**，而不是直接用于反推每个产品阈值的设计因果。换言之，它可以帮助理解为什么一些系统会更重视“保留连续性”，另一些系统会更重视“重置后重新交接”，但若缺少产品方直接说明，就不宜据此断言 Claude Code、Gemini CLI 或其他 Agent 的具体阈值就是由 `context anxiety` 直接决定的。 -> **实践建议**：压缩阈值不应只考虑"保留多少上下文"，还应考虑"模型在多少容量下开始焦虑"。不同模型的焦虑阈值不同。 +> **实践建议**：压缩阈值不应只考虑"保留多少上下文"，还应考虑模型在接近容量上限时的稳定性、摘要成本、交接复杂度与可验证性；但具体阈值设计仍应以各产品的直接证据为准。 ### "Context Rot"上下文腐烂（来源：[Effective Context Engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)，2025-09-29） @@ -253,11 +355,11 @@ Anthropic 工程团队在长任务 harness 开发中发现：**模型在上下 ### 验证步骤的价值 -只有 Gemini CLI 实现了独立验证（Phase 4 Probe）。其他所有工具都信任单次 LLM 输出。这是**成本与质量的核心权衡**——额外一次 LLM 调用的成本 vs 压缩质量提升。 +在本文覆盖且实现细节可核实的 Agent 中，Gemini CLI 是目前唯一明确展示独立 Probe 验证步骤的方案。对 Claude Code、Copilot CLI、Codex CLI 这类闭源或细节未公开工具，更稳妥的表述应是“**未见公开证据**”而不是直接断言其不存在。这体现了成本与质量之间的一组典型权衡：额外一次 LLM 调用的成本 vs 压缩质量提升。 --- -## 八、压缩后的 UI 行为：清屏 vs 保留 +## 十、压缩后的 UI 行为：清屏 vs 保留 压缩不仅是后端操作——**用户看到什么**直接影响对 Agent 状态的认知。各 Agent 在压缩后的 UI 处理策略差异显著。 @@ -306,7 +408,7 @@ if (message.summarizeMetadata) { | Agent | 压缩后清屏？ | 用户看到什么 | 来源 | |------|------------|------------|------| | **Claude Code** | **是** | "Summarized conversation" 标记 + 新的空白对话区域 | 二进制分析 v2.1.86 | -| **Kimi CLI**（Web UI） | **是** | 仅保留最后一轮用户消息起的内容 | 源码：`useSessionStream.ts` `CompactionEnd` handler | +| **Kimi CLI（Web UI）** | **是** | 仅保留最后一轮用户消息起的内容 | 源码：`useSessionStream.ts` `CompactionEnd` handler | | **Gemini CLI** | 否 | 内联显示 "Chat history compressed from X to Y tokens" | 源码：`compressCommand.ts` → `ui.addItem()` | | **Qwen Code** | 否 | 继承 Gemini（内联压缩状态消息） | 源码：`compressCommand.ts`（分叉） | | **Aider** | 否 | 后台静默替换消息列表，无可见变化（verbose 模式下显示一行日志） | 源码：`base_coder.py` L1002-1034 | @@ -318,14 +420,14 @@ if (message.summarizeMetadata) { | 策略 | 优势 | 劣势 | |------|------|------| -| **清屏**（Claude Code、Kimi） | 状态一致、心理重置、防误导 | 用户失去视觉上下文回溯、可能中断思路 | +| **清屏**（Claude Code、Kimi Web UI） | 状态一致、心理重置、防误导 | 用户失去视觉上下文回溯、可能中断思路 | | **保留**（Gemini、Qwen、Aider、Codex） | 视觉连续性、可回溯历史、不中断流程 | 用户可能误以为模型"记得"全部内容 | -> **核心洞察**：清屏与否反映了两种不同的设计哲学——**状态准确性**（显示的 = 模型知道的）vs **视觉连续性**（保留用户的阅读上下文）。Claude Code 和 Kimi CLI 选择了前者，其他 Agent 选择了后者。没有绝对的对错——这取决于用户对 Agent 状态感知的期望。 +> **核心洞察**：清屏与否反映了两种不同的设计哲学——**状态准确性**（显示的 = 模型知道的）vs **视觉连续性**（保留用户的阅读上下文）。就当前可核实证据看，Claude Code 与 Kimi Web UI 更接近前者，其他 Agent 更接近后者。没有绝对的对错——这取决于用户对 Agent 状态感知的期望。 --- -## 九、工具定义膨胀：134K tokens 的教训（来源：[Anthropic Engineering Blog](https://www.anthropic.com/engineering/advanced-tool-use)，2025-11-24） +## 十一、工具定义膨胀：134K tokens 的教训（来源：[Anthropic Engineering Blog](https://www.anthropic.com/engineering/advanced-tool-use)，2025-11-24） 上下文压缩不仅要处理对话历史——**工具定义本身就是上下文膨胀的主要来源**： @@ -353,13 +455,24 @@ if (message.summarizeMetadata) { ## 证据来源 -| Agent | 源码文件 | 获取方式 | +> **证据强度说明**：Gemini / Aider / Kimi 的实现细节更多直接来自开源源码或本仓库源码分析文档；Claude Code / Copilot CLI / Codex CLI 更依赖官方文档、二进制分析或配置项；Goose 与 Qwen Code 的部分细节当前仍混合使用官方资料、仓库二次分析和分叉关系推断。 + + +| Agent | 主要来源 | 获取方式 | |------|---------|---------| -| Gemini CLI | `chatCompressionService.ts` + `prompts/snippets.ts` | GitHub 源码 | +| Gemini CLI | `packages/core/src/services/chatCompressionService.ts` + `packages/core/src/prompts/snippets.ts` | GitHub 源码 | | Aider | `aider/history.py`（143 行）+ `aider/prompts.py` | GitHub 源码 | -| Claude Code | API 文档 `compact-2026-01-12` + 二进制分析 | 官方文档 + strings | -| Kimi CLI | `soul/compaction.py` + `prompts/compact.md` | GitHub 源码 | -| Goose | `context_mgmt/mod.rs` + [官方文档](https://block.github.io/goose/docs/guides/sessions/smart-context-management/) | GitHub 源码 + 官方文档 | -| Qwen Code | 继承 Gemini CLI | GitHub 源码 | +| Claude Code | `docs/tools/claude-code/02-commands.md` 中对 `compact-2026-01-12` 的记载 + `docs/tools/claude-code/EVIDENCE.md` | 仓库文档整理 + 二进制分析 | +| Kimi CLI | `src/kimi_cli/soul/compaction.py` + `src/kimi_cli/prompts/compact.md` | GitHub 源码 | +| Goose | `crates/goose/src/context_mgmt/mod.rs` + [官方文档](https://block.github.io/goose/docs/guides/sessions/smart-context-management/) | GitHub 源码 + 官方文档 | +| Qwen Code | `docs/tools/qwen-code/EVIDENCE.md`（确认 Gemini CLI 分叉）+ 本仓库其他对比分档 | 分叉关系 + 仓库交叉审计 | | Copilot CLI | `infiniteSessions.backgroundCompactionThreshold` | SEA 反编译 | -| Codex CLI | `compact_prompt` 配置 | 二进制分析 | +| Codex CLI | `compact_prompt`、`model_auto_compact_token_limit` 配置项 | 二进制分析 | + +### 外部研究 / 工程参考 + +- Liu et al., [*Lost in the Middle: How Language Models Use Long Contexts*](https://arxiv.org/abs/2307.03172), 2023 +- Hsieh et al., [*RULER: What’s the Real Context Size of Your Long-Context Language Models?*](https://arxiv.org/abs/2404.06654), 2024 +- Li et al., [*Selective Context: Compressing Context to Enhance Inference Efficiency of Large Language Models*](https://arxiv.org/abs/2310.06201), 2023 +- Anthropic, [*Effective Context Engineering for AI Agents*](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) +- Anthropic, [*Harness Design for Long-Running Agentic Apps*](https://www.anthropic.com/engineering/harness-design-long-running-apps)