Anthropic发布AIAgent上下文工程指南

今年 6 月, Andrej Karpathy 就提出: 提示词工程该改名了。

Anthropic发布AIAgent上下文工程指南-2

他建议用「上下文工程」(context engineering)取代「提示词工程」(prompt engineering)。Karpathy 指出,人们一听到「 提示词 」,就会联想到日常使用 LLM 时输入的简短任务描述。

Anthropic发布AIAgent上下文工程指南-3

但在真正的工业级 LLM 应用中,填充上下文窗口才是一门精妙的艺术与科学。

Anthropic发布AIAgent上下文工程指南-4

而刚刚,在 Claude Sonnet 4.5 和 Claude Code 2.0 推出后的第二天,Anthropic 发布的这一篇的工程博客,也呼应了 Karpathy 的观点: 真正的挑战不是编写完美的提示词,而是如何精心策划整个上下文。

Anthropic 明确指出:

构建 AI 应用的重心正在从寻找「正确的词句」转向回答更广泛的问题——「什么样的上下文配置最有可能产生我们期望的模型行为?」

为什么上下文工程如此重要

上下文指的是从大语言模型采样时包含的所有 token。

而工程问题在于如何在 LLM 固有的约束条件下优化这些 token 的效用,以持续实现期望的结果。有效驾驭 LLM 通常需要「 在上下文中思考 」。

换句话说: 考虑 LLM 在任何给定时刻可用的整体状态,以及该状态可能产生的潜在行为。

Anthropic 认为,上下文工程是提示词工程的自然演进。

提示词工程专注于为获得最佳结果而编写和组织 LLM 指令的方法。而 上下文工程 指的是在 LLM 推理过程中策划和维护最优 token 集(信息)的一系列策略,包括提示之外可能出现的所有其他信息。

Anthropic发布AIAgent上下文工程指南-5

在 AI 工程的早期,提示词是主要工作,因为除了日常聊天交互之外,大多数用例都需要为一次性分类或文本生成任务优化提示。

如其名称所暗示的,提示词工程的主要重点是如何编写有效的提示,特别是系统提示。

然而,随着我们转向工程化能够在多轮推理和更长时间跨度上运行的更强大智能体,我们需要管理整个上下文状态(系统指令、工具、模型上下文协议(MCP)、外部数据、消息历史等)的策略。

在循环中运行的智能体会生成越来越多可能与下一轮推理相关的数据,这些信息必须循环精炼。 上下文工程是从不断演变的可能信息宇宙中策划将进入有限上下文窗口内容的艺术与科学。

对构建强大智能体至关重要

尽管速度快且能够管理越来越大的数据量,但研究发现 LLM 像人类一样,在某个点会失去焦点或感到困惑。

针对「大海捞针」式基准测试的研究揭示了「 上下文腐烂 」的概念:

随着上下文窗口中 token 数量的增加,模型从该上下文准确回忆信息的能力会下降。

虽然有些模型表现出更温和的退化,但这一特性在所有模型中都会出现。因此,上下文必须被视为具有边际收益递减的有限资源。就像人类的工作记忆容量有限一样,LLM 在解析大量上下文时也有一个「 注意力预算 」。引入的每个新 token 都会在一定程度上消耗这个预算,增加了仔细策划 LLM 可用 token 的需求。

这种注意力稀缺性源于 LLM 的架构约束。LLM 基于 Transformer 架构,它使每个 token 能够关注整个上下文中的每个其他 token。这导致 n 个 token 产生 n² 个成对关系。

随着上下文长度的增加,模型捕获这些成对关系的能力变得紧张,在上下文大小和注意力焦点之间产生了自然的张力。此外,模型从训练数据分布中发展其注意力模式,其中较短的序列通常比较长的序列更常见。这意味着模型对上下文范围依赖性的经验较少,专门参数也较少。

像位置编码插值这样的技术允许模型通过将其适应到最初训练的较小上下文来处理更长的序列,尽管在 token 位置理解方面会有一些退化。

这些因素创造了性能梯度而不是硬性界限: 模型在更长的上下文中仍然保持高能力,但与在较短上下文上的表现相比,在信息检索和长程推理方面可能表现出较低的精度。

这些现实意味着,深思熟虑的上下文工程对于构建强大的智能体至关重要。

有效上下文的剖析

鉴于 LLM 受到有限注意力预算的约束, 良好的上下文工程意味着找到最小可能的高信号 token 集,以最大化某些期望结果的可能性 。说起来容易做起来难,但在下面的部分中,我们概述了这一指导原则在上下文不同组成部分中的实际意义。

系统提示 应该极其清晰,使用简单、直接的语言,以适当的高度呈现想法。适当的高度是两个常见失败模式之间的最佳点。

在一个极端,我们看到工程师在提示中硬编码复杂、脆弱的逻辑来引发精确的智能体行为。这种方法创造了脆弱性并随着时间的推移增加了维护复杂性。在另一个极端,工程师有时提供模糊的高层指导,未能为 LLM 提供期望输出的具体信号或错误地假设共享上下文。最优高度达到了平衡:足够具体以有效指导行为,但又足够灵活,为模型提供强大的启发式方法来指导行为。

Anthropic发布AIAgent上下文工程指南-6

我们建议将提示组织成不同的部分(如 <background_information> 、 <instructions> 、 ## Tool guidance 、 ## Output description 等),并使用 XML 标记或 Markdown 标题等技术来划分这些部分,尽管随着模型变得更强大,提示的确切格式可能变得不那么重要。

无论你决定如何构建系统提示,你都应该努力寻找完全概述预期行为的最小信息集。(注意,最小并不一定意味着短;你仍然需要预先为智能体提供足够的信息,以确保它遵守期望的行为。)

最好从使用可用的最佳模型测试最小提示开始,看看它在你的任务上的表现如何,然后根据初始测试中发现的失败模式添加清晰的指令和示例来提高性能。

工具 允许智能体与其环境交互并在工作时引入新的额外上下文。因为工具定义了智能体与其信息/动作空间之间的契约,所以工具促进效率非常重要,既要返回 token 高效的信息,又要鼓励高效的智能体行为。

在「为 AI 智能体编写工具——用 AI 智能体」中,我们讨论了构建 LLM 能够很好理解且功能重叠最小的工具。与设计良好的代码库的函数类似,工具应该是自包含的、对错误具有鲁棒性,并且在其预期用途方面极其清晰。输入参数同样应该具有描述性、明确性,并发挥模型的固有优势。

我们看到的最常见失败模式之一是臃肿的工具集,涵盖了太多功能或导致关于使用哪个工具的模糊决策点。如果人类工程师不能明确说出在给定情况下应该使用哪个工具,就不能期望 AI 智能体做得更好。

如我们稍后将讨论的,为智能体策划一个最小可行的工具集也可以导致在长时间交互中更可靠的维护和修剪上下文。

提供示例,也称为少样本提示,是我们继续强烈建议的众所周知的最佳实践。然而,团队通常会在提示中塞入一长串边缘案例,试图阐明 LLM 应该为特定任务遵循的每个可能规则。我们不建议这样做。相反,我们建议努力策划一组多样化的、规范的示例,有效地描绘智能体的预期行为。

对于 LLM 来说,示例是「 值千言万语的图片 」。

我们对上下文不同组成部分(系统提示、工具、示例、消息历史等)的总体指导是要深思熟虑并保持上下文信息丰富但紧凑。现在让我们深入探讨在运行时动态检索上下文。

上下文检索和智能体搜索

在「构建有效的 AI 智能体」中,我们强调了基于 LLM 的工作流程与智能体之间的区别。自从我们写了那篇文章以来,我们倾向于一个简单的智能体定义: LLM 在循环中自主使用工具 。

与客户合作,我们看到该领域正在趋同于这个简单的范式。随着底层模型变得更强大,智能体的自主水平可以扩展:更智能的模型允许智能体独立导航细微的问题空间并从错误中恢复。

我们现在看到工程师思考为智能体设计上下文的方式发生了转变。

今天,许多 AI 原生应用程序采用某种形式的基于嵌入的推理前时间检索,以便为智能体推理提供重要上下文。随着该领域转向更多智能体方法,我们越来越多地看到团队用「 即时 」上下文策略来增强这些检索系统。

与预先处理所有相关数据不同,使用「即时」方法构建的智能体维护轻量级标识符(文件路径、存储的查询、网络链接等),并使用这些引用在运行时使用工具动态将数据加载到上下文中。Anthropic 的智能体编码解决方案 Claude Code 使用这种方法对大型数据库执行复杂的数据分析。

模型可以编写有针对性的查询、存储结果,并利用像 head 和 tail 这样的 Bash 命令来分析大量数据,而无需将完整的数据对象加载到上下文中。这种方法反映了人类认知:我们通常不会记住整个信息语料库,而是引入外部组织和索引系统,如文件系统、收件箱和书签,以按需检索相关信息。

除了存储效率之外,这些引用的元数据提供了一种有效精炼行为的机制,无论是明确提供的还是直观的。对于在文件系统中运行的智能体, tests 文件夹中名为 test_utils.py 的文件的存在意味着与位于 src/core_logic.py 中的同名文件不同的用途。文件夹层次结构、命名约定和时间戳都提供了重要的信号,帮助人类和智能体理解如何以及何时利用信息。

让智能体自主导航和检索数据也实现了渐进式披露——换句话说,允许智能体通过探索逐步发现相关上下文。每次交互都会产生为下一个决策提供信息的上下文:文件大小暗示复杂性;命名约定暗示目的;时间戳可以是相关性的代理。

智能体可以逐层组装理解,只在工作记忆中保持必要的内容,并利用笔记策略进行额外的持久化。这种自我管理的上下文窗口使智能体专注于相关子集,而不是淹没在详尽但可能不相关的信息中。

当然,这里有一个权衡: 运行时探索比检索预计算数据慢。

不仅如此,还需要有见地和深思熟虑的工程来确保 LLM 具有正确的工具和启发式方法来有效导航其信息景观。如果没有适当的指导,智能体可能会通过误用工具、追逐死胡同或未能识别关键信息来浪费上下文。

在某些设置中,最有效的智能体可能采用混合策略,预先检索一些数据以提高速度,并根据其判断进行进一步的自主探索。「正确」自主水平的决策边界取决于任务。

Claude Code 是一个采用这种混合模型的智能体 :CLAUDE.md 文件被天真地预先放入上下文中,而像 glob 和 grep 这样的原语允许它导航其环境并即时检索文件,有效地绕过陈旧索引和复杂语法树的问题。

混合策略可能更适合动态内容较少的上下文,例如法律或金融工作。随着模型能力的提高,智能体设计将倾向于让智能模型智能地行动,逐渐减少人类策划。鉴于该领域的快速发展步伐,「做最简单有效的事情」可能仍然是我们为在 Claude 之上构建智能体的团队提供的最佳建议。

长时间跨度任务的上下文工程

长时间跨度任务要求智能体在 token 计数超过 LLM 上下文窗口的动作序列中保持连贯性、上下文和目标导向行为。对于跨越数十分钟到多小时连续工作的任务,如大型代码库迁移或综合研究项目,智能体需要专门的技术来绕过上下文窗口大小限制。

等待更大的上下文窗口似乎是一个明显的策略。

但在可预见的未来,所有大小的上下文窗口都可能受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下。为了使智能体能够在扩展的时间跨度上有效工作,我们开发了一些直接解决这些上下文污染约束的技术: 压缩、结构化笔记和多智能体架构 。

压缩

压缩是将接近上下文窗口限制的对话进行总结,并用摘要重新启动新的上下文窗口的做法。压缩通常作为上下文工程中的第一个杠杆来推动更好的长期连贯性。从本质上讲,压缩以高保真方式提炼上下文窗口的内容,使智能体能够以最小的性能退化继续。

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

压缩的艺术在于选择保留什么与丢弃什么,因为过于激进的压缩可能导致微妙但关键的上下文丢失,其重要性只有在以后才变得明显。对于实现压缩系统的工程师,我们建议在复杂的智能体轨迹上仔细调整你的提示。首先最大化召回率以确保你的压缩提示从轨迹中捕获每一条相关信息,然后通过消除多余内容来迭代提高精度。

低垂果实的多余内容的一个例子是清除工具调用和结果:一旦工具在消息历史深处被调用,为什么智能体需要再次看到原始结果?最安全、最轻触的压缩形式之一是工具结果清除,最近作为 Claude 开发者平台上的一项功能推出。

结构化笔记

结构化笔记或智能体记忆是智能体定期将笔记写入上下文窗口之外的记忆中的技术。这些笔记稍后会被拉回到上下文窗口中。

这种策略以最小的开销提供持久记忆。就像 Claude Code 创建待办事项列表,或你的自定义智能体维护 NOTES.md 文件一样,这种简单的模式允许智能体跨越复杂任务跟踪进度,维护关键上下文和依赖关系,否则这些将在数十个工具调用中丢失。

Claude 玩宝可梦展示了记忆如何在非编码领域转变智能体能力。

智能体在数千个游戏步骤中保持精确的统计——跟踪目标,如「在过去的 1,234 步中,我一直在 1 号路线训练我的宝可梦,皮卡丘已经获得了 8 级,目标是 10 级。」在没有任何关于记忆结构的提示的情况下,它开发了探索区域的地图,记住了它已经解锁的关键成就,并维护了战斗策略的战略笔记,帮助它学习哪些攻击对不同的对手最有效。

在上下文重置后,智能体读取自己的笔记并继续多小时的训练序列或地牢探索。这种跨总结步骤的连贯性使得长时间跨度策略成为可能,而仅在 LLM 的上下文窗口中保持所有信息时这是不可能的。

作为我们 Sonnet 4.5 发布的一部分,我们在 Claude 开发者平台上以公开测试版发布了一个记忆工具,通过基于文件的系统使在上下文窗口之外存储和查询信息变得更容易。这允许智能体随着时间的推移建立知识库,跨会话维护项目状态,并在不将所有内容保持在上下文中的情况下引用以前的工作。

子智能体架构

子智能体架构提供了另一种绕过上下文限制的方法。与一个智能体试图在整个项目中维护状态不同,专门的子智能体可以使用干净的上下文窗口处理聚焦的任务。主智能体用高层计划进行协调,而子智能体执行深度技术工作或使用工具查找相关信息。每个子智能体可能会广泛探索,使用数万个 token 或更多,但只返回其工作的压缩、提炼摘要(通常为 1,000-2,000 个 token)。

这种方法实现了清晰的关注点分离——详细的搜索上下文在子智能体中保持隔离,而主智能体专注于综合和分析结果。这种模式在「我们如何构建多智能体研究系统」中讨论,在复杂研究任务上显示出比单智能体系统的实质性改进。

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

压缩为需要大量来回交流的任务保持对话流程;

笔记在具有明确里程碑的迭代开发中表现出色;

多智能体架构处理复杂的研究和分析,其中并行探索带来回报。

即使模型继续改进,在扩展交互中保持连贯性的挑战仍将是构建更有效智能体的核心。

结论

上下文工程代表了我们如何使用 LLM 构建的根本转变。随着模型变得更强大,挑战不仅仅是制作完美的提示——而是深思熟虑地策划在每一步进入模型有限注意力预算的信息。无论你是为长时间跨度任务实现压缩,设计 token 高效的工具,还是使智能体能够即时探索其环境,指导原则都保持不变:找到最小的高信号 token 集,最大化你期望结果的可能性。

我们概述的技术将随着模型的改进而继续发展。我们已经看到,更智能的模型需要更少的规定性工程,允许智能体以更多的自主权运行。但即使能力扩展,将上下文视为珍贵、有限的资源仍将是构建可靠、有效智能体的核心。

立即在 Claude 开发者平台开始上下文工程,并通过我们的记忆和上下文管理 cookbook 获取有用的提示和最佳实践。

致谢

版权声明:
作者:shadowrocket
链接:https://www.shadowrocket9.top/78.html
来源:Shadowrocket官网
文章版权归作者所有,未经允许请勿转载。

THE END
分享
二维码
< <上一篇
下一篇>>