Context Engineering: 如何修复上下文

TL;DR 本文讲述了6种上下文处理方式，可以缓解或避免上下文失效的情况：

上下文管理策略

• • RAG(检索增强生成): 有选择地添加相关信息，以帮助大语言模型生成更优的响应。
• • 工具装载(Tool Loadout): 仅选择相关的工具定义添加到上下文当中。
• • 上下文隔离(Context Quarantine: 将不同的上下文分隔在各自专用的线程中。
• • 上下文修剪(Context Pruning): 从上下文中移除无关或不必要的信息。
• • 上下文摘要(Context Summarization): 将累积的上下文浓缩为精简的摘要。
• • 上下文卸载(Context Offloading: 将信息存储在大语言模型的上下文之外，通常通过用于存储和管理数据的工具来实现。

以下原文，Enjoy!

缓解与避免上下文失效

继我们之前的文章长上下文是如何失效的？之后，让我们来详细探讨一下如何缓解或完全避免这些失效情况。

但在开始之前，让我们简要回顾一下长上下文可能失效的几种方式：

• • 上下文中毒(Context Poisoning): 当幻觉或其他错误进入上下文，并被反复引用时。
• • 上下文干扰(Context Distraction): 当上下文变得过长，导致模型过度关注上下文，而忽略了其在训练中学到的知识。
• • 上下文混淆(Context Confusion): 当上下文中的多余信息被模型用来生成低质量的响应时。
• • 上下文冲突(Context Clash): 当你在上下文中积累的新信息和工具与提示中的其他信息发生冲突时。

这里的核心是信息管理。上下文中的一切都会影响响应。我们又回到了那句古老的编程格言：“Garbage in, garbage out（垃圾进，垃圾出。）”幸运的是，我们有很多选项来处理上述问题。

1. RAG

检索增强生成（RAG）是一种选择性地添加相关信息以帮助 LLM 生成更好响应的行为。

关于 RAG 的文章已经铺天盖地，我们今天不打算深入探讨，只想说：它依然很有生命力。

每当有模型提高其上下文窗口的上限时，新一轮“RAG已死”的辩论就会随之而来。最近一次重大事件是 Llama 4 Scout 带着一个一千万token的窗口问世。面对如此大的窗口，你真的会忍不住想：“管他呢，全扔进去就行了”，然后收工。

但是，正如我们上次所讨论的：如果你把上下文当作一个杂物抽屉，那么里面的杂物就会影响你的响应。

2. 工具装载

工具装载（Tool Loadout）指的是只选择相关的工具定义添加到你的上下文中的行为。

“Loadout”（装载）是一个游戏术语，指的是你在进入一个关卡、一场比赛或一轮游戏前所选择的技能、武器和装备的特定组合。通常，你的“装载”是根据具体情境量身定制的——比如你的角色、关卡、团队其他成员的配置以及你自己的技能。

在这里，我们借用这个术语来描述为特定任务选择最相关工具的过程。

也许最简单的工具选择方法就是对你的工具描述应用 RAG。这正是 Tiantian Gan 和 Qiyao Sun 在他们的论文"RAG MCP^[1]"中所做的。通过将工具描述存储在向量数据库中，他们能够根据输入提示选择最相关的工具。

在提示 DeepSeek-v3 时，该团队发现，当你有超过30个工具时，选择正确的工具变得至关重要。超过30个，工具的描述开始重叠，造成混淆。当工具数量超过100个时，模型几乎肯定无法通过他们的测试。使用 RAG 技术来选择少于30个工具，可以显著缩短提示长度，并使工具选择的准确性提高多达3倍。

对于较小的模型，问题在远未达到30个工具时就开始出现了。我们上一篇文章中提到的一篇论文《少即是多（Less is More）^[2]》，证明了 Llama 3.1 8b 在给定46个工具时在一个基准测试中失败了，但在只给定19个工具时却成功了。问题在于上下文混淆，而不是上下文窗口的限制。

为了解决这个问题，《少即是多》背后的团队开发了一种使用 LLM 驱动的工具推荐器来动态选择工具的方法。他们提示 LLM 去推理“它‘认为’回答用户查询所需的工具数量和类型”。然后对这个输出进行语义搜索（同样是工具 RAG），以确定最终的工具装载。他们在伯克利函数调用排行榜（Berkeley Function Calling Leaderboard）上测试了这种方法，发现 Llama 3.1 8b 的性能提高了44%。

《少即是多》论文还指出了上下文更小带来的另外两个好处：降低功耗和提高速度，这在边缘设备（即在你的手机或个人电脑上运行 LLM，而不是在专用服务器上）上运行时是至关重要的指标。即使他们的动态工具选择方法未能改善模型的结果，所节省的功耗和提升的速度也值得付出努力，分别节省了18%和77%。

值得庆幸的是，大多数智能体的应用范围较小，只需要少数几个精心挑选的工具。但如果功能广度或集成数量需要扩展，请务必考虑你的工具装载。

3. 上下文隔离

上下文隔离（Context Quarantine）是将上下文隔离到各自专用线程中的行为，每个线程由一个或多个 LLM 单独使用。

当我们的上下文不太长且不包含无关内容时，我们会得到更好的结果。实现这一点的一种方法是将我们的任务分解为更小的、隔离的工作——每个工作都有自己的上下文。

这种策略有许多例子^[3]，但对这一策略的一个易于理解的阐述来自 Anthropic 的一篇详细介绍其多智能体研究系统的博客文章。他们写道：

搜索的本质是压缩：从庞大的语料库中提炼出洞见。子智能体通过在各自的上下文窗口中并行操作来促进压缩，它们同时探索问题的不同方面，然后将最重要的词元（token）浓缩给主研究智能体。每个子智能体还提供了关注点分离——独特的工具、提示和探索轨迹——这减少了路径依赖，并实现了彻底、独立的调查。

研究任务本身就很适合这种设计模式。当给定一个问题时，可以识别出几个子问题或探索领域，并使用多个智能体分别进行提示。这不仅加快了信息收集和提炼的速度（如果有足够的计算资源），而且还使每个上下文不会累积过多信息或与给定提示无关的信息，从而提供更高质量的结果：

我们的内部评估表明，多智能体研究系统在涉及同时进行多个独立方向探索的广度优先查询中表现尤为出色。我们发现，一个以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在我们的内部研究评估中，其性能比单一智能体的 Claude Opus 4 高出90.2%。例如，当被要求找出信息技术标准普尔500指数中所有公司的董事会成员时，多智能体系统通过将任务分解给子智能体找到了正确答案，而单一智能体系统则因缓慢的顺序搜索而未能找到答案。

这种方法也有助于工具装载，因为智能体设计师可以创建几种具有各自专用工具装载和如何使用每种工具的指令的智能体原型。

因此，对于智能体构建者来说，挑战在于找到可以将孤立任务分拆到独立线程中的机会。需要多个智能体之间共享上下文的问题不太适合这种策略。

如果你的智能体所处的领域适合并行化，请务必阅读 Anthropic 的整篇文章。它非常出色。

4. 上下文修剪

上下文修剪（Context Pruning）是从上下文中移除不相关或不需要的信息的行为。

智能体在调用工具和组合文档时会累积上下文。有时，值得停下来评估一下已经组合了哪些内容，并移除其中的无用部分。你可以将这项任务交给你的主 LLM，或者设计一个单独的由 LLM 驱动的工具来审查和编辑上下文。或者你也可以选择更适合修剪任务的专用工具。

上下文修剪有其（相对）悠久的历史，因为在 ChatGPT 出现之前，上下文长度在自然语言处理（NLP）领域是一个更麻烦的瓶颈。一种基于这段历史的当前修剪方法是 Provence^[4]，一个“用于问答的高效且稳健的上下文修剪器”。

Provence 速度快、准确、易于使用且相对较小——只有 1.75 GB。你可以用几行代码来调用它，就像这样：

from transformers import AutoModel

provence = AutoModel.from_pretrained("naver/provence-reranker-debertav3-v1", trust_remote_code=True)

# 读入加州阿拉米达维基百科条目的 markdown 版本
with open('alameda_wiki.md', 'r', encoding='utf-8') as f:
    alameda_wiki = f.read()

# 根据一个问题来修剪文章
question = 'What are my options for leaving Alameda?'
provence_output = provence.process(question, alameda_wiki)

Provence 对这篇文章进行了编辑，削减了95%的内容，只给我留下了这个相关的子集^[5]。它做得非常完美。

人们可以使用 Provence 或类似的功能来削减文档或整个上下文。此外，这种模式也为维护一个结构化的上下文版本（例如存储在字典或其他形式中）提供了强有力的论据，在每次调用 LLM 之前，可以从这个结构化的版本中编译出一个字符串。这种结构在进行修剪时会非常方便，可以确保主要指令和目标被保留，而文档或历史记录部分则可以被修剪或总结。

5. 上下文摘要

上下文摘要（Context Summarization）是将累积的上下文提炼成一个精简摘要的行为。

上下文摘要最初是作为处理较小上下文窗口的一种工具出现的。当你的聊天会话接近超出最大上下文长度时，系统会生成一个摘要，然后开始一个新的线程。聊天机器人用户在 ChatGPT 或 Claude 中手动完成此操作，要求机器人生成一个简短的回顾，然后将其粘贴到新的会话中。

然而，随着上下文窗口的增大，智能体构建者发现，摘要的好处不仅仅是保持在总上下文限制之内。随着上下文的增长，它会变得分散注意力，并导致模型减少对其在训练中学到的知识的依赖。我们称之为上下文干扰。玩宝可梦的 Gemini 智能体背后的团队发现，任何超过10万词元（token）的内容都会触发这种行为：

虽然 Gemini 2.5 Pro 支持超过一百万词元的上下文，但如何为智能体有效利用它，提出了一个新的研究前沿。在这种智能体设置中，观察到当上下文显著增长超过10万词元时，智能体表现出倾向于重复其庞大历史中的行为，而不是综合出新的计划。这种现象虽然只是坊间传闻，但突显了用于检索的长上下文与用于多步生成式推理的长上下文之间的重要区别。

对你的上下文进行摘要很容易做到，但要为任何给定的智能体做到完美却很难。知道应该保留哪些信息，并向一个由 LLM 驱动的压缩步骤详细说明这一点，对智能体构建者至关重要。将此功能作为一个独立的、由 LLM 驱动的阶段或应用来分离是值得的，这可以让你收集评估数据，从而直接为优化此任务提供信息和支持。

6. 上下文卸载

上下文卸载（Context Offloading）是将信息存储在 LLM 上下文之外的行为，通常通过一个存储和管理数据的工具来实现。

这可能是我最喜欢的策略，只因为它简单到你不敢相信它会奏效。

同样，Anthropic 对这项技术有一篇很好的文章^[6]，详细介绍了他们的“思考（think）”工具，这基本上就是一个草稿板：

通过“思考”工具，我们让 Claude 能够在得出最终答案的过程中，增加一个额外的思考步骤——并为其配备一个指定的空间……这在执行长链条的工具调用或与用户的长多步对话中特别有帮助。

我非常欣赏 Anthropic 发表的研究和其他文章，但我不太喜欢这个工具的名字。如果这个工具叫做“草稿板（scratchpad）”，你会立刻知道它的功能。它是一个让模型可以写下笔记的地方，这些笔记不会干扰其上下文，但又可供日后参考。“思考（think）”这个名字与“扩展思考（extended thinking）”相冲突，并且不必要地将模型拟人化……但扯远了。

拥有一个记录笔记和进展的空间是有效的。Anthropic 的研究表明，将“思考”工具与特定领域的提示（在智能体中你无论如何都会这样做）相结合，可以带来显著的收益，对于专业化智能体，其基准测试性能提升高达54%。

Anthropic 确定了三种上下文卸载模式有用的场景：

1. 1. 工具输出分析。当 Claude 在行动前需要仔细处理先前工具调用的输出，并且可能需要回溯其方法时；
2. 2. 策略密集型环境。当 Claude 需要遵循详细的指导方针并验证合规性时；以及
3. 3. 顺序决策。当每个行动都建立在前一个行动的基础上，且错误代价高昂时（常见于多步领域）。

上下文管理通常是构建智能体最困难的部分。正如 Karpathy 所说，智能体设计师的工作就是“恰到好处地填充上下文窗口(如下图)”，巧妙地部署工具、信息和进行定期的上下文维护。

以上所有策略的关键洞见在于上下文并非没有代价。上下文中的每一个词元（token）都会影响模型的行为，无论好坏。现代 LLM 巨大的上下文窗口是一项强大的能力，但这并不能成为在信息管理上敷衍了事的借口。

当你构建下一个智能体或优化现有智能体时，问问自己：这个上下文中的所有内容是否都物有所值？如果不是，你现在有六种方法来修复它。