摘要
1) 一句话总结
上下文工程是提示词工程的自然演进，旨在通过动态管理和精简输入给大语言模型的高质量 token 集合，克服模型的“注意力预算”限制，从而构建高效且能够在长周期任务中可靠运行的 AI 智能体。
2) 核心要点
- 核心理念转变：AI 开发正从单纯优化提示词（提示词工程）转向管理整个上下文状态（上下文工程），目标是寻找尽可能小且高信号的 token 集合。
- 注意力预算与上下文衰退：受 Transformer 架构（n² 成对关系）限制，随着 token 数量增加，模型会出现“上下文衰退”，导致信息检索和长程推理精度下降，因此上下文应被视为有限资源。
- 系统提示词设计：提示词应处于“金发姑娘区”（既不硬编码复杂脆弱的逻辑，也不提供模糊指导），建议使用 XML 或 Markdown 划分结构，并从最小可行信息集开始测试和迭代。
- 工具与示例优化：工具必须自包含、功能重叠最小且 token 效率高，避免提供臃肿的工具集；少样本提示（Few-shot）应提供多样化且典型的示例，而非堆砌所有边缘情况。
- 即时上下文检索（Just-in-time）：现代智能体（如 Claude Code）倾向于在运行时通过工具（如 Bash 命令）动态探索和加载数据，实现渐进式信息披露，而非预先将所有数据加载到上下文中。
- 长周期任务策略 - 上下文压缩：通过提取和总结接近窗口限制的对话，并清除冗余内容（如深层历史中的工具调用结果），以最小的性能损失重启上下文窗口。
- 长周期任务策略 - 结构化笔记：赋予智能体外部记忆能力（如维护
NOTES.md文件），使其能够在数十次工具调用或上下文重置后，依然能跟踪复杂任务进度和关键依赖。 - 长周期任务策略 - 子智能体架构：主智能体负责高层规划，专门的子智能体在干净的上下文中执行深度探索，并仅向主智能体返回浓缩的摘要（通常 1000-2000 个 token）。
3) 风险与不足（原文明确提及）
- 提示词脆弱性风险：在系统提示词中硬编码复杂的逻辑会产生脆弱性，并随着时间推移增加维护的复杂性。
- 工具集臃肿风险：涵盖过多功能或重叠的工具集会导致智能体在决策时模棱两可；如果人类工程师都无法明确该用哪个工具，AI 智能体也无法做好。
- 运行时探索的性能折衷：让智能体在运行时自主探索数据比直接检索预先计算的数据速度更慢。
- 自主探索失控风险：如果没有适当的工程指导和启发式方法，智能体可能会因为滥用工具、陷入死胡同或未能识别关键信息而浪费宝贵的上下文空间。
- 过度压缩风险：在进行上下文压缩时，过于激进的压缩策略可能会导致丢失微妙但关键的上下文信息。
正文
在提示词工程（prompt engineering）成为应用 AI 领域关注焦点的几年后，一个新术语开始崭露头角：上下文工程（context engineering）。使用语言模型进行开发，已经不再仅仅是为提示词寻找合适的字眼，而更多的是在回答一个更宏大的问题：“怎样的上下文配置最有可能生成我们期望的模型行为？”
上下文指的是从大型语言模型（LLM）中采样时包含的 token 集合。摆在面前的工程问题是：如何在 LLM 固有的限制下优化这些 token 的效用，从而始终如一地实现预期结果。有效地驾驭 LLM 通常需要“在上下文中思考”——换句话说：考虑 LLM 在任何给定时间可用的整体状态，以及该状态可能产生的潜在行为。
在本文中，我们将探索上下文工程这一新兴的艺术，并为构建可引导、高效的智能体提供一个完善的心智模型。
上下文工程 vs. 提示词工程
在 Anthropic，我们将上下文工程视为提示词工程的自然演进。提示词工程指的是编写和组织 LLM 指令以获得最佳结果的方法（有关概述和有用的提示词工程策略，请参阅我们的文档）。上下文工程指的是在 LLM 推理期间，策划和维护最佳 token（信息）集合的一系列策略，包括提示词之外可能落入其中的所有其他信息。
在 LLM 工程的早期，提示词是 AI 工程工作中最主要的部分，因为除了日常聊天交互之外，大多数用例都需要针对单样本分类或文本生成任务优化提示词。顾名思义，提示词工程的主要重点是如何编写有效的提示词，尤其是系统提示词（system prompts）。然而，随着我们转向开发能够在多轮推理和更长时间跨度内运行的、能力更强的智能体，我们需要管理整个上下文状态（系统指令、工具、模型上下文协议 (MCP)、外部数据、消息历史等）的策略。
在循环中运行的智能体会生成越来越多的数据，这些数据可能与下一轮推理相关，并且这些信息必须循环地进行提炼。上下文工程是一门艺术也是一门科学，它致力于从不断演变的、海量的潜在信息中，精心挑选出进入有限上下文窗口的内容。
为什么上下文工程对构建强大的智能体至关重要
尽管 LLM 速度很快且能够管理越来越大的数据量，但我们观察到，就像人类一样，LLM 在达到某个临界点时也会失去焦点或产生混乱。针对“大海捞针”式基准测试的研究揭示了“上下文衰退”（context rot）的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。
虽然某些模型的性能下降比其他模型更平缓，但这种特征在所有模型中都会出现。因此，必须将上下文视为一种边际收益递减的有限资源。就像人类的工作记忆容量有限一样，LLM 在解析大量上下文时也会消耗其“注意力预算”（attention budget）。引入的每一个新 token 都会消耗一定量的预算，这就增加了仔细筛选 LLM 可用 token 的必要性。
这种注意力稀缺源于 LLM 的架构限制。LLM 基于 Transformer 架构，该架构使得每个 token 都能关注整个上下文中的所有其他 token。对于 n 个 token，这会导致 n² 个成对关系。
随着上下文长度的增加，模型捕获这些成对关系的能力会被拉伸到极限，从而在上下文大小和注意力焦点之间产生自然的张力。此外，模型从训练数据分布中发展出其注意力模式，而在训练数据中，较短的序列通常比较长的序列更常见。这意味着模型在处理跨越整个上下文的依赖关系方面经验较少，专门用于此的参数也较少。
诸如位置编码插值（position encoding interpolation）等技术允许模型通过将较长序列适应到最初训练的较小上下文来处理它们，尽管这会在一定程度上降低对 token 位置的理解。这些因素产生的是一个性能梯度，而不是一个陡峭的悬崖：模型在较长上下文中仍然具有很高的能力，但与在较短上下文中的表现相比，其在信息检索和长程推理方面的精度可能会降低。
这些现实意味着，深思熟虑的上下文工程对于构建强大的智能体至关重要。
高效上下文的剖析
鉴于 LLM 受到有限注意力预算的约束，优秀的上下文工程意味着找到尽可能小的、高信号的 token 集合，以最大化实现某种预期结果的可能性。实施这一实践说起来容易做起来难，但在接下来的部分中，我们将概述这一指导原则在上下文的不同组成部分中的实际意义。
系统提示词应该极其清晰，并使用简单、直接的语言，以适合智能体的“高度”（altitude）来呈现想法。合适的高度是介于两种常见失败模式之间的“金发姑娘区”（Goldilocks zone，即恰到好处的区域）。在一个极端，我们看到工程师在提示词中硬编码复杂、脆弱的逻辑，以引出精确的智能体行为。这种方法会产生脆弱性，并随着时间的推移增加维护的复杂性。在另一个极端，工程师有时会提供模糊的、高层次的指导，未能为 LLM 提供预期输出的具体信号，或者错误地假设了共享上下文。最佳高度达到了平衡：足够具体以有效地指导行为，同时又足够灵活，为模型提供强大的启发式方法来引导行为。
我们建议将提示词组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题等技术来划分这些部分，尽管随着模型能力的增强，提示词的具体格式可能会变得不那么重要。
无论您决定如何构建系统提示词，您都应该努力寻找能够完整概述您预期行为的最小信息集。（请注意，最小并不一定意味着简短；您仍然需要预先为智能体提供足够的信息，以确保它遵循预期的行为。）最好先使用可用的最佳模型测试一个最小提示词，看看它在您的任务上的表现，然后根据初始测试中发现的失败模式，添加清晰的指令和示例来提高性能。
工具允许智能体与其环境进行交互，并在工作时引入新的、额外的上下文。因为工具定义了智能体与其信息/动作空间之间的契约，所以工具必须促进效率，这极其重要，既要返回 token 效率高的信息，又要鼓励高效的智能体行为。
在《为 AI 智能体编写工具——与 AI 智能体一起》一文中，我们讨论了构建易于被 LLM 理解且功能重叠最小的工具。类似于设计良好的代码库中的函数，工具应该是自包含的、对错误具有鲁棒性的，并且对其预期用途极其清晰。输入参数同样应该具有描述性、无歧义，并发挥模型固有的优势。
我们看到的最常见的失败模式之一是臃肿的工具集，它们涵盖了太多的功能，或者在决定使用哪个工具时导致了模棱两可的决策点。如果人类工程师无法明确指出在特定情况下应该使用哪个工具，就不能指望 AI 智能体做得更好。正如我们稍后将讨论的，为智能体策划一个最小可行工具集，也可以在长时间的交互中带来更可靠的上下文维护和修剪。
提供示例（也称为少样本提示，few-shot prompting）是一项众所周知的最佳实践，我们继续强烈建议采用。然而，团队经常会将一长串边缘情况塞进提示词中，试图阐明 LLM 在特定任务中应遵循的每一条可能规则。我们不建议这样做。相反，我们建议努力策划一组多样化的、典型的示例，以有效地描绘智能体的预期行为。对于 LLM 来说，示例就是“胜过千言万语的图片”。
我们对上下文不同组成部分（系统提示词、工具、示例、消息历史等）的总体指导原则是：深思熟虑，保持上下文信息丰富且紧凑。现在，让我们深入探讨在运行时动态检索上下文。
上下文检索与智能体搜索
在《构建高效的 AI 智能体》一文中，我们强调了基于 LLM 的工作流与智能体之间的区别。自从写了那篇文章之后，我们倾向于对智能体给出一个简单的定义：LLM 在循环中自主使用工具。
在与客户合作的过程中，我们看到整个领域都在向这个简单的范式收敛。随着底层模型变得更加强大，智能体的自主水平也可以随之提升：更智能的模型允许智能体独立探索微妙的问题空间并从错误中恢复。
我们现在看到，工程师在思考如何为智能体设计上下文方面发生了转变。如今，许多 AI 原生应用程序采用某种形式的基于嵌入（embedding）的推理前检索，以呈现重要的上下文供智能体进行推理。随着该领域向更具智能体特性的方法过渡，我们越来越多地看到团队使用“即时”（just in time）上下文策略来增强这些检索系统。
采用“即时”方法构建的智能体不再预先处理所有相关数据，而是维护轻量级标识符（文件路径、存储的查询、Web 链接等），并使用这些引用在运行时通过工具将数据动态加载到上下文中。Anthropic 的智能体编码解决方案 Claude Code 就使用了这种方法在大型数据库上执行复杂的数据分析。模型可以编写目标查询、存储结果，并利用诸如 head 和 tail 等 Bash 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种方法反映了人类的认知：我们通常不会记住整个信息库，而是引入外部组织和索引系统（如文件系统、收件箱和书签），以便按需检索相关信息。
除了存储效率之外，这些引用的元数据还提供了一种机制来有效地完善行为，无论是显式提供的还是直观的。对于在文件系统中运行的智能体来说，tests 文件夹中名为 test_utils.py 的文件，与位于 src/core_logic/ 中同名文件所暗示的用途是不同的。文件夹层级结构、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何以及何时利用信息。
让智能体自主导航和检索数据还能实现渐进式披露（progressive disclosure）——换句话说，允许智能体通过探索逐步发现相关的上下文。每次交互都会产生为下一个决策提供信息的上下文：文件大小暗示复杂性；命名约定暗示用途；时间戳可以作为相关性的代理指标。智能体可以逐层构建理解，仅在工作记忆中保留必要的内容，并利用记笔记的策略来实现额外的持久化。这种自我管理的上下文窗口使智能体专注于相关的子集，而不是淹没在详尽但可能不相关的信息中。
当然，这里存在权衡：运行时探索比检索预先计算的数据要慢。不仅如此，还需要有主见且深思熟虑的工程设计，以确保 LLM 拥有正确的工具和启发式方法来有效地导航其信息环境。如果没有适当的指导，智能体可能会因为滥用工具、陷入死胡同或未能识别关键信息而浪费上下文。
在某些设置中，最有效的智能体可能会采用混合策略，预先检索一些数据以提高速度，并根据其判断进行进一步的自主探索。“正确”自主水平的决策边界取决于任务。Claude Code 就是一个采用这种混合模型的智能体：CLAUDE.md 文件会被简单直接地预先放入上下文中，而像 glob 和 grep 这样的原语允许它导航其环境并即时检索文件，从而有效地避开了过时索引和复杂语法树的问题。
混合策略可能更适合动态内容较少的上下文，例如法律或财务工作。随着模型能力的提高，智能体设计的趋势将是让智能模型智能地行动，人类的干预会逐渐减少。鉴于该领域进展迅速，“做最简单且有效的事”可能仍然是我们对基于 Claude 构建智能体的团队的最佳建议。
长时间跨度任务的上下文工程
长时间跨度任务（Long-horizon tasks）要求智能体在 token 数量超过 LLM 上下文窗口的动作序列中，保持连贯性、上下文和目标导向的行为。对于跨越数十分钟到数小时连续工作的任务，如大型代码库迁移或综合性研究项目，智能体需要专门的技术来绕过上下文窗口大小的限制。
等待更大的上下文窗口似乎是一个显而易见的策略。但在可预见的未来，各种大小的上下文窗口都可能面临上下文污染和信息相关性的问题——至少在期望获得最强智能体性能的情况下是如此。为了使智能体能够在更长的时间跨度内有效工作，我们开发了几种直接解决这些上下文污染限制的技术：上下文压缩、结构化笔记和多智能体架构。
上下文压缩 (Compaction)
上下文压缩是一种实践，即提取接近上下文窗口限制的对话，总结其内容，并使用该摘要重新启动一个新的上下文窗口。压缩通常作为上下文工程中的第一个杠杆，以推动更好的长期连贯性。在其核心，压缩以高保真度的方式提炼上下文窗口的内容，使智能体能够在性能下降最小的情况下继续工作。
例如，在 Claude Code 中，我们通过将消息历史传递给模型来总结和压缩最关键的细节来实现这一点。模型保留了架构决策、未解决的错误和实现细节，同时丢弃了冗余的工具输出或消息。然后，智能体可以使用这个压缩后的上下文加上最近访问的五个文件继续工作。用户获得了连续性，而无需担心上下文窗口的限制。
压缩的艺术在于选择保留什么和丢弃什么，因为过于激进的压缩可能会导致丢失微妙但关键的上下文，而这些上下文的重要性只有在后来才会显现。对于实施压缩系统的工程师，我们建议在复杂的智能体执行轨迹（traces）上仔细调整您的提示词。首先最大化召回率，以确保您的压缩提示词捕获了轨迹中的每一条相关信息，然后通过消除多余的内容进行迭代以提高精度。
容易处理的多余内容的一个例子是清除工具调用和结果——一旦在消息历史深处调用了某个工具，智能体为什么还需要再次看到原始结果呢？最安全、最轻量级的压缩形式之一是工具结果清除，这是最近在 Claude 开发者平台（Claude Developer Platform）上推出的一项功能。
结构化笔记 (Structured note-taking)
结构化笔记，或称智能体记忆（agentic memory），是一种智能体定期编写笔记并将其持久化到上下文窗口之外的内存中的技术。这些笔记会在稍后被拉回到上下文窗口中。
这种策略以最小的开销提供了持久记忆。就像 Claude Code 创建待办事项列表，或者您的自定义智能体维护一个 NOTES.md 文件一样，这种简单的模式允许智能体跟踪复杂任务的进度，维护关键的上下文和依赖关系，否则这些信息会在数十次工具调用中丢失。
Claude 玩《宝可梦》（Pokémon）展示了记忆如何改变智能体在非编码领域的能力。智能体在数千个游戏步骤中保持精确的记录——跟踪诸如“在过去的 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 集合，以最大化实现预期结果的可能性。
随着模型的改进，我们概述的技术将继续演进。我们已经看到，更智能的模型需要较少的规定性工程，从而允许智能体以更高的自主性运行。但即使能力不断扩展，将上下文视为一种宝贵的、有限的资源，仍将是构建可靠、有效智能体的核心。
立即在 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 的支持。