Anthropic 在 2025 年 9 月的官方博客里说得很直接：上下文工程是提示词工程的自然进化。提示词工程问"什么样的词能产生最好的输出"，上下文工程问"什么样的信息配置最可能产生我想要的行为"。

为什么会变：因为 Agent 在多轮循环里跑，每一轮都产生更多材料，而这些材料未必都该进入下一轮。决定什么留下、什么移除，才是工程问题。

一个具象的比喻：LLM 是 CPU，上下文窗口是它的 RAM。你的工作就是做好这块 RAM 的调度。

上下文腐烂：Context Rot

这是上下文工程存在的根本原因。

Chroma 在 2025 年 7 月的技术报告里测试了 18 个模型（含 Claude Opus 4、GPT-4.1、Gemini 2.5 Pro、Qwen3），任务是难度固定、只变输入长度。结果是：所有实验的性能都一致地下降。

Anthropic 也报告同样的模式：有些模型退化更平缓，但没有一个免疫。

原因是架构性的——Transformer 让每个 token 关注其他所有 token，产生 n² 的成对关系，注意力随上下文增长而稀释。

Lost in the Middle

Liu 等人的经典发现（TACL，被引 7000+）：模型对长上下文中段的信息利用率显著下降，规模化场景下退化可达 40%。

关键推论：能塞进窗口的信息量，和使用好它的能力，是两条完全不同的曲线。

更大的窗口能解决问题吗

不能。这是最普遍的认知误区。

百万 token 窗口仍然会上下文腐烂，仍然逼你做选择。Anthropic 明确表示等更大窗口不是策略。

指导原则在任何窗口大小下都成立：找到能产生目标结果的、最小的高信号 token 集合。

四个被混用的术语

Token 预算 vs 注意力预算

Token 预算只是硬性上限，注意力预算才是有效上限。 Token 预算控制器实际要控制的是注意力预算，通常设在物理边界的 60-80%。

KV Cache vs Prompt Cache

两个名字相似，层次完全不同。

超长上下文的 KV Cache 可能达到数十 GB——1M token 约需 15GB 显存/用户。这决定了"无脑全量上下文"在服务端不可扩展。

四条实战路线

Anthropic 的工程方法论收敛为四个动词，社区总结成标准框架。它们不是四选一，是分层组合。

判断标准只有一条：每一层都要回答"这个信息为什么值得占用主上下文"。

路线一：写穿（Write-through）

核心理念：不是所有信息都要一直待在上下文里。写到外部存储，用的时候再调。

这像人的记忆方式——你不会把一整本书背下来，而是记住它在书架上的位置。

坑：Agent 把东西写出去就忘了读。指针体系必须有读回机制——只写不读的外部存储等于没有。

路线二：选择（Select）

核心理念：别一次性把知识库全塞进去，按需动态加载。

从预检索到即时检索（Just-in-Time Retrieval）

这是 2026 年的重要趋势转变：

• 过去：RAG 在推理前一次性把相关文档塞满上下文

• 现在：Agent 只保留轻量"指针"（文件路径、URL、数据库查询），真需要了再用工具拉数据

Claude Code 就是这么干的——它不会一次性读完整个代码库，而是用 head、tail、grep、find 定点加载。

这就像人的认知：你查资料不会把整个图书馆搬回家，只带回那几页需要的。

代价要说清楚：检索质量的天花板就是系统的天花板。检索不准，选择机制再精巧也没用。

路线三：压缩（Compress）

当上下文接近上限，把历史摘要化，用摘要开启新窗口。

1. 调用模型总结历史对话
2. 抽取：关键决策、未解决问题、重要文件路径
3. 丢弃：冗余的工具原始输出（老的 ls 输出没必要留）
4. 用摘要作为新上下文起点继续工作

分层压缩：2026 年更好的做法

默认方案——"把旧轮次压成短段落、保留最近轮次原文"——把同一段时间的所有信息一视同仁，这在 2026 年已被明确指出是粗糙的。

更好的做法是分层压缩：

压缩的第一原则是永不丢约束。 丢掉"用户要求周一交"这种句子的代价，远大于丢掉一千字过程描写。

最安全的压缩形式：Tool Result Clearing

已经调用过很久、结果也已被后续消化的老工具输出，可以直接清掉，基本无损。

Anthropic 的务实建议：先保召回（recall），再优化精度（precision）。压缩初期宁可多留，确保不丢关键信息；稳定后再逐步剪掉明显多余的部分。

路线四：隔离（Isolate）

把 Agent 搞不定的复杂任务，拆给子 Agent，每个在自己的干净窗口里工作。

主 Agent：高层规划、任务分发、结果汇总
  └─ 子 Agent A：独立窗口，专注子任务（可能消耗几万 token 探索）
  └─ 子 Agent B：独立窗口，专注另一子任务
     ↓
  只返回 1-2K token 的精炼总结

主 Agent 的上下文始终干净，不被子任务细节淹没。

隔离的边界

Cognition 的两条原则最值得记住：

1. 共享上下文（Share context）

2. 行动携带隐含决策（Actions carry implicit decisions）

2026 年的判断标准：

看子任务之间需不需要谈判——需要谈判的不要拆。

四种上下文灾难

成本账：最硬的存在理由

上下文工程的成本差距已经大到离谱。

三个实务结论：

结论一：这是比换模型更大的杠杆。 同样效果，省 50-90% 成本。

结论二：TTFT（首 token 延迟）随窗口膨胀而恶化。 上下文长度同时是成本问题和体验问题。

结论三：KV cache 决定了无脑全量上下文在服务端不可扩展。 上下文工程是刚需，不是优化。

场景化选型