AI 智能体的上下文工程：实用指南
作者：@AnthropicAI
在应用 AI 领域，提示词工程 (prompt engineering) 曾是几年来万众瞩目的焦点。而如今，一个新名词正脱颖而出：上下文工程 (context engineering)。构建语言模型应用的过程，正在从“如何为提示词找到最合适的措辞”，转变为回答一个更宏大的问题：“什么样的上下文配置，最有可能引导我们的模型产生期望的行为？”
上下文 (Context) 指的是从大语言模型 (LLM) 进行采样时，输入给模型的所有 Token 的集合。而我们面临的 工程 (engineering) 问题，则是在大语言模型固有的限制下，优化这些Token的效用，从而稳定地实现预期目标。要想有效地驾驭大语言模型，你常常需要学会从上下文的角度思考——换句话说，要全面地考虑大语言模型在任何给定时刻所能获得的所有信息状态，以及这些状态可能催生出哪些潜在行为。
在这篇文章中，我们将一同探索上下文工程这门新兴的艺术，并为构建可控、高效的 AI 智能体提供一个更精炼的思维模型。
上下文工程 vs. 提示词工程
在 Anthropic，我们将上下文工程看作是提示词工程的自然演进。提示词工程指的是为了获得最佳结果，而编写和组织大语言模型指令的方法（可以参考我们的文档来了解概览和实用的提示词工程策略）。而上下文工程则是一整套策略，用于在模型推理过程中，精心筛选和维护一组最优的Token（信息），这其中也包括了提示词之外可能进入上下文的所有其他信息。
在利用大语言模型进行工程实践的早期，提示词是 AI 工程工作的重头戏，因为除了日常聊天互动外，大多数用例都需要为单次分类或文本生成任务优化提示词。顾名思义，提示词工程主要关注如何编写有效的提示词，特别是系统提示词 (system prompts)。然而，随着我们开始构建能力更强、能够在多轮推理和更长时间跨度上运行的 AI 智能体，我们就需要新的策略来管理整个上下文状态（包括系统指令、工具、模型上下文协议 (Model Context Protocol, MCP)、外部数据、消息历史等）。
一个循环运行的 AI 智能体会产生越来越多可能与下一轮推理相关的数据，这些信息必须被周期性地提炼。上下文工程正是一门艺术与科学，它的核心就是从这个不断演变的信息宇宙中，精心挑选出那些应该被放入有限上下文窗口的内容。
与编写提示词这种一次性的任务不同，上下文工程是一个迭代的过程，每当我们决定要向模型传递什么信息时，都需要进行一次精心的筛选。
为什么上下文工程对构建强大的 AI 智能体至关重要
我们观察到，尽管大语言模型的速度越来越快，能处理的数据量也越来越大，但它们和人类一样，在某个点上也会注意力不集中或感到困惑。一些类似“大海捞针”式的基准测试研究揭示了一个概念，叫作上下文衰减 (context rot)：随着上下文窗口中的Token数量增加，模型从中准确回忆信息的能力反而会下降。
虽然有些模型性能下降得比其他模型平缓一些，但这个特性在所有模型中都普遍存在。因此，我们必须将上下文视为一种有限的、边际效益递减的资源。就像人类的工作记忆容量有限一样，大语言模型在解析大量上下文时也有一个“注意力预算”。每引入一个新的Token，都会消耗一部分预算，这就使得我们必须更加谨慎地筛选提供给模型的信息。
这种注意力稀缺源于大语言模型的架构限制。大语言模型基于 Transformer 架构，该架构允许每个Token关注到上下文中的其他所有Token。这意味着对于 n 个Token，会产生 n² 对两两之间的关系。
随着上下文长度的增加，模型捕捉这些成对关系的能力会被摊薄，从而在上下文大小和注意力焦点之间产生了一种天然的矛盾。此外，模型的注意力模式是在训练数据上形成的，而在这些数据中，短序列通常比长序列更常见。这意味着模型处理长距离依赖的经验较少，专门用于此的参数也较少。
像位置编码插值 (position encoding interpolation) 这样的技术，可以通过调整使模型适应原本训练时较小的上下文，从而处理更长的序列，但这也会导致模型对Token位置的理解有所下降。这些因素共同导致了性能的平滑下降，而不是断崖式下跌：模型在长上下文下依然能力强大，但在信息检索和长距离推理方面的精确度，可能会比在短上下文下有所降低。
这些现实情况意味着，深思熟虑的上下文工程对于构建强大的 AI 智能体至关重要。
高效上下文的构成要素
既然大语言模型受到有限注意力预算的制约，那么好的上下文工程就意味着要找到尽可能小但信号最强的Token集合，以最大化实现预期结果的可能性。这个原则说起来容易做起来难，但在下一节中，我们将具体阐述这一指导原则在上下文不同组成部分中的实际应用。
系统提示词 (System prompts) 应该极其清晰，使用简单直接的语言，并以恰当的抽象层级来呈现思想。这个“恰当的抽象层级”就像是“金发姑娘区” (Goldilocks zone)，刚好介于两种常见的失败模式之间。一个极端是，工程师在提示词中硬编码复杂而脆弱的逻辑，试图引发精确的智能体行为。这种方法会增加系统的脆弱性，并随着时间的推移增加维护的复杂性。另一个极端是，工程师有时只提供模糊、高层次的指导，这既无法为模型提供关于期望输出的具体信号，又错误地假设了模型与我们有共同的背景知识。最理想的抽象层级则是在两者之间取得平衡：既足够具体以有效引导行为，又足够灵活，能为模型提供强大的启发式规则来指导其行动。
我们建议将提示词组织成不同的部分（例如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题等技巧来划分这些部分，不过随着模型能力的提升，提示词的具体格式可能正变得不那么重要。
无论你决定如何构建你的系统提示词，你都应该力求用最少的信息完整地勾勒出你期望的行为。（请注意，最少不一定意味着简短；你仍然需要预先给智能体足够的信息，以确保它能遵循期望的行为。）最好的方法是，从一个最精简的提示词开始，用最好的模型来测试它在你的任务上的表现，然后根据初始测试中发现的失败模式，添加清晰的指令和示例来改进性能。
工具 (Tools) 允许 AI 智能体与环境互动，并在工作时引入新的、额外的上下文。由于工具定义了智能体与其信息/行动空间之间的契约，因此，工具的设计必须能够提升效率，这既包括返回的信息要在Token上高效，也包括鼓励智能体采取高效的行为。
在《与 AI 智能体一起为 AI 智能体编写工具》一文中，我们讨论了如何构建能被大语言模型很好理解且功能重叠最小的工具。与设计良好的代码库中的函数类似，工具应该是自包含的、对错误具有鲁棒性，并且其预期用途应该极其明确。输入参数也应同样具有描述性、无歧义，并能发挥模型的固有优势。
我们看到最常见的失败模式之一是工具集过于臃肿，要么功能覆盖范围太广，要么在选择使用哪个工具时导致决策模糊。如果一个人类工程师都无法确定在特定情况下应该使用哪个工具，那么我们也不能指望一个 AI 智能体能做得更好。正如我们稍后将讨论的，为智能体精心策划一个最小可行的工具集，也有助于在长时间的交互中更可靠地维护和删减上下文。
示例 (Examples)，也就是所谓的少样本提示 (few-shot prompting)，是一个众所周知的最佳实践，我们仍然强烈推荐。然而，团队常常会在提示词中塞入一长串的边缘案例，试图阐明大语言模型在特定任务中应遵循的每一条规则。我们不推荐这样做。相反，我们建议努力策划一组多样化、具有代表性的经典示例，以有效地展示智能体的预期行为。对于大语言模型来说，示例就是“胜过千言万语的图画”。
我们对上下文不同组成部分（系统提示词、工具、示例、消息历史等）的总体指导是：深思熟虑，保持上下文信息丰富但紧凑。现在，让我们深入探讨如何在运行时动态检索上下文。
在《构建高效的 AI 智能体》一文中，我们强调了基于大语言模型的工作流与 AI 智能体之间的区别。自那篇文章发布以来，我们逐渐倾向于一个更简单的定义：AI 智能体就是在一个循环中自主使用工具的大语言模型。
通过与客户并肩合作，我们看到整个领域正在向这个简单的范式靠拢。随着底层模型变得越来越强大，AI 智能体的自主性水平也在不断提升：更智能的模型允许智能体独立地处理复杂的、充满细微差别的问题空间，并能从错误中恢复。
我们现在看到，工程师在思考如何为 AI 智能体设计上下文时，观念正在发生转变。如今，许多 AI 原生应用都采用了某种基于嵌入 (embedding) 的推理前检索技术，以便为智能体提供重要的上下文信息进行推理。随着领域向更具智能体性的方法过渡，我们越来越多地看到团队在这些检索系统的基础上，增加了“即时” (just in time) 的上下文策略。
采用“即时”方法的智能体，并非预先处理所有相关数据，而是维护一些轻量级的标识符（如文件路径、存储的查询、网页链接等），并利用这些引用，在运行时通过工具动态地将数据加载到上下文中。Anthropic 的智能体编程解决方案 Claude Code 就使用了这种方法，在大型数据库上执行复杂的数据分析。模型可以编写有针对性的查询、存储结果，并利用像 head 和 tail 这样的 Bash 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种方法与人类的认知方式相似：我们通常不会记住信息的全部内容，而是引入外部的组织和索引系统，如文件系统、收件箱和书签，以便在需要时检索相关信息。
除了存储效率高之外，这些引用的元数据还提供了一种有效优化行为的机制，无论这些元数据是明确提供的还是直观的。对于一个在文件系统中操作的 AI 智能体来说，一个名为 test_utils.py 的文件出现在 tests 文件夹中，其意图显然不同于一个同名文件位于 src/core_logic.py 目录中。文件夹层级、命名规范和时间戳都提供了重要的信号，帮助人类和 AI 智能体理解如何以及何时利用信息。
让 AI 智能体自主导航和检索数据，也实现了信息的“渐进式披露” (progressive disclosure)——换句话说，允许智能体通过探索逐步发现相关上下文。每一次交互都会产生新的上下文，为下一次决策提供信息：文件大小暗示了复杂性；命名规范暗示了用途；时间戳可以作为相关性的代理。智能体可以一层一层地构建理解，只在工作记忆中保留必要的内容，并利用笔记策略进行额外的持久化。这种自我管理的上下文窗口，使智能体能够专注于相关的子集，而不是被详尽但可能无关的信息所淹没。
当然，这里存在一个权衡：运行时探索比检索预先计算好的数据要慢。不仅如此，还需要富有见地和深思熟虑的工程设计，以确保大语言模型拥有合适的工具和启发式规则来有效地导航其信息环境。没有适当的指导，智能体可能会因为误用工具、追逐死胡同或未能识别关键信息而浪费上下文。
在某些情况下，最有效的 AI 智能体可能会采用一种混合策略：为了速度，预先检索一些数据，然后根据自己的判断进行进一步的自主探索。决定“恰当”自主性水平的界限取决于任务本身。Claude Code 就是一个采用这种混合模型的智能体：CLAUDE.md 文件会简单地预先加载到上下文中，而像 glob 和 grep 这样的基本命令则允许它在环境中导航并即时检索文件，从而有效地绕过了索引陈旧和复杂语法树的问题。
对于内容变化不那么动态的场景，比如法律或金融工作，混合策略可能更适用。随着模型能力的提升，智能体设计的趋势将是让智能的模型去做智能的事，而人类的干预将逐渐减少。鉴于该领域的飞速发展，对于那些在 Claude 之上构建 AI 智能体的团队来说，“做最简单有效的事”可能仍然是我们最好的建议。
面向长时程任务的上下文工程
长时程任务要求 AI 智能体在一系列动作中保持连贯性、上下文感知和目标导向行为，而这些动作序列的Token总数会超过大语言模型的上下文窗口。对于那些需要持续工作几十分钟到数小时的任务，比如大型代码库迁移或全面的研究项目，AI 智能体需要专门的技术来绕过上下文窗口大小的限制。
等待更大的上下文窗口似乎是一个显而易见的策略。但很可能在可预见的未来，无论上下文窗口有多大，都会面临上下文污染和信息相关性的问题——至少在追求最强智能体性能的情况下是如此。为了让 AI 智能体能够在更长的时间跨度上有效工作，我们开发了一些直接解决这些上下文污染限制的技术：压缩、结构化笔记和多智能体架构。
压缩 (Compaction)
压缩是指将一个接近上下文窗口限制的对话，对其内容进行总结，然后用这个摘要重新开启一个新的上下文窗口。压缩通常是上下文工程中用来提升长期连贯性的第一个手段。其核心在于，压缩以高保真的方式提炼上下文窗口的内容，使智能体能够以最小的性能下降继续工作。
例如，在 Claude Code 中，我们通过将消息历史传递给模型，让它总结和压缩最关键的细节来实现这一点。模型会保留架构决策、未解决的错误和实现细节，同时丢弃冗余的工具输出或消息。然后，智能体可以带着这个压缩后的上下文以及最近访问的五个文件继续工作。用户可以获得连续的体验，而无需担心上下文窗口的限制。
压缩的艺术在于选择保留什么、丢弃什么，因为过于激进的压缩可能会导致丢失那些微妙但关键的上下文，而这些上下文的重要性可能要到后来才会显现。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹上仔细调整你的提示词。首先要最大化召回率，确保你的压缩提示词能捕捉到轨迹中的每一个相关信息，然后通过消除多余内容来迭代提升精确度。
一个唾手可得的多余内容就是清理工具调用和结果——一旦一个工具在消息历史的深处被调用过，智能体为什么还需要再次看到原始结果呢？最安全、最轻量级的压缩形式之一就是工具结果清理，最近它作为一项功能在 Claude 开发者平台上发布。
结构化笔记 (Structured note-taking)
结构化笔记，或称智能体记忆，是一种让 AI 智能体定期将笔记写入并持久化到上下文窗口之外的内存中的技术。这些笔记可以在稍后的时间点被重新拉回上下文窗口。
这种策略以最小的开销提供了持久的记忆。就像 Claude Code 创建一个待办事项列表，或者你自定义的智能体维护一个 NOTES.md 文件一样，这种简单的模式允许智能体在复杂任务中跟踪进度，维护那些否则会在数十次工具调用中丢失的关键上下文和依赖关系。
Claude 玩《宝可梦》的例子展示了记忆如何在非编程领域改变智能体的能力。这个智能体在数千个游戏步骤中保持着精确的记录——跟踪诸如“在过去的 1234 步里，我一直在 1 号道路上训练我的宝可梦，皮卡丘已经升了 8 级，目标是升 10 级”这样的目标。在没有任何关于记忆结构的提示下，它自发地绘制了已探索区域的地图，记住了自己解锁了哪些关键成就，并维护着战斗策略的笔记，帮助它学习哪种攻击对不同对手最有效。
在上下文重置后，智能体只需阅读自己的笔记，就能继续长达数小时的训练序列或地牢探索。这种跨越总结步骤的连贯性，使得那些在将所有信息都保留在大语言模型上下文窗口中无法实现的长时程策略成为可能。
作为我们 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上以公开测试版的形式发布了一个记忆工具，它通过一个基于文件的系统，使得在上下文窗口之外存储和查阅信息变得更加容易。这使得智能体能够随着时间的推移建立知识库，跨会话维护项目状态，并在不将所有内容保留在上下文中的情况下参考以前的工作。
子智能体架构 (Sub-agent architectures)
子智能体架构提供了另一种绕过上下文限制的方法。与其让一个智能体试图维护整个项目的状态，不如让专门的子智能体处理专注的任务，每个子智能体都有一个干净的上下文窗口。主智能体用一个高层次的计划进行协调，而子智能体则执行深入的技术工作或使用工具查找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多的Token，但只返回其工作的浓缩、提炼后的摘要（通常为 1000-2000 个Token）。
这种方法实现了明确的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主导智能体则专注于综合和分析结果。这种模式在《我们如何构建多智能体研究系统》一文中有过讨论，它在复杂的研任务上表现出比单智能体系统显著的优势。
在这些方法之间如何选择，取决于任务的特性。例如：
压缩适用于需要大量来回交流的任务，以保持对话的流畅性；
笔记在有明确里程碑的迭代开发中表现出色；
多智能体架构则适用于并行探索能带来巨大回报的复杂研究和分析任务。
即使模型不断进步，在长时间交互中保持连贯性的挑战，仍将是构建更高效 AI 智能体的核心问题。
结论
上下文工程代表了我们构建大语言模型应用方式的根本性转变。随着模型变得越来越强大，挑战不再仅仅是打造完美的提示词——而是在每一步都深思熟虑地筛选哪些信息进入模型有限的注意力预算。无论你是为长时程任务实现压缩，设计Token高效的工具，还是让智能体能够即时探索其环境，指导原则始终如一：找到那个能最大化你预期结果可能性的、信号最强但规模最小的Token集合。
我们概述的这些技术将随着模型的进步而继续演进。我们已经看到，更智能的模型需要更少的规范性工程，从而允许智能体以更大的自主性运作。但即使能力不断扩展，将上下文视为一种宝贵的、有限的资源，仍将是构建可靠、高效 AI 智能体的核心。
立即在 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 的支持。
来源：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents