Context Engineering
如果说 Prompt Engineering 是写作，Context Engineering 就是资源管理——管理的对象是一个随任务推进不断膨胀的上下文窗口。
问题的形状
Agent 运行时，上下文沿一个固定的方向恶化：每轮循环追加观察和工具结果，只增不减。而模型的处境随之恶化：
- 窗口上限：超过就装不下，硬截断会丢失关键信息。
- 注意力稀释：即使装得下，模型对窗口中部内容的利用率也显著偏低（lost in the middle）。关键信息埋在 50 万 token 中间，约等于不存在。
- 成本：每次模型调用都为整段上下文付费，上下文越长，循环越贵。
因此 Context Engineering 的目标不是“塞得越多越好”，而是：在任何时刻，让窗口里恰好是大脑完成任务所需的那一小块高信号内容。
策略一：压缩
当历史轨迹膨胀时，把旧的对话与结果折叠成摘要：
- 会话摘要：把前 N 轮对话压缩成一段“到目前为止发生了什么”，替换掉原文。主流 Coding Agent 的 auto-compact 就是这个机制。
- 工具结果裁剪：命令输出、文件内容往往一上来就是几万 token。常见做法是截断保头部、只回传统计信息（“共 3400 行，前 100 行如下”），或让 Agent 分页按需取。
- 结构化笔记：让 Agent 把关键事实写进一份持续维护的笔记文件（任务目标、已尝试的方案、重要发现），旧轨迹可以被丢弃，笔记始终常驻。这比对话摘要更抗信息丢失，因为它是有选择地保留。
压缩的代价
摘要必然丢信息，而丢掉的可能是后来才发现的关键细节。工程上的对策是“压缩 + 底账”：摘要进上下文，原文落盘（文件、数据库），需要时再检索回来。让“扔掉”变成“挪走”。
策略二：隔离
不是所有信息都必须挤进同一个窗口：
- 子代理隔离：给一个耗时的搜索或分析任务派生一个子 Agent，它有自己的窗口，干完只把结论带回主窗口。主 Agent 用几百 token 拿到几万 token 的劳动成果。这是多智能体协同（进阶篇）最重要的动机之一。
- 环境外置：把大块状态放到文件系统或数据库里，上下文只保留路径和索引。需要时读一小段——文件系统就是最大的外存。
- 分而治之：任务本身拆给多次独立调用，每次调用只看到它需要的那部分（映射-化简的思路）。
策略三：检索注入
窗口有限而世界无限，于是“不存储、按需取”成为第三条路：
- RAG 式注入：知识库内容不进上下文，等任务需要时检索最相关的片段注入。详见用户记忆与知识库一章。
- 工具化读取：把“查资料”变成一次工具调用（搜索、grep、SQL），让大脑自己决定何时取、取多少——把信息获取的主动权交给模型，通常比预先全量塞入更好。
KV Cache：被忽视的工程收益
现代推理服务对前缀完全相同的部分有缓存（前缀缓存），命中后大幅降低延迟和费用。这对上下文管理的启示是：
- 系统提示和工具定义放在最前面，一旦确定就不要改（连顺序都不要变），否则缓存全部失效。
- 上下文尽量只做追加（append-only），避免改写历史消息。
这是少数“免费的午餐”：同样的内容，组织顺序不同，成本可以差数倍。
本章小结
- 上下文问题的本质：窗口有限、注意力稀释、成本线性增长，三股力量都随会话变长而恶化。
- 三大策略：压缩（摘要 + 底账）、隔离（子代理 + 环境外置）、检索注入（RAG + 工具化读取）。
- 高信号小窗口优于低信号大窗口。
- 利用前缀缓存：前缀稳定、只增不改。