我们发现，决定智能体成败的关键在于你赋予它的上下文的质量。大多数智能体失败不再是模型失败，而是上下文失败。
所谓“上下文工程”，它不是一句提示词，它是一个系统工程。
一次廉价演示和一次神奇 AI 体验之间的差距，全在于——上下文的质量。
Prompt不香了？Context Engineering又是哪个工程师发明的新名词？
评论区一众大厂和创业者都在喊“+1”。（后来小编搜了一下：新名词的是Shopify CEO Tobi Lutke提出的，前OpenAI大神Karpathy也X转帖了。）
与其再去研究“怎么写提示词（prompt）”，真正应该关注的，是如何为 AI 组织一个完整、合适、动态的上下文（context），这才是 Agent 成败的关键。
可以说再一次把“Prompt”与“Contex”的引战放到了明面上。当然从评论区的效果上看，事实也的确如此。
相信大家都有这样的“皱眉头”经历：
费劲写了一段“完美Prompt”，希望AI给出精准回答。（ps：想一想，你有没有写过这样一个提示“做好这件事，奖励你1万块！”）但结果，AI模型却就总是给出一个非常机械的、“缺少灵魂”的输出。
对此，作者指出：为什么上下文比提示词更重要了？
随着 AI Agent（智能体）的崛起，我们输入模型的“有限工作记忆”里到底装了什么，变得比以往任何时候都更关键。（即：大模型就像一台超强的语言引擎，但它的“记忆”有限，单靠一段话很难覆盖复杂的业务需求和多维信息。结果就是，AI“答非所问”，或者机械死板，差强人意。）
现在，决定一个 Agent 成败的核心因素，不再是调用哪个大模型、写了多花哨的提示词，而是——你给它的上下文质量够不够好。
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 美元”之类的小聪明来提升模型性能了——本来就应该如此。
真正的优势在于：你是否能精心构建上下文，帮模型最大程度减少“战争迷雾”。它正在趋近于人类式的信息需求。
上下文没那么简单，包含7部分
要理解“上下文工程”，我们得先重新定义“上下文”这个词。
它不是你发给 LLM 的一句话。作者指出：
你可以把它想象成模型在生成回答之前，所能看到的一切信息：
作者将上下文的构成分成了 7 部分：
系统指令 / 初始提示（System Prompt）：在对话开始时，预先定义模型行为的一组说明，可包含示例、规则等。
用户提示（User Prompt）：用户当下发出的任务或问题。
短期记忆 / 对话历史（State / History）：当前对话中的来龙去脉，包括之前的提问与回应。
长期记忆（Long-Term Memory）：模型跨会话记住的持久信息，例如用户偏好、项目摘要、背景知识等。
检索信息（RAG）：来自外部文档、数据库或 API 的实时信息，用于增强模型回答。
可用工具（Available Tools）：模型可调用的函数或工具列表，如
check_inventory、send_email。结构化输出格式（Structured Output）：定义模型回答的格式，比如 JSON 模板或结构体。
好的上下文 ≠ 靠 LLM 猜，而是靠系统主动“喂”进去该知道的一切。
从“廉价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 的失败，更多是上下文失败，而不是模型失败。
从提示工程转向上下文工程，有何不同？
现在，我们可以回答两者到底有什么不同了。
如果说提示词工程是想写出“一句话打动模型”，那么上下文工程是一门系统工程学科。
首先，来看定义（更接地气地讲）：
上下文工程（Context Engineering）是设计和构建动态系统的一门学问，目标是在正确的时间、以正确的格式，向大模型提供完成任务所需的一切信息和工具。
它的核心特征有 4 个：
系统，而不是字符串：不是静态的模板，而是在调用 LLM 之前动态生成的结果。
动态、按需生成：对一个请求来说，也许上下文是日程表；另一个请求可能需要最近的网页搜索或邮件往来。
信息与工具，刚刚好地送达：避免垃圾进垃圾出（Garbage In, Garbage Out），只提供任务真正需要的信息与能力。
格式也很关键：与其丢一堆生肉数据，不如给出提炼后的摘要；工具调用格式清晰，胜过模糊提示。
即，作者提出，只有为 LLM 提供恰当且动态组合的信息、工具和指令，才能让 AI 真正理解并高效完成复杂任务。
所以，要构建强大、稳定的 AI Agent，不再是靠“提示词魔法”或“换个大模型”，而是靠“上下文工程”：
在正确的时间，把正确的信息与工具，以正确的格式，放进模型的脑子里。
而这是一项跨学科挑战，既需要理解业务场景，也需要明确目标输出，更需要设计清晰的信息结构，让语言模型真正完成任务。
网友热议：造新词儿？
对于上下文工程，一位谷歌的同事（巧了，也叫菲利普，也是作者团队的人员，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 信号、链上信息的上下文输入，这样模型才能“真正做事”，而不是只会“聊天”。
真正的杠杆在于上下文工程。
老瓶装新酒？
技术本质都是黑盒巫术
不过，也有人为，prompt 和 context 有点强分彼此，区别不大，只是表达不同。（言外之意，老瓶装新酒，为了造 buzz。）
所谓“context engineering”只是把 prompt 拆成多个来源组合而已，本质还是 prompt engineering。
多位评论者指出：“prompt” 和 “context” 在技术上本质是一回事，都是输入模型的 Token 序列。
模型并不区分你是通过“用户输入”还是“上下文历史”送进来的内容。
一位开发者更是总结得很直白：“你完全可以把 context 整个打包成 prompt 发进去，对模型没区别。”
还有网友强调：“magic”背后依然离不开编程和理解模型原理，也有人批评上下文工程很容易变成一种“玄学”炒作。
简单的理解，不管叫 prompt 还是 context，都是黑盒巫术本质还是“try and see”。
还有网友调侃：LLM 是非确定性机器，结果不稳定、重复性不强，所谓“工程”不过是“调参的艺术”。
写在最后：Prompt 淡出或是必然
