新智元报道
编辑：桃子
继提示工程之后，「上下文工程」又红了！这一概念深得 Karpathy 等硅谷大佬的喜欢，堪称「全新的氛围编程」。而智能体成败的关键，不在于精湛的代码，而是上下文工程。
硅谷如今炙手可热的，不再是提示词工程，而是上下文工程（Context Engineering）！
就连 AI 大神 Karpathy，都为「上下文工程」投下了一票。
还有 Shopify CEO Tobias Lütke 称，自己更喜欢「上下文工程」，因其准确描述了一个核心技能——
通过为任务提供完整的背景信息，让大模型能够合理解决问题的艺术。
一夜之间，「上下文工程」红遍全网，究竟是为什么？
上下文工程，一夜爆红
这背后原因，离不开 AI 智能体的兴起。
OpenAI 总裁 Greg Brockman 多次公开表示，「2025 年，是 AI 智能体的元年」。
决定智能体成功或失败最关键的因素，是提供的「上下文质量」。也就是说，加载到「有限工作记忆」中的信息愈加重要。
大多数 AI 智能体失败的案例，不是模型的失败，而是上下文的失败！
那么，什么是上下文？
要理解「上下文工程」，首先需要扩展「上下文」的定义。
它不仅仅是你发送给 LLM 的单一提示，可以将其视为「模型再生成响应之前，看到的所有内容」，如下：
-
指令/系统提示：定义模型在对话中行为的初始指令集，可以/应该包括示例、规则等。
-
用户提示：用户的即时任务或问题。
-
状态/历史（短期记忆）：当前对话，包括用户和模型的响应，截至此刻。
-
长期记忆：跨多次之前对话收集的持久知识库，包含学习到的用户偏好、过去项目的摘要或要求记住以备将来使用的事实。
-
检索信息（RAG）：外部、实时的知识，来自文档、数据库或 API 的相关信息，用于回答特定问题。
-
可用工具：模型可以调用的所有功能或内置工具的定义，比如 check_inventory、send_email。
-
结构化输出：模型响应格式的定义，例如 JSON 对象。
可以看出，与专注于在单一本文字符串中，精心构建完美指令的「提示词工程」不同，「上下文工程」的范畴要广泛得多。
简单来说：
「上下文工程」是一门学科，它致力于设计和构建动态系统。
这些系统能够在恰当的时机、以恰当的格式，提供恰当的信息和工具，从而让 LLM 拥有完成任务所需的一切。
以下是「上下文工程」的所有特点
· 它是一个系统，而非一个字符串：上下文并非一个静态的提示词模板，而是一个系统的输出，这个系统在对 LLM 进行主调用之前就已经运行。
· 它是动态的：上下文是即时生成的，为当前任务量身定制。比如，某个请求可能需要的是日历数据，而另一个请求则可能需要电子邮件内容或网络搜索结果。
· 它强调在恰当时机提供恰当信息与工具：其核心任务是确保模型不会遗漏关键细节（谨记「垃圾进，垃圾出」原则）。这意味着只在必要且有益的情况下，才向模型提供知识（信息）和能力（工具）。
· 它注重格式：信息的呈现方式至关重要。一份简洁的摘要远胜于原始数据的罗列；一个清晰的工具接口定义也远比一条模糊的指令有效。
是一门科学，也是一门艺术
Karpathy 长文点评中，同样认为「上下文工程」是艺术的一种。
人们往往将提示词（prompt），联想为日常使用中——发给 LLM 的简短任务描述。
然而，在任何一个工业级的 LLM 应用中，上下文工程都是一门精深的科学，也是一门巧妙的艺术。
其核心在于，为下一步操作，用恰到好处的信息精准填充上下文窗口。
说它是科学，是因为要做好这一点，需要综合运用一系列技术，其中包括：
任务描述与解释、少样本学习示例、RAG（检索增强生成）、相关的（可能是多模态的）数据、工具、状态与历史记录、信息压缩等等。
信息太少或格式错误，LLM 就没有足够的上下文来达到最佳性能；
信息太多或关联性不强，又会导致 LLM 的成本上升、性能下降。
要做好这一点是颇为复杂的。
说它是艺术，则是因为其中需要依赖开发者对大模型「脾性」的直觉把握和引导。
除了上下文工程本身，一个 LLM 应用还必须做到：
-
将问题恰到好处地拆解成控制流
-
精准地填充上下文窗口
-
将调用请求分派给类型和能力都合适的 LLM
-
处理「生成-验证」的 UIUX 流程
-
以及更多——例如安全护栏、系统安全、效果评估、并行处理、数据预取等等…
因此，「上下文工程」只是一个正在兴起的、厚重且复杂的软件层中的一小部分。
这个软件层负责将单个的 LLM 调用，以及更多其他操作整合协调，从而构建出完整的 LLM 应用。
Karpathy 表示，把这类应用轻率地称为「ChatGPT 的套壳」，这种说法不仅老掉牙了，而且大错特错。
有网友对此调侃道，上下文工程，是全新的「氛围编程」。
Karpathy 回应称，「我倒不是想自创个新词什么的。我只是觉得，大家一提到「提示词」，就容易把一个其实相当复杂的组件给想简单了」。
你会用一个提示词去问 LLM「天空为什么是蓝色的」。但应用程序呢，则是需要为大模型构建上下文，才能解决那些为它量身定制的任务。
智能体成败，全靠它了
其实，打造真正高效的 AI 智能体秘诀，关键不在于编写的代码有多复杂，而在于你所提供的上下文有多优质。
一个效果粗糙的演示产品，同一个表现惊艳的智能体，其根本区别就在于提供的上下文质量。
想象一下，一个 AI 助理需要根据一封简单的邮件来安排会议：
嘿，想问下你明天有空简单碰个头吗？
「粗糙的演示」智能体获得的上下文很贫乏。它只能看到用户的请求，别的什么都不知道。
它的代码可能功能齐全——调用一个 LLM 并获得响应，但输出的结果却毫无帮助，而且非常机械化：
感谢您的消息。我明天可以。请问您想约在什么时间？
接下来，再看看由丰富的上下文加持的惊艳智能体。
其代码的主要任务并非是思考如何回复，而是去收集 LLM 达成目标所需的信息。在调用 LLM 之前，你会将上下文扩展，使其包含：
代码的主要工作，不是决定如何响应，而是收集 LLM 完成目标所需的信息。
在调用 LLM 之前，你会扩展上下文，包括：
日历信息：显示你全天都排满了
与此人的过去邮件：用来判断应该使用何种非正式语气
联系人列表：用来识别出对方是一位重要合作伙伴
用于 send_invite 或 send_email 的工具
然后，你就可以生成这样的回复：
嘿，Jim！我明天日程完全排满了，会议一个接一个。周四上午我有空，你看方便吗？邀请已经发给你了，看这个时间行不行哈。
这种惊艳的效果，其奥秘不在于模型更智能，或算法更高明，而在于为正确的任务提供了正确的上下文。
这正是「上下文工程」将变得至关重要的原因。
所以说，智能体的失败，不只是模型的失败，更是上下文的失败。
要构建强大而可靠的 AI 智能体，我们正逐渐摆脱对寻找「万能提示词」，或依赖模型更新的路径。
这一点，深得网友的认同。
其核心在于对上下文的工程化构建：即在恰当的时机、以恰当的格式，提供恰当的信息和工具。
这是一项跨职能的挑战，它要求我们深入理解业务用例、明确定义输出，并精心组织所有必要信息，从而使 LLM 能够真正「完成任务」。
最后，借用网友一句话，「记忆」才是 AGI 拼图的最后一块。
参考资料：
