AI 智能体的高效上下文工程

本文翻译自Claude官方博客的文章，觉得对中文社区的朋友想了解最新的上下文工程实践有所帮助。原文链接在Effective context engineering for AI agents

在经历了几年「提示工程」作为应用 AI 的关注焦点之后，一个新的术语开始走到前台：「上下文工程」（Context  Engineering）。使用语言模型的构建工作，正在逐渐从寻找提示中的正确词句，转变为回答一个更广泛的问题：“哪种上下文配置最有可能生成我们希望模型表现出来的行为？”

上下文指的是在从大语言模型（LLM）中采样时所包含的一组 token。眼前的工程问题是，在 LLM 的固有限制下，优化这些 token 的效用，以便持续稳定地实现期望的结果。有效地驾驭 LLM 通常需要在上下文中思考——换句话说：考虑在任意时间点 LLM 可用的整体状态，以及该状态可能带来的潜在行为。

在本文中，我们将探索新兴的上下文工程艺术，并提供一个精炼的心智模型，用于构建可引导且高效的智能体。

上下文工程 vs 提示工程

在 Anthropic（Claude的开发商），我们认为上下文工程是提示工程的自然演进。提示工程指的是编写和组织 LLM 指令的方法，以获得最佳结果（请参阅我们的文档以了解概览和实用的提示工程策略）。上下文工程指的是在 LLM 推理过程中，策划和维护最佳 token（信息）集合的策略，包括所有可能出现在上下文中的其他信息，而不仅仅是提示。

在使用 LLM 进行工程开发的早期，提示是 AI 工程工作的最大组成部分，因为大多数非日常聊天的用例都需要为一次性分类或文本生成任务优化提示。顾名思义，提示工程的主要焦点是如何编写有效的提示，特别是系统提示。然而，随着我们迈向能在多轮推理和更长时间范围内运行的更强大智能体，我们需要管理整个上下文状态（系统指令、工具、Model Context Protocol (MCP)、外部数据、消息历史等）的策略。

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

提示工程与上下文工程的区别在于：前者是离散的编写提示任务，而后者是迭代的，每次决定要传递给模型的内容时都会发生策划阶段。

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

尽管 LLM 速度快，并能处理越来越大体量的数据，但我们观察到它们和人类一样，在某个点上会失去焦点或产生混乱。“大海捞针”式基准测试揭示了一个概念：上下文腐烂（context rot）。随着上下文窗口中的 token 数量增加，模型从上下文中准确回忆信息的能力下降。

虽然一些模型的性能退化更平缓，但这一特征在所有模型中都会出现。因此，上下文必须被视为一种有限资源，并且存在边际收益递减的现象。就像人类的工作记忆容量有限一样，LLM 也有一个“注意力预算”，当解析大量上下文时，它会消耗这个预算。每引入一个新的 token 都会消耗一定预算，从而增加了对 token 精心策划的需求。

这种注意力稀缺性源自 LLM 的架构约束。LLM 基于 Transformer 架构，使得每个 token 都可以在整个上下文中与其他所有 token 建立注意力关系。这导致 n 个 token 会形成 n² 对关系。

随着上下文长度增加，模型捕捉这些配对关系的能力被拉薄，形成了上下文大小与注意力集中之间的天然张力。此外，模型的注意力模式是从训练数据分布中发展出来的，其中较短的序列通常比较长的序列更常见。这意味着模型在处理全局依赖关系时经验更少、专门参数也更少。

位置编码插值等技术使得模型能够通过将较长序列适配为原始训练的小上下文，从而处理更长的序列，但会在 token 位置理解上有所退化。这些因素带来了性能梯度而不是硬性断崖：模型在较长上下文下仍然非常强大，但与短上下文相比，信息检索和长程推理的精度可能会下降。

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

有效上下文的构成

鉴于 LLM 的注意力预算有限，良好的上下文工程意味着要找到最小的高信号 token 集合，从而最大化实现期望结果的可能性。实施这种实践远比说起来困难，但在下面的部分中，我们会概述这一指导原则在上下文不同组成部分上的具体意义。

系统提示应当非常清晰，并使用简单直接的语言，在合适的高度呈现想法。所谓合适的高度，就是在两种常见失败模式之间找到“恰到好处”的平衡。一种极端情况是工程师在提示中硬编码复杂脆弱的逻辑，以诱导精确的智能体行为。这种方式会导致脆弱性，并随着时间推移增加维护复杂性。另一种极端情况是工程师提供模糊的高层次指导，无法给 LLM 提供明确信号，或者错误地假设了共享上下文。最佳高度在两者之间：既具体到足以有效引导行为，又灵活到可以为模型提供强有力的启发式指导。

我们建议将提示组织成不同部分（例如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题来划分这些部分，尽管随着模型能力增强，提示的确切格式可能变得不那么重要。

无论如何组织系统提示，你都应当追求最小的信息集合，能够完整描述期望的行为。（注意，最小并不一定意味着简短；你仍然需要在一开始给智能体足够的信息，以确保它遵守预期行为。）最好的做法是，先用最好的模型测试一个最小提示，观察它在任务上的表现，然后根据初始测试中发现的失败模式，增加清晰的指令和示例来提高表现。

工具允许智能体与其环境交互，并在工作过程中引入新的附加上下文。由于工具定义了智能体与信息/动作空间之间的契约，因此确保工具能够促进效率极为重要——既要通过返回 token 高效的信息来节省上下文预算，又要鼓励智能体产生高效的行为。

在 《为 AI 智能体编写工具——用 AI 智能体编写工具》 一文中，我们讨论了如何构建 LLM 能很好理解的工具，并确保工具功能之间的重叠最小。类似于设计良好的代码库，工具应当是自包含的、能够容错的，并且在预期用途上极其清晰。输入参数同样应当具有描述性、不含歧义，并能发挥模型的固有优势。

我们最常见的一种失败模式是工具集合臃肿：覆盖的功能过多，或者在选择使用哪个工具时存在模糊的决策点。如果一个人类工程师都不能明确说出在某种情况下该使用哪个工具，那我们不能指望 AI 智能体表现得更好。正如我们稍后会讨论的，为智能体提供一个最小可行的工具集合，还能在长期交互中提高维护可靠性并便于上下文的修剪。

提供示例，也就是少样本提示(few-short)，一直是一种被广泛认可的最佳实践，我们仍然强烈建议使用。然而，团队通常会在提示中塞入一长串边界情况，试图明确规定 LLM 在某个任务中应该遵循的每一条规则。我们并不推荐这样做。相反，我们建议精心挑选一组多样化、具有代表性的示例，能够有效地展示智能体的预期行为。对于 LLM 来说，示例就是“一图胜千言”。

在上下文的不同组成部分（系统提示、工具、示例、消息历史等）中，我们的总体建议是：保持深思熟虑，让上下文既有信息量，又保持紧凑。

接下来，我们将深入探讨如何在运行时动态检索上下文。

上下文检索与智能体搜索

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

在与客户的合作中，我们看到业界正在收敛到这种简单的范式。随着底层模型的能力增强，智能体的自主性水平也在扩展：更聪明的模型让智能体能够独立导航复杂的问题空间，并从错误中恢复。

我们现在看到工程师们在设计智能体上下文时的思维方式正在发生转变。今天，许多 AI 原生应用都采用某种基于嵌入的推理前检索机制，以便为智能体提供重要的上下文进行推理。随着行业向更具自主性的智能体方法转变，我们越来越多地看到团队将这些检索系统与“即时上下文”（just in time context）策略相结合。

与其在推理前预处理所有相关数据，不如使用“即时”方法的智能体只维护轻量级的标识符（文件路径、存储查询、网页链接等），并使用这些引用在运行时通过工具动态加载数据。Anthropic 的智能体编码解决方案 Claude Code 就采用了这种方式，它可以在大型数据库上执行复杂的数据分析。模型能够编写有针对性的查询、存储结果，并利用 head 和 tail 等 Bash 命令来分析大量数据，而无需一次性加载整个数据对象到上下文中。

这种方法与人类认知相似：我们通常不会记住整套信息，而是引入外部的组织与索引系统，如文件系统、收件箱和书签，以便按需检索相关信息。

除了存储效率之外，这些引用的元数据还提供了一种高效优化行为的机制，无论是显式的还是隐含的。对于一个在文件系统中运行的智能体来说，一个位于 tests 文件夹中的 test_utils.py 文件，其用途与位于 src/core_logic.py 文件夹中的同名文件显然不同。文件夹层次结构、命名约定和时间戳，都提供了重要信号，帮助人类和智能体理解如何以及何时使用这些信息。

允许智能体自主导航和检索数据，还能够实现逐步披露（progressive disclosure）——换句话说，让智能体通过探索逐步发现相关上下文。每一次交互都会产生新的上下文，从而影响下一步的决策：文件大小可以暗示复杂度，命名约定暗示用途，时间戳可以作为相关性的代理。智能体可以逐层构建理解，只在工作记忆中保留必要内容，并利用笔记策略来增加持久性。这样自我管理的上下文窗口，让智能体专注于相关子集，而不是淹没在庞大但可能无关的信息中。

当然，这种方式存在权衡：运行时探索比预先检索数据要慢。不仅如此，还需要经过深思熟虑的工程设计，确保 LLM 拥有正确的工具和启发式方法，能够有效地在信息环境中导航。缺乏恰当引导的情况下，智能体可能会浪费上下文，错误使用工具、陷入死胡同，或者无法识别关键信息。

在某些场景下，最有效的智能体可能会采用混合策略：预先检索部分数据以加快速度，同时在需要时进一步进行自主探索。选择合适的自主水平取决于任务类型。Claude Code 就采用了这种混合模型：CLAUDE.md 文件会被直接放入上下文，而 glob 和 grep 等基本命令则允许它在运行时导航环境并即时检索文件，从而有效避免索引陈旧和复杂语法树带来的问题。

混合策略可能更适用于内容不那么动态的场景，例如法律或金融工作。随着模型能力的提升，智能体设计将趋向于让智能模型以更智能的方式行事，并且需要越来越少的人类策划。考虑到该领域快速发展的节奏，“做最简单可行的事情”可能仍将是为 Claude 构建智能体团队的最佳建议。

长期任务中的上下文工程

长期任务要求智能体在一系列超过 LLM 上下文窗口限制的动作中，保持连贯性、上下文一致性和目标导向的行为。对于那些持续数十分钟甚至数小时的连续工作任务，比如大型代码库迁移或全面的研究项目，智能体需要专门的技术来绕过上下文窗口大小的限制。

等待更大的上下文窗口似乎是一个显而易见的策略。但在可预见的未来，任何大小的上下文窗口都可能受到上下文污染和信息相关性问题的困扰——尤其是在需要最强智能体性能的情况下。为了让智能体能在较长时间范围内高效工作，我们开发了几种直接应对上下文污染约束的技术：压缩（compaction）、结构化笔记（structured note-taking）和多智能体架构（multi-agent architectures）。

压缩（Compaction）

压缩是一种做法：当会话接近上下文窗口限制时，对其内容进行总结，并用该总结重新启动一个新的上下文窗口。压缩通常是上下文工程中的第一根杠杆，用于推动更好的长期连贯性。本质上，压缩是对上下文窗口内容进行高保真提炼，使智能体能在最小化性能下降的情况下继续任务。

例如，在 Claude Code 中，我们通过将消息历史传递给模型，让其总结和压缩最关键的细节来实现这一点。模型会保留架构决策、未解决的 bug 和实现细节，同时丢弃冗余的工具输出或消息。随后，智能体可以在这个压缩后的上下文基础上，加上最近访问过的五个文件继续任务。用户因此能够获得连贯性，而不必担心上下文窗口的限制。

压缩的艺术在于选择保留什么、舍弃什么。过度激进的压缩可能会丢失一些微妙但至关重要的上下文，而这些上下文的重要性可能会在后续才显现。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹上仔细调优提示。首先最大化召回率，确保压缩提示能捕获轨迹中所有相关信息；然后迭代改进精确度，逐步去除多余内容。

一个显而易见的多余内容是工具调用及其结果——一旦工具调用已经深埋在消息历史中，为什么智能体还需要再次看到原始结果？一种最安全、最轻量化的压缩方式就是清除工具结果，这也是 Claude 开发者平台最近上线的一项功能。

结构化笔记（Structured Note-taking）

结构化笔记（或称智能体记忆，agentic memory）是一种技术：智能体定期将笔记写入上下文窗口之外的持久存储中。这些笔记可以在之后被重新拉回到上下文窗口中。

这种策略为持久记忆提供了最小开销。例如，Claude Code 会创建一个待办事项(to-do)列表，或者你的自定义智能体维护一个 NOTES.md 文件。这个简单模式允许智能体在复杂任务中跟踪进展，保留那些否则会在数十次工具调用中丢失的关键上下文和依赖。

Claude 玩《精灵宝可梦》的案例展示了记忆如何改变智能体在非编程领域的能力。智能体能在数千步的游戏中保持精确统计——比如“在过去的 1234 步里，我一直在 1 号道路训练宝可梦，皮卡丘已经从目标的 10 级中提升了 8 级。”在没有任何提示指明记忆结构的情况下，它会自行发展地图，记住已经探索的区域，追踪解锁的关键成就，并保留战斗策略的笔记，以帮助它学习哪些攻击对不同对手最有效。

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

作为 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上推出了记忆工具的公开测试版，它让开发者更容易通过基于文件的系统在上下文窗口之外存储和查阅信息。这使得智能体能够随着时间积累知识库，在不同会话中维护项目状态，并在不必将所有信息放进上下文的情况下引用先前的工作。

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

子智能体架构提供了另一种绕过上下文限制的方式。与其让一个智能体尝试在整个项目中维护状态，不如让专门的子智能体处理聚焦任务，每个子智能体都拥有干净的上下文窗口。主智能体则通过高层次的计划进行协调，而子智能体执行深入的技术工作，或利用工具找到相关信息。

每个子智能体都可能进行广泛的探索，使用数万甚至更多的 token，但最终只会返回其工作的简洁总结（通常 1000–2000 token）。

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

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

• 压缩适用于需要广泛来回交流的任务；
• 笔记适用于具有清晰里程碑的迭代开发；
• 多智能体架构适用于复杂的研究与分析，在并行探索中能获得收益。

即使模型继续改进，如何在长时间交互中保持连贯性仍将是构建更高效智能体的核心挑战。

总结

上下文工程代表了我们使用 LLM 的构建方式的一次根本性转变。随着模型能力的增强，挑战已不再只是打造完美的提示——而是如何深思熟虑地策划，在每一步中进入模型有限注意力预算的信息。

无论你是在为长期任务实现压缩（compaction），设计 token 高效的工具，还是让智能体以“即时”方式探索其环境，指导原则始终如一：找到最小的高信号 token 集合，以最大化达成目标结果的可能性。

随着模型不断改进，这些技术也会持续演进。我们已经看到，更智能的模型需要更少的规定性工程，允许智能体以更高的自主性运行。但即使能力在扩展，将上下文视为一种宝贵且有限的资源，依然会是构建可靠、高效智能体的核心。

今天就可以在 Claude 开发者平台上开始尝试上下文工程，并通过我们的记忆与上下文管理手册获取有用的技巧与最佳实践。

致谢

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

本篇文章来源于微信公众号: PixelsTech