上下文工程：比提示工程更重要的新战场

模型能力越来越强，提示词写得漂亮已经不再是护城河。真正拉开差距的，是你往上下文窗口里放了什么、放多少、以什么顺序放——这就是”上下文工程”（Context Engineering）。

一、上下文由四部分组成

1. 系统指令：角色、边界、输出规范。
2. 工具与知识：可调用的工具定义、检索到的文档片段。
3. 历史与记忆：对话历史、长期记忆、用户画像。
4. 当前任务：本条请求与即时输入。

窗口有限，四者互相挤压。上下文工程的核心命题就是：在有限预算下，让最关键的信息占据最好的位置。

二、预算分配：别让历史吃掉一切

一个常见崩法：对话越聊越长，历史把窗口占满，关键文档被挤出去。做法：

• 给每部分设token 上限，历史超过阈值就摘要压缩。
• 近期对话保留原文，久远对话压成摘要。
• 知识片段按相关度取 Top-N，而不是全塞。

三、压缩与检索的分工

• 压缩：把旧历史、长文档压成要点，牺牲细节换空间。
• 检索：任务需要什么就临时取什么（RAG / 记忆检索），按需加载。

两者配合：常驻用压缩版，命中才拉原文，这就是当下主流 Agent 的做法。

四、顺序也有讲究

模型对上下文的不同位置敏感度不同：

1. 最前面：系统指令，务必稳定一致（顺带吃满提示缓存）。
2. 中段：大的参考资料，可承受一定”迷失中间”。
3. 最后面：当前任务与关键约束，放在离生成最近处，注意力最强。

五、一个可复用的组装流程

1. 定死系统指令（版本化管理）。
2. 注入工具定义（只给当前任务需要的）。
3. 检索并压缩历史与知识。
4. 置入当前问题与约束。
5. 校验总长度不超模型窗口，留出输出余量。

六、常见反模式

• 塞满再说：以为信息越多越好，结果噪声淹没信号。
• 上下文漂移：长会话中目标被稀释，Agent 逐渐跑偏。
• 重复冗余：同一信息在系统、历史、文档里出现三遍，浪费预算。
• 忽视缓存：前缀频繁变化，成本高且不稳定。

提示工程是”怎么说”，上下文工程是”给它什么、给多少”。当模型足够强，后者才是决定成败的那一环。