面向 AI 智能体的有效上下文工程 \ Anthropic

在应用 AI 中，提示词工程作为关注焦点已有几年；如今，一个新术语开始受到重视：上下文工程。利用语言模型构建系统，越来越不只是为提示词寻找恰当的词语和措辞，而是要回答一个更广泛的问题：“怎样的上下文配置最有可能生成我们期望的模型行为？”

上下文是指在从大型语言模型（LLM）采样时包含的一组 token。眼前的工程问题，是在 LLM 的固有约束下优化这些 token 的效用，以稳定达成期望结果。要有效驾驭 LLM，往往需要在上下文中思考——也就是说，考虑任意时刻 LLM 可获得的整体状态，以及该状态可能产生的行为。

本文将探讨正在形成的上下文工程艺术，并为构建可控、高效的智能体提供一套更精炼的心智模型。

上下文工程与提示词工程

在 Anthropic，我们将上下文工程视为提示词工程的自然演进。提示词工程指为了获得最佳结果而编写和组织 LLM 指令的方法（概览和有用策略参见我们的文档）。上下文工程则指在 LLM 推理期间，策展和维护最优 token（信息）集合的一系列策略，其中还包括提示词之外可能进入该集合的所有信息。

在 LLM 工程早期，提示词是 AI 工程工作的最大组成部分，因为除日常聊天外的大多数用例，都要求针对一次性分类或文本生成任务优化提示词。顾名思义，提示词工程的主要关注点是如何写出有效提示词，尤其是系统提示词。不过，当我们转向构建能跨多轮推理和更长时间跨度运行的更强智能体时，就需要管理整个上下文状态的策略（系统指令、工具、Model Context Protocol（MCP）、外部数据、消息历史等）。

循环运行的智能体会生成越来越多可能与下一轮推理有关的数据，这些信息必须循环地加以提炼。上下文工程正是从这个不断演化的候选信息宇宙中，为有限上下文窗口策展内容的艺术与科学。

与编写提示词这种离散任务不同，上下文工程是迭代式的：每次决定向模型传入什么内容时，都会发生策展阶段。

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

尽管 LLM 速度很快、能管理越来越大的数据量，我们观察到它们与人类一样，在某个节点会失去焦点或陷入混乱。关于“大海捞针”式基准的研究揭示了上下文腐化这一概念：随着上下文窗口中的 token 数量增加，模型从这些上下文中准确回忆信息的能力会下降。

有些模型的退化较为平缓，有些则更明显，但这一特征出现在所有模型中。因此，上下文必须被视为边际回报递减的有限资源。正如人类拥有有限的工作记忆容量，LLM 在解析大量上下文时也要动用“注意力预算”。每增加一个 token 都会消耗部分预算，因此更需要谨慎策展 LLM 可见的 token。

这种注意力稀缺源于 LLM 的架构约束。LLM 基于 transformer 架构，它允许整个上下文中每个 token 都关注其他每个 token。这会为 n 个 token 产生 n² 个两两关系。

随着上下文长度增加，模型捕捉这些两两关系的能力会被摊薄，于是上下文规模和注意力焦点之间出现天然张力。此外，模型从训练数据分布中学习注意力模式，而较短序列通常远多于较长序列。这意味着模型对覆盖整个上下文的依赖关系经验更少，也拥有更少的专门参数。

位置编码插值等技术，可以通过将更长序列适配到原先训练时较小的上下文来让模型处理长序列，但对 token 位置理解会有一定退化。这些因素形成的是性能梯度而非硬性断崖：模型在长上下文下依旧很强，但相对于短上下文时的表现，其信息检索和长程推理精度可能下降。

这些现实意味着，经过深思熟虑的上下文工程是构建强大智能体的必要条件。

有效上下文的组成

既然 LLM 受到有限注意力预算的约束，好的上下文工程就意味着找到尽可能小的高信号 token 集合，让达成某个期望结果的可能性最大。落实这一实践远比说起来容易；下面我们将说明，这一指导原则对上下文的不同组成部分意味着什么。

系统提示词应当极其清楚，并使用简洁、直接的语言，在适合智能体的恰当高度表达观念。这个恰当高度是两种常见失败模式之间的“金发姑娘区间”。一端是工程师在提示词中硬编码复杂、脆弱的逻辑，以诱发精确的智能体行为；这种方法会造成脆弱性，并随时间增加维护复杂度。另一端是工程师有时提供含糊、高层的指引，既不能给 LLM 提供期望输出的具体信号，又错误地假设存在共享上下文。最佳高度应取得平衡：既足够具体、能有效引导行为，又足够灵活、能为模型提供强有力的行为启发式。

光谱的一端是脆弱的 if-else 硬编码提示词，另一端则是过于笼统或错误假设共享上下文的提示词。

我们建议将提示词组织为彼此区分的章节（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题等技术划分章节；不过，随着模型能力增强，提示词的精确格式可能正变得不那么重要。

无论你如何组织系统提示词，都应追求能完整描述期望行为的最小信息集合。（请注意，最小并不一定意味着短；你仍需预先给智能体足够信息，以确保它遵循期望行为。）最好先用最强可用模型测试最小提示词在任务上的表现，再根据初次测试发现的失败模式，加入清晰指令和示例来改进性能。

工具让智能体能够与环境交互，并在工作过程中拉取新的额外上下文。由于工具定义了智能体与其信息/行动空间之间的契约，工具必须促进效率：既要返回 token 高效的信息，也要鼓励高效的智能体行为。

在《为 AI 智能体编写工具——借助 AI 智能体》中，我们讨论过如何构建 LLM 易于理解、且功能重叠极少的工具。与设计良好的代码库中的函数类似，工具应当自包含、对错误稳健，并且对其预期用途极其清楚。输入参数也应具备描述性、无歧义，并发挥模型的固有优势。

我们最常看到的失败模式之一，是臃肿的工具集：它们覆盖太多功能，或使智能体在选择工具时遇到模糊决策点。如果一位人类工程师无法明确说出某种情形该用哪个工具，就不能指望 AI 智能体做得更好。正如后文会讨论的，为智能体策展一组最小可行工具，也能让长交互中的上下文维护和裁剪更可靠。

提供示例（即 few-shot prompting）是广为人知的最佳实践，我们仍强烈建议这样做。不过，团队常常为试图说明 LLM 在某任务中应遵循的每一条可能规则，而把一长串边缘案例塞进提示词。我们不建议这么做。相反，应努力策展一组多样、有代表性的范例，有效展示智能体的预期行为。对 LLM 而言，示例是“一图胜千言”的“图”。

我们对上下文的不同组成部分（系统提示词、工具、示例、消息历史等）的总体建议是：深思熟虑，使上下文信息充分而又紧凑。现在让我们进入运行时动态检索上下文的话题。

上下文检索与智能体搜索

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

与客户共同工作时，我们看到该领域正在趋向这一简单范式。随着底层模型变得更强，智能体的自主程度可以扩展：更聪明的模型使智能体能够独立穿行于微妙的问题空间，并从错误中恢复。

我们现在看到工程师设计智能体上下文的思路正在转变。如今，许多 AI 原生应用采用某种基于嵌入的、推理前时间检索方式，为智能体推理呈现重要上下文。随着领域转向更具智能体性的做法，我们越来越多地看到团队用“恰好及时”的上下文策略来增强这些检索系统。

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

除存储效率外，这些引用的元数据还提供了高效细化行为的机制，无论这种信息是显式给出还是可直觉推断。对于在文件系统中工作的智能体，tests 文件夹内名为 test_utils.py 的文件，与 src/core_logic/ 中同名文件暗示了不同用途。文件夹层级、命名约定和时间戳都会提供重要信号，帮助人和智能体理解何时、如何使用信息。

让智能体自主导航和检索数据还带来了渐进式披露——换言之，使智能体能通过探索逐步发现相关上下文。每次交互都会产生影响下一次决策的上下文：文件大小暗示复杂度，命名约定提示用途，时间戳可以代理相关性。智能体可以逐层构建理解，只在工作记忆中保存必要内容，并使用记笔记策略实现额外持久性。这个自我管理的上下文窗口使智能体专注于相关子集，而不是淹没在穷尽却可能无关的信息中。

当然，这存在权衡：运行时探索比检索预先计算的数据更慢。不仅如此，还需要带有立场且经过深思熟虑的工程，以确保 LLM 具备用于有效导航信息空间的恰当工具和启发式。缺乏合适指引时，智能体可能因误用工具、追逐死路或未识别关键信息而浪费上下文。

在某些场景，最有效的智能体可能采用混合策略：为速度预先检索一些数据，并酌情继续自主探索。通向“恰当”自主程度的决策边界取决于任务。Claude Code 是采用此混合模型的智能体：它会把 CLAUDE.md 文件朴素地预先放入上下文，同时 glob 和 grep 等原语允许它在恰当时刻导航环境并检索文件，从而有效绕开陈旧索引和复杂语法树的问题。

对内容变化较少的上下文，如法律或金融工作，混合策略可能更适合。随着模型能力提升，智能体设计会趋向让聪明模型聪明地行动，并逐步减少人工策展。鉴于进展极快，“做能工作的最简单事情”很可能仍是我们给 Claude 智能体构建团队的最佳建议。

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

长程任务要求智能体在一系列动作中保持连贯、上下文和目标导向，而其 token 总数会超过 LLM 的上下文窗口。对于大型代码库迁移或综合研究项目等持续数十分钟至数小时的连续任务，智能体需要专门技术来绕开上下文窗口大小限制。

等待更大的上下文窗口似乎是一种显而易见的策略。但在可预见的未来，任何规模的上下文窗口都可能受到上下文污染和信息相关性问题影响——至少在追求最强智能体表现的情形中如此。为使智能体能在延长的时间跨度上有效工作，我们开发了几种直接应对这些上下文污染约束的技术：压缩、结构化记笔记和多智能体架构。

压缩

压缩是指当对话接近上下文窗口上限时，对内容做摘要，并以该摘要重新启动一个新的上下文窗口。压缩通常是上下文工程中改善长期连贯性的第一杠杆。其核心是以高保真方式提炼一个上下文窗口的内容，让智能体以最小性能退化继续工作。

例如，在 Claude Code 中，我们通过将消息历史传给模型，让其总结并压缩最关键的细节来实现这一点。模型在丢弃冗余工具输出或消息的同时，保留架构决策、未解决 bug 和实现细节。随后智能体可以借助这份压缩上下文以及最近访问的五个文件继续工作。用户无需担心上下文窗口限制，也能获得连续性。

压缩的艺术在于选择保留什么、丢弃什么；过于激进的压缩会丢失细微却关键的上下文，而其重要性可能到后来才显现。对实现压缩系统的工程师，我们建议在复杂智能体轨迹上仔细调优提示词：先最大化召回，确保压缩提示能捕捉轨迹中每一条相关信息；再通过消除多余内容迭代提升精确度。

一个显而易见的冗余内容例子是清除工具调用及其结果——当工具调用已深埋在消息历史中，智能体为何还要再次看到原始结果？最安全、最轻量的压缩形式之一，是清除工具结果；这最近刚作为功能在 Claude Developer Platform 上推出。

结构化记笔记

结构化记笔记（或称智能体记忆）是一种技术：智能体会定期把笔记写入上下文窗口之外的持久内存。这些笔记会在稍后重新拉回上下文窗口。

该策略以极低开销提供持久记忆。就像 Claude Code 创建待办清单，或你的自定义智能体维护 NOTES.md 文件一样，这一简单模式让智能体能够跟踪复杂任务的进展，保存那些本会在数十次工具调用间丢失的关键上下文和依赖关系。

Claude 玩宝可梦 展示了记忆如何在非编码领域改变智能体能力。智能体在数千个游戏步骤中保持精确计数——跟踪诸如“过去 1,234 步里，我一直在 1 号道路训练宝可梦；皮卡丘已向目标等级 10 提升了 8 级”等目标。即使没有被提示记忆结构，它也会建立已探索区域的地图，记住解锁的重要成就，并维护战斗策略笔记，从而学习哪些攻击对不同对手最有效。

在上下文重置后，智能体读取自己的笔记，并继续持续数小时的训练序列或地牢探索。跨摘要步骤的这种连贯性，使得仅把全部信息保留在 LLM 上下文窗口内时不可能实现的长程策略成为可能。

作为 Sonnet 4.5 发布 的一部分，我们在 Claude Developer Platform 上公开测试推出了记忆工具，它通过基于文件的系统，让在上下文窗口外存储和查阅信息更容易。这让智能体可以随时间积累知识库、跨会话维护项目状态，并引用先前工作，而无需把所有内容一直留在上下文中。

子智能体架构

子智能体架构提供了另一种绕开上下文限制的方法。与其让单个智能体尝试维护整个项目的状态，不如由专门子智能体使用干净的上下文窗口处理聚焦任务。主智能体以高层计划协调，而子智能体执行深入技术工作或用工具查找相关信息。每个子智能体可能广泛探索，使用数万甚至更多 token，却只返回一份凝练、提炼的工作摘要（通常为 1,000–2,000 token）。

这种方法实现了清晰的关注点分离：详细搜索上下文隔离在子智能体内，主智能体专注于综合和分析结果。该模式在《我们如何构建多智能体研究系统》中讨论过，并且在复杂研究任务上相较单智能体系统有显著提升。

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

• 压缩为需要大量来回交互的任务维持对话流；
• 记笔记擅长具有清晰里程碑的迭代式开发；
• 多智能体架构适合并行探索能带来回报的复杂研究和分析。

即便模型持续进步，在延长交互中维持连贯性的挑战，仍将是构建更有效智能体的核心。

结论

上下文工程代表了我们利用 LLM 构建系统时的根本转变。随着模型变得更强，挑战不再只是雕琢完美提示词，而是在每一步慎重策展进入模型有限注意力预算的信息。无论你是在为长程任务实现压缩、设计 token 高效工具，还是让智能体恰好及时地探索环境，指导原则始终相同：找到最小的高信号 token 集合，以最大化达成期望结果的可能性。

我们概述的技术将随模型进步不断演化。我们已经看到，更聪明的模型需要更少的规定性工程，使智能体拥有更大自主性。但即使能力扩展，把上下文视为宝贵、有限的资源，仍将是构建可靠、高效智能体的核心。

立即开始在 Claude Developer Platform 上进行上下文工程，并通过记忆与上下文管理 cookbook 获取有用的技巧和最佳实践。

致谢

本文由 Anthropic Applied AI 团队的 Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield 撰写，团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 亦有贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的支持。