有效的Agent上下文工程｜Anthropic

Created time

Mar 24, 2026 10:01 AM

AI 代理的有效上下文工程

在提示词工程（prompt engineering）成为应用 AI 领域焦点几年后，一个新术语开始崭露头角：上下文工程（context engineering）。

大语言模型（LLM）的开发重心正从寻找“完美的提示词”，转向回答一个更宏大的问题：“什么样的上下文配置最能引导模型产生预期的行为？”

上下文是指在对大语言模型进行采样时所包含的标记（token）集合。

而工程的核心挑战在于：在 LLM 固有的约束条件下，优化这些标记的效用，以稳定地达成目标。

要高效地驾驭 LLM，往往需要“在上下文中思考”——即审视模型在任何给定时刻所处的整体状态，并预判该状态可能引发的行为。

本文将探讨这一新兴的上下文工程艺术，并为构建可控且高效的代理提供一套精炼的思维模型。

上下文工程 vs. 提示词工程

在 Anthropic，我们将上下文工程视为提示词工程的自然演进。提示词工程侧重于编写和组织指令以获得最佳结果；而上下文工程则涵盖了在 LLM 推理过程中，管理和筛选最优标记集合（信息）的一系列策略，这包括了提示词之外的所有输入信息。

在 LLM 开发初期，提示词工程是工作重心，因为大多数应用场景仅需针对单次分类或生成任务优化提示词。然而，随着我们转向构建能够跨多轮推理、在更长时域内运行的智能代理，我们需要管理整个上下文状态（系统指令、工具、模型上下文协议 (MCP)、外部数据、消息历史等）的策略。

代理在循环运行中会产生越来越多的数据，这些数据可能对下一轮推理至关重要，因此必须进行周期性的精炼。上下文工程就是从不断演变的庞大信息库中，筛选出进入有限上下文窗口内容的艺术与科学。

与编写提示词这一离散任务不同，上下文工程是迭代式的，且筛选过程发生在每次决定向模型输入什么内容时。

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

尽管 LLM 处理数据的速度和容量都在提升，但我们观察到，模型和人类一样，在达到一定程度时会失去焦点或产生困惑。针对“大海捞针”式基准测试的研究揭示了上下文衰减（context rot）的概念：随着上下文窗口中标记数量的增加，模型准确提取信息的能力会下降。

虽然不同模型的衰减程度各异，但这一特性普遍存在。因此，必须将上下文视为一种边际收益递减的有限资源。

正如人类拥有有限的工作记忆容量一样，LLM 在解析大量上下文时也受限于“注意力预算”。每引入一个新的标记都会消耗部分预算，这使得精确筛选输入标记变得愈发必要。

这种注意力稀缺源于 LLM 的 Transformer 架构。该架构允许每个标记与上下文中的所有其他标记进行关联，从而产生 n² 数量级的两两关系。

随着上下文长度增加，模型捕捉这些关系的能力会被拉薄，导致上下文规模与注意力焦点之间产生天然的张力。

此外，模型在训练数据中接触到的短序列远多于长序列，因此缺乏处理长距离依赖的经验和专门参数。

尽管位置编码插值等技术能让模型处理长序列，但往往伴随着位置理解能力的下降。

这些因素共同导致了性能的平滑下滑，而非断崖式下跌：模型在长上下文中依然强大，但在信息检索和长程推理的精度上可能不及短上下文。

这些现实表明，深思熟虑的上下文工程是构建高性能代理的关键。

有效上下文的构成

鉴于 LLM 受限于有限的注意力预算，优秀的上下文工程意味着：寻找最小化的高信号标记集合，以最大化达成预期结果的可能性。这一原则在实践中应如何体现？

系统提示词应极其清晰，使用简单直接的语言，将想法呈现于“恰当的高度”。

所谓“恰当的高度”，是指在两种常见失败模式之间找到平衡点：

一种是硬编码复杂且脆弱的逻辑，导致维护困难；另一种是提供模糊的高层指导，导致模型缺乏具体信号。

最佳高度应既能有效引导行为，又具备足够的灵活性。

我们建议将提示词划分为不同部分（如 <background_information>, <instructions>, ## Tool guidance 等），并使用 XML 标签或 Markdown 标题进行界定。

无论结构如何，目标始终是：用最精简的信息完整勾勒出预期行为。建议从极简提示词开始测试，根据失败模式逐步补充指令和示例。

工具使代理能够与环境交互并获取额外上下文。

工具定义了代理与信息/行动空间之间的契约，因此必须确保工具的高效性，既要保证返回信息的标记利用率，又要引导代理的高效行为。

最常见的错误是工具集过于臃肿，导致功能重叠或决策歧义。如果人类工程师都无法明确判断在某种情况下该用哪个工具，就不能指望 AI 代理做得更好。精简的工具集不仅能提升性能，也更易于维护。

示例（少样本提示）是公认的最佳实践，但不要试图在提示词中堆砌所有边缘案例。相反，应精心挑选一组具有代表性的典型示例，它们比千言万语更能直观地展示预期行为。

总之，无论是系统提示词、工具、示例还是消息历史，核心原则都是：保持上下文信息丰富且紧凑。

动态检索与代理自主性

随着模型能力提升，代理的自主性也在增强。许多 AI 应用正从预处理检索转向“即时（just-in-time）”上下文策略。

代理无需预先处理所有数据，而是维护轻量级的标识符（文件路径、查询语句、链接等），并在运行时通过工具动态加载数据。

例如，Anthropic 的 Claude Code 能够编写针对性查询并利用 Bash 命令分析海量数据，而无需将完整对象载入上下文。

这模拟了人类的认知方式：我们不会记忆所有信息，而是通过文件系统或书签等索引系统按需检索。

让代理自主导航和检索数据，还实现了“渐进式披露”——代理可以在探索中逐步发现相关上下文。

当然，这种方式存在权衡：运行时探索比预取数据更慢，且需要精心设计的工具和启发式规则，否则代理可能会误用工具或陷入死胡同。

在某些场景下，混合策略（预取部分数据以保证速度，同时允许自主探索）最为有效。

长时域任务的上下文工程

对于跨越数十分钟甚至数小时的任务（如大型代码库迁移），代理需要专门的技术来突破上下文窗口限制：

压缩（Compaction）： 当对话接近窗口上限时，对内容进行总结并重置上下文。关键在于保留架构决策、未解 Bug 等核心信息，剔除冗余的工具输出。

结构化笔记（Structured note-taking）： 即“代理记忆”。代理定期将笔记写入上下文窗口之外的存储空间（如 NOTES.md），并在后续需要时调取。这使得代理能够跨会话维持状态和进度。

子代理架构（Sub-agent architectures）： 将复杂任务拆解，由专门的子代理处理具体工作，仅向主代理返回精炼的总结。这种分工能有效隔离搜索上下文，提升整体效率。

结语

上下文工程代表了 LLM 开发范式的根本转变。

随着模型能力增强，挑战不再仅仅是编写完美的提示词，而是如何审慎地筛选进入模型有限注意力预算的信息。

无论采用压缩、笔记还是动态检索，核心原则始终不变：以最小的高信号标记集合，最大化实现预期目标。

即使未来模型能力持续升级，将上下文视为一种珍贵的有限资源，仍将是构建可靠、高效 AI 代理的基石。