编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

继“氛围编码”（Vibe Coding）之后，AI 圈又迎来一个爆火的新名词——“上下文工程”（Context Engineering）。

相比大模型刚崛起时出现的“提示词工程”这个广为人知的说法，“上下文工程”正逐渐被认为是更准确、更专业的替代词，背后也反映出整个大语言模型（LLM）应用范式的转变。

“上下文工程”一词的由来

这个说法最早引起广泛关注，是因为 Shopify CEO Tobi Tobi Lutke 在 X（原 Twitter）上发了一个帖子：“我更喜欢用‘上下文工程’来代替‘提示词工程’这个词。它更贴切地描述了核心技能：为任务提供足够的上下文，让大语言模型有可能得出合理解答的艺术。”

这条推文迅速引发共鸣，连 AI 界技术大牛、前 OpenAI 研究员 Andrej Karpathy 也转发附上了“+1”以示认同。

Andrej Karpathy 写道：

同意！“上下文工程”比“提示词工程”更合适。

大多数人一听到“提示词”，想到的只是平时用 LLM 时输的一小段任务描述。而在真正工业级的 LLM 应用中，上下文工程才是关键所在——一门既讲科学又讲直觉的技术活，要把上下文窗口精确地填入下一步所需的信息。

说它是“科学”，是因为你得处理清晰的任务描述、示例、外部信息检索（RAG）、相关数据（可能还是多模态的）、工具、状态和历史，还要考虑怎么压缩信息……这些环节做对并不简单。如果信息太少或形式不对，大模型就无法获取足够的上下文，性能大打折扣；信息太多或太无关，成本会上升，性能反而可能下降。做好这件事，绝非易事。

它之所以是“艺术”，是因为你得有对“大模型心理学”的直觉判断，知道人类期望它怎么理解信息、怎么回应。

当然，除了上下文工程本身，构建一个真正的 LLM 应用还涉及很多其它工作，比如：

• 如何把大问题拆解为合适的控制流程

• 如何精准打包上下文窗口

• 如何调度调用不同能力、不同类型的模型

• 如何设计生成-验证的 UI/UX 流程

• 还有一整套包括安全控制、性能评估、并行执行、预取机制等在内的复杂逻辑……

因此，上下文工程只是整个 LLM 应用系统中，一个小而复杂的组成部分。它属于正在迅速发展的一整层“厚重软件栈”，这个软件栈负责协调每一次模型调用（以及远不止如此），从而构建出真正可用的大模型应用。

所以，“ChatGPT 包装器”这个说法，早就不合时宜，而且严重低估了这项工作的复杂性。

到底什么是“上下文”？

那么，对于普通 AI 从业者而言，该如何理解与运用“上下文工程”，它是否和“提示词工程”一样，只是写几句指令就行？

对此，来自 DeepMind 的高级 AI 关系工程师 Philipp Schmid 给出了深刻的解读。他指出，「随着智能体（Agent）技术的发展，我们越来越意识到，什么信息被放入模型“有限的工作记忆”中，才是决定任务成功与否的关键。如今很多 Agent 的失败，不再是模型能力不足，而是上下文没设计好。」

要真正理解“上下文工程”，我们首先得重新认识“上下文”这个词。它并不仅仅是你输入给模型的一句话，而是模型在生成回答之前，所能看到的全部信息。

可以把上下文理解为以下这些组成部分：

• 系统指令（System Prompt）：开场设定，告诉模型这次对话应该怎么表现。可以包含示例、规则等等。

• 用户输入：用户的提问或任务指令。

• 对话历史（短期记忆）：本轮对话中模型和用户的所有来回内容。

• 长期记忆：跨会话保存的信息，比如用户偏好、过往项目的总结、或明确告诉模型要记住的事实。

• 外部检索信息（RAG）：从文档、数据库或 API 获取的最新资料，用来辅助模型回答。

• 可用工具：模型可以调用的工具或函数（例如 check_inventory、send_email）。

• 结构化输出格式：指定模型回答的格式，比如一个 JSON 对象。

为什么“上下文工程”如此重要？

你写的代码复杂不复杂，反而没那么重要。重要的是你给模型准备了什么样的上下文。

打个比方，假设你做了一个智能助理，用来安排会议。当用户发来一封简单邮件：

“嘿，明天你有空开个小会聊聊吗？”

版本一：廉价演示级别的 Agent

它拿到这句话就直接丢给大模型，没有别的上下文辅助。结果模型生成一个死板的回应：

“谢谢你的信息。明天可以。请问你希望几点呢？”

看似没问题，但毫无“智能”。

版本二：魔法般的 Agent

这个 Agent 会在调用模型前，把相关背景信息都准备好：

• 查你的日历（发现你明天全天都排满了）

• 看你跟这位联系人过往的邮件（判断你们说话可以用轻松语气）

• 识别对方是重要合作伙伴

• 配好发邀请的工具（send_invite）

于是模型生成的回复是这样的：

“嘿 Jim！我明天全都排满了，一整天都在开会。周四上午有空，合适吗？我发了个邀请，看看行不行。”

看出来了吗？这不是模型变聪明了，而是你喂给它的信息更好了。真正的“魔法”，其实是“上下文”变了。

从“提示词”走向“上下文工程”

那到底什么是“上下文工程”？如果说提示词工程是写一段聪明的指令让模型尽可能给出好结果，那上下文工程做的事情要更复杂：

上下文工程，是设计和构建一整套动态系统，让大模型在正确的时间，看到正确的信息和工具，以完成目标任务。

更具体来说：

• 不是一句话，而是一个系统：上下文不是静态模板，而是模型调用前动态生成的一整套输入。

• 按需生成，实时定制：每次请求生成的上下文都不同。有时是日历信息，有时是用户邮件，有时是最新网页搜索结果。

• 关键在于“信息+工具”的时机与精度：模型输出质量好不好，核心是你给它的东西准不准、够不够。如果给的上下文本身就是错的或没用的，那结果自然也好不到哪去。

• 信息呈现方式也很重要：一堆乱七八糟的原始数据，远不如一个清晰的摘要；一段模糊的提示，不如一个结构明确的工具调用说明。

总结

现在，想做出真正靠谱、强大、实用的 AI Agent，关键不在于模型换没换新、提示词写得多高级，而是上下文工程做得怎么样：你有没有把正确的信息、工具、格式，在正确的时机送到模型面前。

这不仅是工程问题，更是一个跨领域的系统设计问题。你需要懂业务场景、定义好目标输出，然后用“上下文”把一切都准备好，让模型有条件完成任务。

来源：https://www.philschmid.de/context-engineering

推荐阅读：

重磅！百度文心大模型4.5系列模型开源，国内首发平台GitCode现已开放下载

一觉醒来，OpenAI快被小扎“挖空”？！Meta斥上亿美元“偷家”，挖来了一个「最强AI团队」

告别32位！Linux发行版清理旧架构引争议，开发者：真砍我就解散项目

📢 AI 产品爆发，但你的痛点解决了吗？

2025 全球产品经理大会

8 月 15–16 日 

北京·威斯汀酒店

互联网大厂、AI 创业公司、ToB/ToC 实战一线的产品人

12 大专题分享，洞察趋势、拆解路径、对话未来。

立即扫码领取大会PPT

抢占 AI 产品下一波红利