转载提示：本文转载自 bbruceyuan 原文。原作者：bbruceyuan。原文发布日期：2026-02-22。本文已按站点规范移除原文中的推广/导流内容，仅保留技术分析与示例。0. 阅读收获 (takeaway) 读完本文，你将了解：Context Rot（上下文腐烂）：为什么更大的 context window 不是万能解药Cache-Safe Compaction：如何在压缩 context 时不破坏 cachePlan 模式的演进：从 todo.md 到专门 planner agent文件系统 & Just-in-Time Context：Agent 的"延展记忆"子代理的 Cache 友好设计：90%+ prefix reuse 是怎么做到的The Bitter Lesson：哪些设计是持久的，哪些会被模型进步淘汰 前置知识：本文是 Agent 系统中的 Prompt Caching 设计（上） 的续篇。如果你还没读过，建议先了解 Cache 破坏机制、Prompt 布局和工具管理策略。更基础的概念见 理解 KV Cache 与 Prompt Caching。1. Context Rot：上下文腐烂 Anthropic 的研究指出：随着 context 中 token 增加，模型注意力分散，性能下降。 Attention 中每个 token 要和所有其他 token 建立 $n^2$ 的 pairwise 关系。Context 越长 → 每个 token 的"注意力预算"越少 → 模型可能"忘记"早期的重要指令，或被大量 tool output 稀释关键信息。 更大的 context window 不是万能解药。 能塞进去不代表模型能有效利用。 这就是为什么 Agent 不能简单地把所有信息堆进 context——我们需要主动管理。2. Compaction：Cache-Safe 的上下文压缩 压缩是解决 context 增长的关键手段，但必须是 cache-safe 的。2.1 Claude Code 的 Cache-Safe Compaction Cache-Safe Compaction 流程 Claude Code 的压缩策略非常精巧：压缩请求使用完全相同的 system prompt + tools + 对话前缀只在末尾追加 compaction prompt这样压缩请求本身就能复用父会话的 cache预留 "compaction buffer"——context 快满之前就开始压缩2.2 OpenAI Codex 的 /responses/compact Codex 提供专门的 API 端点：返回压缩后的 item 列表 + encrypted compaction 项目保留模型对原始对话的"潜在理解"（指的是把 summary 内容放到上下文中）超过 auto_compact_limit 自动触发 两者共同点：压缩是必要的，但压缩过程本身不能破坏已有的 cache。3. 注意力操纵：Plan 模式的演进 Agent 如何确保模型"聚焦"在正确的事情上？三家有一个有趣的演进过程。3.1 Manus 的演进初期用 todo.md → 约 1/3 actions 浪费在更新 todo 上！最新：专门的 planner agent 替代 → 效率大幅提升3.2 Claude Code 的 Plan Mode独立规划阶段 → 用户审批 → 再执行模型可自主调用 EnterPlanMode3.3 Codex 的 update_plan执行中的一个工具无需用户审批，更轻量 | 方案 | 独立阶段？ | 用户审批？ | 自主控制？ | |------|----------|----------|----------| | Manus planner agent | 独立 agent | 无需审批 | Agent 决定 | | Claude Code Plan Mode | 独立阶段 | 需要审批 | 模型可自主进入 | | Codex update_plan | 也有独立阶段 | 无需审批 | 执行中随时调用 |4. 保留错误内容 一个有趣的共识：不要删除失败的 action 和 observation。 Manus 不会从 context 中删除失败的工具调用结果。双重好处：保持 append-only → 保护 cache模型从错误中学习 → 调整后续策略 错误恢复是真正 agentic 行为的标志。 看不到自己犯的错，怎么学会避免？5. 文件系统 & Just-in-Time Context Agent 不需要把所有信息都放在 context 里——文件系统可以作为"延展记忆"。5.1 Manus 的文件系统…