Context Engineering
为什么重要
深度解析
上下文工程把上下文窗口视为受管理的资源，它有预算、有生命周期，也有已知失败模式。一次典型 LLM 调用会从许多来源组装上下文：定义行为的系统提示词、少样本示例、通过检索拉取的文档、工具定义及结果、长期记忆，以及持续累积的对话历史。这门学科要决定什么有资格进入窗口，以何种格式、按什么顺序进入，何时刷新或压缩，以及如何挡住无关或错误信息。提示词工程问的是指令该怎么措辞，上下文工程问的是指令抵达时，模型应该已经知道什么。
上下文预算
上下文窗口已经从几千 token 增长到几十万甚至更多，但空间从来都不免费。每多一个 token，每次调用的延迟与成本都会增加，注意力也无法优雅扩展：长上下文模型研究表明，埋在长提示词中部的信息，比靠近开头或结尾的内容更难被可靠使用，这种模式被称为“迷失在中间”。因此，实用的上下文工程就是做预算。团队会把早期对话压缩成滚动摘要，只保留冗长工具输出中的关键字段，去除重复样板，并把参考材料从提示词移进检索，只有相关时才拉取。目标是找到最小的上下文，又能装下模型完成当前步骤所需的一切。
运行时组装上下文
现代应用会动态构建上下文，不再手写。RAG 流水线检索与用户问题相关的文档，并在调用时注入；记忆系统跨会话保存关于用户的持久事实；工具使用和 MCP 等协议则让模型在对话途中拉取实时数据，每项结果都会追加到下一步的上下文。智能体循环把这件事推得最远：每次观察、动作和中间结果都落进上下文，因此上下文实际上变成了智能体的工作状态，把短期记忆与计划揉在一起。这正是上下文工程在智能体设计中如此显眼的原因——一次 50 步运行中，决定保留什么、概括什么、丢弃什么，往往就是智能体保持任务方向与逐渐漂移之间的分界线。
更大的窗口不是解药
一个常见误解是，百万 token 上下文窗口会让上下文工程失去必要——把一切倒进去，让模型自己理清即可。实践中，长上下文会带来自己的失败模式。上下文腐烂指窗口逐渐填满时，性能慢慢退化：即使模型宣称支持极长上下文，随着输入增长，检索式问题的准确率仍会下降。上下文中毒更糟：一旦产生幻觉的主张、过时事实或被注入的指令进入上下文，模型就容易把它当成真相继续往上建；把自己输出写回上下文的智能体，还可能让一次早期失误在所有后续步骤中不断放大。相关失败模式还有上下文干扰，无关材料会把模型拉离任务；以及上下文冲突，窗口中的矛盾信息会逼出含糊回答或随意选择。筛选输入、验证写回内容、防御提示注入，并定期重置上下文，是标准对策。
从提示词工程到上下文工程
更早的提示词工程关注措辞：指令怎么写、少样本示例怎么选、角色提示词怎么设。它假设由人类对着几乎空白的窗口写一条提示词。应用成长为流水线和智能体后，瓶颈便转移了——困难之处变成管理信息如何流进一个由指令、数据、工具和历史共同占用的窗口，而且大部分内容由软件组装，不由用户键入。上下文工程这个词于 2025 年在实践者中流行起来，准确命名了这次转变，也因为描述的是团队已经在做的事而留了下来。提示词技巧依然重要，上下文学习也仍是托住一切的机制；只是措辞如今成了更大工程表面中的一个部件，旁边还有检索质量、记忆设计、工具输出格式和上下文生命周期管理。