「上下文工程」在硅谷爆火，提示工程失宠

07-07 11:30

继提示工程之后，「上下文工程」走红，这一概念深受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长文点评中认为「上下文工程」是一种艺术。

人们常把提示词联想为发给LLM的简短任务描述。但在工业级的LLM应用中，上下文工程既是精深的科学，也是巧妙的艺术。

其核心是为下一步操作，用恰到好处的信息精准填充上下文窗口。

说它是科学，是因为要做好需综合运用一系列技术，如任务描述与解释、少样本学习示例、RAG（检索增强生成）、相关数据、工具、状态与历史记录、信息压缩等。信息太少或格式错误，LLM就没有足够的上下文来达到最佳性能；信息太多或关联性不强，又会导致LLM的成本上升、性能下降，做好这一点很复杂。

说它是艺术，是因为需要依赖开发者对大模型「脾性」的直觉把握和引导。除了上下文工程本身，一个LLM应用还必须做到：将问题恰到好处地拆解成控制流，精准地填充上下文窗口，将调用请求分派给类型和能力都合适的LLM，处理「生成 - 验证」的UIUX流程，以及更多操作，如安全护栏、系统安全、效果评估、并行处理、数据预取等。因此，「上下文工程」只是正在兴起的、厚重且复杂的软件层中的一小部分，这个软件层负责整合协调单个的LLM调用及其他操作，构建完整的LLM应用。

Karpathy表示，把这类应用轻率地称为「ChatGPT的套壳」，这种说法既老套又错误。有网友调侃上下文工程是全新的「氛围编程」，Karpathy回应称，「我不是想自创新词，只是大家一提到「提示词」，就容易把一个复杂的组件想简单了」。你会用一个提示词问LLM「天空为什么是蓝色的」，但应用程序需要为大模型构建上下文，才能解决量身定制的任务。

智能体成败，全靠它了

打造高效AI智能体的关键，不在于代码复杂程度，而在于提供的上下文质量。一个效果粗糙的演示产品和一个表现惊艳的智能体，根本区别就在于上下文质量。

比如，一个AI助理要根据一封简单邮件安排会议：嘿，想问下你明天有空简单碰个头吗？「粗糙的演示」智能体获得的上下文贫乏，只能看到用户请求，代码可能功能齐全，但输出结果毫无帮助且机械化：感谢您的消息。我明天可以。请问您想约在什么时间？

而由丰富上下文加持的惊艳智能体，代码主要工作是收集LLM完成目标所需的信息。在调用LLM之前，会扩展上下文，包括：日历信息显示你全天排满；与此人的过去邮件，用来判断应该使用何种非正式语气；联系人列表，用来识别出对方是一位重要合作伙伴；用于send_invite或send_email的工具。然后可以生成这样的回复：嘿，Jim！我明天日程完全排满了，会议一个接一个。周四上午我有空，你看方便吗？邀请已经发给你了，看这个时间行不行哈。

这种惊艳效果的奥秘不在于模型更智能或算法更高明，而在于为正确的任务提供了正确的上下文。这就是「上下文工程」变得至关重要的原因。所以，智能体的失败，不只是模型的失败，更是上下文的失败。

构建强大可靠的AI智能体，我们正逐渐摆脱寻找「万能提示词」或依赖模型更新的路径。这一点得到网友认同。