[译]如何修复你的上下文
缓解与避免上下文失效
承接我们早前的文章《 上下文失效的持续时间 》，下面我们将全面探讨如何缓解或彻底避免这些失效情况。
但在开始之前，我们先简要回顾长上下文可能失效的几种情况：
上下文污染： 当幻觉或其他错误进入上下文并被反复引用时。
上下文干扰： 当上下文过长导致模型过度关注上下文，而忽略了训练期间学到的知识。
上下文混淆： 当模型使用上下文中多余的信息生成低质量响应时。
上下文冲突： 当你在上下文中积累的新信息和工具与提示中的其他信息产生矛盾时。
这里的一切都关乎信息管理。上下文中的所有内容都会影响响应。我们又回到了那句古老的编程格言：“ 输入垃圾，输出垃圾 ”。幸运的是，处理上述问题有很多方法可选。
上下文管理策略
检索增强生成
检索增强生成（RAG）是指有选择性地添加相关信息，以帮助 LLM 生成更好的响应
关于 RAG 已有大量论述，今天我们不再赘述，只需说明：它仍然非常活跃。
每当模型提升上下文窗口的容量上限，新一轮"RAG 已死"的争论就会兴起。上一次重大事件是 Llama 4 Scout 带着 1000 万 token 窗口问世时。面对如此规模，人们确实容易产生"管他呢，全扔进去就完事了"的想法。
但正如我们上次讨论的：如果你把上下文当作杂物抽屉对待，那些杂乱信息就会影响你的反应 。若想深入了解，这里有个看起来很棒的新课程 。
工具配置
工具加载是指仅选择相关的工具定义添加到您的上下文中。
"装备配置"（loadout）是一个游戏术语，指你在关卡、比赛或回合开始前选择的具体能力、武器和装备组合。通常，你的装备配置会根据具体情境进行调整——包括角色特性、关卡设计、团队构成以及你自身的技能组合。
在此，我们借用这个术语来描述为特定任务选择最相关工具的过程。
或许最简单的工具选择方法就是对工具描述应用检索增强生成（RAG）。这正是田甜干和孙启尧在他们题为《RAG MCP》的论文中详细阐述的方法。通过将工具描述存储在向量数据库中，他们能够根据输入提示选择最相关的工具。
团队在使用 DeepSeek-v3 时发现，当工具数量超过 30 个时，选择合适的工具变得至关重要。超过 30 个后，工具描述开始出现重叠，造成混淆。当工具数量超过 100 个时，模型几乎必定无法通过测试。采用 RAG 技术将工具筛选至 30 个以内后，提示词长度显著缩短，工具选择准确率最高可提升 3 倍。
对于小型模型来说，问题早在工具数量达到 30 个之前就已出现。我们在上一篇文章中提到的论文《 少即是多 》表明，当提供 46 个工具时，Llama 3.1 8b 模型无法通过基准测试，而仅提供 19 个工具时却能成功。问题的根源在于上下文混淆， 而非上下文窗口的限制。
为解决这一问题，"少即是多"团队开发了一种利用 LLM 驱动的工具推荐器动态选择工具的方法。他们提示 LLM 进行推理："完成用户查询所需工具的数量和类型"。随后通过语义搜索（再次使用工具 RAG）来确定最终的工具组合。该团队在 Berkeley Function Calling Leaderboard 上测试了这种方法，发现 Llama 3.1 8b 的性能提升了 44%。
《少即是多》这篇论文指出了较小上下文环境的另外两个优势：降低功耗和提高速度，这些在边缘计算（即在手机或个人电脑而非专用服务器上运行 LLM）时尤为关键。即使其动态工具选择方法未能提升模型效果，节省的 18%功耗和 77%速度提升也使得这种努力物有所值。
幸运的是，大多数智能体的功能范围较小，只需少量精心挑选的工具。但如果需要扩展功能广度或集成数量，务必考虑您的工具配置。
上下文隔离
上下文隔离是指将上下文隔离在各自专用的线程中，每个线程由一个或多个 LLMs 单独使用。
当上下文内容不过长且不包含无关信息时，我们能看到更好的效果。实现这一点的方法之一是将任务拆分为更小、独立的作业——每个作业拥有自己的上下文。
这种策略有诸多实例 ，但 Anthropic 公司详细介绍其多代理研究系统的博客文章对此做了通俗易懂的阐述。文中写道：
搜索的本质在于压缩：从海量文本中提炼洞见。子代理通过并行运作各自的上下文窗口来促进压缩过程，同时探索问题的不同方面，然后为首席研究代理浓缩最重要的标记。每个子代理还实现了关注点分离——使用不同的工具、提示和探索路径——这减少了路径依赖，使得全面而独立的研究成为可能。
这种设计模式特别适合研究工作。面对一个问题时，可以识别出若干子问题或探索方向，并使用多个智能体分别处理。这不仅在有足够计算资源的情况下加速了信息收集和提炼过程，还能防止每个上下文积累过多信息或与当前提示无关的内容，从而提供更高质量的结果：
我们的内部评估显示，多智能体研究系统特别擅长处理广度优先查询，这类查询需要同时追踪多个独立方向。我们发现，以 Claude Opus 4 为主导智能体、Claude Sonnet 4 为子智能体组成的多智能体系统，在我们的内部研究评估中表现比单智能体 Claude Opus 4 高出 90.2%。例如，当被要求识别信息技术类标普 500 指数成分公司的所有董事会成员时，多智能体系统通过将任务分解给子智能体找到了正确答案，而单智能体系统则因缓慢的串行搜索未能找到答案。
这种方法也有助于工具配置，因为智能体设计者可以创建多个具有专用工具配置的智能体原型，并为每个工具的使用提供具体说明。
因此，智能体构建者面临的挑战在于寻找机会将独立任务拆分到不同线程上执行。那些需要多个智能体间共享上下文的问题则不太适合采用这种策略。
如果你的智能体领域适合并行处理，务必阅读 Anthropic 的完整文章 ，内容非常出色。
上下文剪枝
上下文剪枝是指从上下文中移除无关或冗余信息的操作。
智能体在执行工具调用和文档整合时会不断积累上下文。有时值得暂停操作，评估已整合的内容并剔除冗余信息。这项工作可以交由主 LLM 处理，也可以设计一个独立的 LLM 驱动工具来审查编辑上下文，或者选择更专注于剪枝任务的专用方案。
上下文剪枝技术有着（相对）悠久的历史，因为在 ChatGPT 出现之前，上下文长度一直是自然语言处理（NLP）领域更突出的瓶颈。基于这一历史背景，当前的剪枝方法中出现了普罗旺斯 ——"一个面向问答系统的高效鲁棒型上下文修剪器"。
普罗旺斯（Provence）速度快、精度高、使用简单且体积相对较小——仅 1.75GB。只需几行代码即可调用，如下所示：
from transformers import AutoModel
provence = AutoModel.from_pretrained("naver/provence-reranker-debertav3-v1", trust_remote_code=True)
# Read in a markdown version of the Wikipedia entry for Alameda, CA
with open('alameda_wiki.md', 'r', encoding='utf-8') as f:
alameda_wiki = f.read()
# Prune the article, given a question
question = 'What are my options for leaving Alameda?'
provence_output = provence.process(question, alameda_wiki)
Provence 对文章进行了编辑删减，删除了 95%的内容，只给我留下了这个相关子集 。效果非常精准。
可以采用 Provence 或类似功能来精简文档或整个上下文。此外，这种模式强有力地论证了以字典等形式维护上下文的结构化 1 版本的重要性——在每次调用 LLM 前，您可以从这个结构中组装出编译好的字符串。这种结构在修剪时特别有用，既能确保主要指令和目标得以保留，又可以对文档或历史记录部分进行删减或摘要处理。
上下文摘要
上下文摘要是指将积累的上下文内容浓缩成简明摘要的行为。
上下文摘要最初是应对较小上下文窗口的工具。当聊天会话接近最大上下文长度限制时，系统会生成摘要并开启新会话。ChatGPT 或 Claude 的用户曾手动操作这一过程——要求聊天机器人生成简短回顾，再粘贴至新会话中。
但随着上下文窗口扩大，智能体开发者发现摘要功能的价值不仅限于维持总上下文限制。当上下文不断增长时，它会分散注意力，导致模型减少对训练阶段所学内容的依赖。我们将这种现象称为上下文干扰 。开发 Pokémon 对战 Gemini 智能体的团队发现，超过 10 万个标记就会触发这种异常行为：
尽管 Gemini 2.5 Pro 支持超过 100 万 token 的上下文长度，但如何有效利用这一特性构建智能代理仍是一个新兴研究领域。在这种代理架构中，当上下文显著超过 10 万 token 时，观察到一个现象：代理倾向于从庞杂历史记录中重复执行动作，而非综合生成新的行动计划。这一发现虽属个案，却揭示了长上下文在检索任务与多步骤生成推理任务中的关键差异。
总结上下文内容看似简单，但要为特定智能体完美实现却非易事。对于智能体构建者而言，关键在于明确哪些信息需要保留，并将其细化到 LLM 驱动的压缩环节中。值得将这个功能单独拆解为 LLM 驱动的独立阶段或应用，这样能收集评估数据，直接优化该任务的执行效果。
上下文卸载
上下文卸载是指将信息存储在 LLM 上下文之外的行为，通常通过一个存储和管理数据的工具来实现。
这可能是我最喜欢的策略，仅仅因为它如此简单以至于你不敢相信它会奏效。
再次说明，Anthropic 有一篇关于该技术的优秀文章 ，详细介绍了他们的"think"工具，这本质上是一个草稿板：
通过"think"工具，我们赋予 Claude 在得出最终答案前进行额外思考步骤的能力——包括为其提供专属空间...这在执行长链工具调用或与用户进行长时间多轮对话时特别有用。
我非常欣赏 Anthropic 发布的研究和其他文章，但对这个工具的名称不太感冒。如果这个工具叫 scratchpad（草稿本），你就能立刻明白它的功能——这是模型用来记录笔记的空间，既不会干扰上下文，又能供后续参考。"think"这个名字与"extended thinking"（扩展思考）冲突，还徒增了对模型的人格化...不过这是题外话了。
事实证明，设置记录笔记和进度的空间确实有效 。Anthropic 的研究显示，将"think"工具与领域特定提示（在智能体中本就会这么做）结合使用，能带来显著提升——针对专业智能体的基准测试最高可获得 54%的改进。
Anthropic 总结了上下文卸载模式适用的三种场景：
工具输出分析。当 Claude 需要仔细处理先前工具调用的输出结果才能采取行动，且可能需要在方法上回溯时；
政策密集型环境。当 Claude 需要遵循详细指导方针并验证合规性时；
序列化决策制定。当每个行动都基于前序步骤且错误代价高昂时（常见于多步骤领域）。
上下文管理通常是构建智能体最困难的部分。正如 Karpathy 所说，编程 LLM 使其" 恰到好处地打包上下文窗口 "，巧妙地部署工具、信息并进行常规上下文维护，正是智能体设计者的核心工作。
上述所有策略的关键洞见在于： 上下文并非免费资源 。上下文中的每个标记都会影响模型行为，无论好坏。现代 LLMs 庞大的上下文窗口是强大能力，但绝不能成为信息管理粗心的借口。
在构建新智能体或优化现有智能体时，请自问：上下文中的每个信息是否都物有所值？若非如此，你现在掌握了六种优化方法。
原文链接：
https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html#context-offloading