AI 智能体的有效上下文工程

在应用 AI 领域，经过几年对提示词工程（prompt engineering）的关注之后，一个新术语开始崭露头角：上下文工程（context engineering）。使用语言模型进行构建，正在从寻找提示词中的正确词汇和短语，转变为回答更广泛的问题：“什么样的上下文配置最有可能产生我们模型的预期行为？“

上下文指的是从大型语言模型（LLM）采样时包含的一组 token。需要工程化解决的问题是：在 LLM 固有约束下优化这些 token 的效用，以持续实现预期结果。有效地驾驭 LLM 通常需要以上下文思维——换句话说：考虑在任何给定时间 LLM 可用的整体状态，以及该状态可能产生的潜在行为。

在本文中，我们将探讨新兴的上下文工程艺术，并为构建可控、有效的智能体提供一个精炼的心智模型。

在 Anthropic，我们将上下文工程视为提示词工程的自然演进。提示词工程是指为实现最佳结果而编写和组织 LLM 指令的方法（参见我们的文档了解概述和有用的提示词工程策略）。上下文工程指的是在 LLM 推理过程中策划和维护最优 token 集（信息）的一系列策略，包括可能进入上下文的所有其他信息，而不仅仅是提示词。

在使用 LLM 进行工程的早期，提示词是 AI 工程工作的最大组成部分，因为除了日常聊天交互之外的大多数用例都需要针对一次性分类或文本生成任务优化的提示词。顾名思义，提示词工程的主要焦点是如何编写有效的提示词，特别是系统提示词。然而，随着我们转向工程化更强大的智能体，这些智能体可以在多轮推理和更长的时间范围内运行，我们需要管理整个上下文状态的策略（系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）。

在循环中运行的智能体会生成越来越多可能与下一轮推理相关的数据，这些信息必须循环精炼。上下文工程是从不断演变的可能信息宇宙中，策划将进入有限上下文窗口内容的艺术和科学。

提示词工程 vs. 上下文工程

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

为什么上下文工程对构建强大的智能体很重要

尽管速度快且能够管理越来越大量的数据，但我们观察到 LLM 像人类一样，在某个点会失去焦点或产生困惑。针对大海捞针式基准测试的研究发现了上下文腐化的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。

虽然一些模型表现出比其他模型更温和的退化，但这种特性在所有模型中都会出现。因此，上下文必须被视为一种有限资源，边际收益递减。就像人类具有有限的工作记忆容量一样，LLM 在解析大量上下文时有一个”注意力预算”。引入的每个新 token 都会在一定程度上耗尽这个预算，增加了仔细策划 LLM 可用 token 的必要性。

这种注意力稀缺性源于 LLM 的架构约束。LLM 基于 transformer 架构，该架构使每个 token 能够关注整个上下文中的每个其他 token。这导致 n 个 token 之间产生 n² 个成对关系。

随着上下文长度的增加，模型捕获这些成对关系的能力被拉伸得很薄，从而在上下文大小和注意力焦点之间产生自然张力。此外，模型从训练数据分布中发展其注意力模式，在这些分布中，较短的序列通常比较长的序列更常见。这意味着模型对上下文范围依赖关系的经验较少，专用参数也较少。

像位置编码插值这样的技术允许模型通过使其适应最初训练的较小上下文来处理更长的序列，尽管在 token 位置理解方面有一些退化。这些因素创造了一个性能梯度而不是硬性截止：模型在更长的上下文中仍然高度能干，但与在较短上下文上的性能相比，在信息检索和长程推理方面可能显示出精度降低。

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

有效上下文的解剖

鉴于 LLM 受到有限注意力预算的约束，良好的上下文工程意味着找到最小可能的高信号 token 集合，以最大化某些预期结果的可能性。实施这一实践说起来容易做起来难，但在下一节中，我们概述了这一指导原则在上下文不同组成部分的实践中的含义。

系统提示词应该非常清晰，使用简单、直接的语言，以正确的高度为智能体呈现想法。正确的高度是介于两种常见失败模式之间的黄金地带。在一个极端，我们看到工程师在他们的提示词中硬编码复杂、脆弱的逻辑以引出确切的智能体行为。这种方法会产生脆弱性，并随着时间的推移增加维护复杂性。在另一个极端，工程师有时提供模糊的高层次指导，未能为 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 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种方法反映了人类认知：我们通常不会记住整个信息语料库，而是引入外部组织和索引系统，如文件系统、收件箱和书签，以按需检索相关信息。

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

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

当然，这是一种权衡：运行时探索比检索预计算的数据要慢。不仅如此，还需要有主见和深思熟虑的工程，以确保 LLM 拥有正确的工具和启发式方法来有效地导航其信息景观。如果没有适当的指导，智能体可能会通过误用工具、追逐死胡同或未能识别关键信息而浪费上下文。

在某些情况下，最有效的智能体可能会采用混合策略，预先检索一些数据以提高速度，并根据其判断进行进一步的自主探索。“正确”自主水平的决策边界取决于任务。Claude Code 是采用这种混合模型的智能体：CLAUDE.md 文件被天真地预先放入上下文中，而像 glob 和 grep 这样的原语允许它导航其环境并即时检索文件，有效地绕过陈旧索引和复杂语法树的问题。

混合策略可能更适合内容不太动态的上下文，例如法律或金融工作。随着模型能力的提高，智能体设计将趋向于让智能模型智能地行动，人工策划逐渐减少。鉴于该领域的快速进展，“做最简单有效的事情”可能仍然是我们对在 Claude 之上构建智能体的团队的最佳建议。

长时域任务的上下文工程

长时域任务要求智能体在 token 计数超过 LLM 上下文窗口的行动序列中保持连贯性、上下文和目标导向行为。对于跨越数十分钟到多小时连续工作的任务，例如大型代码库迁移或综合研究项目，智能体需要专门的技术来解决上下文窗口大小限制。

等待更大的上下文窗口似乎是一种明显的策略。但在可预见的未来，所有大小的上下文窗口可能都会受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下。为了使智能体能够在扩展的时间范围内有效工作，我们开发了一些直接解决这些上下文污染约束的技术：压缩、结构化记笔记和多智能体架构。

压缩

压缩是在对话接近上下文窗口限制时，总结其内容并使用摘要重新启动新上下文窗口的实践。压缩通常是上下文工程中推动更好长期连贯性的第一个杠杆。在其核心，压缩以高保真方式提取上下文窗口的内容，使智能体能够以最小的性能退化继续。

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

压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能会导致丢失微妙但关键的上下文，其重要性只有在以后才会变得明显。对于实现压缩系统的工程师，我们建议在复杂的智能体跟踪上仔细调整您的提示词。首先最大化召回率以确保您的压缩提示词从跟踪中捕获每一条相关信息，然后迭代以通过消除多余内容来提高精度。

低垂果实的多余内容示例是清除工具调用和结果——一旦在消息历史深处调用了工具，为什么智能体需要再次看到原始结果？最安全的轻触式压缩形式之一是工具结果清除，最近作为 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 开发者平台上使用上下文工程，并通过我们的内存和上下文管理 cookbook 访问有用的提示和最佳实践。

致谢

由 Anthropic 应用 AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 做出了贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的支持。