只看“200K token 上下文窗口”这一规格，似乎可以把大多数代码库完整放进去。但真的全部放入后，响应质量反而会明显下降。
多项研究已经证实，模型在较长上下文中可能忽略中间内容。能够放进去和能够用好，是两个不同的问题。
上下文工程正是由此产生的概念。简单来说，它是一种设计方法：把有限的上下文窗口当作预算，在每个时刻只保留最有用的信息。
本文将整理上下文为什么是一种预算、节省预算的四种策略，以及 CLAUDE.md 等始终加载文件的设计标准。
先来看看核心要点。
- 上下文不是越大越好，而是相关性越高越好。
- 策略主要有四种：选择性加载、摘要（压缩）、隔离和外部化（记忆）。
- 始终加载的文件（如 CLAUDE.md）应保持简短，只包含“始终成立的事情”。
- 工具和指令也会消耗上下文。注册但从不使用的工具就是成本。
为什么是预算？上下文的成本结构
上下文窗口会同时产生三种成本。
第一是性能成本。无关内容越多，模型的注意力越分散。尤其是长上下文的中间部分更难被找回，这种“lost in the middle”现象已经广为人知。
第二是金钱成本。输入 token 每次请求都会计费。对话越长，相同内容被重复计费的次数就越多。
第三是机会成本。杂乱信息占用的空间越多，真正需要的代码和文档就越没有位置。
上下文工程带来的视角转变是：不要问“能放多少”，而要问“这个 token 现在有资格放在这里吗？”
策略 1、2：选择性加载与摘要
选择性加载（retrieval）是在需要时只获取所需内容的策略。与其完整读取一个 2,000 行的文件，不如只读取相关函数；与其加载整篇文档，不如通过搜索获取对应章节。
Skill 的渐进式加载（平时只显示一行说明，执行时才加载正文）也是同样的原理。
摘要（compaction）会压缩累积的历史记录。把几十次工具调用记录折叠成一段话，例如“已修改这些文件，测试已通过”。
这就是编程智能体在对话变长时自动执行的压缩。
请记住，摘要会带来信息损失。细节可能在折叠过程中消失，因此重要决策最好在摘要前写入文件。
策略 3、4：隔离与外部化
隔离（isolation）是将会扰乱上下文的工作拆分到单独会话中。如果让子智能体执行大规模探索，文件转储会消耗子智能体的上下文，主会话只会收到几行结论。
这是保护主会话预算最可靠的方法。
外部化（memory）使用上下文之外的存储。会话结束后，上下文会消失，但写入文件的内容会保留下来。
一种典型模式是用 Markdown 记录工作状态，让下一次会话接着处理。将项目知识积累到 CLAUDE.md 和记忆文件中，也属于这种模式。
| 策略 | 一句话总结 | 代表案例 |
|---|---|---|
| 选择性加载 | 只在需要时获取 | 部分读取、Skill 渐进式加载 |
| 摘要 | 折叠历史记录 | 自动压缩 |
| 隔离 | 交给另一个会话 | 子智能体 |
| 外部化 | 写入文件 | 记忆文件、状态文档 |
始终加载文件的设计标准
CLAUDE.md 等文件是每次会话预算中预先扣除的固定成本。因此，标准必须明确。
应包含“始终正确且不可违反的事情”，例如编码规范、禁止事项和构建命令。
应移除“偶尔才需要的事情”。特定任务的详细流程交给 Skill，过去工作的记录则移到记忆文件中。
工具注册也遵循同样的逻辑。连接的 MCP（Model Context Protocol）服务器越多，工具定义就越会作为固定成本累积。
十个未使用的服务器本身就是导致性能下降的因素，值得定期清理。
总结
上下文工程归根结底是相关性管理。不要因为窗口变大就全部填满，而是在每个时刻只把与当前工作相关的内容放在模型的桌面上。
将 Harness Engineering 篇中介绍的执行循环与本文的预算管理结合起来，智能体设计的整体蓝图就完成了。下一篇将介绍一个将这些理念实际组装起来的流水线案例。