微信扫码
添加专属顾问
我要投稿
Prompt工程已过时?Shopify CEO和AI大神Karpathy力推的"上下文工程"才是AI智能体的未来! 核心内容: 1. Prompt工程的局限性及上下文工程的重要性 2. 上下文工程如何决定AI智能体的成败 3. 行业专家对上下文工程的认可与实践案例
我们发现,决定智能体成败的关键在于你赋予它的上下文的质量。大多数智能体失败不再是模型失败,而是上下文失败。
所谓“上下文工程”,它不是一句提示词,它是一个系统工程。
一次廉价演示和一次神奇 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 的一句话。作者指出:
你可以把它想象成模型在生成回答之前,所能看到的一切信息:
系统指令 / 初始提示(System Prompt):在对话开始时,预先定义模型行为的一组说明,可包含示例、规则等。
用户提示(User Prompt):用户当下发出的任务或问题。
短期记忆 / 对话历史(State / History):当前对话中的来龙去脉,包括之前的提问与回应。
长期记忆(Long-Term Memory):模型跨会话记住的持久信息,例如用户偏好、项目摘要、背景知识等。
检索信息(RAG):来自外部文档、数据库或 API 的实时信息,用于增强模型回答。
可用工具(Available Tools):模型可调用的函数或工具列表,如 check_inventory
、send_email
。
结构化输出格式(Structured Output):定义模型回答的格式,比如 JSON 模板或结构体。
真正打造出一个可靠、有用的 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。
上下文包含:
你的日程表(显示你明天全天爆满)
你和对方以往的邮件记录(判断用语是否需要随意一些)
联系人信息(识别出对方是关键合作伙伴)
可用工具(比如发出邀请、自动回复邮件)
最终生成的回应是:
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)是设计和构建动态系统的一门学问,目标是在正确的时间、以正确的格式,向大模型提供完成任务所需的一切信息和工具。
系统,而不是字符串:不是静态的模板,而是在调用 LLM 之前动态生成的结果。
动态、按需生成:对一个请求来说,也许上下文是日程表;另一个请求可能需要最近的网页搜索或邮件往来。
信息与工具,刚刚好地送达:避免垃圾进垃圾出(Garbage In, Garbage Out),只提供任务真正需要的信息与能力。
格式也很关键:与其丢一堆生肉数据,不如给出提炼后的摘要;工具调用格式清晰,胜过模糊提示。
而这是一项跨学科挑战,既需要理解业务场景,也需要明确目标输出,更需要设计清晰的信息结构,让语言模型真正完成任务。
网友热议:造新词儿?
对于上下文工程,一位谷歌的同事(巧了,也叫菲利普,也是作者团队的人员,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 淡出或是必然
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-07-01
AI沟通效率翻倍:5个精准提问框架告别无效对话
2025-07-01
大模型应用不同提示词范式和ReAct Agent智能体实现原理分析
2025-07-01
谷歌AI操控手册!Prompt Engineering核心玩法
2025-07-01
提示词即操作系统:Manus的Prompt体验
2025-07-01
让AI更懂你:我们跟AI说的每一句话都是Prompt提示词
2025-07-01
AI提示词指南:从小白到高手,让你的AI效率提升300%
2025-06-30
掌握提示词设计与工程,开启智能交互新时代!
2025-06-29
提示词的道与术,听完李继刚老师最新的分享,我的 5 点收获
2025-04-08
2025-04-08
2025-05-08
2025-05-08
2025-05-08
2025-04-11
2025-05-07
2025-04-14
2025-05-19
2025-05-07
2025-06-23
2025-06-14
2025-06-04
2025-06-02
2025-05-17
2025-05-16
2025-05-09
2025-04-29