智能体需要上下文（如指令和工具反馈）来执行任务。上下文工程就是在智能体的每一步操作中，将恰到好处的信息填充到上下文窗口中的艺术与科学。本文将当下流行的智能体所采用的上下文工程策略归纳为几种常见方法。
上下文工程
正如 Andrej Karpathy 所说，大型语言模型（LLM）就像一种新的操作系统。LLM 就像是 CPU，其上下文窗口则类似于 RAM，作为模型的工作内存。与 RAM 一样，LLM 上下文窗口处理各种上下文来源的能力也是有限的。而上下文工程的作用与操作系统筛选进入 CPU 内存的内容类似，正如 Karpathy 所总结的那样：
“上下文工程是为下一步操作精准填充上下文窗口的精细艺术与科学”。
在构建 LLM 应用时，我们需要管理以下几种类型的上下文：
- 指令
提示、记忆、少量样本示例、工具描述等。 - 知识
事实、记忆等。 - 工具
工具调用的反馈。
智能体的上下文工程
随着 LLM 在推理和工具调用方面的能力不断提升，今年智能体技术受到了极大的关注。智能体通过交替调用 LLM 和工具来执行任务，这些任务往往持续时间较长。
然而，长期任务以及工具调用积累的反馈意味着智能体常常会使用大量 tokens（语言模型中的基本单位），这可能导致诸多问题：超出上下文窗口容量、成本 / 延迟增加或智能体性能下降。Drew Breunig 很好地概述了长上下文可能引发的具体性能问题，包括：
- 上下文污染
当幻觉信息进入上下文时。 - 上下文干扰
当上下文压倒了训练内容时。 - 上下文混淆
当多余上下文影响了响应时。 - 上下文冲突
当上下文各部分相互矛盾时。
鉴于此，Cognition 强调了构建智能体时上下文工程的重要性：
“上下文工程实际上是构建 AI 智能体的工程师的首要任务。”
Anthropic 也清楚地指出了这一点：
“智能体常常参与跨越数百轮的对话，需要精心的上下文管理策略。”
在本文中，我将分解一些常见的智能体上下文工程策略 ——写入、选择、压缩和隔离。
写入上下文
写入上下文是指将上下文保存到上下文窗口之外，以帮助智能体执行任务。
便签
当人类解决问题时，我们会做笔记并记住相关事项以备将来使用。智能体也在获得这些能力！通过“便签”进行记笔记是一种在智能体执行任务期间持久化信息的方法。核心思想是将信息保存到上下文窗口之外，以便智能体按需获取。Anthropic 的多智能体研究员给出了一个清晰的例子：
“LeadResearcher 首先思考方法，并将其计划保存到内存中以持久化上下文，因为如果上下文窗口超过 200,000 tokens 就会被截断，而保留计划非常重要。”
值得注意的是，便签可以通过多种方式实现。它可以是一个写入文件的工具调用，也可以是会话期间持久化的运行时状态对象中的一个字段。无论哪种方式，其直觉都很明确：便签让智能体在会话期间保存有用信息，以帮助它们完成任务。
记忆
便签有助于智能体在给定会话中解决问题，但有时智能体需要跨多个会话记住事物！Reflexion 引入了在每个智能体回合后进行反思并在后续回合中重用这些自我生成提示的想法。Generative Agents 定期从过去的智能体反馈集合中合成记忆。
这些概念已被 ChatGPT、Cursor 和 Windsurf 等流行产品采用，它们都具有基于用户 - 智能体交互自动生成长期记忆的机制。
选择上下文
选择上下文是指将上下文拉入上下文窗口，以帮助智能体执行任务。
便签
从便签中选择上下文的机制取决于便签的实现方式。如果便签是一个工具，那么智能体可以通过工具调用简单地读取它。如果它是智能体运行时状态的一部分，那么开发者可以选择在每一步中向智能体暴露状态的哪些部分，从而为智能体提供细粒度的上下文控制。
记忆
如果智能体有能力保存记忆，它们也需要选择与所执行任务相关的记忆。这有几个用途。智能体可能会选择少量样本示例（情景记忆）作为期望行为的示例，选择指令（程序记忆）来引导行为，或者选择事实（语义记忆）以提供与任务相关的上下文。
一个挑战是确保选择相关记忆。一些流行智能体仅使用一组有限的文件来存储记忆。例如，许多代码智能体使用“规则”文件保存指令（“程序记忆”）或在某些情况下保存示例（“情景记忆”）。Claude Code 使用 CLAUDE.md 文件，Cursor 和 Windsurf 使用规则文件，这些文件始终被拉入上下文。
但是，如果智能体存储了大量的事实和 / 或关系（语义记忆），选择就变得困难了。ChatGPT 就是一个很好的例子。在 AIEngineer 世界博览会上，Simon Willison 分享了一个记忆选择出错的例子：ChatGPT 获取了他的位置信息并将其注入到他请求的图片中。这种错误的记忆检索可能让用户觉得上下文窗口“不再属于自己”！为了辅助选择，可以使用嵌入和 / 或知识图谱对记忆进行索引。
工具
智能体使用工具，但如果提供过多工具，智能体可能会不堪重负。这通常是因为工具描述可能会重叠，导致模型在选择使用哪个工具时产生困惑。一种方法是将 RAG 应用于工具描述，以基于语义相似性提取与任务最相关的工具，Drew Breunig 将此称为“工具负载”。一些近期论文表明，这种方法可以将工具选择准确性提高 3 倍。
知识
RAG（检索增强生成）是一个非常丰富的话题。代码智能体是大规模生产中智能体 RAG 的最佳例子之一。在实践中，RAG 可能是一个核心的上下文工程挑战。Windsurf 的 Varun 很好地总结了一些这些挑战：
“索引代码 ≠ 上下文检索……[我们正在做索引和嵌入搜索……使用 AST 解析代码并沿语义边界进行分块……随着代码库规模的扩大，嵌入搜索作为检索启发式方法变得不可靠……我们必须依赖多种技术的组合，如 grep/文件搜索、基于知识图谱的检索，以及……重新排序步骤，按相关性对 [上下文] 进行排名。”
压缩上下文
压缩上下文涉及仅保留执行任务所需的 tokens。
上下文总结
智能体交互可能跨越数百轮并使用 token 密集型工具调用。总结是管理这些挑战的一种常见方法。如果你使用过 Claude Code，你就会看到这一点。Claude Code 在用户 - 智能体交互超出上下文窗口的 95% 时运行“自动压缩”，并会总结完整的用户 - 智能体交互轨迹。这种跨越智能体轨迹的压缩可以使用递归或分层总结等各种策略。
此外，在智能体的轨迹中添加总结也很有用。例如，它可用于后处理某些工具调用（例如，token 密集型搜索工具）。Cognition 提到在智能体 - 智能体边界处进行总结以实现知识交接。他们还提到了捕获特定事件或决策的挑战。他们在 Devin 中使用了微调模型来完成这一步，这凸显了这一步骤可能需要付出多少努力。
上下文修剪
与总结通常使用 LLM 提炼最相关的上下文片段不同，修剪通常可以使用启发式方法过滤或正如 Drew Breunig 所指出的“剪枝”上下文。例如，可以从消息列表中移除较旧的消息。Drew 的文章还提到了 Provence，这是一个用于问答的微调 LLM 实用程序，可执行上下文修剪。
隔离上下文
隔离上下文涉及将上下文拆分以帮助智能体执行任务。
多智能体
将上下文拆分到子智能体中是一种最流行且直观的方法。OpenAI Swarm 库的一个动机是“关注点分离”，即一组智能体可以处理子任务。每个智能体都有特定的工具集、指令和自己的上下文窗口。
Anthropic 的多智能体研究员清楚地指出了这样做的好处：许多具有隔离上下文的智能体在性能上超过了单智能体 90.2%，这主要是因为每个子智能体的上下文窗口可以分配给更窄的子任务。正如博客所述：
“[子智能体并行运行，每个子智能体都有自己的上下文窗口，同时探索问题的不同方面。]”
当然，多智能体的挑战包括 token 使用量（例如，比聊天多 15 倍 token）、需要精心设计提示以规划子智能体工作以及协调子智能体。
使用环境隔离上下文
HuggingFace 的深度研究员展示了另一种有趣的上下文隔离方法。大多数智能体使用工具调用 API，这些 API 返回可以传递给工具（例如，搜索 API）以获取工具反馈（例如，搜索结果）的 JSON 对象。HuggingFace 使用 CodeAgent，该智能体输出用于调用工具的代码。然后代码在沙盒中运行。从代码执行中选择的上下文（例如，返回值）随后被传递回 LLM。
这允许上下文在环境中被隔离，位于 LLM 上下文窗口之外。Hugging Face 指出，这是隔离 token 密集型对象的一种好方法：
“[代码智能体允许更好地处理状态……需要稍后存储此图像 / 音频 / 其他内容？没问题，只需将其作为变量分配到你的状态中，稍后可以使用它。]”
状态
值得一提的是，智能体的运行时状态对象也是隔离上下文的好方法。这可以服务于与沙盒相同的目的。状态对象可以使用模式进行设计（例如，Pydantic 模型），该模式具有可以写入上下文的各种字段。模式的一个字段（例如，messages）可以在智能体的每一步中暴露给 LLM，但模式可以将信息隔离在其他字段中以供更具选择性的使用。
结论
当下许多流行智能体展示了以下几种常见的上下文工程模式：
- 写入上下文是指将上下文保存到上下文窗口之外，以帮助智能体执行任务。
- 选择上下文是指将上下文拉入上下文窗口，以帮助智能体执行任务。
- 压缩上下文涉及仅保留执行任务所需的 tokens。
- 隔离上下文涉及将上下文拆分以帮助智能体执行任务。
