最近硅谷刮起一阵新风，主角儿不再是提示词工程，而是“上下文工程”（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的长文点评里，他同样将上下文工程视为一种艺术。他指出，大众通常把“提示词”理解为日常使用中发给LLM的简短任务描述。但在任何一个工业级的LLM应用中，上下文工程都是一门精深的科学，也是一门巧妙的艺术。其核心，就是用恰到好处的信息，精准填充上下文窗口。

说它是科学，是因为要做好这一点，需要综合运用一系列技术：任务描述与解释、少样本学习示例、RAG、相关的（可能还是多模态的）数据、工具、状态与历史记录、信息压缩等等。信息太少或格式不对，LLM缺乏上下文；信息太多或关联性不强，又会导致成本飙升、性能下降。这个平衡点，确实很复杂。

说它是艺术，则是因为这其中需要开发者对大模型的“脾性”有直觉般的把握和引导。

除了上下文本身，一个完整的LLM应用还必须做到：将问题恰到好处地拆解成控制流、精准地填充上下文窗口、将调用请求分派给类型和能力都合适的LLM、处理“生成-验证”的UIUX流程，以及更多，比如安全护栏、系统安全、效果评估、并行处理、数据预取等等。

因此，“上下文工程”只是一个正在兴起的、厚重且复杂的软件层中的一小部分。这个软件层负责将单个的LLM调用以及更多操作整合协调，从而构建出完整的应用。Karpathy特别强调，把这类应用轻率地称为“ChatGPT的套壳”，这种说法不仅老掉牙了，而且大错特错。

有网友调侃说，上下文工程是全新的“氛围编程”。Karpathy则回应道：“我倒不是想自创个新词。我只是觉得，大家一提到‘提示词’，就容易把一个其实相当复杂的组件给想简单了。” 你会用一个提示词去问LLM“天空为什么是蓝色的”，但应用程序需要的，是为大模型构建上下文，才能解决那些针对它量身定制的任务。

智能体成败，全靠它了

打造真正高效的AI智能体，秘诀不在于你编写的代码有多复杂，而在于你提供的上下文有多优质。一个粗糙的演示和一个惊艳的智能体，其根本区别就在于上下文质量。

想象一个AI助理，需要根据一封简单的邮件“嘿，想问下你明天有空简单碰个头吗？”来安排会议。

粗糙的演示：智能体获得的上下文很贫乏，它只能看到用户的请求，别的什么都不知道。代码可能功能齐全，但输出的结果却是：“感谢您的消息。我明天可以。请问您想约在什么时间？”——机械化，毫无帮助。

惊艳的智能体：由丰富的上下文加持。代码的主要工作不是思考如何回复，而是收集LLM达成目标所需的信息。在调用LLM之前，你会将上下文扩展为：日历信息（显示你全天都排满了）、与此人的过去邮件（判断非正式语气）、联系人列表（识别出这是一位重要合作伙伴）、以及用于send_invite或send_email的工具。

然后，生成的回复是：“嘿，Jim！我明天日程完全排满了，会议一个接一个。周四上午我有空，你看方便吗？邀请已经发给你了，看这个时间行不行哈。”

这种惊艳的效果，奥秘不在于模型更智能，或算法更高明，而在于为正确的任务提供了正确的上下文。这正是“上下文工程”将变得至关重要的原因。

所以，智能体的失败，不只是模型的失败，更是上下文的失败。要构建强大而可靠的AI智能体，我们正逐渐摆脱对寻找“万能提示词”或依赖模型更新的路径。其核心在于对上下文的工程化构建：在恰当的时机、以恰当的格式，提供恰当的信息和工具。这是一项跨职能的挑战，它要求我们深入理解业务用例、明确定义输出，并精心组织所有必要信息。

最后，借用网友一句话：“记忆”才是AGI拼图的最后一块。