Prompt格局小了，上下文工程称王！Shopify CEO提上下文工程，大神Karpathy一众创业者狂喊+1,网友：都是巫术 原创

编辑 | 云昭

Prompt工程又“失效”了？！

之前是各种白领对它“喊打喊杀”，担心它取代自己的工作，后来的口风就变成了“大模型强大到不再需要Prompt工程了”，现在圈里又有谷歌的大佬抛出了神断言，让评论区炸锅的那种。

今天一早，小编刷到一篇洗脑神文，差点以为这是新一轮的AI黑话洗脑包上线了。文章直呼：

“Prompt工程”格局小了，更大格局的“Context工程”才是大模型的王道。

不过细读下来，小编并没有作者其实是醉翁之意不在酒，更多还是再说构建智能体时，上下文工程的重要性——

我们发现，决定智能体成败的关键在于你赋予它的上下文的质量。大多数智能体失败不再是模型失败，而是上下文失败。

所谓“上下文工程”，它不是一句提示词，它是一个系统工程。

一次廉价演示和一次神奇 AI 体验之间的差距，全在于——上下文的质量。

Prompt不香了？Context Engineering又是哪个工程师发明的新名词？

评论区一众大厂和创业者都在喊“+1”。（后来小编搜了一下：新名词的是Shopify CEO Tobi Lutke提出的，前OpenAI大神Karpathy也X转帖了。）

这篇文章的作者也大有来头，Google DeepMind的高级AI关系工程师Philipp Schmid。据悉，Schmid正在组建DeepMind的首个AI开发者关系团队，这个团队主要KPI就是输出！而且输出的是DeepMind的前沿AI研究成果！小编果断关注了一波。

话不多说，直接上干货。

1.大模型的新技能不是Prompt

原文标题为《The New Skill in AI is Not Prompting, It's Context Engineering》，大体主张是：

与其再去研究“怎么写提示词（prompt）”，真正应该关注的，是如何为 AI 组织一个完整、合适、动态的上下文（context），这才是 Agent 成败的关键。

可以说再一次把“Prompt”与“Contex”的引战放到了明面上。当然从评论区的效果上看，事实也的确如此。

相信大家都有这样的“皱眉头”经历：

费劲写了一段“完美Prompt”，希望AI给出精准回答。（ps：想一想，你有没有写过这样一个提示“做好这件事，奖励你1万块！”）但结果，AI模型却就总是给出一个非常机械的、“缺少灵魂”的输出。

对此，作者指出：为什么上下文比提示词更重要了？

随着 AI Agent（智能体）的崛起，我们输入模型的“有限工作记忆”里到底装了什么，变得比以往任何时候都更关键。（即：大模型就像一台超强的语言引擎，但它的“记忆”有限，单靠一段话很难覆盖复杂的业务需求和多维信息。结果就是，AI“答非所问”，或者机械死板，差强人意。）

现在，决定一个 Agent 成败的核心因素，不再是调用哪个大模型、写了多花哨的提示词，而是——你给它的上下文质量够不够好。

2.Karpathy等许多大佬也认同“上下文工程”

其实很多圈内大神都赞同“上下文工程”而非“提示工程”。

前OpenAI、特斯拉的大神上个月就公开表示+1支持。

@karpathy

+1 支持“上下文工程（Context Engineering）”而非“提示工程（Prompt Engineering）”。

Karpathy 认为，人们通常把“prompt”理解为日常使用LLM时输入的一小段任务描述。而不同的是，在真正面向工业级应用的 LLM 系统中，上下文工程是一门微妙而复杂的“填充上下文窗口”的艺术与科学。

图片

大神还进一步解释了为什么既是科学又是艺术？

为什么说是科学？因为做好这件事涉及：任务说明与解释、Few-shot 示例、RAG 检索、相关数据（可能是多模态的）、工具、状态、历史记录、信息压缩等。信息太少或格式不对，LLM 就拿不到做出好回应的材料；信息太多或不相关，则会推高成本，反而拉低性能。

为什么说是艺术？因为你需要依靠对“模型心理”的直觉来构建合理的输入。

除了上下文工程之外，Karpathy认为大模型还有很多问题需要解决，比如：

• 正确地拆解问题形成控制流程
• 恰当地打包上下文窗口
• 调度不同类型和能力的模型
• 搭建生成与验证的 UI/UX 流程
• 还有更多：安全机制、性能评估、并行处理、预取缓存……

所以，Context Engineering 只是构建一个完整 LLM 应用所需的厚重软件层中的一小部分而已。

Karpathy指出，“ChatGPT 套壳器”这个说法已经过时，甚至是完全错误的。

而Karpathy点赞的这则帖子正是另一位大佬——

白天当CEO、夜间当黑客的“通才”，Shopify 的掌门人Tobi，在X上，他发表了自己的看法：

我真的很喜欢“上下文工程”这个术语，而并非“提示工程”。

原因是，它更好地描述了核心技能：为大模型提供充分的上下文背景，使得 LLM 有可能合理地解决任务，这是一门艺术。

图片

此外，许多评论者也分享了自己在实际应用中的见解：

完全同意。现在你几乎很难再靠那种“如果你答对我就给你 100 美元”之类的小聪明来提升模型性能了——本来就应该如此。

真正的优势在于：你是否能精心构建上下文，帮模型最大程度减少“战争迷雾”。它正在趋近于人类式的信息需求。

图片

3.上下文没那么简单，包含7部分

要理解“上下文工程”，我们得先重新定义“上下文”这个词。

它不是你发给 LLM 的一句话。作者指出：

你可以把它想象成模型在生成回答之前，所能看到的一切信息：

作者将上下文的构成分成了 7 部分：

• 系统指令 / 初始提示（System Prompt）：在对话开始时，预先定义模型行为的一组说明，可包含示例、规则等。
• 用户提示（User Prompt）：用户当下发出的任务或问题。
• 短期记忆 / 对话历史（State / History）：当前对话中的来龙去脉，包括之前的提问与回应。
• 长期记忆（Long-Term Memory）：模型跨会话记住的持久信息，例如用户偏好、项目摘要、背景知识等。
• 检索信息（RAG）：来自外部文档、数据库或 API 的实时信息，用于增强模型回答。
• 可用工具（Available Tools）：模型可调用的函数或工具列表，如 ​​check_inventory​​​、​​send_email​​。
• 结构化输出格式（Structured Output）：定义模型回答的格式，比如 JSON 模板或结构体。

图片

好的上下文 ≠ 靠 LLM 猜，而是靠系统主动“喂”进去该知道的一切。 

4.从“廉价Demo”到“神奇AI”的关键

真正打造出一个可靠、有用的 AI Agent，核心不在于代码多复杂，也不在于使用了什么花哨的框架，而在于你给它什么上下文。

想象这个简单例子：

有人发来一封邮件：Hey, just checking if you’re around for a quick sync tomorrow.（嘿，想问问你明天能不能快速聊一下。）

对于一个 Agent 而言，它能看到的上下文只有用户刚发来的这句话，于是它冷冰冰地回应：

Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?（谢谢你的信息，明天对我来说可以。你想定几点呢？）

逻辑没错，但像极了“机器人在敷衍人类”，没错这水平也就是个廉价的Demo。

但，如果有了足够丰富的上下文，比如我们把日程表、对方的邮件来往记录、联系人信息、自动回复邮件等工具都喂给它——

我们就可以见证奇迹：神奇 AI（Magical Agent）诞生了！它的回应就像一个会来事儿的真人：

上下文包含：

• 你的日程表（显示你明天全天爆满）
• 你和对方以往的邮件记录（判断用语是否需要随意一些）
• 联系人信息（识别出对方是关键合作伙伴）
• 可用工具（比如发出邀请、自动回复邮件）

最终生成的回应是：

Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works.（嘿 Jim！我明天全天都排满了。周四上午有空，合适吗？我已经发了个邀请，看看是否合适。）

神奇不是因为用了更聪明的模型，而是因为上下文到位了。所以，Agent 的失败，更多是上下文失败，而不是模型失败。

5.从提示工程转向上下文工程，有何不同？

现在，我们可以回答两者到底有什么不同了。

如果说提示词工程是想写出“一句话打动模型”，那么上下文工程是一门系统工程学科。

首先，来看定义（更接地气地讲）：

上下文工程（Context Engineering）是设计和构建动态系统的一门学问，目标是在正确的时间、以正确的格式，向大模型提供完成任务所需的一切信息和工具。

它的核心特征有 4 个：

• 系统，而不是字符串：不是静态的模板，而是在调用 LLM 之前动态生成的结果。
• 动态、按需生成：对一个请求来说，也许上下文是日程表；另一个请求可能需要最近的网页搜索或邮件往来。
• 信息与工具，刚刚好地送达：避免垃圾进垃圾出（Garbage In, Garbage Out），只提供任务真正需要的信息与能力。
• 格式也很关键：与其丢一堆生肉数据，不如给出提炼后的摘要；工具调用格式清晰，胜过模糊提示。

即，作者提出，只有为 LLM 提供恰当且动态组合的信息、工具和指令，才能让 AI 真正理解并高效完成复杂任务。所以，要构建强大、稳定的 AI Agent，不再是靠“提示词魔法”或“换个大模型”，而是靠“上下文工程”：

在正确的时间，把正确的信息与工具，以正确的格式，放进模型的脑子里。

而这是一项跨学科挑战，既需要理解业务场景，也需要明确目标输出，更需要设计清晰的信息结构，让语言模型真正完成任务。

6.网友热议：造新词儿？

对于上下文工程，一位谷歌的同事（巧了，也叫菲利普，也是作者团队的人员，Google DeepMind AI 开发者关系负责人），开始在 Karpathy 的评论区下面调侃：上下文工程是新的“氛围编程”！

图片

Karpathy 回应：哈哈，我不是想造个新词什么的。

哈哈我不是在发明新词，只是觉得人们对“prompt”的理解太过简单化，低估了其复杂性。

“你提示 LLM 回答“天空为什么是蓝色”，那是 prompt。但真正的 AI 应用不是一句话提示，而是精心构建一整个上下文环境，让 LLM 去完成定制化任务。”

图片

此外，相关评论还探讨了“context rot”、动态信息检索、如何进行有效评估以及 AI 项目的落地技巧。 

图片

当然，更多在做Agent产品开发的人表示深度认可：上下文才是真正的杠杆！

@0xCapx（Agent 应用创业公司）

当 Agent 来运营一家企业时，上下文就不再是“锦上添花”，而是“系统架构”本身。

@The_Utility_Co（Web3自动化创业团队）

100% 认同。Prompt 只是“你好”，Context 是你的人生故事、Spotify 歌单、甚至银行账户信息。

当我们将 LLM 接入 Web3 自动化系统时，大部分工作其实都在策划好传感器数据、DAO 信号、链上信息的上下文输入，这样模型才能“真正做事”，而不是只会“聊天”。

真正的杠杆在于上下文工程。

7.老瓶装新酒？技术本质都是黑盒巫术

不过，也有人为，prompt 和 context 有点强分彼此，区别不大，只是表达不同。（言外之意，老瓶装新酒，为了造 buzz。）

所谓“context engineering”只是把 prompt 拆成多个来源组合而已，本质还是 prompt engineering。

多位评论者指出：“prompt” 和 “context” 在技术上本质是一回事，都是输入模型的 Token 序列。

模型并不区分你是通过“用户输入”还是“上下文历史”送进来的内容。

一位开发者更是总结得很直白：“你完全可以把 context 整个打包成 prompt 发进去，对模型没区别。”

还有网友强调：“magic”背后依然离不开编程和理解模型原理，也有人批评上下文工程很容易变成一种“玄学”炒作。

简单的理解，不管叫 prompt 还是 context，都是黑盒巫术本质还是“try and see”。

还有网友调侃：LLM 是非确定性机器，结果不稳定、重复性不强，所谓“工程”不过是“调参的艺术”。

图片

8.写在最后：Prompt 淡出或是必然

在小编看来，提词工程的淡出（产品化），上下文工程兴起，已经是一种趋势。

首先，产品侧来看，随着 RAG、Agent、AutoChain 等机制普及，开发者越来越依赖工具自动构建 prompt，而不是手写 prompt。

“好 prompt” 越来越像产品的功能，而非用户的技能。

其次，模型侧来分析。模型 token window 增大，但 context 变长后“腐烂”（context rot）问题日渐凸显。

图片

对于我们而言，如何管理、组织、剪裁 context 成为下一步挑战。

正如一位Hackernews的网友 Drew Breunig 所提到了一些关键技术：Context Quarantine、Tool Loadout、Summarization 等。

当然，不管是提示词工程，还是上下文工程，小编认为——哪个都不是万能的！

“即使你有 memory bank，有 plugin，最终还是得人类自己写代码。”

参考链接：

​​https://x.com/tobi/status/1935533422589399127​​

​​https://x.com/karpathy/status/1937909397180796982​​

本文转载自​​51CTO技术栈​​，作者：云昭