20Context Engineering 3 支柱

Anthropic 官方 3 支柱(不是 4 个——Just-in-Time Retrieval 是 tool use 的应用,不算独立支柱,这是常见误传):

1. Compaction(同 context 内压)。把历史 messages 摘要成短版,继续在同一 context 推进。Anthropic SDK 内置,大约在 95% context 时自动触发。优点:连续性好,model 不会突然"忘记";缺点:多次 compaction 后信息漂移严重,适合中等长度任务,不适合超长任务(见 #21)。

2. Structured Note-taking(跨 context 持久化)。Agent 主动把"重要状态"写到外部文件(progress.md、decisions.log、scratchpad/),context 撕掉重启后从文件读回。这是 Long-Running Agent 的核心机制(见 #17)。结构化是关键——纯叙述文本下次读回模型不知道从哪续。

3. Multi-agent Architecture(跨 context 分散)。用 sub-agent 隔离细节 context,主 agent 只看浓缩后的结果。Search agent 跑探索性查询然后返回摘要,主 agent 不被 raw search results 填满 context。覆盖 #22 Sub-Agent 委派 + #23 Multi-Agent 编排两种模式。

三者关系(对比矩阵):

             | 信息保留    | 适用任务长度 | 关键风险
─────────────┼─────────────┼──────────────┼──────────────────
Compaction   | 摘要,有损 | 中(单 session) | 信息漂移
Note-taking  | 全量,无损 | 长(跨 session) | 文件结构差则没用
Multi-agent  | 隔离,无损 | 复杂(并行子任务) | token 成本 2-3×

生产 harness 三者都用——它们不是 "选一个",是组合使用。一个典型 Claude Code session:对话内用 compaction,跨 session 用 note-taking(progress.md),复杂调研派 sub-agent。

用户:"调研一下我们 codebase 里所有 deprecated API 的使用,然后重写"

[Phase 1 — 探索:用 Sub-agent(支柱 3)]
  主 agent 派 Explore sub-agent
  Sub-agent 跑大量 grep / file reads,context 涨到 80K
  Sub-agent 返回 ↓ 浓缩结果:
    "找到 12 处 deprecated API,主要分布在 auth/ 和 payment/"
  主 agent context 只 +500 token

[Phase 2 — 规划:用 Note-taking(支柱 2)]
  主 agent 把 12 处列表 + 重写计划写入 plan.md
  写入后 plan.md = cross-session 持久状态

[Phase 3 — 执行:用 Compaction(支柱 1)]
  主 agent 开始改第 1-3 处
  改到第 4 处时 context 涨到 ~90%
  SDK 自动 compaction:把 1-3 处的细节摘要,腾出空间
  继续改第 4-6 处

[Phase 4 — 跨 session:再用 Note-taking(支柱 2)]
  用户暂停。主 agent 把当前进度更新到 progress.md
  下次启动从 progress.md + plan.md 继续

这个例子说明:三支柱不是"选哪个",是按任务阶段组合使用。理解这个组合模式,才算 own 了 context engineering。