智能体的上下文工程

了解您正在为其构建 AI 智能体的应用程序的复杂性，对于打造一个可靠的智能体至关重要。我们需要构建能够有效管理信息以应对超出提示工程（prompt engineering）范畴的复杂需求的 AI 智能体。

在本节课中，我们将探讨什么是上下文工程（context engineering）以及它在构建 AI 智能体中的作用。

简介

本节课将涵盖：

• 什么是上下文工程，以及它为何与提示工程不同。
• 有效的上下文工程策略，包括如何编写、选择、压缩和隔离信息。
• 可能导致 AI 智能体偏离轨道的**常见上下文失效（Context Failures）**及其修复方法。

学习目标

完成本节课后，您将了解并掌握如何：

• 定义上下文工程，并将其与提示工程区分开来。
• 识别上下文的关键组成部分（在大型语言模型 (LLM) 应用程序中）。
• 应用编写、选择、压缩和隔离上下文的策略，以提高智能体的性能。
• 识别常见的上下文失效，如污染（poisoning）、分心（distraction）、混淆（confusion）和冲突（clash），并实施缓解技术。

什么是上下文工程？

对于 AI 智能体来说，上下文是驱动其进行规划以采取特定行动的依据。上下文工程是一种实践，旨在确保 AI 智能体拥有正确的信息来完成任务的下一步。上下文窗口的大小是有限的，因此作为智能体的构建者，我们需要建立系统和流程来管理在上下文窗口中添加、删除和精简信息的操作。

提示工程 vs 上下文工程

提示工程专注于一组单一的静态指令，通过一套规则有效地引导 AI 智能体。而上下文工程则是关于如何管理一组动态信息（包括初始提示），以确保 AI 智能体随着时间的推移能获取其所需的内容。上下文工程的核心思想是使这一过程具有可重复性和可靠性。

上下文的类型

必须记住，上下文不仅限于一种事物。AI 智能体所需的信息可能来自各种不同的来源，我们有责任确保智能体能够访问这些来源：

AI 智能体可能需要管理的上下文类型包括：

• 指令（Instructions）： 这些就像是智能体的“规则”——提示词、系统消息、少样本示例（向 AI 展示如何执行某事），以及其可用工具的描述。这是提示工程的重点与上下文工程相结合的地方。
• 知识（Knowledge）： 这涵盖了事实、从数据库中检索到的信息，或智能体积累的长期记忆。如果智能体需要访问不同的知识库和数据库，这就包括集成检索增强生成（RAG）系统。
• 工具（Tools）： 这些是智能体可以调用的外部函数、API 和 MCP 服务器的定义，以及它使用这些工具后获得的反馈（结果）。
• 对话历史（Conversation History）： 与用户的持续对话。随着时间推移，这些对话会变得越来越长且越来越复杂，这意味着它们会占用上下文窗口的空间。
• 用户偏好（User Preferences）： 随着时间推移了解到的关于用户喜恶的信息。这些信息可以被存储起来，并在做出关键决策以帮助用户时被调用。

有效的上下文工程策略

规划策略

优秀的上下文工程始于良好的规划。以下方法将帮助您开始思考如何应用上下文工程的概念：

• 明确定义结果（Define Clear Results）： AI 智能体将被分配的任务结果应该被清晰地定义。回答这个问题——“当 AI 智能体完成其任务时，世界会变成什么样？”换言之，用户在与 AI 智能体交互后应该获得什么改变、信息或响应。
• 映射上下文（Map the Context）： 一旦您定义了 AI 智能体的结果，您就需要回答“AI 智能体需要什么信息才能完成此任务？”这个问题。这样您就可以开始映射这些信息可能所在的上下文来源。
• 创建上下文管道（Create Context Pipelines）： 既然您知道信息在哪里，您就需要回答“智能体将如何获取这些信息？”这个问题。这可以通过多种方式完成，包括 RAG、使用 MCP 服务器和其他工具。

实用策略

规划固然重要，但一旦信息开始流入我们智能体的上下文窗口，我们就需要有实用的策略来管理它：

管理上下文

虽然有些信息会自动添加到上下文窗口中，但上下文工程的核心在于更主动地管理这些信息，这可以通过以下几种策略来实现：

• 智能体草稿本（Agent Scratchpad）： 这允许 AI 智能体在单个会话期间记录有关当前任务和用户交互的相关信息。这应存在于上下文窗口之外的文件或运行时对象中，智能体可以在需要时在此会话期间对其进行检索。
• 记忆（Memories）： 草稿本适用于管理单个会话上下文窗口之外的信息。而记忆使智能体能够跨多个会话存储和检索相关信息。这可能包括摘要、用户偏好以及用于未来改进的反馈。
• 压缩上下文（Compressing Context）： 一旦上下文窗口增大并接近其限制，就可以使用摘要和修剪等技术。这包括仅保留最相关的信息或删除较旧的消息。
• 多智能体系统（Multi-Agent Systems）： 开发多智能体系统是上下文工程的一种形式，因为每个智能体都有自己的上下文窗口。在构建这些系统时，如何共享这些上下文并将其传递给不同的智能体是另一项需要规划的事情。
• 沙盒环境（Sandbox Environments）： 如果智能体需要运行某些代码或处理文档中的大量信息，处理结果可能需要消耗大量的 token。与其将所有内容都存储在上下文窗口中，智能体可以使用一个能够运行此代码的沙盒环境，并仅从中读取结果和其他相关信息。
• 运行时状态对象（Runtime State Objects）： 这是通过创建信息容器来管理的，以应对智能体需要访问特定信息的情况。对于复杂的任务，这将使智能体能够逐步存储每个子任务的结果，从而使上下文仅保持与该特定子任务的连接。

上下文工程示例

假设我们想让 AI 智能体“帮我预订去巴黎的行程”。

• 一个仅使用提示工程的简单智能体可能只会回答：“好的，您想什么时候去巴黎？”它只处理了用户提问当时的直接问题。
• 一个使用了上述上下文工程策略的智能体会做得更多。甚至在响应之前，其系统可能就会：

1. 检查您的日历以查找可用日期（检索实时数据）。
2. 回忆过去的旅行偏好（来自长期记忆），例如您首选的航空公司、预算或您是否更喜欢直飞航班。
3. 识别可用工具以预订航班和酒店。

随后，一个响应示例可能是：“嘿 [您的名字]！我看到您在十月的第一周有空。需要我为您寻找在您通常的 [预算] 范围内，乘坐 [首选航空公司] 飞往巴黎的直飞航班吗？”。这种更丰富、具备上下文意识的响应展示了上下文工程的强大威力。

常见的上下文失效

上下文污染（Context Poisoning）

• 它是什么： 当幻觉（LLM 生成的虚假信息）或错误进入上下文并被反复引用时，会导致智能体追求不可能的目标或制定毫无意义的策略。
• 怎么办： 实施上下文验证（context validation）和隔离（quarantine）。在将信息添加到长期记忆之前对其进行验证。如果检测到潜在的污染，请开启全新的上下文线程，以防止不良信息传播。
• 旅行预订示例： 您的智能体产生幻觉，认为从当地的一个小型机场到一座遥远的国际城市有直飞航班，而实际上该机场根本不提供国际航班。这个不存在的航班细节被保存到上下文中。后来，当您要求智能体预订时，它不断试图寻找这条不可能航线的机票，从而导致反复报错。
• 解决方案： 实施一个验证步骤，在将航班细节添加到智能体的工作上下文之前，使用实时 API 验证航班和航线的真实存在性。如果验证失败，错误信息将被“隔离”并不再使用。

上下文分心（Context Distraction

• 它是什么： 当上下文变得如此之大，以至于模型过多地关注累积的历史记录，而不是使用其在训练期间学到的知识，从而导致重复或无用的操作。模型甚至可能在上下文窗口存满之前就开始犯错。
• 怎么办： 使用上下文摘要（context summarization）。定期将累积的信息压缩为较短的摘要，保留重要细节同时删除冗余的历史记录。这有助于“重置”焦点。
• 旅行预订示例： 您很长时间以来一直在讨论各种梦想的旅行目的地，包括详细讲述两年前的背包旅行。当您最终要求“下个月帮我找一趟便宜的航班”时，智能体陷入了陈旧、不相关的细节中，不断询问您的背包装备或过去的行程，忽略了您当前的请求。
• 解决方案： 在特定的对话轮数之后，或者当上下文变得太大时，智能体应该总结对话中最新、最相关的部分——重点关注您当前的旅行日期和目的地——并在下一次调用 LLM 时使用该浓缩摘要，丢弃相关性较低的历史聊天记录。

上下文混淆（Context Confusion）

• 它是什么： 当不必要的上下文（通常表现为提供过多的可用工具）导致模型生成糟糕的响应或调用不相关的工具时。较小的模型尤其容易出现这种情况。
• 怎么办： 使用 RAG 技术实施工具加载管理（tool loadout management）。将工具描述存储在向量数据库中，并为每个特定任务仅选择最相关的工具。研究表明，应将工具选择限制在 30 个以内。
• 旅行预订示例： 您的智能体可以访问数十个工具：book_flight、book_hotel、rent_car、find_tours、currency_converter、weather_forecast、restaurant_reservations 等。您问：“在巴黎出行的最佳方式是什么？”由于工具数量庞大，智能体感到困惑并尝试调用巴黎市内的 book_flight，或调用 rent_car（即使您更喜欢公共交通），因为工具的描述可能会重叠，或者它根本无法分辨出哪个是最好的。
• 解决方案： 对工具描述使用 RAG。当您询问有关巴黎出行的问题时，系统会根据您的查询动态地仅检索最相关的工具（例如 rent_car 或 public_transport_info），向 LLM 呈现一个焦点集中的工具“配置”。

上下文冲突（Context Clash）

• 它是什么： 当上下文中存在相互冲突的信息，从而导致推理不一致或最终响应不佳时。这通常发生在信息分阶段到达，而早期不正确的假设仍保留在上下文中时。
• 怎么办： 使用上下文修剪（context pruning）和卸载（offloading）。修剪意味着随着新细节的到来，删除过时或冲突的信息。卸载则为模型提供了一个单独的“草稿本”工作区来处理信息，而不会弄乱主上下文。
• 旅行预订示例： 一开始您告诉智能体：“我想坐经济舱。”在随后的对话中，您改变了主意说：“其实这次旅行，我们还是订商务舱吧。”如果这两条指令都保留在上下文中，智能体可能会收到冲突的搜索结果，或者对该优先考虑哪个偏好感到困惑。
• 解决方案： 实施上下文修剪。当一条新指令与旧指令相矛盾时，旧指令会在上下文中被删除或显式覆盖。或者，智能体可以在决定之前使用草稿本协调冲突的偏好，确保只有最终的、一致的指令来指导其操作。