告别提示词工程，「上下文工程」才是 AI Agent 的核心竞争力
编者按： 什么样的技能才能真正决定 AI 智能体的成败？是更复杂的算法，还是更精妙的提示词？我们今天为大家带来的文章，作者的观点是：构建强大 AI 智能体的关键已从"提示词工程"转向"上下文工程"。
文章从"上下文"的广义定义出发，详细拆解了影响 AI 决策的七大关键要素，包括系统指令、用户输入、历史对话、长期记忆、外部检索信息、可用工具及输出结构。通过对比"廉价演示项目"与"神奇智能体"的案例，作者生动展现了上下文质量如何决定 AI 的表现 ------ 真正的差距不在于模型本身，而在于是否提供了恰当的上下文支持。作者进一步提出，上下文工程是一套动态流程，需跨领域协作，以结构化的方式整合业务需求与技术实现，确保 LLM 在正确的时间获得正确的信息与工具。
作者 | Philipp Schmid
编译 | 岳扬
上下文工程（Context Engineering）是一个在人工智能领域逐渐走红的新术语。行业内讨论的焦点正从"提示词工程"（prompt engineering）转向一个更广泛、更强大的概念：上下文工程（Context Engineering）。托比·卢克（Tobi Lutke）[1]将其描述为"为任务提供完整的上下文背景，使大语言模型能够合理解决问题的一门艺术"，他说得很到位。
随着 Agents 的兴起，将哪些信息输入"有限的工作记忆（limited working memory）"中变得越来越重要。我们观察到，决定一个 Agent 成败的关键因素，通常就在于你提供给它的上下文质量。大多数 Agent 的失败早已不是模型本身的问题，而恰恰是上下文供给的失败。
01 什么是上下文（Context）？
要理解上下文工程（Context Engineering），我们首先必须扩展对"上下文"的定义。它不仅指你发送给 LLM 的单一提示词（prompt）。应该将其视为模型在生成响应前所看到的一切信息。
- 指令 / 系统提示词（Instructions / System Prompt） ： 用于定义模型在对话期间行为的初始指令集，可以/应该包含示例、规则等。
- 用户提示词（User Prompt） ： 来自用户的即时任务或问题。
- 状态 / 历史（短期记忆）[State / History (short-term Memory] ： 当前的对话内容，包括导致此刻结果的"用户与模型的历史回复"。
- 长期记忆（Long-Term Memory） ： 在之前的多次对话中收集的持久性知识库，包含学习到的用户偏好、过往对话摘要、或被明确告知需要记忆以备后续使用的信息。
- 检索信息（RAG）[Retrieved Information (RAG)] ： 外部的、最新的知识，来自文档、数据库或 API 的相关信息，用于回答特定问题。
- 可用工具（Available Tools） ： 所有可调用函数或内置工具的标准化描述（如输入参数、输出格式、功能说明）（例如 check_inventory, send_email）。
- 结构化输出（Structured Output） ： 对模型响应格式的定义，例如一个 JSON 对象。
02 为什么重要？从「廉价的演示项目」到「神奇的智能体产品」
构建真正高效的 AI 智能体的秘诀，与你编写代码的复杂程度关系不大，而与你提供上下文的质量息息相关。
构建智能体，与你编写的代码或使用的框架关系不大。 一个廉价的演示项目和"神奇的智能体"之间的区别，就在于你所提供上下文的质量。假设让一个 AI 助手根据一封简单的邮件来安排会议：
Hey, just checking if you're around for a quick sync tomorrow.
嘿，想问一问明天方不方便，我们快速碰个头？
"廉价的智能体演示项目"的上下文质量很差。它只看到用户的请求，其他什么都看不到。它的代码可能功能完善，它会调用 LLM 并获得响应，但输出的内容却毫无帮助，且充满机械感：
Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?
感谢来信！明天我有空。你想约在几点？
"神奇的智能体"则由丰富的上下文驱动。其代码的主要任务并非琢磨如何回应，而是收集 LLM 所需的信息，以便更好地响应用户需求。在调用 LLM 之前，你可以扩展上下文，使其包含：
- 你的日历信息（显示你日程已满）。
- 你与此人的过往邮件（用于确定合适的非正式语气）。
- 你的联系人列表（用于识别 ta 为关键的合作伙伴）。
- send_invite 或 send_email 工具。
然后便能生成回应：
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！明天我这边日程全排满了，从早到晚连轴转。周四上午有空，你看行不？邀请已发，确认下是否合适~
这种神奇的效果并非源于更聪明的模型或更精巧的算法，而在于为正确的任务提供了恰当的上下文。这就是为什么上下文工程（Context Engineering）非常重要。智能体的失败并非仅仅是模型的失败，本质上是上下文的缺失。
03 从提示词工程到上下文工程
什么是上下文工程？如果说"提示词工程（prompt engineering）"侧重于在单个文本字符串中精心设计一套完美的指令，那么上下文工程（context engineering）的范畴则宽广得多。简而言之：
上下文工程是一门设计和构建动态系统的学科，它能以正确的格式、在正确的时间提供正确的信息与工具，赋予 LLM 完成任务所需的一切资源。
上下文工程是
- 一套流程，而非某些字符串：上下文不仅是一个静态的提示词模板。它是主 LLM 调用前系统运行所产生的输出。
- 动态构建的：随任务即时生成，适配用户当下的需求。对某个请求，其上下文可能是日历数据，对另一请求，上下文则可能是邮件记录或网页搜索结果。
- 在正确的时间提供正确的信息和工具：其核心职责是确保模型不遗漏关键细节（Garbage In, Garbage Out）。这意味着只有在必需且有帮助时才提供知识（信息）与能力（工具）。
- 注重呈现格式：如何呈现信息很重要。简明扼要的摘要胜过原始数据的堆砌，清晰的工具架构胜过模糊的指令。
04 Summary
构建强大且可靠的 AI 智能体，已经不再需要寻找神奇的提示词或更新模型版本。其核心在于上下文工程，即以正确的格式、在正确的时间提供正确的信息与工具。这是一项跨领域协作的挑战，需要理解业务场景、定义预期输出，并结构化组织所有必要的信息，使 LLM 能够真正"完成任务"。
05 致谢
本综述的完成得益于深度研究（deep research）与人工校验（manual research），并从以下优质资源中汲取了灵感与信息：
- Tobi Lutke tweet[1]
- Karpathy tweet[2]
- The rise of "context engineering"[3]
- Own your context window[4]
- Context Engineering by Simon Willison[5]
- Context Engineering for Agents[6]
END
本期互动内容 🍻
❓你是否有过动态构建上下文的经验？能否分享一个你认为特别成功的案例？
文中链接
[1]https://x.com/tobi/status/1935533422589399127
[2]https://x.com/karpathy/status/1937902205765607626
[3]https://blog.langchain.com/the-rise-of-context-engineering/
[5]https://simonwillison.net/2025/Jun/27/context-engineering/
[6]https://rlancemartin.github.io/2025/06/23/context_engineering/
本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。
原文链接：
