AI 智能体的有效上下文工程
原文: Effective context engineering for AI agents
日期：2025年9月29日
上下文是 AI 智能体的一项关键但有限的资源。在本文中，我们探讨了有效策划和管理驱动智能体上下文的策略。
在应用 AI 领域，经过几年对提示工程的关注之后，一个新术语开始崭露头角：上下文工程(Context Engineering)。使用语言模型进行构建，正逐渐从为提示寻找合适的词语和短语，转向回答一个更广泛的问题：“什么样的上下文配置最有可能产生我们模型的期望行为？”
上下文(Context) 指的是从大语言模型（LLM）进行采样时所包含的 token 集合。手头的工程(engineering) 问题是，在 LLM 固有的约束下，优化这些 token 的效用，以便持续地实现期望的结果。有效地驾驭 LLM 通常需要在上下文中思考(thinking in context) —换句话说：考虑 LLM 在任何给定时间可用的整体状态，以及该状态可能产生的潜在行为。
在本文中，我们将探讨新兴的上下文工程艺术，并为构建可控、有效的智能体提供一个更精炼的心智模型。
上下文工程 vs. 提示工程
在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程指的是为获得最佳结果而编写和组织 LLM 指令的方法（请参阅我们的文档以获取概述和有用的提示工程策略）。上下文工程指的是在 LLM 推理期间，为策划和维护最佳 token（信息）集合而采取的一系列策略，包括可能出现在提示之外的所有其他信息。
在 LLM 工程的早期，提示是 AI 工程工作中最重要的组成部分，因为日常聊天互动之外的大多数用例都需要为单次分类或文本生成任务优化提示。顾名思义，提示工程的主要焦点是如何编写有效的提示，特别是系统提示。然而，随着我们朝着构建能够在多轮推理和更长时间范围内运行的更强大智能体的方向发展，我们需要管理整个上下文状态的策略（系统指令、工具、模型上下文协议 (MCP)、外部数据、消息历史等）。
在一个循环中运行的智能体会生成越来越多的数据，这些数据 可能 与下一轮推理相关，而这些信息必须周期性地进行精炼。上下文工程是一门艺术和科学，它负责从那个不断演变的可能信息宇宙中，策划出将要放入有限上下文窗口的内容。
与编写提示这一离散任务相比，上下文工程是迭代的，并且每次我们决定要传递什么给模型时，都会进行策划阶段。
为什么上下文工程对构建强大的智能体很重要
尽管 LLM 速度快，并且能够管理越来越大的数据量，但我们观察到，LLM 和人类一样，在某一点上会失去焦点或感到困惑。关于“大海捞针(needle-in-a-haystack)”式基准测试的研究揭示了上下文腐烂(context rot)的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。
虽然某些模型的性能下降比其他模型更平缓，但这一特性在所有模型中都会出现。因此，上下文必须被视为一种边际收益递减的有限资源。就像人类有有限的工作记忆容量一样，LLM 在解析大量上下文时也有一个“注意力预算”。每一个新引入的 token 都会消耗这个预算的一部分，从而增加了仔细策划 LLM 可用 token 的必要性。
这种注意力稀缺源于 LLM 的架构约束。LLM 基于 Transformer 架构，它使得每个 token 都能在整个上下文中关注到其他所有 token。对于 n 个 token，这会导致 n² 个成对关系。
随着上下文长度的增加，模型捕捉这些成对关系的能力被拉伸，从而在上下文大小和注意力焦点之间产生了一种自然的张力。此外，模型的注意力模式是在训练数据分布中形成的，其中短序列通常比长序列更常见。这意味着模型对于上下文范围内的依赖关系经验较少，专门化的参数也较少。
像位置编码插值这样的技术允许模型通过将长序列适应于最初训练的较小上下文来处理它们，尽管在 token 位置理解上会有一些性能下降。这些因素创造了一个性能梯度而不是一个硬性悬崖：模型在较长上下文中仍然非常强大，但与在较短上下文中的表现相比，它们在信息检索和长距离推理方面的精度可能会降低。
这些现实意味着，深思熟虑的上下文工程对于构建强大的智能体至关重要。
有效上下文的构成
鉴于 LLM 受到有限注意力预算的约束，好 的上下文工程意味着找到能最大化某种期望结果可能性的最小可能的高信号 token 集合。实现这一实践说起来容易做起来难，但在下一节中，我们将概述这一指导原则在上下文不同组成部分中的实际意义。
系统提示(System prompts) 应该极其清晰，并使用简单、直接的语言，以适合智能体的*恰当高度(right altitude)*来呈现思想。恰当高度是介于两种常见失败模式之间的“金发姑娘区(The Goldilocks Zone)”。在一个极端，我们看到工程师在他们的提示中硬编码复杂、脆弱的逻辑，以引出精确的智能体行为。这种方法会产生脆弱性，并随着时间的推移增加维护复杂性。在另一个极端，工程师有时提供模糊、高层次的指导，这未能给 LLM 提供期望输出的具体信号，或者错误地假设了共享的上下文。最佳高度是在两者之间取得平衡：既足够具体以有效指导行为，又足够灵活以提供给模型强大的启发式方法来指导行为。
在一个极端，我们看到脆弱的 if-else 硬编码提示，而在另一个极端，我们看到过于笼统或错误地假设共享上下文的提示。
我们建议将提示组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题等技术来划分这些部分，尽管随着模型能力的增强，提示的确切格式可能正变得不那么重要。
无论您决定如何构建您的系统提示，您都应该力求使用能完全概述您期望行为的最小信息集。（请注意，最小并不一定意味着短；您仍然需要预先给智能体提供足够的信息，以确保它遵守期望的行为。）最好从使用可用的最佳模型测试一个最小的提示开始，看它在您的任务上的表现如何，然后根据初始测试中发现的失败模式，添加清晰的指令和示例来提高性能。
工具允许智能体与其环境进行操作，并在工作时引入新的、额外的上下文。因为工具定义了智能体与其信息/行动空间之间的契约，所以工具促进效率至关重要，既要通过返回 token 高效的信息，也要通过鼓励高效的智能体行为。
在《为 AI 智能体编写工具——借助 AI 智能体》中，我们讨论了构建能被 LLM 很好理解且功能重叠最小的工具。与设计良好的代码库中的函数类似，工具应该是自包含的、对错误具有鲁棒性，并且其预期用途应该极其清晰。输入参数同样应该是描述性的、无歧义的，并能发挥模型的固有优势。
我们看到的最常见的失败模式之一是臃肿的工具集，它们覆盖了太多的功能或导致关于使用哪个工具的决策点变得模糊。如果一个人类工程师不能明确地说出在特定情况下应该使用哪个工具，那么就不能期望一个 AI 智能体做得更好。 正如我们稍后将讨论的，为智能体策划一个最小可行的工具集也可以使其在长时间交互中更可靠地维护和修剪上下文。
提供示例，也称为少样本提示(few-shot prompting)，是一个众所周知的最佳实践，我们继续强烈建议。然而，团队常常会在提示中塞入一长串的边缘案例，试图阐明 LLM 在特定任务中应遵循的每一个可能的规则。我们不推荐这样做。相反，我们建议努力策划一组多样化的、典型的示例，以有效地描绘智能体的预期行为。对于 LLM 来说，示例是“胜过千言万语的图片”。
我们对上下文不同组成部分（系统提示，工具，示例，消息历史等）的总体指导是，要深思熟虑，并保持您的上下文信息丰富而紧凑。现在让我们深入探讨在运行时动态检索上下文。
上下文检索与智能体化搜索
在《构建有效的 AI 智能体》中，我们强调了基于 LLM 的工作流程与智能体之间的差异。自我们撰写那篇文章以来，我们逐渐倾向于一个对智能体的简单定义：在一个循环中自主使用工具的 LLM。
与我们的客户并肩工作，我们看到该领域正趋向于这个简单的范式。随着基础模型的能力越来越强，智能体的自主程度可以扩展：更智能的模型允许智能体独立地驾驭细微的问题空间并从错误中恢复。
我们现在看到工程师在如何为智能体设计上下文方面的思维方式正在发生转变。今天，许多 AI 原生应用都采用了某种基于嵌入的预推理时间检索来为智能体提供重要的上下文以供其推理。随着该领域向更具智能体化的方法过渡，我们越来越多地看到团队用“即时”上下文策略来增强这些检索系统。
与预先处理所有相关数据不同，采用“即时”方法构建的智能体维护轻量级标识符（文件路径、存储的查询、网页链接等），并使用这些引用在运行时使用工具动态地将数据加载到上下文中。Anthropic 的智能体化编程解决方案 Claude Code 使用这种方法在大型数据库上执行复杂的数据分析。模型可以编写有针对性的查询，存储结果，并利用像 head 和 tail 这样的 Bash 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种方法模仿了人类的认知：我们通常不会记住整个信息语料库，而是引入外部组织和索引系统，如文件系统、收件箱和书签，以便按需检索相关信息。
除了存储效率，这些引用的元数据提供了一种有效优化行为的机制，无论是明确提供还是直观的。对于一个在文件系统中操作的智能体来说，一个名为 test_utils.py 的文件出现在 tests 文件夹中，其意图与一个同名文件位于 src/core_logic.py 中是不同的。文件夹层次结构、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何以及何时利用信息。
让智能体自主导航和检索数据也实现了渐进式披露——换句话说，允许智能体通过探索逐步发现相关上下文。每一次交互都会产生用于指导下一次决策的上下文：文件大小暗示了复杂性；命名约定暗示了用途；时间戳可以作为相关性的代理。智能体可以逐层构建理解，只在工作记忆中保留必要的内容，并利用笔记策略进行额外的持久化。这种自我管理的上下文窗口使智能体专注于相关的子集，而不是淹没在详尽但可能不相关的信息中。
当然，这里存在一个权衡：运行时探索比检索预先计算的数据要慢。不仅如此，还需要有主见和深思熟虑的工程设计，以确保 LLM 拥有有效导航其信息景观的正确工具和启发式方法。没有适当的指导，智能体可能会因为误用工具、追逐死胡同或未能识别关键信息而浪费上下文。
在某些情况下，最有效的智能体可能会采用混合策略，为了速度预先检索一些数据，并自行决定进行进一步的自主探索。决定“恰当”自主程度的界限取决于任务。Claude Code 就是一个采用这种混合模型的智能体：CLAUDE.md 文件会预先简单地放入上下文中，而像 glob 和 grep 这样的基本命令允许它导航其环境并即时检索文件，从而有效地绕过了索引过时和复杂语法树的问题。
混合策略可能更适合内容变化不那么动态的场景，比如法律或金融工作。随着模型能力的提高，智能体设计的趋势将是让智能模型智能地行动，并逐步减少人工策划。鉴于该领域的快速发展，“做最简单的有效方法”可能仍然是我们给基于 Claude 构建智能体的团队的最佳建议。
长时间任务的上下文工程
长时间任务要求智能体在一系列动作中保持连贯性、上下文和目标导向的行为，而这些动作的 token 数量超过了 LLM 的上下文窗口。对于跨越数十分钟到数小时连续工作的任务，如大型代码库迁移或全面的研究项目，智能体需要专门的技术来绕过上下文窗口大小的限制。
等待更大的上下文窗口似乎是一个显而易见的策略。但很可能在可预见的未来，各种大小的上下文窗口都将受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下是如此。为了使智能体能够有效地跨越更长的时间范围工作，我们开发了一些直接解决这些上下文污染约束的技术：压缩、结构化笔记和多智能体架构。
压缩
压缩是指将一个接近上下文窗口限制的对话，总结其内容，并用该摘要重新启动一个新的上下文窗口的做法。压缩通常是上下文工程中驱动更好长期连贯性的第一个杠杆。其核心是，压缩以高保真度的方式提炼上下文窗口的内容，使智能体能够以最小的性能下降继续工作。
例如，在 Claude Code 中，我们通过将消息历史传递给模型来总结和压缩最关键的细节来实现这一点。模型保留了架构决策、未解决的 bug 和实现细节，同时丢弃了冗余的工具输出或消息。然后，智能体可以使用这个压缩后的上下文加上最近访问的五个文件继续工作。用户获得了连续性，而无需担心上下文窗口的限制。
压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能会导致 subtle 但关键的上下文丢失，而其重要性只在稍后才显现出来。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹上仔细调整您的提示。首先最大化召回率，以确保您的压缩提示捕获了轨迹中的每一个相关信息，然后通过消除多余内容来迭代提高精确度。
一个唾手可得的多余内容是清除工具调用和结果——一旦一个工具在消息历史深处被调用过，智能体为什么还需要再次看到原始结果呢？最安全、最轻量级的压缩形式之一是工具结果清除，最近作为Claude 开发者平台上的一个功能推出。
结构化笔记
结构化笔记，或称智能体记忆，是一种技术，即智能体定期将笔记写入持久化到上下文窗口之外的内存中。这些笔记会在稍后被拉回上下文窗口。
这种策略以最小的开销提供了持久的记忆。就像 Claude Code 创建一个待办事项列表，或者您的自定义智能体维护一个 NOTES.md 文件一样，这个简单的模式允许智能体跟踪复杂任务的进度，保持关键的上下文和依赖关系，否则这些信息会在数十次工具调用中丢失。
Claude 玩宝可梦展示了记忆如何在非编程领域改变智能体的能力。该智能体在数千个游戏步骤中保持精确的记录——跟踪目标，如“在过去的 1,234 步中，我一直在 1 号道路上训练我的宝可梦，皮卡丘已经升了 8 级，目标是 10 级。”在没有任何关于记忆结构的提示下，它绘制了已探索区域的地图，记住了它解锁了哪些关键成就，并维护了战斗策略的战略笔记，帮助它学习哪些攻击对不同对手最有效。
在上下文重置后，智能体读取自己的笔记，并继续数小时的训练序列或地牢探索。这种在总结步骤之间的连贯性使得长期的策略成为可能，而如果将所有信息都保留在 LLM 的上下文窗口中，这是不可能的。
作为我们Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上以公开测试版的形式发布了一个记忆工具，它通过一个基于文件的系统，使得在上下文窗口之外存储和查询信息变得更加容易。这允许智能体随着时间的推移建立知识库，跨会话维护项目状态，并引用以前的工作，而无需将所有内容都保留在上下文中。
子智能体架构
子智能体架构提供了另一种绕过上下文限制的方法。与其让一个智能体试图在整个项目中维护状态，不如让专门的子智能体用干净的上下文窗口处理集中的任务。主智能体用一个高层次的计划进行协调，而子智能体则执行深入的技术工作或使用工具来寻找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多的 token，但只返回一个浓缩、提炼过的工作总结（通常是 1,000-2,000 个 token）。
这种方法实现了明确的关注点分离——详细的搜索上下文在子智能体内部保持隔离，而主导智能体则专注于综合和分析结果。这种模式在《我们如何构建多智能体研究系统》中进行了讨论，在复杂的研究任务上，它比单智能体系统显示出显著的改进。
这些方法之间的选择取决于任务的特性。例如：
- 压缩为需要大量来回交流的任务保持对话流程；
- 笔记在具有明确里程碑的迭代开发中表现出色；
- 多智能体架构处理复杂的研究和分析，其中并行探索能带来回报。
即使模型不断改进，在扩展的交互中保持连贯性的挑战仍将是构建更有效智能体的核心。
结论
上下文工程代表了我们用 LLM 构建方式的根本性转变。随着模型变得越来越强大，挑战不仅仅是制作完美的提示——而是在每一步都深思熟虑地策划哪些信息进入模型有限的注意力预算。无论您是为长时间任务实现压缩，设计 token 高效的工具，还是让智能体即时探索其环境，指导原则都保持不变：找到能最大化您期望结果可能性的最小的高信号 token 集合。
我们概述的技术将随着模型的改进而继续演进。我们已经看到，更智能的模型需要更少的规定性工程，允许智能体以更大的自主性运作。但即使能力扩展，将上下文视为一种珍贵、有限的资源，仍将是构建可靠、有效智能体的核心。
立即在 Claude 开发者平台开始上下文工程，并通过我们的记忆和上下文管理手册获取有用的提示和最佳实践。
致谢
由 Anthropic 的应用 AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 亦有贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的支持。
订阅开发者通讯
产品更新、操作指南、社区亮点等。每月发送到您的收件箱。
如果您想收到我们的月度开发者通讯，请提供您的电子邮件地址。您可以随时退订。