什么是上下文工程？

“上下文工程”正成为一个备受关注的新概念，取代了以往的“提示工程”。正如 Shopify 首席执行官 Tobi Lutke 所描述的，上下文工程是“提供所有上下文，使大型语言模型 (LLM) 能够合理解决任务的艺术。” 这一观点切中要害。

随着 Agent （AI 代理）的兴起，我们如何将信息加载到其“有限的工作记忆”中变得愈发重要。我们发现，Agent 的成功与否主要取决于所提供上下文的质量。如今，大多数 Agent 的失败不再是模型本身的缺陷，而是上下文的不足。

什么是上下文？

要理解上下文工程，我们首先必须扩展对“上下文”的定义。它不仅仅是你发送给 LLM 的单个提示。你可以将其理解为模型在生成响应之前所看到的一切。

上下文组成部分：

• • 指令 / 系统提示 (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 对象。

为何重要：从廉价演示到神奇产品

构建真正有效的 AI Agent 的秘密与你编写的代码复杂性关系不大，而与你提供上下文的质量息息相关。

构建 Agent 更多地在于你提供的上下文的质量，而不是你编写的代码或使用的框架。廉价演示与“神奇”Agent 之间的区别就在于上下文的质量。想象一个 AI 助手被要求根据一封简单的电子邮件安排会议：

嗨，想确认下明天你是否有空快速同步一下。

“廉价演示”Agent 的上下文很差。它只看到用户的请求，别无他物。它的代码可能完全正常——它调用 LLM 并获得响应——但输出却毫无帮助且机械：

感谢您的留言。明天我有空。请问您打算什么时间？

“神奇”Agent 则由丰富的上下文驱动。代码的主要工作不是弄清楚如何响应，而是收集 LLM 完成目标所需的信息。在调用 LLM 之前，你会扩展上下文以包含：

• • 你的日程信息（显示你已全部预订）。
• • 你与此人的过往邮件（以确定适当的非正式语气）。
• • 你的联系人列表（将他们识别为关键合作伙伴）。
• • 用于发送邀请或发送电子邮件的工具。

然后，它才能生成一个响应。

嗨 Jim！我明天日程很满，一整天都是会议。周四上午有空，你看可以吗？我发了个邀请，可以的话告诉我一声。

这种“魔法”并非源于更智能的模型或更巧妙的算法，而是源于为正确的任务提供了正确的上下文。这就是上下文工程将变得至关重要的原因。Agent 的失败不仅仅是模型失败，更是上下文失败。

从提示工程到上下文工程

什么是上下文工程？“提示工程”侧重于在单个文本字符串中精心设计完美的指令集，而上下文工程则更为宽广。简单来说：

上下文工程是设计和构建动态系统的学科，该系统在正确的时间以正确的格式提供正确的信息和工具，从而为 LLM 提供完成任务所需的一切。

上下文工程的特点：

• • 是一个系统，而不是一个字符串： 上下文不仅仅是一个静态的提示模板。它是主 LLM 调用之前运行的系统的输出。
• • 动态的： 实时创建，根据即时任务量身定制。对于一个请求，这可能是日历数据；对于另一个请求，可能是电子邮件或网络搜索。
• • 关于在正确的时间提供正确的信息和工具： 核心工作是确保模型不缺少关键细节（“垃圾进，垃圾出”）。这意味着仅在需要和有用时才提供知识（信息）和能力（工具）。
• • 格式至关重要： 你呈现信息的方式很重要。简洁的摘要优于原始数据转储。清晰的工具模式优于模糊的指令。

结论

构建强大可靠的 AI Agent 越来越不取决于寻找一个神奇的提示或模型更新。它关乎上下文的工程，即在正确的时间以正确的格式提供正确的信息和工具。这是一项跨职能的挑战，涉及理解你的业务用例、定义你的输出以及构建所有必要信息，以便 LLM 能够“完成任务”。