[译]Agents的上下文工程

[译]Agents的上下文工程

代理的上下文工程

作者： 兰斯·马丁 (Lance Martin) 日期： 2025年6月23日 来源： https://rlancemartin.github.io/2025/06/23/context_engineering/

内容摘要

智能体需要上下文来执行任务。上下文工程是在智能体运行的每一步，用恰到好处的信息填充上下文窗口的艺术和科学。

在这篇文章中，我将上下文工程分为当今许多流行智能体中常见的几种策略。

  • 写入上下文
  • 选择上下文
  • 压缩上下文
  • 隔离上下文

上下文工程

正如 Andrej Karpathy 所说，大型语言模型（LLM）就像一种新型的操作系统。LLM 就像是 CPU，而它的上下文窗口则像是 RAM，充当模型的工作内存。就像 RAM 一样，LLM 的上下文窗口处理各种上下文来源的能力也是有限的。正如操作系统会管理 CPU 的 RAM 中存放的内容一样，“上下文工程”也扮演着类似的角色。

Karpathy 对此总结得很好：

“[上下文工程是]……在下一步中，用恰到好处的信息填充上下文窗口的精妙艺术和科学。”

上下文的类型

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

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

智能体的上下文工程

今年，随着 LLM 在推理和工具调用方面的能力越来越强，人们对智能体的兴趣大增。智能体将 LLM 调用和工具调用交织在一起，通常用于执行长期任务。

然而，长期运行的任务和来自工具调用的累积反馈意味着智能体通常会使用大量的令牌。这可能会导致许多问题：它可能会超出上下文窗口的大小，增加成本/延迟，或降低智能体性能。

Drew Breunig 很好地概述了较长上下文可能导致性能问题的多种具体方式，包括：

  • 上下文中毒：当幻觉进入上下文时。
  • 上下文干扰：当上下文淹没了训练信息时。
  • 上下文混淆：当多余的上下文影响响应时。
  • 上下文冲突：当部分上下文相互矛盾时。

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

“上下文工程”……实际上是构建人工智能智能体的工程师的首要工作。

Anthropic 公司也清楚地说明了这一点：

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

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

1. 写入上下文

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

  • 暂存器 (Scratchpads)

    • 当人类解决任务时，我们会做笔记并记住一些事情，以备将来处理相关任务时使用。智能体也正在获得这些能力！ 通过“暂存器”做笔记是在智能体执行任务时持久化信息的一种方法。其核心思想是将信息保存在上下文窗口之外，以便智能体可以使用。暂存器可以通过多种方式实现。它们可以是一个简单地写入文件的工具调用。它也可以只是会话期间持久存在的运行时状态对象中的一个字段。

  • 记忆 (Memories)

    • 暂存器可帮助智能体在给定会话中解决任务，但有时智能体需要跨多个会话记住事情。Reflexion 引入了在每个智能体回合后进行反思并重用这些自我生成记忆的想法。生成式智能体 (Generative Agents) 会定期从过去的智能体反馈集合中合成记忆。这些概念已经进入了像 ChatGPT、Cursor 和 Windsurf 这样的流行产品中，它们都有基于用户与智能体交互自动生成长期记忆的机制。

2. 选择上下文

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

  • 暂存器 (Scratchpad)

    • 从暂存器中选择上下文的机制取决于暂存器的实现方式。如果它是一个工具，那么智能体只需通过工具调用就可以读取它。如果它是智能体运行时状态的一部分，那么开发人员可以选择在每一步向智能体公开状态的哪些部分。

  • 记忆 (Memories)

    • 如果智能体有能力保存记忆，它们也需要有能力选择与正在执行的任务相关的记忆。这可能很有用，原因有几个。智能体可能会选择少样本示例（情景记忆）作为期望行为的例子，选择指令（程序记忆）来引导行为，或者选择事实（语义记忆）为智能体提供与任务相关的上下文。一个挑战是确保选择了相关的记忆。一些流行的代理只是使用一小部分总是被拉入上下文的文件。然而，如果一个智能体存储了大量的​​事实和/或关系（例如，语义记忆），选择就变得更加困难。用于记忆索引的嵌入和/或知识图通常用于辅助选择。

  • 工具 (Tools)

    • 智能体使用工具，但如果提供的工具过多，可能会变得不堪重负。这通常是因为工具描述可能会重叠，导致模型混淆使用哪个工具。一种方法是对工具描述应用 RAG（检索增强生成），以便根据语义相似性为任务获取最相关的工具。

  • 知识 (Knowledge)

    • RAG 是一个丰富的主题，可能是一个核心的上下文工程挑战。代码智能体是 RAG 在大规模生产中的一些最佳示例。

3. 压缩上下文

压缩上下文涉及仅保留执行任务所需的令牌。

  • 上下文摘要 (Context Summarization)

    • 智能体交互可以跨越数百轮，并使用令牌密集的工具调用。摘要是管理这些挑战的一种常用方法。可以在智能体设计的某些点添加摘要。例如，它可以用于后处理某些工具调用（例如，令牌密集的搜索工具）。

  • 上下文修剪 (Context Trimming)

    • 摘要通常使用 LLM 来提取最相关的上下文片段，而修剪通常可以过滤或“修剪”上下文。这可以使用硬编码的启发式方法，例如从消息列表中删除较旧的消息。

4. 隔离上下文

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

  • 多智能体 (Multi-agent)

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

  • 带环境的上下文隔离 (Context Isolation with Environments)

    • HuggingFace 的深度研究员展示了另一个有趣的上下文隔离示例。大多数智能体使用工具调用 API，它返回可以传递给工具的 JSON 对象（工具参数）以获取工具反馈。Hugging Face 使用一个 CodeAgent，它输出包含所需工具调用的代码。然后代码在沙箱中运行。来自工具调用的选定上下文（例如，返回值）然后被传递回 LLM。这允许上下文在环境中与 LLM 隔离。

  • 状态 (State)

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

结论

智能体上下文工程的模式仍在不断发展，但我们可以将常见方法分为 4 大类——写入、选择、压缩和隔离。理解和利用这些模式是当今构建有效智能体的核心部分。 原文链接