收藏必备：大模型智能体开发核心——上下文工程四大策略详解

上下文工程是向智能体轨迹每一步填充恰到好处的信息的艺术与科学。文章提出四种主要策略：写入上下文（将信息保存在上下文窗口外）、选择上下文（拉入相关信息）、压缩上下文（只保留必要token）和隔离上下文（分解上下文）。这些方法包括便签本、记忆管理、摘要、修剪、多智能体系统等，是构建高效AI智能体的核心技术。

AI绘画哇哒哒

896人浏览 · 2025-09-22 15:22:47

AI绘画哇哒哒 · 2025-09-22 15:22:47 发布

智能体需要上下文来执行任务。上下文工程是向智能体轨迹的每一步填充恰到好处的信息的艺术和科学。在这篇文章中，我将上下文工程归纳为当今许多流行智能体中常见的几种策略。在这里插入图片描述

上下文工程

正如安德烈·卡帕西（Andrej Karpathy）所说，大型语言模型（LLM）就像一种新型的操作系统。LLM 类似于 CPU，它的上下文窗口则像是 RAM，充当模型的工作记忆。就像 RAM 一样，LLM 上下文窗口处理各种上下文来源的容量有限。正如操作系统管理什么内容适合 CPU 的 RAM 一样，“上下文工程”也扮演着类似的角色。卡帕西对此总结得很好：

[上下文工程是]“……将恰到好处的信息填充到上下文窗口中以供下一步使用的精妙艺术和科学。” 在这里插入图片描述

那么，在构建 LLM 应用程序时，我们需要管理哪些类型的上下文呢？上下文工程是一个涵盖几种不同上下文类型的总括概念：

指令 – 提示、记忆、少样本示例、工具描述等
知识 – 事实、记忆等
工具 – 工具调用的反馈

智能体的上下文工程

今年，随着 LLM 在推理和工具调用方面变得越来越好，人们对智能体的兴趣也大大增加。智能体交错LLM 调用和工具调用，通常用于长时间运行的任务。

然而，长时间运行的任务和累积工具调用的反馈意味着智能体通常会使用大量的 token。这会导致许多问题：它可能超出上下文窗口的大小，增加成本/延迟，或降低智能体性能。德鲁·布鲁尼格（Drew Breunig）很好地概述了上下文长度可能导致性能问题的几种具体方式，包括：

上下文中毒（Context Poisoning）：当幻觉进入上下文时。
上下文分散（Context Distraction）：当上下文压倒训练时。
上下文混淆（Context Confusion）：当多余的上下文影响响应时。
上下文冲突（Context Clash）：当上下文的某些部分存在分歧时。

考虑到这一点，Cognition 指出了上下文工程的重要性：

“上下文工程”……实际上是构建 AI 智能体的工程师的头号工作。

Anthropic 也明确指出：

智能体通常会进行数百轮对话，需要仔细的上下文管理策略。

那么，现在人们是如何解决这个挑战的呢？我将方法分为 4 类——写入、选择、压缩和隔离——并在下面给出每种方法的示例。

写入上下文

写入上下文意味着将其保存在上下文窗口之外，以帮助智能体执行任务。

便签本（Scratchpads）

当人类解决任务时，我们会做笔记并记住未来的相关任务。智能体也正在获得这些能力！通过“便签本”进行笔记是在智能体执行任务时持久化信息的一种方法。核心思想是将信息保存在上下文窗口之外，以便智能体可以使用它。Anthropic 的多智能体研究员展示了一个清晰的例子：

首席研究员首先思考方法并将其计划保存到内存中以持久化上下文，因为如果上下文窗口超过 200,000 个 token，它将被截断，并且保留计划很重要。

便签本可以通过几种不同的方式实现。它们可以是一个简单的写入文件的工具调用。它也可以只是运行时状态对象中在会话期间持久存在的字段。无论哪种情况，便签本都允许智能体保存有用的信息来帮助它们完成任务。

记忆（Memories）

便签本帮助智能体在给定会话中解决任务，但有时智能体受益于在许多会话中记住事物。Reflexion 引入了在每个智能体回合之后进行反思并重新使用这些自我生成的记忆的想法。Generative Agents 创建了定期从过去智能体反馈集合中合成的记忆。

这些概念已进入流行的产品，例如 ChatGPT、Cursor 和 Windsurf，它们都具有根据用户-智能体交互自动生成长期记忆的机制。

选择上下文

选择上下文意味着将其拉入上下文窗口以帮助智能体执行任务。

便签本（Scratchpad）

从便签本中选择上下文的机制取决于便签本的实现方式。如果它是一个工具，那么智能体只需进行工具调用即可读取它。如果它是智能体运行时状态的一部分，那么开发者可以选择在每个步骤向智能体公开状态的哪些部分。这提供了精细的控制级别，用于在后续回合中向 LLM 公开便签本上下文。

记忆（Memories）

如果智能体能够保存记忆，它们还需要能够选择与正在执行的任务相关的记忆。这可能出于几个原因而有用。智能体可能会选择**少样本示例（情景记忆）**来获取所需行为的示例，**指令（程序记忆）来引导行为，或事实（语义记忆）**来为智能体提供与任务相关的上下文。

一个挑战是确保选择了相关的记忆。一些流行的智能体只是使用一组狭窄的总是被拉入上下文的文件。例如，许多代码智能体使用文件来保存指令（“程序”记忆）或在某些情况下保存示例（“情景”记忆）。Claude Code 使用 CLAUDE.md。Cursor 和 Windsurf 使用规则文件。

但是，如果智能体存储了大量的事实和/或关系（例如，语义记忆），选择就更难了。ChatGPT 是一个流行产品的很好例子，它存储并从大量的用户特定记忆中进行选择。

嵌入和/或知识图谱用于记忆索引通常用于辅助选择。尽管如此，记忆选择仍然具有挑战性。在 AIEngineer 世界博览会上，西蒙·威利森（Simon Willison）分享了一个记忆选择出错的例子：ChatGPT 从记忆中获取了他的位置，并意外地将其注入到请求的图像中。这种意外或不希望的记忆检索可能会让一些用户觉得上下文窗口“不再属于他们”！

工具（Tools）

智能体使用工具，但如果提供的工具过多，它们可能会不堪重负。这通常是因为工具描述可能重叠，导致模型对使用哪个工具感到困惑。一种方法是对工具描述应用 RAG（检索增强生成），以便根据语义相似性为任务获取最相关的工具。一些最近的论文表明，这会将工具选择的准确性提高 3 倍。

知识（Knowledge）

RAG 是一个丰富的主题，可以成为一个核心的上下文工程挑战。代码智能体是 RAG 在大规模生产中最好的例子之一。Windsurf 的 Varun 很好地抓住了其中一些挑战：

索引代码 ≠ 上下文检索……[我们正在进行索引和嵌入搜索……[通过] AST 解析代码并沿语义有意义的边界进行分块……随着代码库的增长，嵌入搜索作为检索启发式变得不可靠……我们必须依赖 grep/文件搜索、基于知识图谱的检索以及……一个重排序步骤的组合，其中 [上下文] 按相关性顺序排序。

压缩上下文

压缩上下文涉及只保留执行任务所需的 token。

上下文摘要（Context Summarization）

智能体交互可以持续数百轮并使用大量 token 的工具调用。摘要是管理这些挑战的常见方式之一。如果你使用过 Claude Code，你就会看到它的作用。当你超过上下文窗口的 95% 时，Claude Code 会运行“自动压缩”，它将总结用户-智能体交互的完整轨迹。这种跨智能体轨迹的压缩可以使用各种策略，例如递归或分层摘要。

在智能体设计的某些点添加摘要也可能很有用。例如，它可以用于后处理某些工具调用（例如，大量 token 的搜索工具）。第二个例子，Cognition 提到了在智能体-智能体边界进行摘要，以在知识交接期间减少 token。如果需要捕获特定的事件或决策，摘要可能是一个挑战。Cognition 为此使用了一个微调模型，这强调了这一步需要投入多少工作。

上下文修剪（Context Trimming）

与摘要通常使用 LLM 来提炼最相关的上下文片段不同，修剪通常可以过滤，或者正如德鲁·布鲁尼格所指出的那样，“修剪”上下文。这可以使用硬编码的启发式方法，例如从消息列表中删除较旧的消息。德鲁还提到了 Provence，一个用于问答的训练有素的上下文修剪器。

隔离上下文

隔离上下文涉及将其分解以帮助智能体执行任务。

多智能体（Multi-agent）

隔离上下文最流行的方法之一是将其分散到子智能体中。OpenAI Swarm 库的动机是“关注点分离”，即一个智能体团队可以处理子任务。每个智能体都有一组特定的工具、指令和自己的上下文窗口。

Anthropic 的多智能体研究员证明了这一点：许多具有独立上下文的智能体优于单一智能体，这主要是因为每个子智能体上下文窗口都可以分配给更狭窄的子任务。正如博客所说：

[子智能体] 并行运行，拥有自己的上下文窗口，同时探索问题的不同方面。

当然，多智能体的挑战包括 token 使用（例如，据 Anthropic 报告，比聊天多高达 15 倍的 token）、需要仔细的提示工程来规划子智能体工作，以及子智能体的协调。

环境中的上下文隔离（Context Isolation with Environments）

HuggingFace 的深度研究员展示了上下文隔离的另一个有趣的例子。大多数智能体使用工具调用 API，它返回 JSON 对象（工具参数），可以传递给工具（例如，搜索 API）以获取工具反馈（例如，搜索结果）。HuggingFace 使用一个 CodeAgent，它输出包含所需工具调用的代码。然后代码在沙盒中运行。然后将从工具调用中选择的上下文（例如，返回值）传递回 LLM。在这里插入图片描述

这允许上下文在环境中与 LLM 隔离。Hugging Face 指出，这是一个隔离大量 token 对象的绝佳方式：

[代码智能体允许] 更好地处理状态……需要存储此图像/音频/其他以供以后使用？没问题，只需将其分配为状态中的变量，你就可以稍后使用它。

状态（State）

值得一提的是，智能体的运行时状态对象也可以是隔离上下文的好方法。这可以起到与沙盒相同的目的。状态对象可以设计有模式（例如，Pydantic 模型），该模式具有可以写入上下文的字段。模式的一个字段（例如，messages）可以在智能体的每个回合中暴露给 LLM，但模式可以在其他字段中隔离信息以进行更具选择性的使用。