上​下文​工程：​给​模型​的​记忆​做​减法

过去一年里，上下文窗口从 128K 卷到了百万级。一个自然的推论是：上下文工程会变得不重要——反正都塞得下。我认为这个推论是错的，而且方向完全相反。

长上下文的隐性成本

「塞得下」不等于「用得好」。在实际的 agent 系统里，超长上下文至少有三个隐性成本：

1. 注意力稀释。关键指令淹没在几万 token 的工具输出里，模型对它的遵循率会显著下降。这不是玄学，是可以在评测里复现的行为衰减
2. 错误锚定。上下文里一旦出现过错误的中间结论，后续推理会反复引用它。上下文不是白板，是有惯性的
3. 成本与延迟。每个 token 都要花钱、花时间。当一个 agent 循环运行几十轮，无节制的上下文积累是指数级的浪费

减法的三种形态

有效的上下文管理，核心操作是三种「删除」：

压缩历史

把已完成阶段的完整过程压缩成结论。一次成功的调试过程可能产生 5 万 token 的工具输出，但下一阶段真正需要的只是一句话：

已定位：竞态条件出现在 cache.invalidate() 与
write-back 之间，修复方案是引入版本号检查（已验证）。

隔离执行

体力活派给子 agent，主上下文只接收产出。子 agent 的几万行日志在它自己的上下文里消化，返回的是一段结构化摘要。这是「指挥官保护全局视野」在工程上的直接对应。

主动遗忘

不是所有信息都值得留在工作记忆里。文件的完整内容读过之后，留下路径和关键行号就够了——需要时可以重新读取。可恢复的信息不占上下文，这是减法的安全边界。

---

一个可检验的判断

把上面的原则压缩成一句话：

上下文的价值密度,随长度单调递减；工程的目标是维持密度，而不是扩大容量。

这个判断是可检验的：固定任务集，对比「全量上下文」与「压缩上下文」两组 agent 的完成率与成本。我的初步实验里，压缩组在成本降低约 60% 的同时，完成率反而更高——因为注意力稀释的损失超过了信息丢失的损失。

数字本身不重要（不同任务集会有很大差异），重要的是这个方向：**当模型能力继续提升，瓶颈会越来越清晰地落在「喂给它什么」上。**上下文工程不会消失，它会成为 AI 工程的核心学科。