上下文工程：把对的信息放进有限的窗口

「上下文窗口都几十万 token 了，还需要精打细算吗？」需要，而且越来越重要。窗口变大不等于你该把所有东西都塞进去——塞得越满，模型越容易迷失，成本越高，关键信息越容易被淹没。

上下文工程（Context Engineering），就是在有限的窗口里，为模型组织出「刚好够用」的信息。它正在取代零散的「提示词技巧」，成为 AI 应用的核心工程能力。

窗口是预算，不是仓库

把上下文窗口当成一份预算来管理：每放进一段内容，都要问它「值不值这些 token」。无关的历史、重复的说明、整篇贴进来的文档，都是在挤占真正重要信息的位置。

模型的注意力是稀缺资源。你给的噪声越多，它分给关键信息的注意力就越少。

「中间遗忘」是真实存在的

大量实验观察到一个现象：当关键信息位于长上下文的中间位置时，模型最容易忽略它；放在开头或结尾则命中率明显更高。这意味着「放什么」之外，「放在哪个位置」同样影响结果。把最重要的指令和材料放在头尾，是一个简单但有效的习惯。

四个动作：筛、压、排、隔

1. 筛选（Select）

不是有什么就放什么。根据当前问题，只取真正相关的部分。RAG 的检索、对工具结果的裁剪、对历史对话的相关性过滤，本质都是在做筛选。多数上下文问题，根源是「放太多」而不是「放太少」。

2. 压缩（Compress）

长对话和长文档可以先做摘要再进上下文。比如多轮会话累积到一定长度，就把早期内容压成一段「对话摘要」，保留结论、丢弃过程。既省 token，又让模型抓住重点。

3. 排序（Order）

结合「中间遗忘」效应，把最关键的内容放在开头或结尾。系统指令通常置顶，当前问题与最相关材料置底（靠近模型要生成的位置），让它们「离决策最近」。

4. 隔离（Isolate）

用清晰的结构把不同性质的信息分开：系统指令、检索资料、对话历史、当前问题各归各位，用标题或分隔标记隔开。结构化的上下文比一锅粥式的拼接，模型理解得更准。

【角色与规则】 ...系统指令...
【参考资料】   [1] ...  [2] ...
【对话摘要】   用户此前确认了 A、否定了 B
【当前问题】   ...

多轮场景：管理「会话状态」

在多轮对话或 Agent 里，上下文是会不断累积的。与其每轮把全部历史原样带上，不如维护一份结构化的会话状态：已确认的事实、待办、关键约束。每轮只把这份精炼状态 + 最近几轮原文带进去。这样上下文不会随轮次线性膨胀，质量也更稳定。

小结

上下文工程的核心心法只有一句：给模型「刚好够用」的信息，放在「它最容易看见」的位置。具体落到四个动作——筛选、压缩、排序、隔离。窗口越大，懂得克制反而越值钱。决定 AI 应用质量上限的，往往不是模型，而是你喂给它的上下文。