ai-agents-for-beginners
Context Engineering for AI Agents
(点击上方图片以查看本课视频)
理解你为之构建 AI 代理的应用的复杂性，对于打造一个可靠的代理非常重要。我们需要构建能够有效管理信息的 AI 代理，以应对超出提示工程范围的复杂需求。
在本课中，我们将了解什么是上下文工程以及它在构建 AI 代理中的作用。
Introduction
本课将涵盖：
• 什么是上下文工程 以及它为何不同于提示工程。
• 有效上下文工程的策略，包括如何编写、选择、压缩和隔离信息。
• 常见的上下文失败，可能使你的 AI 代理出现问题以及如何修复它们。
Learning Goals
完成本课后，你将了解并掌握如何：
• 定义上下文工程 并将其与提示工程区分开。
• 识别 LLM 应用中上下文的关键组成部分。
• 应用编写、选择、压缩和隔离上下文的策略 来提升代理性能。
• 识别常见的上下文失败，例如中毒、分心、混淆和冲突，并实施缓解技术。
What is Context Engineering?
对于 AI 代理来说，上下文是驱动代理规划采取特定动作的要素。上下文工程是确保 AI 代理拥有完成下一个任务步骤所需正确信息的实践。上下文窗口是有大小限制的，因此作为代理构建者，我们需要构建系统和流程来管理在上下文窗口中添加、移除和压缩信息。
Prompt Engineering vs Context Engineering
提示工程侧重于一组静态指令，以一套规则有效地引导 AI 代理。上下文工程则是如何管理一组动态信息（包括初始提示），以确保 AI 代理随着时间推移拥有所需的信息。围绕上下文工程的主要思想是使这一过程可重复且可靠。
Types of Context
重要的是要记住，上下文不只是单一事物。AI 代理需要的信息可以来自多种不同来源，我们的任务是确保代理能够访问这些来源：
AI 代理可能需要管理的上下文类型包括：
• 指令： 像代理的“规则”——提示、系统消息、少样本示例（向 AI 展示如何执行某事）以及可使用工具的描述。这里是提示工程与上下文工程结合的重点。
• 知识： 涵盖事实、从数据库检索的信息或代理积累的长期记忆。如果代理需要访问不同的知识库和数据库，这包括整合检索增强生成 (RAG) 系统。
• 工具： 代理可以调用的外部函数、API 和 MCP 服务器的定义，以及使用它们所得到的反馈（结果）。
• 对话历史： 与用户的持续对话。随着时间推移，这些对话会变得更长更复杂，从而占据上下文窗口的空间。
• 用户偏好： 随时间收集到的关于用户喜好或不喜好的信息。这些可以被存储并在做出关键决策时调用以帮助用户。
Strategies for Effective Context Engineering
Planning Strategies
良好的上下文工程始于良好的规划。以下方法将帮助你开始思考如何应用上下文工程概念：
- 定义清晰的结果 - 分配给 AI 代理的任务结果应明确定义。回答问题——“当 AI 代理完成任务时，世界会是什么样子？” 换句话说，用户在与 AI 代理交互后应该获得什么改变、信息或回应。
- 绘制上下文地图 - 一旦定义了 AI 代理的结果，就需要回答“AI 代理为了完成此任务需要哪些信息？”。这样你就可以开始映射这些信息可能存放的位置。
- 创建上下文管道 - 既然你知道了信息在哪里，就需要回答“代理将如何获取这些信息？”。这可以通过多种方式完成，包括 RAG、使用 MCP 服务器和其他工具。
Practical Strategies
规划很重要，但一旦信息开始流入我们代理的上下文窗口，我们需要有实际策略来管理它：
Managing Context
虽然一些信息会自动添加到上下文窗口，但上下文工程更强调主动管理这些信息，可以通过以下几种策略来实现：
-
Agent Scratchpad 允许 AI 代理在单次会话期间记录与当前任务和用户交互相关的重要信息。它应存在于上下文窗口之外的文件或运行时对象中，代理在需要时可以在此会话内检索。
-
Memories 草稿本适合管理单次会话上下文窗口之外的信息。记忆使代理能够在多次会话间存储和检索相关信息。这可能包括摘要、用户偏好和用于未来改进的反馈。
-
Compressing Context 一旦上下文窗口增长并接近其限制，可以使用摘要和修剪等技术。这包括只保留最相关的信息或删除较旧的消息。
-
Multi-Agent Systems 开发多代理系统是一种上下文工程形式，因为每个代理都有自己的上下文窗口。构建这些系统时，需要规划如何共享和传递这些上下文。
-
Sandbox Environments 如果代理需要运行一些代码或处理文档中的大量信息，这可能需要大量 token 来处理结果。代理可以使用沙箱环境来运行这些代码，仅读取结果和其他相关信息，而不是将所有这些内容存储在上下文窗口中。
-
Runtime State Objects 通过创建信息容器来管理当代理需要访问特定信息的情况。对于复杂任务，这将使代理能够逐步存储每个子任务的结果，从而让上下文仅与该特定子任务保持关联。
Example of Context Engineering
假设我们希望一个 AI 代理 “为我订一趟去巴黎的行程。”
• 一个仅使用提示工程的简单代理可能只是回应：“好的，你想什么时候去巴黎？”。它只处理用户当时直接提出的问题。
• 使用本文所述上下文工程策略的代理会做更多事情。在回应之前，其系统可能会：
◦ 检查你的日历 以确认可用日期（检索实时数据）。
◦ 回忆过去的旅行偏好（来自长期记忆），例如你偏好的航空公司、预算，或是否偏好直飞。
◦ 识别可用的订票和酒店预订工具。
- 然后，一个示例回复可能是： “嘿 [你的名字]！我看到你在十月的第一周有空。要我在你常用预算范围内，帮你查找 [Preferred Airline] 的直飞去巴黎的航班吗？” 这种更丰富、更具上下文感知的回应展示了上下文工程的威力。
Common Context Failures
Context Poisoning
是什么： 当幻觉（LLM 生成的错误信息）或错误进入上下文并被反复引用，导致代理追求不可能的目标或制定荒谬策略时，就会发生上下文中毒。
如何处理： 实施 上下文验证 和 隔离。在将信息添加到长期记忆之前进行验证。如果检测到潜在的中毒，启动新的上下文线程以防止错误信息传播。
旅行订票示例： 你的代理幻想出一趟 从某个小型本地机场直飞到远方国际城市，而该机场实际上并不提供国际航班。这个不存在的航班细节被保存到上下文中。后来，当你要求代理预订时，它不停地试图为这条不可能的路线找票，导致反复出错。
解决方案： 在将航班细节添加到代理的工作上下文之前，实施一步 使用实时 API 验证航班存在性和航线。如果验证失败，则将错误信息“隔离”并不再使用。
Context Distraction
是什么： 当上下文变得非常庞大时，模型可能过于关注累积的历史，而不是利用训练中学到的内容，导致重复或无用的行为。模型甚至可能在上下文窗口未满之前就开始犯错。
如何处理： 使用 上下文摘要。定期将累积的信息压缩为更短的摘要，保留重要细节并删除冗余历史。这有助于“重置”关注点。
旅行订票示例： 你长时间讨论过多种梦想旅行目的地，包括两年前一次背包旅行的详细叙述。当你最终要求 “帮我找下个月的廉价机票” 时，代理被旧的无关细节拖住，不断询问你的背包装备或过去的行程，而忽视了你当前的请求。
解决方案： 在达到一定轮次或上下文变得过大时，代理应 总结最近且相关的对话部分——聚焦于你当前的旅行日期和目的地——并在下一次 LLM 调用时使用该压缩后的摘要，丢弃不太相关的历史聊天。
Context Confusion
是什么： 当不必要的上下文（通常表现为过多可用工具）导致模型生成糟糕的响应或调用无关工具时发生。较小的模型尤其容易出现这种情况。
如何处理： 使用 RAG 技术实施 工具载入管理。将工具描述存储在向量数据库中，并仅为每个具体任务选择最相关的工具。研究表明将工具选择限制在 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
是什么： 当上下文中存在冲突信息时，会导致不一致的推理或糟糕的最终响应。这通常发生在信息分阶段到达，而早期的错误假设仍保留在上下文中。
如何处理： 使用 上下文修剪 和 外卸。修剪意味着在新细节到来时移除过时或冲突的信息。外卸则为模型提供一个单独的“草稿区”以处理信息，而不会弄乱主上下文。
旅行订票示例： 你最初告诉代理，“我想坐经济舱。” 后来在对话中你改变了主意，说，“实际上，这次我们坐商务舱吧。” 如果两条指示都保留在上下文中，代理可能会收到冲突的搜索结果或对优先考虑哪条偏好感到困惑。
解决方案： 实施 上下文修剪。当新指令与旧指令矛盾时，旧指令应从上下文中移除或被明确覆盖。或者，代理可以使用 草稿区 来调和冲突偏好，然后再决定，确保只有最终一致的指令指导其行动。
Got More Questions About Context Engineering?
加入 Microsoft Foundry Discord 与其他学习者交流，参加答疑时间并获得 AI 代理相关问题的解答。
免责声明： 本文件已使用 AI 翻译服务 Co-op Translator（https://github.com/Azure/co-op-translator）进行翻译。尽管我们努力确保准确性，但请注意自动翻译可能包含错误或不准确之处。原始语言的文件应视为具有权威性的来源。对于关键信息，建议采用专业人工翻译。对于因使用本翻译而产生的任何误解或错误解释，我们不承担责任。