本文由 Anthropic 应用 AI 团队撰写：Effective context engineering for AI agents。其中探讨了从提示工程 (prompt engineering) 到上下文工程 (context engineering) 的演变，并将其定位为构建高效、可控 AI 智能体的关键。文章指出，随着模型能力的增强，核心挑战已从编写完美的提示语转变为精心管理和优化输入给模型的整个信息集（即上下文）。

关键细节

上下文的基本构成与优化

  • 系统提示 (System Prompts)：应使用清晰、直接的语言。避免过于具体、僵化的逻辑，也要避免过于模糊、宽泛的指导。建议使用 XML 标签或 Markdown 标题来组织提示结构，使其清晰。
  • 工具 (Tools)：工具的设计应追求 token 效率和功能独立性，避免功能重叠导致智能体混淆。一个常见的失败模式是工具集过于臃肿。
  • 示例 (Examples)：提供少量（few-shot）但多样化、有代表性的示例，比罗列大量边缘案例效果更好。

动态上下文管理策略

  • 即时上下文检索 (Just in time context)：智能体并非预先加载所有数据，而是在运行时使用工具（如读取文件、查询数据库）动态地将所需信息载入上下文。这种方式模拟了人类按需检索信息的习惯，实现了信息的“渐进式披露” (progressive disclosure)。
  • 混合策略 (Hybrid Strategy)：在某些场景下，可以结合预先加载部分数据和智能体自主探索，以平衡速度和灵活性。

应对长时程任务的专门技术

对于超出单个上下文窗口容量的长期任务（如大型代码迁移、全面研究项目），可以采用以下技术：

  1. 压缩 (Compaction)：当对话接近上下文窗口极限时，让模型对现有内容进行总结和压缩，然后带着这个摘要开启一个新的上下文窗口。最简单的压缩形式是清除历史记录中原始的工具调用结果。
  2. 结构化笔记 (Structured note-taking)：让智能体将关键信息、待办事项或中间结论记录到上下文窗口之外的持久化存储中（如一个 NOTES.md 文件），并在需要时重新读入。这相当于为智能体提供了外部记忆。
  3. 子智能体架构 (Sub-agent architectures)：将一个复杂任务分解，由一个主智能体进行高层协调，多个专职的子智能体处理具体的子任务。每个子智能体在自己的独立上下文中完成工作，然后将精炼后的结果返回给主智能体。

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

发布于 2025 年 9 月 29 日

上下文是 AI 智能体的一个关键但有限的资源。在这篇文章中，我们探讨了有效策划和管理为它们提供支持的上下文的策略。

在应用 AI 领域，提示工程 (prompt engineering) 几年来一直是关注的焦点，之后一个新术语开始崭露头角：上下文工程 (context engineering)。使用语言模型进行构建，正变得越来越不局限于为提示找到正确的词语和短语，而是更多地回答一个更广泛的问题：“什么样的上下文配置最有可能产生我们模型的期望行为？”

上下文 (Context) 指的是从大型语言模型 (LLM) 采样时包含的 token 集合。眼前的工程 (engineering) 问题是，在 LLM 的固有约束下优化这些 token 的效用，以便持续实现期望的结果。有效地驾驭 LLM 通常需要情境化思考 (thinking in context)——换句话说：考虑 LLM 在任何给定时间可用的整体状态，以及该状态可能产生的潜在行为。

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

上下文工程 vs. 提示工程

在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程指的是为了获得最佳结果而编写和组织 LLM 指令的方法（参见我们的文档以获取概述和有用的提示工程策略）。上下文工程 指的是在 LLM 推理期间策划和维护最佳 token（信息）集合的一套策略，包括所有可能出现在提示之外的其他信息。

在 LLM 工程的早期阶段，提示是 AI 工程工作中最大的组成部分，因为日常聊天互动之外的大多数用例都需要针对单次分类或文本生成任务优化的提示。正如该术语所暗示的，提示工程的主要焦点是如何编写有效的提示，特别是系统提示。然而，随着我们转向工程设计能够在多轮推理和更长时间范围内运行的、能力更强的智能体，我们需要策略来管理整个上下文状态（系统指令、工具、模型上下文协议 (MCP)、外部数据、消息历史等）。

一个循环运行的智能体会产生越来越多的数据，这些数据可能与下一轮推理相关，而这些信息必须周期性地进行提炼。上下文工程就是一门艺术和科学，它要从不断演变的信息宇宙中，精心挑选将进入有限上下文窗口的内容。

xxx 与编写提示这一离散任务相比，上下文工程是迭代的，每次我们决定向模型传递什么内容时，都会发生策划阶段。

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

尽管 LLM 速度很快，并且能够管理越来越大的数据量，但我们观察到，LLM 和人类一样，会在某个点上失去焦点或感到困惑。关于“大海捞针”式基准测试的研究揭示了上下文腐烂 (context rot) 的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。

虽然某些模型的性能下降比其他模型更平缓，但这一特性在所有模型中都会出现。因此，上下文必须被视为一种边际收益递减的有限资源。就像人类拥有有限的工作记忆容量一样，LLM 在解析大量上下文时也有一个“注意力预算”可供使用。引入的每一个新 token 都会消耗一定量的预算，这使得我们越来越需要仔细策划可供 LLM 使用的 token。

这种注意力稀缺源于 LLM 的架构限制。LLM 基于 Transformer 架构，该架构使每个 token 都能关注 (attend to) 整个上下文中的所有其他 token。这导致 n 个 token 之间存在 n² 的成对关系。

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

像位置编码插值这样的技术允许模型处理更长的序列，方法是使其适应最初训练的较小上下文，尽管在 token 位置理解上会有所下降。这些因素造成了性能的梯度下降，而不是硬性的悬崖式下跌：模型在较长上下文中仍然保持着高能力，但与在较短上下文中的表现相比，在信息检索和长程推理方面的精确度可能会降低。

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

有效上下文的剖析

鉴于 LLM 受到有限注意力预算的约束，良好的上下文工程意味着找到最小、可行的高信噪比 token 集合，以最大化实现某种期望结果的可能性。实现这一实践远非说起来那么容易，但在下一节中，我们将概述这一指导原则在上下文的不同组成部分中的实践意义。

系统提示 应该极其清晰，使用简单、直接的语言，在*合适的“高度”*上为智能体呈现思想。这个合适的高度是介于两种常见失败模式之间的“金发姑娘区”(Goldilocks zone)。在一个极端，我们看到工程师在提示中硬编码复杂、脆弱的逻辑，以引发精确的智能体行为。这种方法会随着时间的推移产生脆弱性并增加维护复杂性。在另一个极端，工程师有时会提供模糊、高层次的指导，无法为 LLM 提供期望输出的具体信号，或者错误地假设了共享上下文。最佳的高度是在两者之间取得平衡：足够具体以有效指导行为，又足够灵活以为模型提供强大的启发式方法来指导行为。

xxx 在光谱的一端，我们看到的是脆弱的 if-else 硬编码提示，而在另一端，我们看到的是过于宽泛或错误假设共享上下文的提示。

我们建议将提示组织成不同的部分（例如 <background_information>、<instructions>、## 工具指南、## 输出描述 等），并使用 XML 标签或 Markdown 标题等技术来划分这些部分，尽管随着模型能力越来越强，提示的确切格式可能正变得越来越不重要。

无论您决定如何构建系统提示，都应该努力使用最少的信息集来完整概述您的预期行为。（请注意，最少并不一定意味着简短；您仍然需要在前期为智能体提供足够的信息，以确保它遵守期望的行为。）最好的方法是，首先使用可用的最佳模型测试一个最小化的提示，看看它在您的任务上表现如何，然后根据初始测试中发现的失败模式添加清晰的指令和示例来提高性能。

工具 允许智能体与其环境交互，并在工作时引入新的、额外的上下文。因为工具定义了智能体与其信息/行动空间之间的契约，所以工具促进效率是极其重要的，这既包括返回 token 高效的信息，也包括鼓励高效的智能体行为。

在为 AI 智能体编写工具——使用 AI 智能体一文中，我们讨论了构建易于 LLM 理解且功能重叠最小的工具。与设计良好的代码库中的函数类似，工具应该是自包含的、对错误具有鲁棒性，并且其预期用途应极其清晰。输入参数同样应该是描述性的、无歧义的，并能发挥模型的固有优势。

我们看到的最常见的失败模式之一是，工具集过于臃肿，覆盖了太多功能，或者导致在选择使用哪个工具时出现模棱两可的决策点。如果人类工程师都不能明确地说出在给定情况下应该使用哪个工具，那么就不能指望 AI 智能体能做得更好。正如我们稍后将讨论的，为智能体策划一个最小可行的工具集，也可以在长时间的交互中实现更可靠的上下文维护和修剪。

提供示例，即所谓的“少样本提示”(few-shot prompting)，是一个众所周知的最佳实践，我们继续强烈建议这样做。然而，团队常常会在提示中塞入一长串的边缘案例，试图阐明 LLM 在特定任务中应遵循的每一种可能规则。我们不推荐这样做。相反，我们建议努力策划一组多样化的、规范的示例，以有效地描绘智能体的预期行为。对于 LLM 来说，示例就是“价值千言的图片”。

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

上下文检索与智能体搜索

在构建有效的 AI 智能体一文中，我们强调了基于 LLM 的工作流与智能体之间的差异。自撰写那篇文章以来，我们逐渐倾向于一个简单的定义：智能体就是 LLM 在循环中自主使用工具。

通过与客户的合作，我们看到该领域正向这个简单的范式靠拢。随着底层模型变得更加强大，智能体的自主性水平可以扩展：更智能的模型允许智能体独立地在微妙的问题空间中导航并从错误中恢复。

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

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

除了存储效率之外，这些引用的元数据还提供了一种有效改进（refine）行为的机制，无论是显式提供还是直观感知的。对于一个在文件系统中操作的智能体来说，tests 文件夹中名为 test_utils.py 的文件，其含义与位于 src/core_logic/ 文件夹下的同名文件是不同的。文件夹层次结构、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何以及何时利用信息。

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

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

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

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

针对长周期任务的上下文工程

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

等待更大的上下文窗口似乎是一个显而易见的策略。但很可能在可预见的未来，所有大小的上下文窗口都会受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下是如此。为了使智能体能够在更长的时间范围内有效工作，我们开发了一些直接解决这些上下文污染限制的技术：压缩 (compaction)、结构化笔记 (structured note-taking) 和多智能体架构 (multi-agent architectures)。

压缩 (Compaction)

压缩 (Compaction) 是一种做法，即当对话接近上下文窗口限制时，对其内容进行总结，并使用该摘要重新启动一个新的上下文窗口。压缩通常是上下文工程中推动更好长期连贯性的第一个杠杆。其核心是，压缩以高保真度的方式提炼上下文窗口的内容，使智能体能够以最小的性能下降继续工作。

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

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

一个唾手可得的“多余内容”示例是清除工具调用和结果——一旦一个工具在消息历史的深处被调用过，智能体为什么还需要再次看到原始结果呢？最安全、最轻量级的压缩形式之一是工具结果清除，这是最近在 Claude 开发者平台上推出的一个功能。

结构化笔记

结构化笔记 (Structured note-taking)，或称智能体记忆 (agentic memory)，是一种技术，智能体定期将在上下文窗口之外的持久化内存中写入笔记。这些笔记会在稍后的时间被拉回上下文窗口。

这种策略以最小的开销提供了持久性记忆。就像 Claude Code 创建一个待办事项列表，或者您的自定义智能体维护一个 NOTES.md 文件一样，这种简单的模式允许智能体跟踪复杂任务的进展，保持关键的上下文和依赖关系，否则这些信息会在几十次工具调用中丢失。

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

在上下文重置后，智能体会阅读自己的笔记，并继续长达数小时的训练序列或地牢探索。这种跨越总结步骤的连贯性，使得长周期策略成为可能，而如果仅将所有信息保留在 LLM 的上下文窗口中，这是不可能实现的。

作为我们 Sonnet 4.5 发布 的一部分，我们在 Claude 开发者平台上发布了 一个记忆工具 的公开测试版，它使通过基于文件的系统在上下文窗口之外存储和查阅信息变得更加容易。这允许智能体随着时间的推移建立知识库，跨会话维护项目状态，并引用以前的工作，而无需将所有内容都保留在上下文中。

子智能体架构

子智能体架构 (Sub-agent architectures) 提供了另一种绕过上下文限制的方法。不是由一个智能体试图在整个项目中维护状态，而是由专门的子智能体使用干净的上下文窗口来处理集中的任务。主智能体通过一个高层次的计划进行协调，而子智能体则执行深入的技术工作或使用工具查找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多的 token，但只返回其工作的浓缩、提炼后的摘要（通常为 1,000-2,000 token）。

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

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

  • 压缩 (Compaction) 适用于需要大量来回交互的任务，以保持对话流程；
  • 笔记 (Note-taking) 擅长于具有明确里程碑的迭代开发；
  • 多智能体架构 (Multi-agent architectures) 处理复杂的研究和分析，此时并行探索会带来好处。

即使模型不断改进，在扩展交互中保持连贯性这一挑战，仍将是构建更有效智能体的核心。

结论

上下文工程代表了我们使用 LLM 构建方式的根本转变。随着模型变得更加强大，挑战不仅仅是精心制作完美的提示——而是在每一步都深思熟虑地策划哪些信息进入模型有限的注意力预算。无论您是为长周期任务实现压缩、设计 token 高效的工具，还是使智能体能够即时探索其环境，指导原则始终如一：找到最大化期望结果可能性的、最小的高信噪比 token 集合。

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

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