上下文的三板斧
Compaction、结构化笔记、子 Agent 架构，长任务的三种上下文管理策略
本页解决的问题
先给结论「上下文的三板斧」要解决的关键问题是什么？
Compaction、结构化笔记、子 Agent 架构，长任务的三种上下文管理策略
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
Option A：开启新窗口，但新窗口什么都不记得，Agent 会重复已做过的工作。
Option B：继续在旧窗口工作，但随着 Token 增多，模型的注意力被稀释，表现下降。
这不是理论问题。Claude Code、Cursor、Devin 这些产品每天都在解决这个问题。
- 关键决策：选择什么保留、什么丢弃。这是一个信息论问题：并非所有 Token 都等价，有些信息丢了就无法恢复。
- 低风险操作：清理旧的 tool call 结果（比如文件列表、搜索输出），这些通常不影响后续推理。
- 高风险操作：丢弃架构决策的推理过程、未解决的 bug 描述，这些如果丢了，Agent 会重蹈覆辙。
- Claude Code 的实践：保留架构决策和未解决的 bug 信息，丢弃冗余的文件内容输出和已完成任务的中间步骤。
- 核心思想：把短期记忆（上下文窗口）外化为长期记忆（文件系统），实现跨窗口的信息延续。
- Claude Code 的实践：维护 TODO list 文件，每完成一步就更新，这样即使上下文被压缩或重置，打开 TODO 就知道进度。
- Claude 打宝可梦的案例：Agent 维护一个游戏笔记文件，记录地图位置、已获道具、下一步计划。每次新对话开始时先读这个笔记，实现记忆传递。
- 关键设计：笔记格式要固定且结构化，不能是自由散文，否则读回来时还要额外 Token 来理解笔记内容。
- 核心价值：关注点分离 + 上下文隔离。子 Agent 的工作草稿不会污染主 Agent 的上下文。
- Token 经济：一个子 Agent 可能在内部消耗 30,000 Token 来读代码、分析依赖、做推理，但只向上报告 1,500 Token 的结论。主 Agent 的上下文保持精简。
- 并行优势：多个子 Agent 可以同时工作，各自探索不同方向，最后由主 Agent 整合。这比单一 Agent 串行探索快得多。
- 真实应用：Cursor 的 background agent、Claude Code 的 Task tool，都是子 Agent 架构的体现。
- CLAUDE.md / Rules 文件直接载入
- 用户偏好、项目配置
- 高频使用的上下文信息
- 优点：即时可用，无需额外调用
- 缺点：每次都占 Token，不管用不用得到
- 用 glob/grep 按需搜索文件
- 用 RAG 检索相关文档
- 调用 API 获取实时数据
- 优点：上下文保持精简，只含当前需要的
- 缺点：多一次工具调用的延迟
类比浏览器缓存策略：热数据放内存缓存（预加载），冷数据放磁盘或网络获取（JIT）。目标是让上下文的命中率最大化：大多数推理所需的信息已经在窗口里，偶尔需要的才动态获取。
| 策略 | 核心思想 | 适用场景 | 代表产品 |
|---|---|---|---|
| Compaction | 压缩旧上下文，保留关键信息继续 | 连续长对话，不会被中断 | Claude Code auto-compact |
| Note-taking | 主动写笔记到外部，跨窗口读回 | 可能中断、需跨 session 延续 | Claude Code TODO、Cursor Rules |
| Sub-agent | 子 Agent 深入探索，只回传摘要 | 需要深度探索但不想污染主上下文 | Cursor Task、Claude Code spawn |
「根本挑战」为什么能找到相关内容
「Compaction、结构化笔记、子 Agent 架构，长任务的三种上下文管理策略」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「Compaction、结构化笔记、子 Agent 架构，长任务的三种上下文管理策略」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
- 关键决策： 选择什么保留、什么丢弃。这是一个信息论问题：并非所有 Token 都等价，有些信息丢了就无法恢复
- 低风险操作： 清理旧的 tool call 结果（比如文件列表、搜索输出），这些通常不影响后续推理
- 高风险操作： 丢弃架构决策的推理过程、未解决的 bug 描述，这些如果丢了，Agent 会重蹈覆辙
先区分找得到和找得准
把「Compaction、结构化笔记、子 Agent 架构，长任务的三种上下文管理策略」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「根本挑战」走到「策略一」
「根本挑战」先把问题落在「长任务的失忆问题 一个复杂的编程任务可能需要 Agent 执行数十步操作，产生数万 Token 的对话历史。当上下文窗口快满时，系统面临两难选择： Option A： 开启新窗口，但新窗口什么都不记得，Agent 会重复已做过的工作。 Option B： 继续在旧窗口工作，但随着 Token 增多，模型的注意力被稀释，表现下降。 这不是理论问题。Claude Code、Cursor、Devin 这些产品每天都在解决这…」上；到了「策略一」，讨论继续推进到「1 Compaction 上下文压缩 当对话快要触达上下文窗口上限时，用一次 LLM 调用对已有对话做 摘要 ：保留关键信息，丢弃冗余细节，然后在压缩后的上下文上继续工作。 关键决策： 选择什么保留、什么丢弃。这是一个信息论问题：并非所有 Token 都等价，有些信息丢了就无法恢复。 低风险操作： 清理旧的 tool call 结果（比如文件列表、搜索输出），这些通常不影响后续推理。 高风险操作： 丢弃架构决策的推理…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「根本挑战」：长任务的失忆问题 一个复杂的编程任务可能需要 Agent 执行数十步操作，产生数万 Token 的对话历史。当上下文窗口快满时，系统面临两难选择： Option A： 开启新窗口，但新窗口什么都不记得，Agent 会重复已做过的工作。 Option B： 继续在旧窗口工作，但随着 Token 增多，模型的注意力被稀释，表现下降。 这不是理论问题。Claude Code、Cursor、Devin 这些产品每天都在解决这…
- 「策略一」：1 Compaction 上下文压缩 当对话快要触达上下文窗口上限时，用一次 LLM 调用对已有对话做 摘要 ：保留关键信息，丢弃冗余细节，然后在压缩后的上下文上继续工作。 关键决策： 选择什么保留、什么丢弃。这是一个信息论问题：并非所有 Token 都等价，有些信息丢了就无法恢复。 低风险操作： 清理旧的 tool call 结果（比如文件列表、搜索输出），这些通常不影响后续推理。 高风险操作： 丢弃架构决策的推理…
- 「最后的要点」：核心思想： 把短期记忆（上下文窗口）外化为长期记忆（文件系统），实现跨窗口的信息延续
最后的「最后的要点」把讨论落到「核心思想： 把短期记忆（上下文窗口）外化为长期记忆（文件系统），实现跨窗口的信息延续」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。