上下文工程是 AI 领域中一个正在兴起的新术语。对话正在从“提示工程”转向一个更广泛、更强大的概念：上下文工程。Tobi Lutke 将其描述为“提供所有上下文，使 LLM 能够合理地解决任务的艺术”，他是对的。
随着代理的兴起，我们加载到“有限工作记忆”中的信息变得更加重要。我们看到，决定代理成功或失败的主要因素是您提供给它的上下文质量。大多数代理失败不再是模型失败，而是上下文失败。
什么是上下文？
要理解上下文工程，我们必须首先扩展我们对“上下文”的定义。它不仅仅是您发送给 LLM 的单个提示。将其视为模型在生成响应之前看到的一切。
- 指令/系统提示： 一组初始指令，定义模型在对话期间的行为，可以/应该包括示例、规则……
- 用户提示： 用户提出的即时任务或问题。
- 状态/历史（短期记忆）： 当前对话，包括导致此刻的用户和模型响应。
- 长期记忆： 跨越许多先前对话积累的持久知识库，包含学习到的用户偏好、过去项目的摘要或被告知要记住以备将来使用的事实。
- 检索到的信息（RAG）： 外部的、最新的知识，来自文档、数据库或 API 的相关信息，用于回答特定问题。
- 可用工具： 模型可以调用的所有函数或内置工具的定义（例如，check_inventory、send_email）。
- 结构化输出： 模型响应格式的定义，例如 JSON 对象。
为什么它很重要：从廉价演示到神奇产品
构建真正有效的 AI 代理的秘诀与您编写的代码的复杂性关系不大，而与您提供的上下文质量息息相关。
构建代理与您编写的代码或使用的框架关系不大。廉价演示和“神奇”代理之间的区别在于您提供的上下文质量。想象一下，一个 AI 助手被要求根据一封简单的电子邮件安排会议：
嘿，只是想看看你明天是否有空快速同步一下。
“廉价演示”代理的上下文很差。它只看到用户的请求，没有其他信息。它的代码可能功能完美——它调用 LLM 并获得响应——但输出却毫无帮助且机械：
感谢您的留言。我明天有空。请问您想在什么时间？
“神奇”代理由丰富的上下文驱动。代码的主要工作不是弄清楚_如何_响应，而是_收集_LLM 完成其目标所需的信息。在调用 LLM 之前，您将扩展上下文以包括：
- 您的日历信息（显示您已完全预订）。
- 您与此人的过去电子邮件（以确定适当的非正式语气）。
- 您的联系人列表（以将他们识别为关键合作伙伴）。
- 用于 send_invite 或 send_email 的工具。
然后您可以生成响应。
嘿，吉姆！我明天排满了，一整天都排得满满的。周四上午有空，你觉得可以吗？我发了邀请，如果可以的话告诉我。
这种魔力不在于更智能的模型或更巧妙的算法。它在于为正确的任务提供正确的上下文。这就是上下文工程将变得重要的原因。代理失败不仅仅是模型失败；它们是上下文失败。
从提示到上下文工程
什么是上下文工程？“提示工程”侧重于在单个文本字符串中精心设计完美的指令集，而上下文工程则要广泛得多。简单来说：
上下文工程是设计和构建动态系统的学科，该系统在正确的时间以正确的格式提供正确的信息和工具，从而为 LLM 提供完成任务所需的一切。
上下文工程是：
- 一个系统，而不是一个字符串： 上下文不仅仅是一个静态的提示模板。它是_在_主 LLM 调用之前运行的系统的输出。
- 动态的： 即时创建，根据即时任务量身定制。对于一个请求，这可能是日历数据，对于另一个请求，可能是电子邮件或网络搜索。
- 关于正确的信息、正确时间的工具： 核心工作是确保模型不会遗漏关键细节（“垃圾进，垃圾出”）。这意味着仅在需要和有用时才提供知识（信息）和能力（工具）。
- 格式很重要： 您呈现信息的方式很重要。简洁的摘要优于原始数据转储。清晰的工具模式优于模糊的指令。
结论
构建强大可靠的 AI 代理越来越不关乎找到一个神奇的提示或模型更新。它关乎上下文的工程，以及在正确的时间以正确的格式提供正确的信息和工具。这是一项跨职能的挑战，涉及理解您的业务用例、定义您的输出以及构建所有必要的信息，以便 LLM 能够“完成任务”。
致谢
本概述是在深入和手动研究的帮助下创建的，借鉴了以下几项优秀资源的灵感和信息：
评论区