在应用人工智能领域，提示词工程（prompt engineering）曾是几年来的关注焦点，而如今一个新术语正崭露头角：上下文工程（context engineering）。使用大语言模型（LLM）进行构建，正逐渐从“寻找合适的词句来编写提示”，转向回答一个更宏观的问题：“什么样的上下文配置最有可能引导模型产生我们期望的行为？” 上下文（Context）指的是在对大语言模型进行采样时所包含的一组 token（标记）。而当前的工程挑战（engineering problem）在于：如何在 LLM 固有约束条件下，优化这些 token 的效用，以持续达成预期结果。有效驾驭 LLM 通常需要“以上下文的方式思考”——换句话说，就是考虑在任意时刻提供给 LLM 的整体状态，以及该状态可能引发的潜在行为。
在本文中，我们将探讨这一新兴的上下文工程艺术，并提供一种更精细的心智模型，用于构建可引导、高效的智能体。
上下文工程 vs. 提示词工程
在 Anthropic，我们认为上下文工程是提示工程的自然演进。提示工程指的是编写和组织 LLM 指令以获得最佳结果的方法（参见我们的文档，了解提示工程概览及实用策略）。而上下文工程则指的是一系列在 LLM 推理过程中，用于筛选和维护最优 token 集合（信息）的策略——包括提示之外可能进入上下文的所有其他信息。
在 LLM 应用的早期阶段，提示优化构成了 AI 工程工作的主要部分，因为除了日常聊天交互外，大多数用例都需要针对一次性分类或文本生成任务进行提示优化。顾名思义，提示工程的核心在于如何编写有效的提示，尤其是系统提示（system prompts）。
然而，随着我们转向构建更强大的智能体——这些智能体需在多轮推理和更长时间跨度内持续运行——我们需要管理整个上下文状态（包括系统指令、工具、Model Context Protocol [MCP]、外部数据、消息历史等）的策略。
在一个循环中运行的智能体会不断生成越来越多可能与下一轮推理相关的新数据，这些信息必须被周期性地提炼。上下文工程正是从这个不断演化的信息宇宙中，精心挑选出应放入有限上下文窗口内容的艺术与科学。
与编写提示这一离散任务不同，上下文工程是迭代式的——每次决定向模型传递什么内容时，都会发生一次上下文筛选。
为何上下文工程对构建强大智能体至关重要
尽管 LLM 的速度越来越快、处理的数据量也越来越大，但我们观察到，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）这样的技术，可以让模型通过适配原始训练时较短的上下文来处理更长序列，但会带来一定程度的位置理解退化。这些因素共同导致了一种性能梯度（performance gradient），而非硬性断崖：模型在长上下文中依然强大，但在信息检索和长程推理方面的精度可能不如在短上下文中表现优异。
这些现实意味着：深思熟虑的上下文工程对于构建强大智能体至关重要。
有效上下文的构成要素
鉴于 LLM 受限于有限的注意力预算，优秀的上下文工程意味着找到最小可能的高信号 token 集合，以最大化实现期望结果的可能性。说起来容易做起来难，但在下文中，我们将从上下文不同组成部分的角度，阐述这一指导原则在实践中的含义。
系统提示词（System Prompts）
系统提示应极其清晰，使用简单直接的语言，并以合适的抽象层级（right altitude）呈现想法。所谓“合适的抽象层级”，是指介于两种常见失败模式之间的“黄金区间”：
一端是工程师在提示中硬编码复杂的、脆弱的逻辑，试图精确控制智能体行为。这种方式会导致系统脆弱，并随着时间推移显著增加维护复杂度。 另一端是提供模糊、高层级的指导，未能给 LLM 提供具体的行为信号，或错误地假设模型与人类共享背景知识。 理想的抽象层级应足够具体以有效引导行为，又足够灵活，为模型提供强大的启发式规则。
一端是僵化的 if-else 硬编码提示，另一端是过于笼统或错误假设共享上下文的提示。
我们建议将提示划分为不同部分（如 <背景信息>、<指令>、## 工具指南、## 输出格式说明 等），并使用 XML 标签或 Markdown 标题等方式明确分隔这些部分（尽管随着模型能力提升，提示的具体格式可能变得不那么重要）。
无论你如何组织系统提示，都应努力追求能完整描述预期行为的最小信息集。（注意：“最小”并不一定意味着“简短”；你仍需在一开始就提供足够信息，确保智能体遵循期望行为。）建议先用最强的模型测试一个最小提示，观察其在任务上的表现，再根据初始测试中发现的失败模式，逐步添加清晰的指令和示例以提升性能。
工具（Tools）
工具使智能体能够与其环境交互，并在运行过程中引入新的上下文。由于工具定义了智能体与其信息/动作空间之间的契约，因此工具设计必须兼顾效率：既要返回 token 高效的信息，也要鼓励智能体采取高效行为。
在《用 AI 智能体编写 AI 智能体的工具》一文中，我们讨论过如何构建 LLM 易于理解、功能无重叠的工具。就像设计良好的代码库中的函数一样，工具应自包含、容错性强、用途明确。输入参数也应具有描述性、无歧义，并契合模型的固有优势。
我们最常见的失败模式之一是工具集臃肿：覆盖功能过多，或导致智能体在选择工具时面临模糊决策。如果人类工程师都无法明确判断在某种情况下该用哪个工具，就不应指望 AI 智能体做得更好。正如后文将讨论的，为智能体维护一个最小可行工具集（minimal viable set of tools），也有助于在长时间交互中更可靠地维护和修剪上下文。
示例（Examples）
提供示例（即少样本提示，few-shot prompting）是一种广为人知的最佳实践，我们依然强烈推荐。然而，团队常常试图在提示中塞入大量边缘案例，试图穷尽 LLM 应遵循的所有规则。我们不推荐这种做法。
相反，我们建议精心挑选一组多样化且具有代表性的典型示例，有效展现智能体的预期行为。对 LLM 而言，示例就是“胜过千言万语的图片”。
我们对上下文各组成部分（系统提示词、工具、示例、消息历史等）的整体建议是：保持信息丰富，同时精炼紧凑。接下来，我们将深入探讨如何在运行时动态检索上下文。
上下文检索与智能体搜索
在《构建有效的 AI 智能体》一文中，我们曾强调 LLM 工作流与智能体之间的区别。自那以后，我们倾向于采用一个简单定义：智能体 = LLM 在循环中自主使用工具。
在与客户合作的过程中，我们看到业界正逐渐汇聚到这一范式。随着底层模型能力的提升，智能体的自主性也在增强：更聪明的模型能让智能体独立导航复杂问题空间，并从错误中恢复。
如今，工程师在设计智能体上下文时的思路正在转变。许多 AI 原生应用已在推理前采用基于嵌入（embedding-based）的检索机制，为智能体提供关键上下文以进行推理。随着领域向更智能体化的方法演进，我们越来越多地看到团队在这些检索系统基础上，增加“即时（just-in-time）”上下文策略。
与预先处理所有相关数据不同，“即时”方法让智能体维护轻量级标识符（如文件路径、存储查询、网页链接等），并在运行时通过工具动态加载数据到上下文中。Anthropic 的智能体编程解决方案 Claude Code 就采用这种方法，在大型数据库上执行复杂数据分析。模型可以编写针对性查询、存储结果，并利用 head、tail 等 Bash 命令分析海量数据，而无需将完整数据对象加载到上下文中。这种方式模拟了人类认知：我们通常不会记住整套资料，而是借助文件系统、收件箱、书签等外部组织和索引系统按需检索信息。
除了存储效率，这些引用的元数据还提供了一种高效优化行为的机制——无论是显式提供还是直觉感知。对在文件系统中运行的智能体而言，位于 tests/ 目录下的 test_utils.py 文件与位于 src/core_logic/ 目录下的同名文件，其用途显然不同。目录层级、命名规范、时间戳等都能为人类和智能体提供重要信号，帮助判断如何及何时使用信息。
让智能体自主导航和检索数据，还能实现渐进式披露（progressive disclosure）——即通过探索逐步发现相关上下文。每次交互都会产生新上下文，用于指导下一步决策：文件大小暗示复杂度，命名规范提示用途，时间戳可作为相关性的代理。智能体可以逐层构建理解，仅在工作记忆中保留必要内容，并借助“记笔记”策略实现额外持久化。这种自我管理的上下文窗口使智能体聚焦于相关子集，而非淹没在大量可能无关的信息中。
当然，这也有权衡：运行时探索比检索预计算数据更慢。不仅如此，还需要经过深思熟虑的工程设计，确保 LLM 拥有合适的工具和启发式规则，以有效导航其信息环境。缺乏适当引导时，智能体可能因误用工具、追逐死胡同或未能识别关键信息而浪费上下文。
在某些场景下，最有效的智能体可能采用混合策略：预先检索部分数据以提升速度，并在需要时自主探索更多信息。是否采用更高自主性，取决于具体任务。例如，Claude Code 就采用了这种混合模型：CLAUDE.md 文件会直接放入初始上下文，而 glob、grep 等原语则允许它即时导航环境并检索文件，有效规避了索引过期和复杂语法树等问题。
对于内容变化较少的领域（如法律或金融），混合策略可能更为合适。随着模型能力不断提升，智能体设计将趋向于“让智能模型智能地行动”，人类干预将逐步减少。鉴于领域进展迅速，“做最简单且有效的事”很可能仍是团队在 Claude 上构建智能体的最佳建议。
长期任务的上下文工程
长期任务要求智能体在 token 总数超出 LLM 上下文窗口的连续操作序列中，保持连贯性、上下文一致性和目标导向行为。对于持续数十分钟乃至数小时的任务（如大型代码库迁移或综合性研究项目），智能体需要专门技术来绕过上下文窗口限制。
等待更大的上下文窗口似乎是个显而易见的策略。但很可能在可预见的未来，任何规模的上下文窗口都会面临上下文污染和信息相关性问题——至少在追求最强智能体性能的场景下如此。为使智能体在长时间跨度内高效工作，我们开发了几种直接应对上下文污染约束的技术：压缩（compaction）。
压缩（Compaction）
压缩是指在对话接近上下文窗口上限时，对其内容进行摘要，并用摘要重新初始化一个新的上下文窗口。压缩通常是上下文工程中提升长期连贯性的首要手段。其核心是以高保真方式提炼上下文内容，使智能体能以最小性能损失继续工作。
例如，在 Claude Code 中，我们会将消息历史传递给模型进行摘要，压缩最关键细节。模型会保留架构决策、未解决的 bug 和实现细节，同时丢弃冗余的工具输出或消息。随后，智能体可基于该压缩上下文 + 最近访问的五个文件继续工作。用户无需担心上下文窗口限制，即可获得连续体验。
压缩的艺术在于保留什么、丢弃什么。过度压缩可能导致细微但关键的上下文丢失，而其重要性可能在后期才显现。对于实现压缩系统的工程师，我们建议在复杂智能体轨迹上仔细调优你的压缩提示：先最大化召回率，确保捕捉轨迹中所有相关信息；再迭代提升精确率，剔除冗余内容。
一个典型的冗余内容是清除工具调用及其结果——一旦某个工具调用已深埋在消息历史中，智能体为何还需要再次看到原始结果？目前最安全、最轻量的压缩形式之一就是工具结果清除，该功能最近已在 Claude 开发者平台上线。
结构化笔记（Structured Note-taking）
结构化笔记（又称智能体记忆）是一种让智能体定期将笔记持久化到上下文窗口之外的技术。这些笔记可在后续被重新拉回上下文。
该策略以极低开销提供持久记忆。就像 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 tokens）。
这种方法实现了清晰的关注点分离：详细搜索上下文被隔离在子智能体内部，而主智能体专注于结果的综合与分析。我们在《我们如何构建多智能体研究系统》一文中讨论过这一模式，在复杂研究任务上，其表现显著优于单智能体系统。
这些方法的选择取决于任务特性：
压缩 适用于需要大量来回交互、保持对话流的任务； 笔记 适用于具有明确里程碑的迭代开发； 多智能体架构 适用于可通过并行探索获益的复杂研究与分析任务。 即使模型持续进步，在长时间交互中保持连贯性仍将是构建更高效智能体的核心挑战。
结论
上下文工程代表了我们使用 LLM 构建应用方式的根本转变。随着模型能力不断增强，挑战不再仅仅是“写出完美的提示”，而是在每一步都精心筛选进入模型有限注意力预算的信息。无论你是在为长期任务实施压缩、设计 token 高效的工具，还是让智能体即时探索环境，指导原则始终如一：找到最小的高信号 token 集合，以最大化实现期望结果的可能性。
随着模型不断进步，我们所概述的技术也将持续演进。我们已经看到，更聪明的模型需要更少的预设工程，使智能体能以更高自主性运行。但即便能力不断提升，将上下文视为宝贵且有限的资源，仍将是构建可靠、高效智能体的核心。
阅读原文：
