TL;DR#
核心理念：从提示工程到上下文工程 随着 AI 智能体（Agents）变得更加复杂，重点已从单纯的“提示工程（编写指令）”转向“上下文工程”。上下文工程旨在管理和优化进入模型有限上下文窗口（Context Window）的所有信息（系统提示、工具、数据、历史记录等）。
1. 核心挑战：注意力是有限资源
- 上下文腐烂 (Context Rot)：随着上下文中词元（Tokens）数量增加，模型准确回忆信息的能力会下降。
- 注意力预算：LLM 的注意力机制有其物理限制（n² 关系）。必须将上下文视为具有“边际收益递减”的稀缺资源。
- 指导原则：寻找能最大化预期结果可能性的、最小的高信噪比词元集合。
2. 优化上下文的三大支柱
- 系统提示 (System Prompts)：寻找“最佳适中区（Goldilocks zone）”。避免过于僵化的硬编码逻辑（导致脆弱），也避免过于模糊的高层指导。提示应足够具体以指导行为，又足够灵活以利用模型的启发式能力。
- 工具 (Tools)：追求最小可行工具集。工具功能应自包含、无歧义且通过返回高效的词元来节省上下文。避免工具集臃肿导致智能体决策瘫痪。
- 示例 (Examples)：提供多样化、标准的（canonical）示例。对 LLM 而言，示例胜过千言万语。
3. 动态检索：从“预加载”到“即时 (Just-in-Time)”
- 范式转变：不再预先将所有数据塞入上下文，而是让智能体维护轻量级引用（如文件路径），并在运行时通过工具自主检索数据。
- 渐进式披露：智能体通过探索逐步发现信息（如通过文件名、时间戳判断相关性），只在工作记忆中保留必要内容。
- 混合策略：对于特定任务（如 Claude Code），结合“预置关键信息”与“自主即时检索”以平衡速度与准确性。
4. 解决长时程任务 (Long-Horizon Tasks) 的三大技术 当任务时长超过上下文窗口限制时，需采用以下策略对抗上下文污染：
- 压缩 (Compaction)：定期总结对话历史，保留关键决策和未解决问题，丢弃冗余信息（如清除过往的工具调用结果），以此重启上下文。
- 结构化笔记 (Structured Note-taking)：即“智能体记忆”。让智能体维护外部文件（如
NOTES.md），记录进度和依赖关系。这是实现持久化记忆的低开销方式。 - 子智能体架构 (Sub-agent Architectures)：主智能体负责协调，将具体任务分发给拥有干净上下文窗口的子智能体。子智能体进行广泛探索后，只返回提炼后的摘要。
AI Agent的有效上下文工程#
对于 AI Agent 而言，上下文（Context）是一种至关重要但有限的资源。在这篇文章中，我们将探讨如何有效地筛选和管理驱动这些 Agent 的上下文策略。
在“提示工程（Prompt Engineering）”占据应用 AI 领域焦点数年之后，一个新的术语开始崭露头角：上下文工程（Context Engineering）。使用语言模型进行构建的重心，正逐渐从“为提示词寻找完美的字句”，转移到一个更宏观的问题上来：“什么样的上下文配置最有可能激发模型的预期行为？”
上下文指的是在从大语言模型（LLM）进行采样时所包含的 Token 集合。我们面临的工程问题是：如何在 LLM 固有的约束下，优化这些 Token 的效用，以持续稳定地实现预期结果。高效地驾驭 LLM 通常需要具备上下文思维——换句话说：要考量 LLM 在任意给定时刻可用的整体状态，以及该状态可能引发的潜在行为。
在本文中，我们将探讨上下文工程这门新兴的艺术，并为构建可控、高效的 Agent 提供一个精炼的心智模型。
上下文工程 vs. 提示工程#
在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程指的是为获得最佳结果而编写和组织 LLM 指令的方法（参见我们的文档以获取概述和实用的提示策略）。上下文工程则指的是在 LLM 推理过程中，筛选和维护最佳 Token 集合（信息）的一系列策略，这涵盖了除提示词之外所有可能进入模型的信息。
在 LLM 工程化的早期阶段，提示（Prompting）是 AI 工程工作中最大的组成部分，因为除日常聊天外的绝大多数用例都需要针对单样本分类（one-shot classification）或文本生成任务来优化提示。顾名思义，提示工程的主要焦点是如何编写有效的提示，尤其是系统提示（System Prompts）。然而，随着我们要构建更强大的、能够在多轮推理和更长时间范围内运行的 Agent，我们需要管理整个上下文状态（包括系统指令、工具、模型上下文协议 MCP、外部数据、消息历史等）的策略。
一个在循环中运行的 Agent 会生成越来越多可能与下一轮推理相关的数据，这些信息必须被周期性地提炼。上下文工程既是一门艺术也是一门科学，它研究如何从那个不断膨胀的潜在信息宇宙中，精心筛选出哪些内容应当进入那个有限的上下文窗口。
与编写提示这一离散的一次性任务不同，上下文工程是迭代的，每当我们决定向模型传递什么内容时，都会进行一次筛选（Curation）过程。
为什么上下文工程对构建强大的 Agent 至关重要#
尽管 LLM 速度极快且能够处理海量数据，但我们观察到，它们像人类一样，在达到某个临界点后会失去焦点或感到困惑。关于“大海捞针（Needle-in-a-haystack）”式基准测试的研究揭示了上下文衰退（Context Rot）的概念：随着上下文窗口中 Token 数量的增加，模型从中准确回忆信息的能力会下降。
虽然某些模型的性能下降曲线较为平缓，但这一特性在所有模型中都存在。因此，必须将上下文视为一种边际收益递减的有限资源。就像人类的工作记忆容量有限一样，LLM 在解析大量上下文时也有一个“注意力预算（Attention Budget）”。每引入一个新的 Token 都会消耗一部分预算，这就更需要我们仔细筛选提供给 LLM 的 Token。
这种注意力的稀缺源于 LLM 的架构限制。LLM 基于 Transformer 架构，该架构允许每个 Token 关注整个上下文中的所有其他 Token。对于 n 个 Token，这会产生 n² 个成对关系。
随着上下文长度的增加，模型捕捉这些成对关系的能力会被稀释，从而在“上下文大小”和“注意力焦点”之间产生一种自然的张力。此外，模型的注意力模式是在训练数据分布中形成的，而在训练数据中，较短的序列通常比较长的序列更常见。这意味着模型处理超长上下文依赖关系的经验较少，专门用于此的参数也较少。
虽然像位置编码插值（Position Encoding Interpolation）这样的技术允许模型通过适配训练时的较小上下文来处理更长的序列，但这会伴随 Token 位置理解能力的某种程度下降。这些因素造成的是一个性能梯度而非断崖式下跌：模型在长上下文中仍然非常强大，但与短上下文相比，其在信息检索和长程推理方面的精度可能会降低。
这些现实情况意味着，深思熟虑的上下文工程对于构建高能力的 Agent 至关重要。
高效上下文的解构#
既然 LLM 受限于有限的注意力预算，好的上下文工程就意味着找到能够最大化预期结果可能性的、最小的高信号（High-signal） Token 集合。知易行难，但在接下来的部分，我们将概述这一指导原则在上下文不同组件中的实践意义。
系统提示（System Prompts）应该极其清晰，使用简单、直接的语言，并以合适的高度向 Agent 呈现构想。所谓的“合适高度”，是指介于两种常见失败模式之间的“金发姑娘区（Goldilocks zone，意指恰到好处）”。在极端的一端，我们看到工程师在提示中硬编码复杂的、脆弱的逻辑，试图引出精确的 Agent 行为。这种方法会导致系统脆弱，并随着时间推移增加维护的复杂性。在另一端，工程师有时会提供模糊、高层次的指导，这既无法给 LLM 提供具体的输出信号，又错误地假设了模型拥有共享的上下文背景。最佳的高度能达成一种平衡：既足够具体以有效指导行为，又足够灵活，能为模型提供强大的启发式方法（Heuristics）来引导行为。
我们建议将提示组织成不同的板块（例如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题等技术来划分这些部分。不过，随着模型能力的提升，提示的确切格式正变得不再那么重要。
无论你决定如何构建系统提示，都应致力于使用最小的信息集来完整勾勒出你预期的行为。（注：最小并不一定意味着简短；你仍然需要在前期给予 Agent 足够的信息以确保它遵守预期。）最好的做法是，首先用可用的最强模型测试一个最小化的提示，观察其在任务上的表现，然后根据初始测试中发现的失败模式，添加清晰的指令和示例以提升性能。
**工具（Tools）**允许 Agent 与环境交互，并在工作时引入新的、额外的上下文。因为工具定义了 Agent 与其信息/行动空间之间的契约，所以工具必须能够提升效率——既要返回 Token 高效（token efficient）的信息，也要能鼓励高效的 Agent 行为。
在《为 AI Agent 编写工具》一文中，我们讨论了如何构建易于 LLM 理解且功能重叠最小的工具。与设计良好的代码库中的函数类似，工具应该是自包含的、对错误具有鲁棒性的，并且其预期用途应极其明确。输入参数同样应该是描述性的、无歧义的，并能发挥模型的固有优势。
我们看到最常见的失败模式之一是工具集臃肿，涵盖了过多的功能，或者导致在使用哪个工具时出现模棱两可的决策点。如果人类工程师都无法确定在特定情况下该用哪个工具，就别指望 AI Agent 能做得更好。正如我们将要讨论的，为 Agent 筛选一个**最小可行工具集（Minimal Viable Set of Tools）**也有助于在长时间交互中更可靠地维护和修剪上下文。
提供示例（即常说的小样本提示 Few-shot Prompting）是一个我们持续强烈推荐的最佳实践。然而，团队往往试图在提示中塞入一长串边缘案例清单，试图穷尽 LLM 在特定任务中应遵循的所有规则。我们不推荐这样做。相反，我们建议精心筛选一组多样化的、典型的示例，有效地展示 Agent 的预期行为。对于 LLM 来说，示例就是“胜过千言万语的图片”。
对于上下文的不同组成部分（系统提示、工具、示例、消息历史等），我们的总体建议是：深思熟虑，让你的上下文既信息丰富又保持精炼。现在，让我们深入探讨在运行时（Runtime）动态检索上下文。
上下文检索与 Agent 式搜索#
在《构建高效的 AI Agent》中，我们强调了基于 LLM 的工作流与 Agent 之间的区别。自那篇文章发布以来，我们倾向于对 Agent 下一个简单的定义：LLM 在循环中自主使用工具。
通过与客户的合作，我们看到该领域正趋向于这个简单的范式。随着底层模型变得更加强大，Agent 的自主性水平也可以随之扩展：更智能的模型允许 Agent 独立地探索细微的问题空间并从错误中恢复。
我们现在看到工程师在为 Agent 设计上下文时的思维发生了转变。如今，许多 AI 原生应用采用某种形式的基于嵌入（Embedding-based）的推理前检索，为 Agent 提供推理所需的重要上下文。随着领域向更具 Agent 特性的方法演进，我们越来越多地看到团队使用“即时（Just-in-time）”上下文策略来增强这些检索系统。
采用“即时”方法的 Agent 不会预先处理所有相关数据，而是维护轻量级的标识符（文件路径、存储的查询、网页链接等），并使用这些引用在运行时通过工具动态地将数据加载到上下文中。Anthropic 的 Agent 编码解决方案 Claude Code 就使用这种方法对大型数据库执行复杂的数据分析。模型可以编写有针对性的查询、存储结果，并利用像 head 和 tail 这样的 Bash 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种方法模仿了人类的认知：我们通常不会背诵整个信息库，而是引入外部组织和索引系统（如文件系统、收件箱和书签），以便按需检索相关信息。
除了存储效率外，这些引用的元数据（Metadata）还提供了一种有效改进行为的机制，无论是显式的还是隐式的。对于在一个文件系统中操作的 Agent 来说，一个位于 tests 文件夹下的 test_utils.py 文件，其意图显然不同于位于 src/core_logic/ 下的同名文件。文件夹层级、命名约定和时间戳都提供了重要的信号，帮助人类和 Agent 理解如何以及何时利用信息。
让 Agent 自主导航和检索数据还实现了渐进式披露（Progressive Disclosure）——换句话说，允许 Agent 通过探索逐步发现相关上下文。每一次交互都会产生为下一次决策提供信息的上下文：文件大小暗示了复杂性；命名约定暗示了用途；时间戳可以作为相关性的参考。Agent 可以逐层构建理解，只在工作记忆中保留必要的内容，并利用笔记策略实现额外的持久化。这种自我管理的上下文窗口使 Agent 能够专注于相关的子集，而不是淹没在详尽但可能无关的信息中。
当然，这里存在权衡：运行时探索比检索预先计算好的数据要慢。不仅如此，还需要有主见且深思熟虑的工程设计，以确保 LLM 拥有有效导航其信息环境的正确工具和启发式方法。如果没有适当的引导，Agent 可能会因滥用工具、钻牛角尖或未能识别关键信息而浪费上下文资源。
在某些场景下，最有效的 Agent 可能会采用一种混合策略：为了速度预先检索一些数据，并自行决定进行进一步的自主探索。决定“正确”自主性水平的边界取决于任务本身。Claude Code 就是一个采用这种混合模型的 Agent：CLAUDE.md 文件会被简单粗暴地预先放入上下文，而像 glob 和 grep 这样的原语则允许它导航环境并即时检索文件，从而有效地绕过了索引陈旧和复杂语法树的问题。
对于内容动态性较低的上下文（例如法律或金融工作），混合策略可能更适合。随着模型能力的提升，Agent 设计的趋势将是让智能模型表现得更智能，逐步减少人类的干预。鉴于该领域日新月异的发展速度，对于在 Claude 之上构建 Agent 的团队来说，“做最简单有效的事”可能仍是我们最好的建议。
针对长时程任务的上下文工程#
长时程任务（Long-horizon tasks）要求 Agent 在一系列动作中保持连贯性、上下文和目标导向行为，而这些动作序列产生的 Token 数量往往超过 LLM 的上下文窗口。对于跨越数十分钟到数小时连续工作的任务（例如大型代码库迁移或综合性研究项目），Agent 需要专门的技术来绕过上下文窗口大小的限制。
等待更大的上下文窗口似乎是一个显而易见的策略。但很可能在可预见的未来，所有大小的上下文窗口都会受到上下文污染和信息相关性问题的影响——至少在追求极致 Agent 性能的情况下是如此。为了使 Agent 能够在长时间范围内有效工作，我们开发了一些直接应对这些上下文污染限制的技术：压缩（Compaction）、结构化笔记（Structured note-taking）和多 Agent 架构（Multi-agent architectures）。
压缩 (Compaction)#
压缩是指当对话接近上下文窗口限制时，总结其内容，并用该摘要重新启动一个新的上下文窗口的做法。压缩通常是上下文工程中提升长期连贯性的第一个手段。其核心在于，压缩能以高保真度的方式提炼上下文窗口的内容，使 Agent 能够以最小的性能损耗继续工作。
例如，在 Claude Code 中，我们通过将消息历史传递给模型，让其总结和压缩最关键的细节来实现这一点。模型会保留架构决策、未解决的 Bug 和实现细节，同时丢弃冗余的工具输出或消息。然后，Agent 可以基于这个压缩后的上下文加上最近访问的五个文件继续工作。用户获得了连续性，而无需担心上下文窗口的限制。
压缩的艺术在于取舍（保留什么 vs 丢弃什么），因为过于激进的压缩可能导致细微但关键的上下文丢失，而其重要性可能在之后才会显现。对于实现压缩系统的工程师，我们建议在复杂的 Agent 追踪记录（Traces）上仔细调整你的提示。首先最大化召回率（Recall），以确保你的压缩提示捕获了追踪中的每一个相关信息，然后通过消除多余内容来迭代提高精确率（Precision）。
一个容易剔除的多余内容的例子是清除工具调用和结果——一旦一个工具在消息历史的深处被调用过，Agent 为什么还需要再次看到原始结果呢？最安全、最轻量的压缩形式之一是工具结果清除，这也是 Claude 开发者平台最近推出的一项功能。
结构化笔记 (Structured note-taking)#
结构化笔记，或称 Agent 记忆（Agentic Memory），是一种 Agent 定期将笔记写入并持久化到上下文窗口之外的存储中的技术。这些笔记会在稍后的时间被拉回上下文窗口。
这种策略以最小的开销提供了持久性记忆。就像 Claude Code 创建一个待办事项列表，或者你的自定义 Agent 维护一个 NOTES.md 文件一样，这个简单的模式允许 Agent 在复杂任务中跟踪进度，维护那些否则会在数十次工具调用中丢失的关键上下文和依赖关系。
Claude 玩《精灵宝可梦（Pokémon）》的例子展示了记忆如何在非编码领域改变 Agent 的能力。该 Agent 在数千个游戏步骤中保持精确的记录——追踪诸如“在过去的 1,234 步中，我一直在 1 号道路训练我的宝可梦，皮卡丘已经升了 8 级，目标是 10 级”这样的目标。在没有任何关于记忆结构的提示下，它绘制了已探索区域的地图，记住了它解锁了哪些关键成就，并维护了战斗策略笔记，帮助它学习哪些攻击对不同对手最有效。
在上下文重置后，Agent 会阅读自己的笔记，并继续进行数小时的训练序列或地牢探索。这种跨越摘要步骤的连贯性使得长时程策略成为可能，而如果仅靠将所有信息保留在 LLM 的上下文窗口中，这是不可能实现的。
作为我们 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上以公开测试版的形式发布了一个记忆工具，它通过一个基于文件的系统，使得在上下文窗口之外存储和查阅信息变得更加容易。这使得 Agent 能够随着时间推移建立知识库，跨会话维护项目状态，并引用以前的工作，而无需将所有内容都塞在上下文中。
子 Agent 架构 (Sub-agent architectures)#
子 Agent 架构提供了另一种绕过上下文限制的方法。与其让一个 Agent 试图在整个项目中维护状态，不如让专门的子 Agent 使用干净的上下文窗口来处理聚焦的任务。主 Agent 负责制定高层计划并进行协调，而子 Agent 则执行深入的技术工作或使用工具查找相关信息。每个子 Agent 可能会进行广泛的探索，消耗数万甚至更多的 Token，但最终只返回其工作的浓缩、提炼后的摘要（通常为 1,000-2,000 个 Token）。
这种方法实现了明确的关注点分离（Separation of Concerns）——详细的搜索上下文被隔离在子 Agent 内部，而主导 Agent 则专注于综合和分析结果。这种模式在《我们如何构建多 Agent 研究系统》中进行过讨论，在复杂的研究任务上，它显示出比单 Agent 系统有显著的改进。
在这些方法之间进行选择取决于任务的特性。例如：
- 压缩适合需要大量来回交流的任务，能保持对话流畅性；
- 笔记在具有明确里程碑的迭代开发中表现出色；
- 多 Agent 架构擅长处理复杂的研究和分析，这类任务中并行探索能带来巨大回报。
即使模型不断改进，在长时间交互中保持连贯性的挑战，仍将是构建更高效 Agent 的核心问题。
结论#
上下文工程代表了我们基于 LLM 构建应用方式的根本性转变。随着模型变得越来越强大，挑战不再仅仅是打磨完美的提示词——而是在每一步都深思熟虑地筛选哪些信息能进入模型有限的注意力预算。无论你是在为长时程任务实施压缩，设计 Token 高效的工具，还是让 Agent 能够即时探索其环境，指导原则始终如一：找到能最大化你预期结果可能性的、最小的高信号 Token 集合。
我们概述的这些技术将随着模型的改进而继续演进。我们已经看到，更智能的模型需要更少的指令式工程，允许 Agent 以更高的自主性运行。但即使能力不断扩展，将上下文视为一种宝贵的、有限的资源，仍将是构建可靠、高效 Agent 的核心准则。
立即开始在 Claude 开发者平台中使用上下文工程，并通过我们的记忆和上下文管理手册获取实用的技巧和最佳实践。