Anthropic官方《面向 AI Agents 的有效上下文工程》

转载

发布于 2025 年 9 月 29 日

上下文对于 AI 智能体来说是一个关键但有限的资源。在这篇文章中,我们探讨了有效策划和管理为智能体提供支持的上下文的策略。

经过几年对应用 AI 中提示工程(prompt engineering)的关注,一个新术语开始崭露头角:上下文工程(context engineering)。使用语言模型进行构建已经不再仅仅是为提示寻找合适的词语和短语,而是更多地回答一个更广泛的问题:"什么样的上下文配置最有可能产生我们模型的期望行为?"

上下文 是指在从大型语言模型(LLM)采样时包含的一组标记(token)。当前的工程 问题是在 LLM 固有约束条件下优化这些标记的效用,以便持续实现期望的结果。有效地驾驭 LLM 通常需要以上下文的方式思考 --- 换句话说:考虑在任何给定时间 LLM 可用的整体状态,以及该状态可能产生的潜在行为。

在这篇文章中,我们将探索新兴的上下文工程艺术,并为构建可控、有效的智能体提供一个精炼的思维模型。

上下文工程 vs. 提示工程

与编写提示这一离散任务相比,上下文工程是迭代的,策划阶段在我们每次决定传递给模型什么内容时都会发生。

在 Anthropic,我们将上下文工程视为提示工程的自然演进。提示工程是指编写和组织 LLM 指令以获得最佳结果的方法(请参阅我们的文档以了解概述和有用的提示工程策略)。上下文工程是指在 LLM 推理过程中策划和维护最佳标记集(信息)的一系列策略,包括可能在提示之外到达那里的所有其他信息。

在使用 LLM 进行工程的早期,提示是 AI 工程工作的最大组成部分,因为日常聊天交互之外的大多数用例都需要针对一次性分类或文本生成任务优化的提示。正如该术语所暗示的,提示工程的主要焦点是如何编写有效的提示,特别是系统提示。然而,随着我们转向工程化更有能力的智能体,这些智能体可以在多轮推理和更长的时间范围内运行,我们需要管理整个上下文状态的策略(系统指令、工具、模型上下文协议(MCP)、外部数据、消息历史等)。

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

为什么上下文工程对构建有能力的智能体很重要

尽管 LLM 的速度很快,并且能够管理越来越大的数据量,但我们观察到,LLM 像人类一样,在某个点上会失去焦点或产生困惑。关于"大海捞针"式基准测试的研究揭示了上下文腐烂的概念:随着上下文窗口中标记数量的增加,模型从该上下文中准确回忆信息的能力会下降。

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

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

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

位置编码插值这样的技术允许模型通过将它们适应到原始训练的较小上下文来处理更长的序列,尽管在标记位置理解方面会有一些降级。这些因素创建了一个性能梯度而不是硬性悬崖:模型在较长的上下文中仍然非常有能力,但在信息检索和长程推理方面可能显示出比在较短上下文中的表现降低的精确度。

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

有效上下文的剖析

在频谱的一端,我们看到脆弱的 if-else 硬编码提示,而在另一端,我们看到过于笼统或错误假设共享上下文的提示。

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

系统提示 应该非常清晰,并使用简单、直接的语言,以智能体的正确高度呈现想法。正确的高度是两种常见失败模式之间的黄金地带。在一个极端,我们看到工程师在他们的提示中硬编码复杂、脆弱的逻辑以引发确切的智能体行为。这种方法会造成脆弱性并随着时间的推移增加维护复杂性。在另一个极端,工程师有时提供模糊的高层次指导,无法为 LLM 提供期望输出的具体信号,或错误地假设共享上下文。最佳高度达到了平衡:足够具体以有效指导行为,但又足够灵活以为模型提供强大的启发式方法来指导行为。

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

无论您决定如何构建系统提示,您都应该努力获得完全概述期望行为的最小信息集。(请注意,最小不一定意味着简短;您仍然需要预先给智能体足够的信息,以确保它遵守期望的行为。)最好从使用最好的可用模型测试最小提示开始,看看它在您的任务上的表现如何,然后根据初始测试期间发现的失败模式添加清晰的指令和示例来提高性能。

工具允许智能体与其环境一起操作,并在工作时引入新的、额外的上下文。由于工具定义了智能体与其信息/行动空间之间的契约,因此工具促进效率非常重要,既要通过返回标记高效的信息,又要通过鼓励高效的智能体行为来实现。

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

我们看到的最常见的失败模式之一是臃肿的工具集,涵盖了太多功能或导致关于使用哪个工具的模糊决策点。如果人类工程师不能明确地说在给定情况下应该使用哪个工具,就不能期望 AI 智能体做得更好。正如我们稍后将讨论的,为智能体策划一个最小可行的工具集也可以在长时间交互中实现更可靠的上下文维护和修剪。

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

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

上下文检索和智能体搜索

在《构建有效的 AI 智能体》中,我们强调了基于 LLM 的工作流和智能体之间的差异。自从我们写了那篇文章以来,我们倾向于对智能体采用一个简单的定义:LLM 在循环中自主使用工具。

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

我们现在看到工程师思考为智能体设计上下文的方式发生了转变。今天,许多 AI 原生应用程序采用某种形式的基于嵌入的推理前检索,为智能体提供重要的上下文进行推理。随着该领域转向更智能体化的方法,我们越来越多地看到团队用"及时"上下文策略来增强这些检索系统。

智能体不是预先处理所有相关数据,而是使用"及时"方法构建的智能体维护轻量级标识符(文件路径、存储的查询、网络链接等),并使用这些引用在运行时使用工具动态地将数据加载到上下文中。Anthropic 的智能体编码解决方案 Claude Code 使用这种方法对大型数据库执行复杂的数据分析。该模型可以编写有针对性的查询、存储结果,并利用 Bash 命令(如 head 和 tail)来分析大量数据,而无需将完整的数据对象加载到上下文中。这种方法反映了人类认知:我们通常不会记住整个信息语料库,而是引入外部组织和索引系统,如书签、标签和搜索功能,以便在需要时定位信息。

关键在于建立一个强大的信息架构,智能体可以使用工具与之交互。这需要仔细考虑如何组织和索引数据,以便智能体可以高效地检索它需要的内容,而无需将所有内容都保存在上下文中。

长期任务的上下文工程

构建能够在长时间跨度内运行的智能体需要战略性地管理上下文窗口。我们观察到三种主要技术,用于在长时间交互中管理上下文:

1. 压缩(Compaction)

压缩涉及定期总结对话内容并重新初始化上下文。当智能体的消息历史变得太长时,您可以使用 LLM 来总结到目前为止的对话,保留关键信息,同时丢弃不必要的细节。这个摘要然后成为新的起点,允许智能体在不被大量历史标记负担的情况下继续。

2. 结构化笔记(Structured Note-Taking)

智能体可以维护在主要上下文窗口之外的结构化笔记。当智能体遇到重要信息时,它可以将其写入外部存储(如文件系统或数据库)。然后,智能体可以在需要时使用工具检索这些笔记,而不是将所有信息保留在上下文中。这种方法将智能体的"工作记忆"(上下文窗口)与其"长期记忆"(外部存储)分开。

3. 子智能体架构(Sub-Agent Architectures)

与其使用单个智能体来处理复杂的长期任务,不如将任务分解为较小的、更集中的子任务,每个子任务由专门的子智能体处理。每个子智能体都有自己的上下文窗口和专门的工具集,使其能够在其特定领域高效工作。主智能体协调这些子智能体,管理它们之间的信息流,并确保整体任务得到完成。

结论

上下文工程代表了我们如何使用 LLM 构建的根本转变。随着模型变得更有能力,挑战不仅仅是制作完美的提示 --- 而是在每一步深思熟虑地策划哪些信息进入模型的有限注意力预算。

核心原则很简单:将上下文视为珍贵的、有限的资源。这意味着:

  • 编写清晰、简洁的系统提示,在正确的高度提供指导
  • 设计返回高信号、标记高效信息的工具
  • 使用多样化的规范示例,而不是详尽的边缘案例列表
  • 实施"及时"检索策略,而不是预先加载所有可能的信息
  • 采用压缩、结构化笔记或子智能体架构来管理长期任务

随着 AI 智能体在复杂性和能力方面不断发展,有效的上下文工程将继续是构建可靠、有效智能体的核心。通过深思熟虑地管理注意力预算,我们可以创建不仅强大而且在各种任务和时间范围内都高效和可靠的智能体。

即使模型继续提高其处理更长上下文的能力,将上下文视为珍贵的、有限的资源的原则仍将是构建可靠、有效智能体的核心。

相关推荐
chaofan9803 小时前
如何用 Claude Code 搭建安全、可测、可自动化的 GitHub CI 流程?
运维·人工智能·ci/cd·ai·自动化·github·claude
yaocheng的ai分身3 小时前
GLM-4.6:先进的 Agentic、推理和编码能力
ai编程·chatglm (智谱)
量子位3 小时前
DeepSeek突然拥抱国产GPU语言!TileLang对标CUDA替代Triton,华为昇腾Day0官宣支持适配
ai编程·deepseek
用户4099322502125 小时前
PostgreSQL索引这么玩,才能让你的查询真的“飞”起来?
后端·ai编程·trae
追逐时光者6 小时前
一款基于 AI 大模型驱动、开源且强大的知识库搭建系统,支持 AI 创作、问答、搜索等能力!
ai编程
yaocheng的ai分身7 小时前
Anthropic 官方《用 Claude Agent SDK 构建智能体》
ai编程
子昕7 小时前
Claude 4.5来了!82%碾压GPT-5,AI编程体验彻底变了
ai编程
yaocheng的ai分身7 小时前
cursor 1.7更新
ai编程
yaocheng的ai分身7 小时前
重建 Devin 以适配 Claude Sonnet 4.5:经验与挑战
ai编程