CHAPTER 04
上下文工程 Context Engineering
把上下文当作稀缺的“注意力预算”来经营
上下文工程是提示词工程的自然演进。问题从“找对措辞”变成：“什么样的上下文配置，最可能激发我们想要的行为？” 上下文 = 采样时纳入的所有 token；工程目标是在 LLM 的固有约束下，优化这些 token 的效用。
为什么重要：Context Rot 与注意力预算
随着上下文 token 增多，模型从中准确回忆信息的能力会下降——这被称为“上下文腐蚀”。Transformer 中 n 个 token 有 n² 成对关系，长上下文会让注意力被稀释。结论：上下文是边际收益递减的稀缺资源，必须精心策展。
核心原则
最小高信号 token 集
找到“能完整刻画预期行为的最小信息集合”。最小不等于短——该给的前置信息要给足，但不塞冗余。
系统提示
结构化分区
用 XML 标签 / Markdown 标题把提示分区（背景、指令、工具指南、输出格式）。先给最强模型试最简提示，再按失败模式补充。
示例
少而经典 few-shot
示例是“胜过千言的图画”。不要堆一长串边角案例，而是挑选多样、有代表性的典型示例，展示期望行为。
上下文的主要组成（都要“ informatively yet tight”）
- System instructions 系统指令
- Tools 工具与 MCP 的接口约定
- Message history 多轮消息历史
- External / retrieved data 外部与检索到的数据
- Examples 少样本示例
运行时检索与“及时(JIT)上下文”：不必把所有东西预先塞满。让 Agent 像人一样在文件系统中自主导航、按需拉取——目录层级、命名规范、时间戳都是有用信号，支持“渐进式披露”。代价是运行时探索比预计算检索更慢，需要好的工具与启发式来引导。
混合策略：Claude Code 的做法
一部分内容（如 CLAUDE.md）预先直接放进上下文；同时用 glob / grep 这类原语“及时”检索文件，绕过陈旧索引和复杂语法树。内容变化不剧烈的领域（法务、金融）更适合这种混合。总基调依然是：做能奏效的最简单的事。