如何为AI智能体构建高效的上下文工程（Context Engineering）？

大模型时代，真正的瓶颈不再是“怎么写提示”，而是“该给模型看什么”。上下文工程（Context Engineering）正取代提示工程，成为构建高性能AI智能体的核心——因为LLM的注意力是有限资源，信息过载反而导致性能衰减。高效智能体的关键，在于用最小、最密的信息集，精准引导模型行为。

过去几年，“提示工程”被奉为调教大模型的魔法咒语。但随着智能体从单次问答走向多轮、长周期任务（如自动编程、复杂研究），静态提示已远远不够。模型需要在动态环境中持续决策，而上下文窗口却像人类的工作记忆——容量有限，且越塞越乱。

1️ 上下文 ≠ 提示，它是智能体的“工作台”

上下文包含系统指令、工具定义、历史消息、外部数据等所有输入token。提示只是其中一小部分。真正的挑战在于：如何在有限窗口内，动态筛选出对当前决策最有价值的信息？这已从“写作技巧”升级为“信息调度系统”。

2️ 注意力预算会“通货膨胀”

Transformer架构的n²注意力机制意味着：每多一个token，都在稀释模型对关键信息的关注。实验显示，即使模型支持10万+上下文，其“大海捞针”能力仍随长度衰减——长≠强，精炼才高效。

3️ 三大长周期策略：压缩、笔记、分身

• 压缩（Compaction）：像人类总结会议纪要，丢弃冗余工具输出，保留决策脉络；

• 结构化笔记：让智能体自己写NOTES.md，实现跨会话记忆（如Claude玩《宝可梦》记训练进度）；

• 子智能体架构：主脑规划，小兵干活，避免单一上下文爆炸。

未来AI应用的竞争，将从“谁家模型大”转向“谁家上下文管理更聪明”。轻量、自主、可记忆的智能体架构将成为标配。法律、金融、科研等长周期领域，将是上下文工程技术的主战场。

“最好的提示，是让模型根本不需要看太多提示。”

作为从业者，我们必须放弃“把所有知识塞进上下文”的执念。真正的智能，是知道何时不看什么。对普通用户而言，这意味着未来AI助手将更像一个“会做笔记、懂取舍”的同事，而非复读机。

以下为文章原文

上下文是人工智能智能体的一项关键但有限的资源。在本文中，我们将探讨有效筛选和管理驱动智能体运行的上下文的策略。

在应用人工智能领域，提示工程（prompt engineering）曾是过去几年的关注焦点，而如今一个新术语正日益受到重视：上下文工程（context engineering）。使用大语言模型进行构建，已不再仅仅聚焦于为提示词寻找恰当的措辞和短语，而是更多地转向回答一个更宏观的问题：“何种上下文配置最有可能引导模型产生我们期望的行为？”

上下文指的是在从大语言模型（LLM）采样时所包含的一组词元（tokens）。当前面临的工程挑战，是在大语言模型固有约束条件下，优化这些词元的效用，以持续达成预期结果。要有效驾驭大语言模型，往往需要“以上下文为思维核心”——换言之，需综合考虑在任意给定时刻模型所能获取的整体状态，并评估该状态可能引发的潜在行为。

在本文中，我们将探讨新兴的上下文工程艺术，并提供一种经过提炼的心智模型，用于构建可控且高效的智能体。

上下文工程 vs. 提示工程

在 Anthropic，我们认为上下文工程是提示工程的自然演进。提示工程是指编写和组织大语言模型指令以获得最佳输出效果的方法（参见我们的文档，了解概述及实用的提示工程策略）。而上下文工程则指在大语言模型推理过程中，筛选并维护最优词元集合（即信息）的一整套策略，包括提示之外可能进入上下文的所有其他信息。

在早期使用大语言模型进行工程开发时，提示设计构成了人工智能工程工作的主要部分，因为除日常聊天交互外，大多数应用场景都需要针对单次分类或文本生成任务优化提示。顾名思义，提示工程的核心在于如何编写有效的提示，尤其是系统提示（system prompts）。然而，随着我们转向构建能在多轮推理和更长时间跨度下运行的更强能力智能体，我们需要一套管理完整上下文状态的策略——这包括系统指令、工具、模型上下文协议（Model Context Protocol, MCP）、外部数据、消息历史等。

在一个循环中运行的智能体会不断生成越来越多可能对下一轮推理有用的数据，而这些信息必须被周期性地精炼和筛选。上下文工程正是从这个持续演化的信息宇宙中，精心挑选哪些内容应填入有限上下文窗口的艺术与科学。

与编写提示这一离散任务不同，上下文工程是一个迭代过程，每次决定向模型传递哪些内容时，都会进行一次上下文筛选。

为何上下文工程对构建强大智能体至关重要?

尽管大语言模型（LLM）处理速度极快，且能管理的数据量日益增长，但我们观察到，LLM 与人类一样，在达到某个临界点后会失去焦点或产生混淆。“大海捞针”式基准测试的研究揭示了“上下文衰减”（context rot）的概念：随着上下文窗口中词元（tokens）数量的增加，模型从该上下文中准确回忆信息的能力反而下降。

尽管不同模型的性能退化程度有所差异，但这一特性在所有模型中普遍存在。因此，上下文必须被视为一种边际收益递减的有限资源。正如人类的工作记忆容量有限，LLM 在解析大量上下文时也依赖一个“注意力预算”。每引入一个新的词元(token)，都会以某种方式消耗该预算，从而更迫切地要求我们精心筛选提供给 LLM 的词元(tokens)。

这种注意力稀缺性源于 LLM 的架构限制。LLM 基于 Transformer 架构，该架构允许每个词元(token)在整个上下文中关注其他所有词元(tokens)，从而对 n 个词元(tokens)产生 n² 对相互关系。

随着上下文长度的增加，模型捕捉这些成对关系的能力被不断稀释，导致上下文规模与注意力聚焦之间形成天然张力。此外，模型的注意力模式源自训练数据分布——其中较短序列通常比长序列更为常见。这意味着模型在处理跨整个上下文的长程依赖关系方面经验较少，也缺乏专门优化的参数。

诸如位置编码插值（position encoding interpolation）等技术，可通过将长序列适配到原始训练时较小的上下文长度来支持更长输入，但会一定程度上削弱模型对词元位置的理解能力。这些因素共同造成了一种性能梯度，而非硬性断崖：模型在更长上下文中仍具备较强能力，但在信息检索和长程推理方面的精确度可能低于其在较短上下文中的表现。

这些现实表明，深思熟虑的上下文工程对于构建高性能智能体至关重要。

高效上下文的构成要素

鉴于 LLM 受限于有限的注意力预算，优秀的上下文工程意味着找到最小但信息密度最高的词元(tokens)集合，以最大化实现预期结果的可能性。践行这一原则说起来容易做起来难，但在下文中，我们将具体阐述该指导原则在上下文各组成部分中的实际体现。

系统提示应极其清晰，并使用简洁、直接的语言，以适合智能体的“抽象层级”呈现信息。“合适的抽象层级”是指介于两种常见失败模式之间的“恰到好处”区间。一端是工程师在提示中硬编码复杂而脆弱的逻辑，试图精确控制智能体行为——这种方法会导致系统脆弱性，并随着时间推移显著增加维护复杂度；另一端则是工程师仅提供模糊、高层次的指导，未能给 LLM 提供明确的输出信号，或错误地假定模型已共享某些上下文。理想的抽象层级应在两者之间取得平衡：足够具体以有效引导行为，又足够灵活，为模型提供强有力的启发式规则来自主决策。

在一端，我们看到的是脆弱的、硬编码的 if-else 式提示；在另一端，则是过于笼统或错误地假定模型已共享上下文的提示。

我们建议将提示划分为清晰的独立部分（例如 <background_information>（背景信息）、<instructions>（指令）、## 工具指引、## 输出描述 等），并使用 XML 标签或 Markdown 标题等技术来明确区分这些部分。尽管随着模型能力的提升，提示的具体格式可能正变得不那么关键。

无论你选择如何组织系统提示，都应力求用最少的信息完整描述出你期望的行为。（注意：“最少”并不一定意味着“简短”；你仍需在一开始就为智能体提供足够信息，以确保其行为符合预期。）最佳做法是先用当前最强大的模型测试一个最小化提示，观察其在目标任务上的表现，然后根据初步测试中发现的失败模式，有针对性地补充清晰的指令和示例，以提升性能。

工具使智能体能够与环境交互，并在运行过程中动态引入新的、额外的上下文。由于工具定义了智能体与其信息/动作空间之间的契约，因此工具的设计必须注重效率——既要返回词元高效的信息，也要引导智能体采取高效的行为。

在《用 AI 智能体为 AI 智能体编写工具》（Writing tools for AI agents – with AI agents）一文中，我们讨论过构建那些易于 LLM 理解且功能重叠最小的工具。正如设计良好的代码库中的函数一样，工具应当是自包含的、对错误具有鲁棒性，并且对其预期用途表述得极为清晰。输入参数也应同样具备描述性强、无歧义的特点，并契合模型的固有优势。

我们最常见的失败模式之一，就是工具集过于臃肿，覆盖了过多功能，或导致在选择使用哪个工具时出现模糊的决策点。如果人类工程师都无法明确判断在特定情境下应使用哪个工具，就不应指望 AI 智能体能做得更好。正如我们稍后将讨论的那样，为智能体精心筛选一套最小可行的工具集，也有助于在长时间交互中更可靠地维护和修剪上下文。

提供示例（即所谓的少样本提示，few-shot prompting）是一种广为人知的最佳实践，我们依然强烈推荐。然而，团队常常试图在提示中塞入一长串边缘案例，试图穷尽 LLM 在特定任务中应遵循的所有规则。我们不建议这样做。相反，我们建议精心挑选一组多样且具有代表性的典型示例，有效展现智能体应有的行为。对 LLM 而言，示例就是“胜过千言万语的图画”。

我们在上下文各个组成部分（系统提示、工具、示例、消息历史等）上的总体建议是：深思熟虑，保持上下文既信息丰富又紧凑精炼。接下来，让我们深入探讨如何在运行时动态检索上下文。

上下文检索与智能体驱动的搜索

在《构建高效的 AI 智能体》（Building effective AI agents）一文中，我们曾强调基于大语言模型（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 平台上构建智能体的最佳建议。

面向长周期任务的上下文工程

长周期任务要求智能体在一系列操作中保持连贯性、上下文一致性和目标导向行为，而这些操作所产生的词元数量往往超出大语言模型（LLM）的上下文窗口限制。对于持续数十分钟乃至数小时的连续任务——例如大型代码库迁移或综合性研究项目——智能体需要专门的技术来克服上下文窗口大小的限制。

等待更大上下文窗口的出现似乎是一种显而易见的策略。但在可预见的未来，无论上下文窗口多大，都仍会面临“上下文污染”和信息相关性的问题——至少在追求最强智能体性能的场景下是如此。为了使智能体在更长时间跨度内高效工作，我们开发了几种直接应对上下文污染约束的技术：压缩（compaction）、结构化笔记（structured note-taking）和多智能体架构（multi-agent architectures）。

压缩（compaction）

压缩是指当对话接近上下文窗口上限时，对内容进行摘要，并以该摘要重新初始化一个新的上下文窗口。压缩通常是上下文工程中用于提升长期连贯性的首要手段。其核心在于以高保真度提炼当前上下文窗口的内容，使智能体能够以最小的性能损失继续运行。

例如，在 Claude Code 中，我们会将消息历史传递给模型，由其总结并压缩最关键的信息。模型会保留架构决策、未解决的 bug 和实现细节，同时丢弃冗余的工具输出或消息。随后，智能体可在这一压缩后的上下文中继续运行，并附带最近访问的五个文件。用户因此获得无缝体验，无需担忧上下文窗口的限制。

压缩的艺术在于如何权衡保留与舍弃的内容——过度激进的压缩可能导致细微但关键的上下文丢失，而这些信息的重要性可能要到后续阶段才显现。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹（agent traces）上仔细调优你的提示。首先最大化召回率，确保压缩提示能捕获轨迹中的所有相关信息；然后通过迭代剔除冗余内容，逐步提升精确率。

一个典型的低垂果实式冗余内容就是清除工具调用及其结果——一旦某次工具调用已深埋于消息历史中，智能体为何还需要再次看到原始结果？目前最安全、最轻量的压缩形式之一就是工具结果清理，该功能最近已在 Claude 开发者平台作为一项特性正式推出。

结构化笔记（Structured note-taking）

结构化笔记，也称为智能体记忆（agentic memory），是一种让智能体定期将笔记写入上下文窗口之外的持久化存储中的技术。这些笔记会在后续适当时机被重新加载回上下文窗口。

该策略以极低的开销提供持久记忆。例如，Claude Code 会创建待办事项清单，或你的自定义智能体维护一个 NOTES.md 文件。这种简单模式使智能体能够在复杂任务中追踪进度，保留那些在数十次工具调用后本会丢失的关键上下文和依赖关系。

Claude 玩《宝可梦》的案例展示了记忆如何在非编程领域显著增强智能体能力。该智能体能在数千个游戏步骤中精确记录状态——例如：“在过去 1,234 步中，我一直在 1 号道路训练我的宝可梦，皮卡丘已向 10 级目标提升了 8 级。” 即使没有人为指定记忆结构，它也能自主绘制已探索区域的地图，记住已解锁的关键成就，并保存战斗策略笔记，从而学习哪些招式对不同对手最有效。

在上下文重置后，智能体会读取自己的笔记，继续长达数小时的训练序列或地牢探索。这种跨摘要步骤的连贯性，使得仅靠 LLM 上下文窗口无法实现的长周期策略成为可能。

作为 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台推出了一个基于文件系统的记忆工具（公开测试版），使智能体更容易在上下文窗口之外存储和查阅信息。这使得智能体能够随时间积累知识库、在会话之间维持项目状态，并引用先前的工作成果，而无需将所有内容保留在上下文中。

子智能体架构（Sub-agent architectures）

子智能体架构提供了另一种绕过上下文限制的途径。与其让单一智能体试图在整个项目中维持状态，不如由多个专用子智能体分别处理聚焦的任务，并各自拥有干净的上下文窗口。主智能体负责高层规划，而子智能体则执行深度技术工作或使用工具检索相关信息。每个子智能体可能会进行大量探索，消耗数万个甚至更多tokens，但最终仅返回一份浓缩、提炼后的工作摘要（通常为 1,000–2,000 tokens）。

这种方法实现了清晰的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主智能体则专注于综合与分析结果。正如我们在《我们如何构建多智能体研究系统》（How we built our multi-agent research system）一文中所讨论的，该模式在复杂研究任务上相比单智能体系统展现出显著优势。

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

• 压缩适用于需要频繁来回交互、强调对话连贯性的任务；

• 结构化笔记在具有明确里程碑的迭代式开发中表现卓越；

• 多智能体架构则适合那些并行探索能带来显著收益的复杂研究与分析任务。

即使模型能力持续提升，在长时间交互中维持连贯性仍将是构建更高效智能体的核心挑战。

结论

上下文工程代表了我们使用大语言模型（LLM）进行构建方式的根本性转变。随着模型能力不断提升，挑战已不再仅仅是编写完美的提示词，而是在每一步都深思熟虑地筛选哪些信息进入模型有限的注意力预算。无论你是在为长周期任务实施压缩策略、设计词元高效的工具，还是让智能体以“即时”方式探索其环境，核心指导原则始终如一：找到最小但信息密度最高的词元集合，以最大化实现预期结果的可能性。

随着模型持续进步，我们所概述的这些技术也将不断演进。我们已经观察到，更智能的模型对工程干预的依赖正在减少，使智能体能够以更高程度的自主性运行。然而，即便能力不断扩展，将上下文视为一种宝贵且有限的资源，仍将是构建可靠、高效智能体的核心要义。