【Anthropic好文】AI 代理的高效上下文工程

AI 代理的高效上下文工程

来源：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
获取时间：2025-10-02 14:57:58 UTC

在应用型 AI 领域经历了几年以提示工程为关注焦点之后，一个新术语走到了台前：上下文工程。如今，构建语言模型应用不再只是寻找提示中的恰当词句，而是要回答一个更宏观的问题：“怎样的上下文配置最有可能让模型产生我们期望的行为？”

上下文指的是在对大型语言模型（LLM）进行采样时纳入的那组 Token。当前的工程问题，是在 LLM 的固有限制下，优化这些 Token 的效用，从而稳定地实现预期结果。要有效驯服 LLM，往往需要在上下文中思考——换言之：随时思考 LLM 当前可见的整体状态，以及这些状态可能诱发的行为。

在本文中，我们将探索新兴的上下文工程方法，并提供一个经过打磨的心智模型，帮助你构建可调控、效果显著的代理。

上下文工程 vs. 提示工程

在 Anthropic，我们将上下文工程视为提示工程的自然进化。提示工程指的是为获得最佳结果而编写和组织 LLM 指令的方法（参见我们的文档，了解概述和实用策略）。上下文工程则指在 LLM 推理过程中，策划并维护最优 Token 集（信息）的策略，涵盖提示之外落入上下文的所有内容。

在使用 LLM 的早期阶段，提示是 AI 工程工作的核心，因为除了日常聊天外，大多数用例都需要针对单次分类或文本生成任务优化的提示。顾名思义，提示工程的重点在于如何编写有效提示，尤其是系统提示。然而，随着我们迈向构建更强大的代理，它们会在多个推理回合和更长的时间跨度中运作，我们就需要管理整个上下文状态（系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）的策略。

在循环运行的代理会生成越来越多的潜在数据，这些数据可能与下一轮推理相关，因而必须循环精炼。上下文工程既是艺术也是科学，核心在于从不断演化的海量信息中挑选出可放入有限上下文窗口的内容。

相比一次性编写提示的离散任务，上下文工程是迭代式的，每次决定要传递给模型什么内容时都要进行策划。

为什么上下文工程对构建强大代理至关重要

尽管 LLM 具有高速处理能力并能管理越来越多的数据，我们观察到它们和人类一样，会在某个节点失焦或产生困惑。针对 needle-in-a-haystack 风格基准的研究揭示了上下文腐蚀的概念：随着上下文窗口中的 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 代理做得更好。正如稍后将讨论的，为代理策划一组最小可行的工具，也有助于在长时交互中更可靠地维护和修剪上下文。

提供示例（即少样本提示）仍然是我们强烈推荐的最佳实践。然而，团队往往会将一长串边界案例塞进提示中，期望详细列出 LLM 在特定任务中应该遵循的每一条规则。我们并不建议这么做。相反，我们建议精心策划一组多样化、经典的示例，清晰展示代理的期望行为。对 LLM 而言，示例就是“胜过千言万语的图片”。

总体而言，我们对于上下文不同组成部分（系统提示、工具、示例、消息历史等）的建议是：保持审慎，让上下文既信息丰富又紧凑。接下来，我们深入探讨如何在运行时动态检索上下文。

上下文检索与代理式搜索

在《构建高效 AI 代理》中，我们强调了基于 LLM 的工作流与代理之间的差异。自那篇文章以来，我们逐渐倾向于对代理的一个简单定义：在循环中自主使用工具的 LLM。

与客户合作的过程中，我们看到整个领域都在趋同于这一简单范式。随着底层模型能力的增强，代理的自治程度也随之提升：更智能的模型让代理能够独立探索复杂问题空间并从错误中恢复。

如今，工程师在为代理设计上下文时的思路正在转变。许多 AI 原生应用仍会在推理前使用基于向量嵌入的检索，以提前提供重要上下文。随着大家转向更加代理化的方法，我们越来越常看到团队为这些检索系统补充“及时”（just in time）的上下文策略。

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

除了存储效率，这些引用的元数据还能以显式或隐式的方式，帮助高效地修正行为。对于在文件系统中操作的代理而言，tests 文件夹中的 test_utils.py 与 src/core_logic.py 中同名文件，目的截然不同。文件夹层级、命名约定、时间戳，都为人类和代理提供了重要信号，帮助判断如何、何时利用信息。

让代理自主导航和检索数据，也支持渐进式披露——也就是说，让代理通过探索逐步发现相关上下文。每次交互都会产生新的上下文，为下一步决策提供信息：文件大小暗示复杂度，命名约定暗示用途，时间戳可能是相关性的代理指标。代理可以层层累积理解，只在工作记忆中保留必要内容，并借助笔记策略增加持久性。这样的自管理上下文窗口让代理聚焦于相关子集，而不是被详尽但潜在无关的信息淹没。

当然，这里面存在权衡：运行时探索比检索预先计算的数据更慢。此外，还需要带有明确倾向且经过深思熟虑的工程实践，确保 LLM 拥有适当的工具和启发式，以高效地导航其信息场景。缺乏良好引导的代理可能会浪费上下文，错误使用工具、陷入死胡同或忽略关键信息。

在某些场景下，最有效的代理会采用混合策略：先行检索部分数据以提高速度，再视情况继续自主探索。合适的自治水平取决于任务本身。Claude Code 就是采用混合模式的代理：会将 CLAUDE.md 文件直接放入上下文，同时使用 glob、grep 等原语探索环境，在需要时即时检索文件，从而避开索引陈旧与语法树复杂度等问题。

混合策略可能更适用于内容变化不那么频繁的场景，例如法律或金融工作。随着模型能力不断提升，代理设计会趋向于让聪明的模型发挥智能，逐步减少人工策展。考虑到行业迅速发展，“做最简单且有效的事”大概率仍是构建 Claude 之类代理的最佳建议。

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

长周期任务要求代理在大量动作序列中保持连贯、上下文一致以及目标导向，即便 Token 数已经超出 LLM 的上下文窗口。对于需要连续工作几十分钟甚至数小时的任务，如大型代码库迁移或综合研究项目，代理需要特殊技巧绕过上下文窗口的限制。

等待更大的上下文窗口似乎是不二之选。但在可预见的未来，各种尺寸的上下文窗口都可能受到上下文污染和信息相关性的困扰——尤其当我们希望获得最强大的代理表现时。为了让代理在长时间跨度中仍能高效工作，我们提出了几种直接应对上下文污染的方法：压缩、结构化笔记和多代理架构。

压缩（Compaction）

压缩是指在对话逼近上下文窗口上限时，对其内容进行总结，并用摘要重新启动一个新的上下文窗口。压缩通常是上下文工程中提升长期连贯性的第一根杠杆。它的核心是以高保真方式提炼上下文窗口的内容，使代理得以在性能几乎不退化的情况下继续任务。

以 Claude Code 为例，我们会将消息历史传递给模型，让其总结并压缩最关键的细节。模型会保留架构决策、尚未解决的缺陷和实现细节，同时丢弃冗余的工具输出或消息。然后代理会带着这些压缩后的上下文，外加最近访问的五个文件继续工作。用户无需担心上下文窗口的限制，也能获得连续性体验。

压缩的艺术在于取舍：过度激进的压缩可能会丢失那些后来才显得重要的细微上下文。对于实现压缩系统的工程师，我们建议在复杂的代理轨迹上仔细调优提示。先最大化召回率，确保压缩提示捕获轨迹中每一条相关信息，再逐步提升精确率，删减多余内容。

一个典型的易删冗余内容是工具调用及其结果。当某个工具在消息历史的深处被调用过，代理再次看到其原始结果的价值有限。最安全且轻量的压缩形式之一就是清理工具结果，这也是我们近期在 Claude 开发者平台 上发布的功能。

结构化笔记（Structured note-taking）

结构化笔记，也称代理记忆，是指代理定期将笔记写入上下文窗口之外的持久存储，当需要时再将这些笔记拉回上下文窗口。

这种策略以极小开销提供持久记忆。无论是 Claude Code 创建待办清单，还是你的自定义代理维护 NOTES.md 文件，这种简单模式都能让代理在复杂任务中追踪进展，保留本会在几十次工具调用中遗失的关键信息与依赖关系。

Claude 玩宝可梦 展示了记忆如何在非编码领域改变代理能力。该代理在成千上万次游戏步骤中保持精准统计——例如，“在过去的 1,234 个回合里，我一直在 1 号道路训练宝可梦，皮卡丘距离目标 10 级又提升了 8 级。”即便没有任何关于记忆结构的提示，它也会自行绘制探索地图，记住已解锁的关键成就，并保留战斗策略笔记，帮助其学习针对不同对手的最佳招式。

在上下文重置后，代理会阅读自己的笔记，继续持续数小时的训练或迷宫探索。这种跨摘要步骤的连贯性，使得在单纯的 LLM 上下文窗口中无法实现的长周期策略成为可能。

在发布 Sonnet 4.5 的同时，我们在 Claude 开发者平台推出了基于文件的记忆工具公开测试版，帮助更轻松地在上下文窗口之外存储和查阅信息。借此，代理可以随着时间积累知识库、在多次会话间维持项目状态，并在无需将所有信息留在上下文中的情况下引用过往工作。

子代理架构（Sub-agent architectures）

子代理架构提供了绕过上下文限制的另一条路径。与其让一个代理在整段项目中维持所有状态，不如让专业化的子代理在干净的上下文窗口中处理聚焦任务。主代理负责高层规划，而子代理深入执行技术工作或使用工具寻找相关信息。每个子代理都可能大量探索，消耗数万 Token，但只会返回压缩凝练的工作总结（通常 1,000-2,000 Token）。

这种方式实现了明确的关注点分离——细节搜索上下文被隔离在子代理内部，主代理则专注于综合与分析结果。正如我们在《我们如何构建多代理研究系统》中讨论的那样，这一模式在复杂研究任务上比单代理系统有显著提升。

选择哪种方法取决于任务特性。例如：

• 压缩适合需要大量往返对话的任务，以维持对话流；
• 笔记适合具有清晰里程碑的迭代开发；
• 多代理架构适合并行探索价值高的复杂研究与分析。

即便模型不断进步，在长时交互中保持连贯性的挑战仍将是打造更高效代理的核心课题。

结论

上下文工程标志着我们构建 LLM 应用方式的一次根本性转变。随着模型能力提升，挑战不再只是打造完美提示——更在于细致策划每一步进入模型有限注意力预算的信息。无论你是在为长周期任务实施压缩、设计 Token 高效的工具，还是让代理在运行时及时探索环境，指导原则始终如一：找到那组最小、但信号最强的 Token，以最大化实现预期结果的可能性。

随着模型持续进化，我们阐述的这些技术也会不断发展。我们已经看到，更智能的模型需要更少的规范性工程，让代理拥有更多自治权。然而，即便能力持续扩张，将上下文视作宝贵且有限的资源，仍然是构建可靠、高效代理的核心。

立即在 Claude 开发者平台上开始实践上下文工程，并通过我们的记忆与上下文管理菜谱获取实用技巧与最佳实践。