我要投稿
微信搜一搜，关注“AI工程化”
AI智能体上下文管理的终极指南：从失效诊断到高效解决方案，一文掌握核心技巧。 核心内容： 1. 长上下文失效的四大模式分析（污染、分心、混乱、冲突） 2. 六种系统性解决方案详解（RAG选择、工具载荷等） 3. 前沿模型性能数据与具体实现案例
上下文管理是AI智能体开发的核心难题。即使大模型有了千万级token窗口，也不意味着可以无脑塞信息——垃圾进，垃圾出的铁律依然有效。在此之前我们刊载了Manus在上下文工程上的心得。
AI智能体的上下文工程：Manus的构建心得
近日，Drew Breunig也分享了它对于上下文管理层面的见解。这是一个完整的上下文管理指南，分为问题诊断《How Long Contexts Fail | Drew Breunig[1]》和解决方案《How to Fix Your Context | Drew Breunig[2]》两部分。
第一部分分析了四种长上下文失效模式：污染（幻觉进入上下文被反复引用）、分心（模型过度关注上下文忽略训练知识）、混乱（无关信息影响回应）、冲突（上下文内部矛盾）。作者用具体研究数据证明，即使Gemini超过10万token就开始重复历史动作，工具超过30个就会让模型困惑。
第二部分提出6种系统性解决方案：RAG选择性添加信息、工具载荷智能选择工具、上下文隔离分离任务、上下文剪枝移除无关信息、上下文摘要压缩内容、上下文卸载外部存储。每种方法都有具体实现和性能数据。
内容干货满满，非常有指导意义，强烈推荐阅读。
随着前沿模型上下文窗口持续增长，许多模型支持多达100万个token，我看到很多关于长上下文窗口将解锁梦想智能体的兴奋讨论。毕竟，有了足够大的窗口，你可以简单地将可能需要的一切都扔进提示中——工具、文档、指令等等——让模型处理其余部分。
长上下文重创了RAG热情（当你可以将所有文档都塞进提示时，何必费力找最佳文档！），催生了MCP炒作（连接到每个工具，模型可以做任何工作！），并推动了对智能体的热情。
但实际上，更长的上下文并不能产生更好的回应。过载你的上下文会导致智能体和应用程序以令人惊讶的方式失效。上下文可能变得中毒、分散注意力、混乱或冲突。这对智能体尤其成问题，因为智能体依赖上下文收集信息、综合发现和协调行动。
让我们看看上下文可能失控的方式，然后回顾缓解或完全避免上下文失效的方法。
上下文污染是当幻觉或其他错误进入上下文，并被反复引用时。
DeepMind团队在Gemini 2.5技术报告[3]中指出了上下文污染问题，我们上周分析过[4]。在玩口袋妖怪时，Gemini智能体偶尔会在游戏中产生幻觉，污染其上下文：
这个问题的一种特别严重的形式可能是"上下文污染"——上下文的许多部分（目标、摘要）被关于游戏状态的错误信息"污染"，这通常需要很长时间才能消除。结果，模型可能会专注于实现不可能或无关的目标。
如果其上下文的"目标"部分被污染，智能体会制定荒谬的策略，并重复行为以追求无法实现的目标。
上下文分心是当上下文增长到如此之长，以至于模型过度关注上下文，忽略了训练期间学到的知识。
随着智能体工作流程中上下文的增长——模型收集更多信息并建立历史——这种累积的上下文可能变得分散注意力而不是有帮助。玩口袋妖怪的Gemini智能体清楚地展示了这个问题：
虽然Gemini 2.5 Pro支持1M+token上下文，但在智能体中有效使用它呈现了新的研究前沿。在这种智能体设置中，观察到随着上下文显著增长到超过100k token，智能体表现出倾向于重复其庞大历史中的动作，而不是综合新颖计划。这种现象，尽管是轶事性的，突出了长上下文检索和长上下文多步骤生成推理之间的重要区别。
智能体没有使用其训练来制定新策略，而是专注于重复其广泛上下文历史中的过去动作。
对于较小的模型，分心阈值要低得多。Databricks研究[5]发现，模型正确性在Llama 3.1 405b约32k处开始下降，较小模型更早。
如果模型在其上下文窗口填满之前就开始出现异常行为，那么超大上下文窗口的意义何在？简而言之：摘要和事实检索。如果你不在做这两件事中的任何一件，要小心你选择的模型的分心阈值。
上下文混乱是当上下文中的多余内容被模型用来生成低质量回应时。
有一段时间，看起来每个人都要发布一个MCP[6]。一个强大的模型，连接到你的所有服务和东西，做你所有平凡任务的梦想感觉触手可及。只需将所有工具描述扔到提示中然后开始。Claude的系统提示[7]向我们展示了方向，因为它主要是工具定义或使用工具的指令。
但即使整合和竞争不会拖慢MCPs[8]，上下文混乱也会。事实证明，工具太多确实是个问题。
伯克利函数调用排行榜[9]是一个工具使用基准测试（benchmark），评估模型有效使用工具回应提示的能力。现在是第3版，排行榜显示每个模型在提供超过一个工具时表现都更差。此外，伯克利团队"设计了提供的函数都不相关的场景...我们期望模型的输出是不进行函数调用。"然而，所有模型偶尔会调用不相关的工具。
浏览函数调用排行榜，你可以看到问题随着模型变小而恶化：
上下文混乱的一个突出例子可以在最近的一篇论文[10]中看到，该论文评估了小模型在GeoEngine基准测试[11]上的性能，这是一个包含46种不同工具的试验。当团队给量化（压缩）的Llama 3.1 8b一个包含所有46个工具的查询时，它失败了，尽管上下文远在16k上下文窗口之内。但当他们只给模型19个工具时，它成功了。
问题是：如果你把某些东西放在上下文中，模型必须关注它。它可能是无关信息或不必要的工具定义，但模型会将其考虑在内。大型模型，特别是推理模型，在忽略或丢弃多余上下文方面越来越好，但我们持续看到无价值信息绊倒智能体。更长的上下文让我们塞入更多信息，但这种能力伴随着缺点。
上下文冲突是当你在上下文中积累与上下文中其他信息冲突的新信息和工具时。
这是上下文混乱的更成问题版本：这里的坏上下文不是无关的，它与提示中的其他信息直接冲突。
微软和Salesforce团队在最近的一篇论文[12]中出色地记录了这一点。团队从多个基准测试中提取提示，并将其信息'分片'到多个提示中。这样想：有时，你可能坐下来在点击回车之前向ChatGPT或Claude输入段落，考虑每个必要的细节。其他时候，你可能从一个简单的提示开始，然后在聊天机器人的答案不令人满意时添加进一步的细节。微软/Salesforce团队修改了基准测试提示，使其看起来像这些多步骤交换：
左侧提示中的所有信息都包含在右侧的几条消息中，这些消息将在多轮聊天中播放。
分片提示产生了显著更差的结果，平均下降39%。团队测试了一系列模型——OpenAI备受推崇的o3得分从98.1下降到64.1。
发生了什么？为什么如果信息是分阶段收集而不是一次性全部收集，模型表现会更差？
答案是上下文混乱：组装的上下文，包含整个聊天交换的内容，包含模型在拥有所有信息之前回答挑战的早期尝试。这些错误答案仍然存在于上下文中，并在模型生成最终答案时影响模型。团队写道：
我们发现LLM经常在早期轮次中做出假设并过早尝试生成最终解决方案，对此过度依赖。简而言之，我们发现当LLM在对话中走错路时，它们会迷失方向并且不会恢复。
这对智能体构建者来说不是好兆头。智能体从文档、工具调用和承担子问题的其他模型中组装上下文。所有这些从不同来源拉取的上下文都有可能与自身不一致。此外，当你连接到你没有创建的MCP工具时，它们的描述和指令与你提示的其余部分冲突的可能性更大。
接续我们此前的文章"长上下文如何失效[13]"，让我们来看看如何缓解或完全避免这些失效问题。
首先简单回顾一下长上下文可能失效的几种方式：
这些问题的核心都是信息管理。上下文中的一切都会影响回应。我们又回到了编程的老话："垃圾进，垃圾出"。好在有很多选择来处理上述问题。
检索增强生成（Retrieval-Augmented Generation，RAG）是选择性添加相关信息来帮助LLM生成更好回应的行为。
关于RAG已经写了太多，我们今天不会深入，只想说：它仍然很有用。
每当模型提高上下文窗口规模时，就会诞生新一轮"RAG已死"的辩论。最近一次重大事件是Llama 4 Scout发布了1000万token窗口。在这样的规模下，真的很诱人去想"算了，全塞进去"就完事了。
但正如我们上次提到的：如果你把上下文当作杂物抽屉，杂物会影响你的回应[14]。如果想了解更多，这里有个看起来不错的新课程[15]。
工具载荷是只选择相关工具定义添加到上下文中的行为。
"载荷"这个术语来自游戏，指的是在关卡、比赛或回合开始前选择的特定能力、武器和装备组合。通常，你的载荷会根据具体情况量身定制——角色、关卡、队友构成和你自己的技能。
这里，我们借用这个术语来描述为给定任务选择最相关工具。
选择工具最简单的方法可能是对工具描述应用RAG。这正是Tiantian Gan和Qiyao Sun在论文"RAG MCP[16]"中详述的做法。通过将工具描述存储在向量数据库（vector database）中，他们能够根据输入提示选择最相关的工具。
在提示DeepSeek-v3时，团队发现当工具超过30个时，选择正确工具变得至关重要。超过30个，工具描述开始重叠，造成混乱。超过100个工具，模型几乎必然无法通过他们的测试。使用RAG技术选择少于30个工具产生了显著更短的提示，工具选择准确率提高了多达3倍。
对于较小的模型，问题在我们达到30个工具之前就开始了。我们在上一篇文章中提到的论文"少即是多[17]"证明，Llama 3.1 8b在给出46个工具时无法通过基准测试（benchmark），但只给19个工具时就能成功。问题是上下文混乱，不是上下文窗口限制。
为了解决这个问题，"少即是多"背后的团队开发了一种使用LLM驱动的工具推荐器动态选择工具的方法。LLM被提示推理"它'认为'回答用户查询需要的工具数量和类型"。然后对这个输出进行语义搜索（semantic search）（又是工具RAG）来确定最终载荷。他们用伯克利函数调用排行榜[18]测试了这种方法，发现Llama 3.1 8b的性能提高了44%。
"少即是多"论文指出了较小上下文的另外两个好处：降低功耗和提高速度，这在边缘计算（edge computing）时是关键指标（意思是在你的手机或PC上运行LLM，而不是在专用服务器上）。即使他们的动态工具选择方法无法改善模型结果，功耗节省和速度提升也值得努力，分别节省了18%和77%。
好在大多数智能体（Agents）的表面积较小，只需要几个手工筛选的工具。但如果功能广度或集成数量需要扩展，始终要考虑你的载荷。
上下文隔离是将上下文隔离在各自专用线程中的行为，每个线程被一个或多个LLM单独使用。
当上下文不太长且不包含无关内容时，我们会看到更好的结果。实现这一点的一种方法是将任务分解成更小的、隔离的工作——每个都有自己的上下文。
这种策略有很多[19]例子[20]，但Anthropic的详述其多智能体研究系统的博客文章[21]是这种策略的一个易懂的阐述。他们写道：
搜索的本质是压缩：从庞大语料库中提炼洞察。子智能体（subagents）通过在各自的上下文窗口中并行操作来促进压缩，同时探索问题的不同方面，然后为主要研究智能体浓缩最重要的token。每个子智能体还提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖性并实现了彻底、独立的调查。
研究适合这种设计模式。当给出问题时，可以识别几个子问题或探索领域，并使用多个智能体分别提示。这不仅加快了信息收集和提炼（如果有可用的计算资源），还防止每个上下文积累过多信息或与给定提示无关的信息，从而提供更高质量的结果：
我们的内部评估显示，多智能体研究系统在需要同时追求多个独立方向的广度优先查询（breadth-first queries）方面表现尤其出色。我们发现，以Claude Opus 4为主智能体、Claude Sonnet 4为子智能体的多智能体系统在我们的内部研究评估中比单智能体Claude Opus 4的表现好90.2%。例如，当被要求识别信息技术标普500公司的所有董事会成员时，多智能体系统通过将此分解为子智能体任务找到了正确答案，而单智能体系统通过缓慢的顺序搜索无法找到答案。
这种方法还有助于工具载荷，因为智能体设计者可以创建几个智能体原型（agent archetypes），每个都有自己专用的载荷和如何使用每个工具的指令。
因此，智能体构建者的挑战是找到孤立任务分拆到单独线程的机会。需要多个智能体之间共享上下文的问题不太适合这种策略。
如果你的智能体领域适合并行化，务必阅读完整的Anthropic文档[22]。它很出色。
上下文剪枝是从上下文中移除无关或不需要信息的行为。
智能体在启动工具和组装文档时会积累上下文。有时，值得暂停评估已组装的内容并移除垃圾。这可以是你分配给主LLM的任务，或者你可以设计一个独立的LLM驱动工具来审查和编辑上下文。或者你可以选择更适合剪枝任务的东西。
上下文剪枝有相对较长的历史，因为在ChatGPT之前，上下文长度在自然语言处理（Natural Language Processing，NLP）领域是更成问题的瓶颈。一个当前的剪枝方法，建立在这段历史之上，是Provence[23]，"一个高效且稳健的问答上下文剪枝器"。
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%的内容，只给我留下了这个相关子集[24]。它做得很好。
可以使用Provence或类似功能来筛选文档或整个上下文。此外，这种模式有力地论证了在字典或其他形式中维护上下文的结构化版本，在每次LLM调用之前从中组装编译的字符串。这种结构在剪枝时会很有用，允许你确保保留主要指令和目标，同时可以剪枝或摘要文档或历史部分。
上下文摘要是将累积的上下文压缩成简洁摘要的行为。
上下文摘要最初出现是作为处理较小上下文窗口的工具。当你的聊天会话接近超过最大上下文长度时，会生成摘要并开始新线程。聊天机器人用户在ChatGPT或Claude中手动执行此操作，要求机器人生成简短回顾，然后粘贴到新会话中。
然而，随着上下文窗口增加，智能体构建者发现摘要除了保持在总上下文限制内还有其他好处。随着上下文增长，它变得分散注意力，导致模型较少依赖训练期间学到的知识。我们称之为上下文分心[25]。口袋妖怪游戏Gemini智能体背后的团队发现任何超过100,000个token都会触发这种行为：
虽然Gemini 2.5 Pro支持1M+token上下文，但在智能体中有效使用它呈现了新的研究前沿。在这种智能体设置中，观察到随着上下文显著增长到超过100k token，智能体表现出倾向于重复其庞大历史中的动作，而不是综合新颖计划。这种现象，尽管是轶事性的，突出了长上下文检索和长上下文多步骤生成推理之间的重要区别。
摘要你的上下文容易做到，但对任何给定智能体来说很难完善。知道应该保留什么信息，并在LLM驱动的压缩步骤中详细说明这一点，对智能体构建者至关重要。值得将此功能分解为自己的LLM驱动阶段或应用程序，这允许你收集可以直接告知和优化此任务的评估数据。
上下文卸载是将信息存储在LLM上下文之外的行为，通常通过存储和管理数据的工具。
这可能是我最喜欢的策略，仅仅因为它如此简单以至于你不相信它会奏效。
再次，Anthropic对该技术有很好的阐述[26]，详述了他们的"think"工具，基本上是一个草稿本（scratchpad）：
通过"think"工具，我们给Claude提供了包含额外思考步骤的能力——拥有自己的指定空间——作为得出最终答案的一部分...这在执行长工具调用链或与用户进行长多步对话时特别有用。
我真的很欣赏Anthropic发布的研究和其他写作，但我不喜欢这个工具的名字。如果这个工具叫scratchpad，你会立即知道它的功能。它是模型记录不会混淆其上下文的笔记的地方，可供稍后参考。"think"这个名字与"扩展思考[27]"冲突，并且不必要地拟人化了模型...但我跑题了。
有一个记录笔记和进度的空间奏效。Anthropic显示将"think"工具与特定领域提示配对（你在智能体中无论如何都会这样做）产生显著收益，相对于专业智能体基准测试（benchmark）提高多达54%。
Anthropic确定了上下文卸载模式有用的三种场景：
工具输出分析。当Claude需要在行动前仔细处理先前工具调用的输出，并可能需要在其方法中回溯时； 政策繁重环境。当Claude需要遵循详细指导方针并验证合规性时； 顺序决策制定。当每个动作都建立在之前的动作之上且错误代价高昂时（常见于多步骤域）。
百万token上下文窗口的到来感觉变革性。能够将智能体可能需要的一切都扔到提示中，激发了对能够访问任何文档、连接到每个工具并保持完美记忆的超智能助手的愿景。
但正如我们所见，更大的上下文创造了新的失效模式。上下文污染嵌入随时间复合的错误。上下文分心导致智能体严重依赖其上下文并重复过去的动作而不是向前推进。上下文混乱导致无关的工具或文档使用。上下文冲突创造了破坏推理的内部矛盾。
这些失效对智能体打击最大，因为智能体正好在上下文膨胀的场景中操作：从多个来源收集信息、进行顺序工具调用、参与多轮推理并积累大量历史。
上下文管理通常是构建智能体最困难的部分。正如Karpathy所说，编程LLM"恰到好处地打包上下文窗口[28]"，巧妙部署工具、信息和定期上下文维护是智能体设计者的核心工作。
上述所有策略的关键洞察是上下文不是免费的。上下文中的每个token都会影响模型的行为，无论好坏。现代LLM的大规模上下文窗口是强大的能力，但它们不是信息管理马虎的借口。
当你构建下一个智能体或优化现有智能体时，问问自己：这个上下文中的一切都在发挥作用吗？如果没有，你现在有六种方法来修复它。
53AI，企业落地大模型首选服务商
产品：场景落地咨询+大模型应用平台+行业解决方案
承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业
2025-05-29
2025-05-23
2025-06-01
2025-05-07
2025-05-07
2025-05-07
2025-06-07
2025-06-21
2025-06-12
2025-05-20
2025-07-31
2025-07-31
2025-07-31
2025-07-30
2025-07-30
2025-07-30
2025-07-30
2025-07-29
回到顶部
粤ICP备14082021号