超越提示词：Anthropic 揭示下一代AI智能体的关键——上下文工程

上下文（Context）是 AI 智能体（AI agents）的关键资源，但其容量有限。本文旨在探讨如何有效策划和管理为 AI 智能体提供动力所需的“上下文”。

经过几年聚焦于提示词工程（prompt engineering）的应用，人工智能领域涌现出了一个新术语：上下文工程（context engineering）。如今，构建大型语言模型（LLM）应用，不再仅仅是为提示词寻找合适的措辞，更重要的是要回答“何种上下文配置最有可能让模型产生我们期望的行为？”这一更宏观的问题。

上下文指的是从大型语言模型（LLM）中采样时所包含的指令序列（tokens）。而工程问题，则是优化这些指令序列的效用，同时克服大型语言模型固有的局限性，以持续实现预期的结果。有效驾驭大型语言模型通常需要“上下文化思维”——换言之，即要考虑大型语言模型在任何给定时间所能获取的整体状态，以及该状态可能产生的潜在行为。

在本文中，我们将深入探讨上下文工程这门新兴艺术，并提供一个更完善的思维模型，以构建更易操控、更高效的 AI 智能体。

上下文工程与提示词工程有何不同？

Anthropic 公司将上下文工程视为提示词工程的自然演进。

提示词工程指的是为实现最佳效果，编写和组织大型语言模型指令的方法（请参阅 Anthropic 文档，了解提示词工程的概述和实用策略）。上下文工程则是一套策略，用于在大型语言模型推理过程中，策划和维护最佳的指令序列（信息）集合，其中包括除提示词之外可能存在的所有其他信息。

在早期的大型语言模型工程中，提示词（prompting）是人工智能工程工作最重要的组成部分。因为除了日常聊天交互外，大多数用例都需要针对单次分类或文本生成任务进行优化的提示词。顾名思义，提示词工程主要关注如何编写有效的提示词，尤其是系统提示词。

然而，随着我们转向构建在多次推理和更长时间范围内运行的更强大的 AI 智能体，我们需要管理整个上下文状态的策略 (包括系统指令、工具、模型上下文协议（Model Context Protocol, MCP）、外部数据、消息历史记录等)。

一个循环运行的 AI 智能体，会生成越来越多可能与下一次推理相关的，且必须进行循环优化处理的数据。上下文工程就是一门艺术与科学。这门“艺术与科学”旨在从不断演变的信息宇宙中，筛选出将进入有限上下文窗口的内容。

与编写提示词的离散任务相反，上下文工程是迭代的，并且每次我们决定向模型传递什么信息时，都会进行策划阶段。

为什么上下文工程对构建强大的 AI 智能体至关重要？

尽管大型语言模型在处理速度和数据量方面表现出色，但 Anthropic 观察到，它们像人类一样，在达到某个点后会“注意力不集中”或“感到困惑”。对“大海捞针”式基准测试的研究揭示了**上下文腐烂（context rot）**的概念：随着上下文窗口中指令序列数量的增加，模型准确回忆上下文信息的能力会下降。

虽然有些模型的性能下降得比其他模型更缓慢，但这种特性在所有模型中都普遍存在。因此，上下文必须被视为一种有限资源，其边际回报递减。与人类具有有限工作记忆容量类似，大型语言模型也拥有一个“注意力预算”，在解析大量上下文时会动用这个预算。每引入一个新的指令序列，都会在一定程度上消耗这个预算，因此更有必要仔细策划提供给大型语言模型的指令序列。

这种注意力稀缺性源于大型语言模型的架构限制。大型语言模型基于变换器架构（transformer architecture），该架构使得每个指令序列都能关注（attend to）整个上下文中的所有其他指令序列。这意味着对于 n 个指令序列，会产生 n² 个两两关系。

随着上下文长度的增加，模型捕捉这些两两关系的能力被过度拉伸，从而在上下文大小和注意力焦点之间产生了天然的矛盾。此外，模型从训练数据分布中学习其注意力模式，而这些数据中通常短序列比长序列更常见。这意味着模型在处理上下文范围内的依赖关系方面经验较少，并且针对此类情况的专门参数也较少。

像位置编码插值（position encoding interpolation）这样的技术，允许模型通过使其适应最初训练的较小上下文来处理更长的序列，尽管这会略微降低对指令序列位置的理解。

这些因素造成了一种性能上的梯度而非断崖式下降：模型在较长上下文下仍表现出强大的能力，但与在较短上下文下的性能相比，其信息检索和长程推理的精确度可能会降低。

这些现实意味着，深思熟虑的上下文工程对于构建强大的 AI 智能体至关重要。

高效上下文的要素

鉴于大型语言模型受制于有限的注意力预算，好的上下文工程意味着找到尽可能小但信号最强的指令序列集合，从而最大限度地提高实现预期结果的可能性。在实践中，实施这一原则要比说起来容易得多。但在以下部分中，我们将结合上下文的不同组成部分，阐述这一指导原则在实践中的具体含义。

系统提示词（System prompts） 应该极其清晰，并使用简单、直接的语言，以“恰当的高度”呈现给 AI 智能体。所谓“恰当的高度”，是指介于两种常见失败模式之间的“金发姑娘区(Goldilocks zone)”。

一方面，我们看到一些工程师在提示词中硬编码了复杂、脆弱的逻辑，以试图引发精确的 AI 智能体行为。这种方法会随着时间的推移增加脆性，并增加了维护的复杂性。

另一方面，工程师有时会提供模糊、高层次的指导，未能给大型语言模型提供所需的具体输出信号，或者错误地假设了共享上下文。最佳高度在于取得平衡：既要足够具体以有效指导行为，又要足够灵活，为模型提供强大的启发式（heuristics）方法来指导行为。

一方面，我们看到脆弱的 if-else 硬编码提示词；另一方面，我们看到过于笼统或错误地假设共享上下文的提示词。

我们建议将提示词组织成不同的部分（例如 <background_information>、 <instructions>、 ## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题来划分这些部分。尽管随着模型能力的提升，提示词的具体格式可能变得不那么重要。

无论你如何组织系统提示词，都应该力求提供最少的信息，以完整地概述你期望的行为。（请注意，“最少”并不一定意味着“短”，你仍然需要预先给智能体足够的信息，以确保它遵守期望的行为。）最好首先使用可用的最佳模型测试一个最小的提示词，以了解它在你的任务上的表现。然后，根据在初始测试中发现的失败模式，添加清晰的指令和示例来改进性能。

工具允许 AI智能体与其环境进行交互，并在运行时获取新的额外上下文。由于工具定义了 AI 智能体与其信息/行动空间之间的契约，因此工具必须通过返回指令序列高效的信息并促进高效的 AI 智能体行为来提高效率，这一点至关重要。

在《为 AI 智能体编写工具——与 AI 智能体协同》一文中，我们讨论了如何构建大型语言模型易于理解且功能重叠最小的工具。与精心设计的代码库中的函数类似，工具应自包含、对错误具有鲁棒性，且其预期用途应极其明确。输入参数也应具有描述性、无歧义，并能发挥模型的固有优势。我们最常见的失败模式之一是工具集过于庞大，涵盖的功能过多，或导致在选择使用哪个工具时出现模糊的决策点。如果人类工程师无法明确表示在给定情况下应该使用哪个工具，那么不能指望 AI 智能体会做得更好。正如我们稍后将讨论的，为 AI 智能体制定最小可行工具集还有助于在长时间交互中更可靠地维护和精简上下文。

提供高质量的示例，也称为小样本提示词（few-shot prompting），是一种众所周知的最佳实践， Anthropic 持续强烈建议采用。然而，团队常常会将一长串边缘案例塞进提示词中，试图阐明大型语言模型在特定任务中应遵循的每一条规则。我们不推荐这种做法。相反，我们建议努力策划一组多样化、规范的示例，有效地展示 AI 智能体的预期行为。对于大型语言模型来说，示例就是“一图胜千言”的“图片”。

我们对上下文（系统提示词、工具、示例、消息历史记录等）各个组成部分的总体指导是：深思熟虑，并保持你的上下文信息丰富但紧凑。现在，让我们深入探讨在运行时动态检索上下文。

上下文检索和智能体搜索

在《构建高效 AI 智能体》一文中，我们强调了基于大型语言模型的工作流与 AI智能体之间的区别。自从我们撰写该文章以来，我们倾向于采用一个简单的 AI 智能体定义：大型语言模型在循环中自主使用工具。

我们与客户合作发现，这个领域正在趋向于这种简单的范式。随着底层模型能力的增强，AI 智能体的自主性也可以随之提升：更智能的模型能够让智能体独立地驾驭复杂的解决空间，并从错误中恢复。

目前，工程师们对AI 智能体上下文设计的思考方式正在发生转变。如今，许多 AI 原生应用都采用某种基于嵌入（embedding-based）的推理前检索，以便为 AI 智能体提供重要上下文进行推理。随着该领域向更具智能体性的方法过渡，我们越来越多地看到团队正在用“即时（just in time）”上下文策略来增强这些检索系统。

采用“即时”方法的 AI 智能体，不是预先处理所有相关数据，而是保留轻量级标识符（如文件路径、存储的查询、网络链接等），并利用这些引用通过工具在运行时动态地将数据加载到上下文中。Anthropic 的 AI智能体编程解决方案 Claude Code 使用这种方法，对大型数据库执行复杂的数据分析。模型可以编写有针对性的查询、存储结果，并利用 Bash 命令（如 Head 和 Tail）分析大量数据，而无需将完整的数据对象加载到上下文中。

这种方法模仿了人类的认知：我们通常不会记住全部信息语料库，而是引入外部组织和索引系统（如文件系统、收件箱和书签）来按需检索相关信息。

除了存储效率，这些引用的元数据提供了一种有效优化行为的机制，无论是明确提供还是直观的。对于在文件系统中操作的 AI 智能体来说，tests 文件夹中名为 test_utils.py 的文件的存在，与 src/core_logic/ 文件夹中具有相同名称的文件的含义不同。文件夹层次结构、命名约定和时间戳都提供了重要的信号，帮助人类和 AI 智能体理解如何以及何时利用信息。

让 AI 智能体自主导航和检索数据，也实现了渐进式披露（progressive disclosure）——换句话说，允许 AI 智能体通过探索逐步发现相关上下文。每次交互都会产生上下文，为下一次决策提供信息：文件大小暗示复杂性，命名约定暗示用途，时间戳可以作为相关性的代理。

AI 智能体可以逐层构建理解，仅在工作记忆中保留必要的信息，并利用笔记策略进行额外持久化。这种自我管理的上下文窗口使 AI 智能体专注于相关子集，而不是淹没在详尽但可能不相关的信息中。当然，这也是有取舍的：运行时探索比检索预计算数据要慢。不仅如此，还需要富有见地和深思熟虑的工程设计，以确保大型语言模型拥有正确的工具和启发式方法，来有效地导航其信息版图。如果没有适当的指导，AI 智能体可能会因误用工具、追逐死胡同或未能识别关键信息而浪费上下文。

在某些设置中，最有效的 AI 智能体可能会采用混合策略，即预先检索一些数据以提高速度，并酌情进行进一步的自主探索。“恰当”的自主性水平的决策边界取决于任务。

Claude Code 就是一个采用这种混合模型的 AI 智能体：CLAUDE.md 文件会预先简单地放到上下文中，而像 glob 和 grep 这样的底层工具则允许它即时导航环境和检索文件，有效避开了索引过时和复杂语法树的问题。

这种混合策略可能更适用于内容动态性较差的上下文，如法律或金融领域的工作。随着模型能力的提升，智能体设计将趋向于让智能模型智能地行动，并逐步减少人为策划。考虑到该领域快速发展，对于在 Claude 之上构建 AI 智能体的团队来说，“做最简单但有效的事”可能仍然是我们的最佳建议。

面向长周期任务的上下文工程

长周期任务要求 AI 智能体在行动序列中保持连贯性、上下文，以及目标导向的行为，而这些行动序列的指令序列数量超过了大型语言模型的上下文窗口限制。对于那些持续数十分钟甚至数小时的连续工作任务，如大型代码库迁移或全面的研究项目，AI 智能体需要专门的技术来解决上下文窗口大小的限制。

等待更大的上下文窗口似乎是一个显而易见的策略。但很可能在可预见的未来，所有大小的上下文窗口都将受到上下文污染和信息相关性问题的影响——至少在追求最强 AI 智能体性能的场景下是如此。

为了使 AI 智能体能够在更长的时间范围内有效工作，我们开发了一些直接解决这些上下文污染限制的技术：压缩（compaction）、结构化笔记（structured note-taking）和多智能体架构（multi-agent architectures）。

压缩

压缩（Compaction）是一种在对话接近上下文窗口限制时，对其内容进行总结，并重新开启一个包含该总结的新上下文窗口的做法。压缩通常是上下文工程中第一个用来提高长期连贯性的杠杆。其核心在于，压缩以高保真度提炼上下文窗口的内容，使 AI 智能体能够以最小的性能下降继续工作。

例如，在 Claude Code 中，我们通过将消息历史记录传递给模型来总结和压缩最关键的细节。模型会保留架构决策、未解决的错误和实现细节，同时丢弃冗余的工具输出或消息。然后，AI 智能体可以继续使用这个压缩后的上下文，以及最近访问过的五个文件。用户可以获得连续性，而无需担心上下文窗口的限制。

压缩的艺术在于如何选择保留和舍弃哪些内容，因为过度激进的压缩可能导致一些细微但关键的上下文丢失，而这些上下文的重要性可能只会在稍后才显现出来。对于实施压缩系统的工程师，我们建议仔细调整在复杂智能体跟踪上的提示词。首先，最大化召回率，以确保你的压缩提示词能够从跟踪中捕获所有相关信息，然后迭代改进精确度，以消除多余的内容。

一个显而易见的冗余内容示例是清除工具调用和结果——一旦工具在消息历史记录深处被调用过，为什么智能体还需要再次查看原始结果呢？最安全、最轻量级的压缩形式之一是工具结果清除，最近作为一项功能在 Claude 开发者平台上发布。

结构化笔记

结构化笔记，或称 AI 智能体记忆，是一种技术。在这种技术中，AI 智能体定期编写持久化到上下文窗口之外的内存中的笔记。这些笔记会在稍后被重新拉回上下文窗口。这种策略以最小的开销提供了持久化内存。就像 Claude Code 创建待办事项列表，或者你的自定义 AI 智能体维护一个 NOTES.md 文件一样，这种简单的模式允许 AI 智能体在复杂的任务中追踪进度，维护否则会在数十次工具调用中丢失的关键上下文和依赖关系。

Claude 玩宝可梦

（Claude playing Pokémon）这款游戏展示了记忆如何在非编程领域改变 AI 智能体的能力。AI智能体在数千个游戏步骤中保持精确的计数——跟踪目标，例如“过去 1234 步我一直在 Route 1 训练我的宝可梦，皮卡丘已经升级了 8级，目标是 10 级。”在没有任何关于记忆结构的提示下，它绘制了探索区域的地图，记住了已解锁的关键成就，并维护了战斗策略笔记，帮助它了解哪种攻击对不同对手最有效。

在上下文重置后，AI 智能体将读取自己的笔记，并继续进行长达数小时的训练序列或地下城探索。这种跨越总结步骤的连贯性，使得长周期策略成为可能，而仅仅在大型语言模型的上下文窗口中保存所有信息是无法实现的。

作为 Sonnet 4.5 发布的一部分， Anthropic 在 Claude 开发者平台上发布了记忆工具的公共 Beta 版本，它使得通过基于文件系统的方法在上下文窗口之外存储和查询信息变得更加容易。这允许 AI 智能体随着时间的推移建立知识库，在不同会话中维护项目状态，并参考之前的工作，而无需将所有内容都保存在上下文中。

子智能体架构

子智能体架构（Sub-agent architectures）提供了另一种解决上下文限制的方法。与其让一个 AI 智能体试图在一个整个项目中维护状态，不如让专门的子智能体处理具有清晰上下文窗口的特定任务。主智能体通过一个高层计划进行协调，而子智能体则执行深入的技术工作或使用工具寻找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多指令序列，但只返回其工作的凝练摘要（通常为 1000-2000 个指令序列）。

这种方法实现了清晰的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主导智能体则专注于综合和分析结果。这种模式，在《我们如何构建多智能体研究系统》一文中有所讨论，显示出在复杂研究任务上比单一智能体系统有显著改进。

这些方法之间选择取决于任务特点。例如：

• 压缩：适用于需要大量来回对话的任务，以保持对话流畅度。
• 笔记记录：在具有明确里程碑的迭代开发中表现出色。
• 多智能体架构：擅长处理复杂的研发和分析工作，并行探索能带来丰厚回报。

即使模型持续改进，保持跨扩展交互的连贯性挑战，仍将是构建更高效 AI 智能体的核心问题。

结论

上下文工程代表了我们构建大型语言模型方式的根本性转变。随着模型能力的增强，挑战不再仅仅是创造完美的提示词，而在于深思熟虑地策划每一步进入模型有限“注意力预算”的信息。无论你是为长周期任务实施压缩，设计指令序列高效的工具，还是让智能体即时探索其环境，指导原则都保持不变：找到最小且具有高信号的指令序列集合，以最大化实现你预期结果的可能性。

这些技术将随着模型的改进而不断发展。我们已经看到，更智能的模型需要的指令性工程更少，使得 AI 智能体能够以更高的自主性运行。但即使能力不断提升，将上下文视为宝贵而有限的资源，仍将是构建可靠、高效 AI 智能体的核心。