一句话定义
上下文工程（Context Engineering）是指系统地设计模型在生成这一刻能看到的全部信息：系统提示、任务说明、检索到的资料、历史对话、工具返回结果，以及它们的组织顺序与压缩方式。
Prompting 关心「怎么说」，Context Engineering 关心「给它看什么」。后者决定了效果的上限。
为什么重要
模型没有记忆，也没有主动获取信息的能力。它每一刻的表现，完全由当前上下文决定。
于是出现一个反直觉的结论：在多数生产系统里，改进上下文的收益大于更换模型。 换模型可能提升 5%，把错误的资料从上下文里剔除可能提升 50%。
Anthropic 在 2024 年把这个词正式提出，本质上是承认：模型已经足够强，瓶颈转移到了「信息供给」这一侧。
上下文的几个组成部分
| 组成 | 作用 | 常见问题 |
|---|---|---|
| 系统提示 | 定义角色与规则 | 过于冗长，规则互相冲突 |
| 任务指令 | 当前要做什么 | 与系统提示重复 |
| 检索资料 | 提供事实依据 | 塞入无关内容，稀释注意力 |
| 对话历史 | 保持连续性 | 无限增长，成本失控 |
| 工具返回 | 外部世界的观测 | 返回原始数据，未做裁剪 |
| 示例 | 对齐格式 | 示例之间风格不一致 |
四个核心动作
- 选择：只放与当前任务真正相关的信息。无关内容不是中性的，它会主动降低准确率。
- 压缩：把长文档摘要成要点，把历史对话折叠成结论。保留决策，丢弃过程。
- 排序：重要信息放在开头或结尾。中间位置最容易被忽略。
- 隔离：把不可信内容（网页、用户上传文件）明确标注为「数据」而非「指令」，这是防提示注入的第一道防线。
与记忆的区别
上下文是工作记忆：一次性、易失、有硬上限。 记忆是长期存储：跨会话、需要主动写入和检索。
把该持久化的东西留在上下文里，会导致成本失控；把该放进上下文的东西指望模型自己记住，会导致表现不稳定。
常见误解
- 「上下文窗口变大了就不用管了」：更大的窗口往往意味着更多干扰，以及更高的成本。
- 「把所有资料都给它，让模型自己判断」：模型不擅长忽略无关信息，它会认真地为噪声找解释。
- 「上下文工程就是写更好的提示词」：写提示词只是其中一部分，其余是数据管道与信息架构问题。
延伸阅读
- RAG：为上下文提供事实来源
- Agent Harness：运行时如何管理上下文生命周期