上下文工程硅谷爆火 Karpathy亲自站台 提示工程瞬间失宠

提示工程的风头还没过去，「上下文工程」已经悄然掀起波澜。在硅谷大佬圈里，这事儿最近被反复提及，连Andrej Karpathy都公开站台，足见其热度。

Shopify的CEO Tobias Lütke也来“补了一刀”，说他更喜欢「上下文工程」这个说法，因为它精准概括了一个核心技能——如何通过提供完整的背景信息，让大模型真正理解问题并合理解决。说白了，这不就是门艺术吗？

一夜之间，这个概念就红了。凭什么？

上下文工程，一夜爆红

背后的推手，是AI智能体的全面崛起。OpenAI的总裁Greg Brockman不止一次高喊，“2025年，是AI智能体的元年”。

而智能体能不能成，关键就看上下文的质量。那些加载到“有限工作记忆”里的信息，变得越来越重要。绝大多数智能体翻车的案例，仔细复盘下来，原因往往不是模型本身不行，而是给的信息不对、不全。换句话说，是上下文的失败。

那么，这里的“上下文”到底指什么？

要搞懂这个问题，得先拓展一下它的定义。它绝不仅仅是你发给LLM的那一段文字提示。不妨这样理解：上下文是模型在生成回答之前，看到的“一切”。它包括但不限于：

• 指令/系统提示：那些定义模型行为的基础规则、示例和边界。
• 用户提示：你提出的即时任务或问题。
• 状态/历史（短期记忆）：当前这次对话全过程的来龙去脉。
• 长期记忆：跨越多轮对话后积累下来的持久性信息，像是用户的偏好、项目的摘要。
• 检索信息（RAG）：从外部知识库、数据库或API里掏出来的实时、相关信息。
• 可用工具：模型能够调用的各种功能，比如查库存、发邮件。
• 结构化输出：要求模型以特定格式（比如JSON）返回数据的定义。

看到了吧？和传统那种死磕一个完美提示词的“提示词工程”不同，“上下文工程”的范畴要宽泛得多，也更接近实战。

用大白话总结一下：上下文工程就是一门设计和构建动态系统的学问。这个系统要能在对的时间，以对的格式，提供对的信息和工具，让模型手上不缺“弹药”，能安心完成任务。它有这么几个显著特点：

• 它是一个系统，不是一个字符串。上下文不是死的模板，而是系统在主任务执行前，动态计算出来的结果。
• 它是动态的。上下文是“即用即生成”，完全为当前任务定制。比如一个请求可能需要查日历，另一个则要去搜邮件或网页。
• 强调适时提供信息与工具。核心是确保模型不遗漏关键细节，坚决贯彻“垃圾进，垃圾出”的铁律。只在必要且有价值的时候，才给模型投喂知识和工具。
• 注重格式。信息怎么呈现，至关重要。一份精炼的摘要，远胜于一堆原始数据的生硬堆砌；一个清晰的工具接口说明，也比一句模糊的指令管用。

是一门科学，也是一门艺术

Karpathy在长文里也强调，这玩意儿就是门艺术。很多人一想到提示词（prompt），脑子里蹦出的就是日常使用的简短任务描述。

但真正放到工业级的LLM应用里，上下文工程既是精深科学，也是巧妙艺术。它的核心就一件事：用恰到好处的信息，精准填满上下文窗口。

说它是科学，是因为要做好这件事，需要综合运用任务描述、少样本学习、RAG、多模态数据处理、工具调用、历史记录管理、信息压缩等一系列技术。信息给少了，模型理解不到位；信息给多了，成本上去了，性能反倒下降。拿捏这个度，非常复杂。

说它是艺术，是因为这中间充满了开发者对模型“脾性”的直觉把握和引导。要知道，一个完整的LLM应用，远不止上下文工程本身。它还要处理：

• 如何将复杂问题拆解成合理的控制流程？
• 如何精准填充上下文窗口？
• 如何将不同的请求派发给类型和能力合适的LLM？
• 如何处理“生成-验证”的用户界面流程？
• 还有安全护栏、效果评估、并行处理、数据预取等等…

所以，“上下文工程”只是这个正在兴起的、厚重且复杂的软件层中的一小部分。这个软件层负责把单个LLM调用，以及其他所有相关操作都整合协调起来。Karpathy说得直接，把这类应用轻率地称为“ChatGPT的套壳”，这说法不仅过时，而且大错特错。

有网友戏称这是“氛围编程”，Karpathy回应道，倒不是非要去发明新词，只是觉得大家一提“提示词”，就容易把一个相当复杂的组件给想简单了。平时用个提示词问“天空为什么是蓝色的”，跟搭建一个为特定任务构建上下文的应用程序，完全不是一回事。

智能体成败，全靠它了

说到底，打造高效AI智能体的秘诀，不在于代码写得多精妙，而在于你提供的上下文质量有多高。一个粗糙的演示产品和让人惊艳的智能体，根本区别就在这里。

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

如果给它的上下文很贫乏，它只能看到用户的请求。即便代码功能齐全，输出的结果也会很机械：“感谢您的消息。我明天可以。请问您想约在什么时间？”

但有了丰富的上下文加持，情况就完全不同。代码的主要任务不再是思考怎么回复，而是去收集LLM达成目标所需的信息。在调用模型前，系统已经自动扩展了上下文，包含了：

• 日历信息：显示你这天已经排满了。
• 与此人过往的邮件：判断出应该用哪种语气。
• 联系人列表：识别出对方是重要合作伙伴。
• 可用于发送邀请或邮件的工具。

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

这种体验背后的奥秘，不在于模型更聪明或算法更高明，而在于“在正确的任务，提供了正确的上下文”。这，就是上下文工程如此重要的原因。

所以再强调一遍：智能体的失败，不只是模型的失败，更是上下文的失败。要构建可靠的AI智能体，我们正逐渐摆脱对“万能提示词”的迷恋，也不纯粹依赖模型更新。其核心在于对上下文的工程化构建——在恰当的时机、以恰当的格式，提供恰当的信息和工具。这是一项跨职能的挑战，它要求我们深入理解业务、明确输出目标，并精心组织所有信息，才能让LLM真正“把活儿干了”。

借用网友的一句话做个收尾吧：“记忆”才是AGI拼图的最后一块。