编者按： LLM 的上下文窗口一直在不断扩大，我们现在是否能”将一切内容塞进上下文”，却依然得到高质量的模型输出？
我们今天为大家带来的这篇文章，作者的核心观点是：上下文不是免费的，信息必须被主动管理，否则”Garbage in, garbage out”的老问题将以更隐蔽的方式重现。
文章系统剖析了长上下文常见的四大失效模式——上下文污染、干扰、混淆与冲突，并提出了六种行之有效的上下文管理策略：RAG（检索增强生成）、工具选配、上下文隔离、修剪、摘要与卸载。这些方法不仅有助于提升模型输出质量，还能显著降低能耗、加快响应速度，尤其在边缘设备或复杂智能体系统中价值突出。作者还结合 Anthropic、DeepSeek、Gemini 的实践经验分享，展示了如何在真实场景中拆解任务、隔离线程、动态筛选工具，从而让大模型”轻装上阵、精准发力”。
作者 | Drew Breunig
编译 | 岳扬
01 缓解与避免上下文失效问题
早前发布我们发布过《How Long Contexts Fail》[1]，本文我们再来系统探讨能够减轻或完全避免这些失效问题的解决方案。
但在开始之前，先简要回顾一下长上下文可能失效的几种方式：
- 上下文污染（Context Poisoning） ：当幻觉信息或其他错误内容混入上下文并被持续引用时发生
- 上下文干扰（Context Distraction） ：因上下文过长导致模型过度关注当前文本，而忽略了训练阶段习得的知识
- 上下文混淆（Context Confusion） ：模型使用上下文中存在的冗余信息生成低质量响应
- 上下文冲突（Context Clash） ：当新增的上下文信息及工具与提示词中既有内容产生矛盾时触发
以上所有问题，归根结底都是信息管理的问题。上下文中的每一条信息都会影响最终的回答。这又回到了那句古老的编程格言：”垃圾进，垃圾出（Garbage in, garbage out）。”[2]
幸运的是，针对上述问题，我们有大量可行的应对方案。
上下文管理策略
- RAG：选择性地添加相关信息，助力大语言模型生成更优的回答
- 工具选配（Tool Loadout）：仅选择相关的工具定义加入上下文
- 上下文隔离（Context Quarantine）：在各独立线程中隔离不同上下文
- 上下文修剪（Context Pruning）：从上下文中移除无关的或不必要的信息
- 上下文摘要（Context Summarization）：将累积的上下文提炼为简明的摘要信息
- 上下文卸载（Context Offloading）：将信息存储在大语言模型上下文之外，通常通过一个负责存储和管理数据的工具实现
02 RAG
检索增强生成（Retrieval-Augmented Generation，RAG）是指选择性地添加相关信息，来助力大语言模型生成更优的回答。
关于 RAG 的讨论早已汗牛充栋，今天我们不会深入展开，只想强调一点：它依然非常有效。
每当模型将上下文窗口的上限再度拉高，就会有人掀起新一轮”RAG 已死”的论战。上次引发大规模讨论是 Llama 4 Scout 发布，带来了 1000 万 token 的上下文窗口。面对如此庞大的容量，人们很容易产生”干脆把所有内容都塞进去，这多省事”的想法。
但正如我们之前的文章[1]所讲：如果你把上下文当成一个杂物抽屉，那这些杂物就会直接影响你的输出结果。若您想深入了解，这里有一门新课程[3]值得推荐。
03 工具选配（Tool Loadout）
工具选配是指仅选择与当前任务相关的工具定义加入上下文。
“选配”（loadout）原为游戏术语，指在关卡/对战/回合开始前对技能、武器与装备进行的特定组合配置。通常需要根据角色特性、关卡难度、团队构成及个人操作习惯进行针对性调整。
在此我们借用该术语，来描述为特定任务筛选最适用工具的过程。
最简单的工具筛选方式莫过于对工具描述实施 RAG 检索。这正是 Tiantian Gan 与 Qiyao Sun 在论文《RAG MCP》[4]中采用的方法 —— 通过将工具描述存储于向量数据库，实现根据输入提示词精准匹配最相关工具。
DeepSeek-v3 团队发现，当工具数量超过 30 个时，精准选配就变得至关重要。超过这个阈值，工具描述会出现重叠混淆；超过 100 个时，模型在测试中几乎必然失败。 而采用 RAG 技术将工具筛选至 30 个以内，不仅能大幅缩短提示词长度，更能将工具选择准确率提升高达 3 倍。
对于小型模型而言，问题在工具数远未达 30 时便会显现。我们在上一篇文章中提到的论文《Less is More》[5]就指出：Llama 3.1 8B 在提供 46 个工具时无法通过基准测试，但当工具数量减少到 19 个时却能成功。问题根源在于上下文混淆，而非上下文窗口的容量限制。
为解决这一问题，《Less is More》团队开发了一种动态工具选择机制：利用一个由大语言模型驱动的工具推荐器。该模型会先推理”它认为回答用户查询所需工具的数量和类型”，然后通过语义搜索（即再次使用工具 RAG）确定最终的工具配置。他们在 Berkeley Function Calling Leaderboard[6] 上测试了该方法，发现 Llama 3.1 8B 的性能提升了 44%。
该研究还指出精简上下文的两大额外优势：更低的功耗和更快的响应速度 —— 这在边缘计算场景（即在手机或 PC 端而非专业服务器上运行大模型）中尤为关键。即使动态选配未能提升模型效果，其带来的能效与响应速度收益也值得投入：分别实现了 18% 的能耗节省和 77% 的速度提升。
幸运的是，大多数智能体（agent）的应用场景较为聚焦，通常只需少量人工精心挑选的工具。但若需扩展功能范围或集成规模，请务必重视工具选配策略。
04 上下文隔离（Context Quarantine）
上下文隔离是指将上下文分别置于各自独立的线程中，每个线程由一个或多个大语言模型单独使用。
当上下文长度适中且不含无关内容时，我们通常能获得更好的结果。实现这一点的方法之一，是将任务拆解为多个更小、彼此隔离的子任务 —— 每个子任务拥有自己专属的上下文。
这种策略有许多应用实例[7-8]，其中一篇通俗易懂的说明来自 Anthropic 的博客文章[9]，详细介绍了他们的多智能体研究系统。文中写道：
搜索的本质是压缩：从海量语料中提炼关键洞见。子智能体通过并行运作，各自使用独立的上下文窗口同时探索问题的不同维度，最终将最重要的信息压缩后传递给主研究智能体。每个子智能体还实现了关注点分离 —— 各自配备不同的工具、提示词和探索路径 —— 从而减少路径依赖，支持更彻底、更独立的研究。
这类设计模式特别适用于研究类任务。面对一个复杂问题时，可以将其拆解为若干子问题或探索方向，并分别交由多个智能体处理。这不仅能加速信息的收集与提炼（前提是具备足够的计算资源），还能避免单个上下文积累过多或不相关的信息，从而提升输出质量：
我们的内部评估表明，多智能体研究系统在”广度优先型”查询中表现尤为突出 —— 这类查询需要同时推进多个独立的研究方向。我们发现，以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在内部研究评估中比单智能体的 Claude Opus 4 性能提升 90.2%。例如，在要求列出标普 500 信息技术板块所有公司的董事会成员时，多智能体系统通过任务分解交由子智能体并行处理，成功找到正确答案；而单智能体系统则因缓慢、串行的搜索未能完成任务。
这种方法也有助于优化工具选配（tool loadout）：智能体设计者可以创建多种智能体原型，每种都配备专属的工具组合及使用说明。
对智能体开发者而言，关键挑战在于识别出哪些任务可以拆解并分配到独立线程中执行。 那些需要多个智能体频繁共享上下文的问题，并不太适合采用此策略。
若您的智能体应用场景适合并行处理，强烈推荐阅读 Anthropic 的完整文章[9]，其内容极为精彩。
05 上下文修剪（Context Pruning）
上下文修剪是指从上下文中移除无关的或冗余的信息。
智能体在调用工具和整合文档的过程中会不断积累上下文。有时，需要暂停操作，评估已收集的内容并清除冗余信息。你可以将这项任务交给主大语言模型处理，也可以专门设计一个由大语言模型驱动的工具来审查并编辑上下文，或选择更专业的修剪方案。
上下文修剪在自然语言处理（NLP）领域其实已有（相对）较长的历史 —— 在 ChatGPT 出现之前，上下文长度曾是一个更为棘手的瓶颈。在此基础上，当前一种实用的修剪方法是 Provence[10]，这是一个”面向问答场景的高效稳健上下文修剪器”。
Provence 速度快、准确率高、使用简单，且体积相对小巧 —— 仅 1.75 GB。你只需几行代码即可调用它，例如：
Provence 对文章进行精简处理，删减 95% 的内容后仅保留相关核心段落[11]，效果令人惊叹。
你可以使用 Provence 或类似功能来裁剪单个文档，甚至整个上下文。此外，这种做法也有力地支持了以下设计模式：将上下文以结构化的形式（例如字典或其他数据结构）进行维护，并在每次调用大语言模型前动态拼接成最终的字符串。这种结构在进行修剪时尤为有用，既能确保核心指令与目标完整保留，又允许对文档或历史记录段进行删减或摘要处理。
06 上下文摘要（Context Summarization）
上下文摘要是将累积的上下文提炼为简洁摘要的过程。
上下文摘要最初是为应对有限上下文窗口而引入的一种手段。当聊天会话即将超出最大上下文长度时，系统会生成一份摘要，并开启一个新线程。用户在 ChatGPT 或 Claude 等聊天机器人中可以手动执行这一操作：要求模型生成简短摘要，然后将该摘要粘贴到新会话中。
然而，随着上下文窗口不断扩展，智能体开发者发现，摘要的价值已不仅限于避免超出上下文容量限制。随着上下文的增长，模型容易分心，更少依赖其在训练中学到的知识 —— 我们称之为”上下文分心”（Context Distraction）。 开发《宝可梦》游戏智能体的 Gemini 团队发现，一旦上下文超过 10 万个 token，就会触发这一现象：
尽管 Gemini 2.5 Pro 支持超百万 token 的上下文，但在智能体场景中有效利用如此长的上下文仍是一个新兴研究领域。在该智能体场景中，当上下文大幅超过 10 万 token 时，智能体倾向于重复其操作历史中的已有动作，不再灵活思考、主动规划。尽管这一现象尚属个案，但却揭示了这样一个现象：用于检索任务的长上下文，与用于多步生成式推理的长上下文，有着根本不同的要求和挑战。
对上下文进行摘要操作本身并不难，但为特定智能体实现精准摘要却充满挑战性。开发者必须明确哪些信息需要保留，并将这一要求清晰传达给执行压缩的大语言模型。 因此，值得将此功能单独拆解为一个由大语言模型驱动的处理阶段或独立应用 —— 这样便于收集评估数据，从而直接指导并优化该任务的执行效果。
07 上下文卸载（Context Offloading）
上下文卸载是指将信息存储在大语言模型上下文之外的技术，通常通过专门的数据存储管理工具实现。
这可能是我最钟爱的策略 —— 简单到令人怀疑它是否真的有效。
Anthropic 曾专门撰文介绍这一技巧[12]，文中详细说明了他们的 “think” 工具，本质上就是一块草稿板：
借助”think”工具，我们让 Claude 在给出最终答案前，额外增加一个思考步骤，并为其划出独立空间……在需要连续调用工具或与用户进行长对话时，这一点尤为实用。
我很欣赏 Anthropic 发布的研究成果，但对此工具的命名持保留意见。倘若它叫”scratchpad（草稿板）”，功能一目了然：给模型一个记笔记的地方，既不污染上下文，又可供后续查阅。而”think”一词容易与”extended thinking”[13]混淆，还无端把模型拟人化……扯远了。
有一块能记录进度与笔记要点的地方，确实行之有效。Anthropic 研究表明，将 “think” 工具与领域专属提示词（这本就是智能体的标准配置）结合使用，能在专业智能体基准测试中实现高达 54% 的性能提升。
Anthropic 总结了上下文卸载模式适用的三大场景：
- 当 Claude 需要仔细分析前期工具的执行结果，并可能因此调整后续行动路径时。
- 在需要严格遵守复杂规则体系，并确保每一步操作都符合规定的情境下。
- 在环环相扣的任务中，每一个后续步骤都依赖于前一步的正确结果，且任何失误都会导致付出高昂代价。
上下文管理往往是打造智能体时最棘手的环节。正如 Karpathy 所说，设计者得”恰到好处地填充上下文窗口[14]”，巧妙地调度多种工具与各种信息，还要定期做上下文清理。
贯穿所有上述策略的关键洞察在于：context is not free，不能随意、无节制地向上下文里填充信息。上下文中的每一个 token，无论相关与否、正确与否，都在左右模型的行为。 现代大语言模型提供的超大上下文窗口固然是一种强大的能力，但这绝不能成为我们疏于信息管理的借口。
下次构建或优化智能体时，不妨问问自己：当前上下文里的每一条信息，真的都在”干活”吗？ 如果有些内容只是占位置、没贡献，那你就该用前面提到的六种方法，把它们清理掉或挪出去。
END
本期互动内容 🍻
❓在你的项目里，是否曾因上下文管理不当（如信息污染、工具混淆）而踩过”坑”？您最终是如何发现并解决这个问题的？
文中链接
[1]https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html
[2]https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
[3]https://maven.com/p/569540/i-don-t-use-rag-i-just-retrieve-documents
[4]https://arxiv.org/abs/2505.03275
[5]https://arxiv.org/abs/2411.15399
[6]https://gorilla.cs.berkeley.edu/leaderboard.html
[7]https://arxiv.org/abs/2402.14207
[9]https://www.anthropic.com/engineering/built-multi-agent-research-system
[10]https://arxiv.org/abs/2501.16214
[11]https://gist.github.com/dbreunig/b3bdd9eb34bc264574954b2b954ebe83
[12]https://www.anthropic.com/engineering/claude-think-tool
[13]https://www.anthropic.com/news/visible-extended-thinking
[14]https://x.com/karpathy/status/1937902205765607626
原文链接：
https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html
</div>
