随着 AI Agent 从工具走向自主体，提示工程已无法满足复杂任务的需求。上下文工程作为新一代构建范式，正在成为产品经理与工程师必须掌握的核心能力。本文系统解析上下文工程的关键组成、技术演进与设计原则，帮助你理解如何在有限注意力预算下，构建更高效、更可控的智能体。

在经过几年对应用AI中提示工程的关注后，一个新术语应运而生：上下文工程。利用语言模型构建正变得越来越不侧重于为提示找到正确的词语和短语，而是更多地关注回答一个更广泛的问题：“哪种上下文配置最有可能促使我们的模型产生期望的行为？”

上下文指的是在从大型语言模型（LLM）进行采样时包含的一组标记。当前面临的工程问题是如何在LLM的固有约束下优化这些标记的效用，以持续获得期望的结果。有效地驾驭LLM通常需要从上下文的角度进行思考——换句话说：在任何给定时间考虑LLM可用的整体状态以及该状态可能产生的潜在行为。

在这篇文章中，我们将探讨新兴的上下文工程艺术，并提供一个改进的思维模型，用于构建可控、高效的代理。

上下文工程与提示工程

在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程指的是为达到最佳结果而编写和组织 LLM 指令的方法（有关概述和有用的提示工程策略，请参阅我们的文档）。上下文工程指的是在 LLM 推理过程中，用于策展和维护最佳标记集（信息）的一套策略，包括可能出现在提示之外的所有其他信息。

在早期进行大型语言模型工程时，提示词工程是人工智能工程工作中的最大组成部分，因为日常聊天互动之外的大多数用例都需要针对单次分类或文本生成任务进行优化的提示。正如其名称所示，提示词工程的主要重点是如何编写有效的提示，尤其是系统提示。然而，随着我们朝着构建能够进行多轮推理和更长时期的更强大的智能体方向发展，我们需要有管理整个上下文状态（系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）的策略。

代理在循环中运行，生成越来越多可能与下一轮推理相关的数据，并且这些信息必须周期性地得到完善。上下文工程是从不断演变的可能信息宇宙中精心策划将进入有限上下文窗口的内容的艺术和科学。

与编写提示这个离散的任务不同，上下文工程是迭代的，并且每次我们决定将什么传递给模型时都会进行策划。

为什么上下文工程对于构建能力型智能体很重要

尽管大型语言模型（LLM）速度很快，并且能够处理越来越大的数据量，但我们观察到，与人类一样，它们在某一点上也会失去焦点或感到困惑。

关于“大海捞针”式基准测试的研究揭示了“上下文腐烂”的概念：随着上下文窗口中token数量的增加，模型从该上下文中准确回忆信息的能力会下降。

尽管一些模型比其他模型表现出更平缓的衰减，但这种特性在所有模型中都普遍存在。因此，上下文必须被视为一种有限的资源，其边际收益递减。就像人类拥有有限的工作记忆容量一样，大型语言模型也有一个“注意力预算”，它们在解析大量上下文时会动用这个预算。每个新引入的 token 都会消耗一定量的预算，这增加了仔细管理 LLM 可用 token 的必要性。

这种注意力稀缺源于大型语言模型的架构限制。大型语言模型基于 Transformer 架构，该架构使得每个 token 都可以关注整个上下文中的其他所有 token。这导致对于 n 个 token 会产生 n² 对关系。

随着其上下文长度的增加，模型捕捉这些成对关系的能力会变得稀疏，从而在上下文大小和注意力焦点之间产生天然的张力。此外，模型会从训练数据分布中发展其注意力模式，而这些分布中较短序列通常比长序列更常见。这意味着模型在处理上下文范围内的依赖关系方面经验较少，并且专门的参数也较少。

位置编码插值等技术允许模型通过将其适应于最初训练时较小的上下文来处理更长的序列，尽管在令牌位置理解方面会有所下降。这些因素造成了性能的渐变而非硬性断崖：模型在较长上下文上仍然非常强大，但与在较短上下文上的性能相比，信息检索和长距离推理的精度可能会降低。

这些现实情况意味着，周密的上下文工程对于构建有能力的代理至关重要。

有效上下文的解剖

鉴于大型语言模型受限于有限的注意力预算，良好的上下文工程意味着找到尽可能小的、高信号的标记集，以最大化某些期望结果的可能性。实践这一原则比说起来要困难得多，但在接下来的部分，我们将概述这一指导原则在上下文的不同组成部分中的实际含义。

系统提示应极其「清晰」，并使用「简单」、「直接」的语言，以适合智能体的“高度”来呈现想法。“高度”是指在两种常见故障模式之间的“黄金地带”。一种极端情况是，工程师在提示中硬编码复杂、脆弱的逻辑，以引发精确的智能体行为。这种方法会造成脆弱性，并随着时间的推移增加维护的复杂性。另一种极端情况是，工程师有时提供模糊、高层次的指导，未能为 LLM 提供具体的可期望输出信号，或者错误地假设了共享的上下文。最佳“高度”在于取得平衡：既要足够具体以有效指导行为，又要足够灵活，为模型提供指导行为的强大启发式方法。

在光谱的一端，我们看到僵化的 if-else 硬编码提示，而在另一端，我们看到过于笼统或错误地假设共享上下文的提示。

我们建议将提示组织成不同的部分（例如<background_information>、<instructions>、

## 工具指南、

## 输出描述等），并使用 XML 标记或 Markdown 标题等技术来区分这些部分，尽管随着模型能力越来越强，提示的确切格式可能变得越来越不重要。

无论您如何决定构建您的系统提示，您都应力求提供最少但能完整概述您期望行为的信息集。（请注意，最少不一定意味着简短；您仍然需要预先向代理提供足够的信息，以确保其遵循期望的行为。）

最好是先使用可用的最佳模型测试一个最小化的提示，以查看其在您的任务上的表现，然后根据初始测试中发现的失败模式添加清晰的说明和示例来改进性能。

工具允许代理与其环境进行交互，并在工作时引入新的、附加的上下文。由于工具定义了代理与其信息/操作空间之间的契约，因此工具的效率至关重要，这既体现在返回标记效率高的信息，也体现在鼓励高效的代理行为。

在为人工智能代理构建对大型语言模型（LLM）有良好理解且功能重叠最小的工具时，我们进行了讨论。与精心设计的代码库的功能类似，工具应该是独立的、容错的，并且对其预期用途极其清晰。输入参数也应该是描述性的、无歧义的，并发挥模型的固有优势。

我们遇到的最常见的故障模式之一是工具集臃肿，它们涵盖的功能过多，或者导致关于使用哪种工具的决策点不明确。如果人类工程师无法明确说明在特定情况下应使用哪种工具，那么对人工智能代理也不应有更高的期望。正如我们稍后将讨论的，为代理精选「最小可行工具集」也可以带来更可靠的维护以及在长时交互中更好地修剪上下文。

提供示例，也称为少样本提示，是一种众所周知的最佳实践，我们仍然强烈建议。然而，团队经常在提示中塞入一长串边缘案例，试图阐述 LLM 在特定任务中应遵循的每条可能规则。我们不建议这样做。相反，我们建议努力精心挑选一组多样化、规范化的示例，以有效地展示代理的预期行为。对于 LLM 来说，示例就是“一图胜千言”。

我们在上下文（系统提示、工具、示例、消息历史记录等）的各个组件中的总体指导原则是：周到并保持上下文信息丰富但简洁。现在，让我们深入探讨运行时动态检索上下文。

上下文检索与智能体搜索

在构建有效的 AI 代理一文中，我们重点介绍了基于 LLM 的工作流程和代理之间的区别。自从我们写了那篇文章以来，我们倾向于对代理给出一个简单的定义：LLM 在循环中自主使用工具。

与我们的客户合作，我们看到该领域正在趋同于这一简单范式。随着底层模型功能越来越强大，代理程序的自主性水平可以得到提升：更智能的模型允许代理程序独立地驾驭复杂的难题空间并从错误中恢复。

我们现在看到工程师在设计代理上下文方面思维方式的转变。如今，许多原生人工智能应用程序在推理前使用某种形式的基于嵌入的检索，为代理提供需要推理的重要上下文。随着该领域向更具代理性的方法过渡，我们越来越多地看到团队使用“即时”上下文策略来增强这些检索系统。

与其预先处理所有相关数据，不如采用“即时”方法构建的代理维护轻量级标识符（文件路径、存储的查询、网络链接等），并使用这些引用在运行时通过工具动态地将数据加载到上下文中。Anthropic 的代理编码解决方案 Claude Code 采用这种方法对大型数据库进行复杂的数据分析。该模型可以编写有针对性的查询，存储结果，并利用 head 和 tail 等 Bash 命令来分析大量数据，而无需将完整的 数据对象加载到上下文中。这种方法模仿了人类的认知：我们通常不会记住整个信息库，而是引入外部组织和索引系统，如文件系统、收件箱和书签，以按需检索相关信息。

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

让代理能够自主导航和检索数据，也实现了渐进式披露——换句话说，允许代理通过探索逐步发现相关上下文。每次交互都会产生有助于下一个决策的上下文：文件大小表明复杂性；命名约定暗示了目的；时间戳可以作为相关性的代理。代理可以一层一层地构建理解，只在工作记忆中保留必要的信息，并利用笔记策略来获得额外的持久性。这种自管理的上下文窗口使代理能够专注于相关子集，而不是淹没在详尽但可能无关紧要的信息中。

当然，有利有弊：运行时探索比检索预先计算好的数据要慢。不仅如此，还需要有主见且深思熟虑的工程设计，以确保 LLM 拥有合适的工具和启发式方法来有效导航其信息环境。如果没有适当的指导，代理可能会因为误用工具、陷入死胡同或未能识别关键信息而浪费上下文。

在某些情况下，最有效的代理可能会采用混合策略，预先检索部分数据以提高速度，并在其自行决定时进行进一步的自主探索。‘正确’自主级别决策的边界取决于任务。Claude Code 是一个采用这种混合模型的代理：CLAUDE.md 文件被朴素地直接放入上下文，而 glob 和 grep 等原语则允许它导航其环境并即时检索文件，从而有效地绕过了过时索引和复杂语法树的问题。

混合策略可能更适合内容不太动态的场景，例如法律或金融工作。随着模型能力的提高，代理设计将趋向于让智能模型智能地运作，人类的策划将逐渐减少。鉴于该领域的快速发展，“做最有效的事情”很可能会继续是我们为在 Claude 之上构建代理的团队提供的最佳建议。

面向长时域任务的上下文工程

长时域任务需要代理在超出 LLM 上下文窗口的动作序列中保持连贯性、上下文和目标导向的行为。对于需要持续工作数十小时到数小时的任务，例如大型代码库迁移或全面的研究项目，代理需要专门的技术来解决上下文窗口大小的限制。

等待更大的上下文窗口似乎是一种显而易见的策略。但很可能在可预见的未来，无论大小的上下文窗口都会受到上下文污染和信息相关性问题的困扰——至少在需要最强代理性能的情况下是这样。为了使代理能够在更长的时间跨度内有效工作，我们开发了几种直接解决这些上下文污染限制的技术：压缩、结构化笔记和多代理架构。

压缩「Compaction」

压缩是指将接近上下文窗口限制的对话进行内容概括，然后用该摘要重新开始一个新的上下文窗口。压缩通常作为上下文工程的首要手段，以提高长期连贯性。其核心在于以高保真方式提炼上下文窗口的内容，使代理能够以极小的性能下降继续进行。

结构化笔记「Structurednote-taking」

结构化笔记，或称为代理记忆，是一种代理会定期将笔记写到上下文窗口之外的持久化内存中的技术。这些笔记稍后会被拉回到上下文窗口中。

该策略以最小的开销提供了持久内存。就像 Claude Code 创建待办事项列表一样，或者您的自定义代理维护 NOTES.md 文件一样，这种简单的模式允许代理跟踪复杂任务的进度，维护关键的上下文和依赖项，否则这些上下文和依赖项将在数十次工具调用中丢失。

Claude 玩《宝可梦》展示了记忆如何在非编码领域改变代理能力。该代理在成千上万的游戏步骤中保持精确的统计——跟踪诸如“在过去 1,234 步中，我一直在 1 号道路训练我的宝可梦，皮卡丘已获得 8 级，目标是 10 级”之类的目标。在没有任何关于记忆结构的提示下，它会生成已探索区域的地图，记住它已解锁的关键成就，并维护战斗策略的战略笔记，以帮助它学习哪些攻击对不同对手最有效。

在上下文重置后，代理会读取自己的笔记并继续进行多小时的训练序列或地下城探索。跨越总结步骤的这种连贯性使得能够实现单独将所有信息保存在 LLM 的上下文窗口中不可能实现的远期策略。

作为我们 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上发布了一个内存工具的公开测试版，通过一个基于文件的系统，可以更轻松地存储和查阅上下文窗口之外的信息。这使得代理能够随着时间的推移建立知识库，在会话之间保持项目状态，并在不将所有内容都保留在上下文中的情况下引用先前的工作。

子代理架构「Sub-agentarchitectures」

子代理架构提供了绕过上下文限制的另一种方法。与其让一个代理尝试维护整个项目的状态，不如让专门的子代理处理具有清晰上下文窗口的聚焦任务。主代理会根据高层计划进行协调，而子代理则执行深入的技术工作或使用工具查找相关信息。每个子代理可能会广泛探索，使用数万甚至更多的 token，但只会返回其工作的精炼、浓缩摘要（通常为 1,000-2,000 token）。

这种方法实现了关注点的清晰分离——详细的搜索上下文保留在子代理中，而主代理则专注于合成和分析结果。这一模式在“我们如何构建多代理研究系统”中有讨论，与单代理系统相比，在复杂的研究任务上有了显著的改进。

这些方法的选择取决于任务的特性。例如：

• 压缩(上下文)为需要大量往返的任务维护了对话流程；
• 笔记对于具有明确里程碑的迭代开发非常有用；
• 多智能体架构能够处理复杂的研发和分析任务，因为并行探索可以带来丰厚的回报。

即使模型不断改进，在扩展交互中保持一致性的挑战仍将是构建更有效代理的核心。

结论

上下文工程代表了我们如何构建 LLM 的基本转变。随着模型能力的增强，挑战不再仅仅是构建完美的提示，而是深思熟虑地在每一步中精选进入模型有限注意力预算的信息。无论您是为长时任务实现压缩，设计令牌效率高的工具，还是使代理能够即时探索其环境，指导原则都保持不变：找到最小的高信号令牌集，以最大化您期望结果的可能性。

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

立即在 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 的支持