随着前沿模型的上下文窗口不断扩大,许多已经支持高达100万token,业界对于长上下文能解锁梦想中的智能体充满了兴奋的讨论。毕竟,有了足够大的窗口,就可以简单地把可能需要的一切——工具、文档、指令等等——全部扔进提示词,然后让模型搞定剩下的事。
长上下文削弱了RAG的热度(当能把所有文档都塞进提示词时,谁还需要找最佳文档呢!),推动了MCP的炒作(连接到每个工具,模型就能做任何工作!),并激发了人们对智能体的热情。
但现实是,更长的上下文并不会产生更好的响应。上下文过载会导致智能体和应用以令人惊讶的方式失败。上下文可能变得有毒、分散注意力、令人困惑或自相矛盾。这对依赖上下文收集信息、综合发现和协调行动的智能体来说尤其成问题。
下面来看看上下文如何失控,然后介绍缓解或完全避免上下文失效的方法。
上下文失效的四种模式
上下文中毒(Context Poisoning)
上下文中毒是指幻觉或其他错误进入上下文后,被反复引用。
DeepMind团队在Gemini 2.5技术报告中指出了上下文中毒问题。当玩宝可梦游戏时,Gemini智能体偶尔会在游戏过程中产生幻觉,毒化其上下文:
这个问题特别严重的形式是"上下文中毒"——上下文的许多部分(目标、摘要)都被关于游戏状态的错误信息"毒化",这通常需要很长时间才能修复。结果,模型可能会执着于实现不可能或不相关的目标。
如果"目标"部分被毒化,智能体就会制定荒谬的策略,并重复行为来追求一个无法实现的目标。
上下文分散(Context Distraction)
上下文分散是指上下文变得太长,以至于模型过度关注上下文,忽略了训练期间学到的知识。
随着智能体工作流程中上下文的增长——模型收集更多信息并建立历史记录——这些累积的上下文可能变得分散注意力而非有帮助。玩宝可梦的Gemini智能体清楚地展示了这个问题:
虽然Gemini 2.5 Pro支持100万以上token的上下文,但在智能体中有效使用它是一个新的研究前沿。在这种智能体设置中,观察到当上下文显著超过10万token时,智能体倾向于重复其庞大历史中的动作,而不是综合新的计划。这种现象虽然是轶事性的,但突出了长上下文检索和长上下文多步骤生成推理之间的重要区别。
智能体没有利用其训练来开发新策略,而是执着于重复其广泛上下文历史中的过去动作。
对于较小的模型,分散注意力的上限要低得多。Databricks的一项研究发现,Llama 3.1 405b的模型正确率在32k左右开始下降,更小的模型下降得更早。
如果模型在上下文窗口填满之前就开始出现问题,那超大上下文窗口有什么意义?简而言之:用于摘要和事实检索。如果不做这两件事,就要警惕所选模型的分散注意力上限。
上下文混淆(Context Confusion)
上下文混淆是指上下文中的多余内容被模型用来生成低质量响应。
有一段时间,似乎每个人都要推出MCP。强大的模型连接到所有服务和东西,完成所有琐碎任务的梦想似乎触手可及。只需把所有工具描述扔进提示词就行。Claude的系统提示向大家展示了方法,因为它主要是工具定义或使用工具的说明。
但即使整合和竞争不会减缓MCP的发展,上下文混淆也会。事实证明,工具太多也可能是个问题。
Berkeley函数调用排行榜是一个工具使用基准,评估模型有效使用工具响应提示的能力。现在已经是第三版了,排行榜显示当提供多个工具时,每个模型的表现都更差。此外,Berkeley团队"设计了没有提供相关函数的场景……期望模型的输出是不调用函数"。然而,所有模型偶尔都会调用不相关的工具。
浏览函数调用排行榜,可以看到随着模型变小,问题变得更糟:
最近一篇论文中可以看到上下文混淆的惊人例子,该论文评估了小模型在GeoEngine基准上的表现,这个测试有46个不同的工具。当团队给量化(压缩)的Llama 3.1 8b一个包含所有46个工具的查询时,即使上下文在16k上下文窗口内,它也失败了。但当只给模型19个工具时,它成功了。
问题在于:如果把某些东西放进上下文,模型就必须注意它。它可能是无关的信息或不必要的工具定义,但模型会将其考虑在内。大型模型,尤其是推理模型,在忽略或丢弃多余上下文方面越来越好,但无价值的信息仍然不断绊倒智能体。更长的上下文让我们能塞进更多信息,但这种能力也有缺点。
上下文冲突(Context Clash)
上下文冲突是指在上下文中积累的新信息和工具与上下文中的其他信息发生冲突。
这是上下文混淆的更严重版本:这里的坏上下文不是无关的,而是直接与提示中的其他信息冲突。
微软和Salesforce团队在最近的一篇论文中出色地记录了这一点。团队从多个基准中提取提示,并将其信息"分片"到多个提示中。可以这样想:有时候,可能会坐下来在ChatGPT或Claude中输入段落,在按回车之前考虑每个必要的细节。其他时候,可能从一个简单的提示开始,然后在聊天机器人的答案不令人满意时添加更多细节。微软/Salesforce团队修改基准提示,使其看起来像这些多步骤交流:
左侧提示中的所有信息都包含在右侧的几条消息中,这些消息将在多轮聊天中呈现。
分片提示产生了显著更差的结果,平均下降39%。团队测试了一系列模型——OpenAI备受推崇的o3得分从98.1降至64.1。
发生了什么?为什么如果信息是分阶段收集的而不是一次性全部收集,模型表现会更差?
答案是上下文混淆:组装的上下文包含整个聊天交流,包含模型在拥有所有信息之前尝试回答挑战的早期尝试。这些不正确的答案仍然存在于上下文中,并在模型生成最终答案时影响它。团队写道:
发现LLM经常在早期轮次中做出假设并过早地尝试生成最终解决方案,然后过度依赖这些假设。简单来说,发现当LLM在对话中走错路时,它们会迷失方向并且无法恢复。
这对智能体构建者来说不是好兆头。智能体从文档、工具调用和其他处理子问题的模型中组装上下文。所有这些从不同来源提取的上下文都有可能自相矛盾。此外,当连接到自己没有创建的MCP工具时,它们的描述和说明与提示的其余部分冲突的可能性更大。
长上下文失效总结
百万token上下文窗口的到来感觉具有变革性。能够将智能体可能需要的一切扔进提示词的能力,激发了对超智能助手的愿景,这些助手可以访问任何文档,连接到每个工具,并保持完美的记忆。
但正如看到的,更大的上下文会创造新的失效模式。上下文中毒嵌入随时间复合的错误。上下文分散导致智能体严重依赖其上下文并重复过去的动作,而不是向前推进。上下文混淆导致使用不相关的工具或文档。上下文冲突创建了破坏推理的内部矛盾。
这些失效对智能体的打击最大,因为智能体恰好在上下文膨胀的场景中运行:从多个来源收集信息、进行顺序工具调用、参与多轮推理以及积累大量历史记录。
幸运的是,有解决方案!在即将发布的文章中,将介绍缓解或避免这些问题的技术,从动态加载工具的方法到建立上下文隔离区。
来自Manus的实战经验
在LangChain最近举办的线上研讨会上,来自Manus的Pete分享了他们在构建生产级智能体过程中积累的上下文工程经验。这些实战总结为解决上述问题提供了具体方案。
为什么需要上下文工程
Pete首先强调,尽管模型微调和后训练变得越来越容易,但初创公司不应急于构建专门化的模型,而应尽可能长时间地依赖通用模型和上下文工程。原因在于:
- 产品迭代速度 :模型训练周期长(1-2周),严重拖慢产品创新速度
- 行为空间固定性 :强化学习需要固定的行为空间,但AI智能体仍处于快速演进阶段,今天有效的设计明天可能就过时了
- 清晰的边界 :上下文工程是应用和模型之间最清晰、最实用的边界
上下文缩减的两种方式
Manus将上下文缩减分为**压缩(compaction)和 摘要(summarization)**两种操作:
压缩 是可逆的:
- 每个工具调用都有完整格式和紧凑格式
- 紧凑版本剥离可从文件系统重建的信息
- 例如写文件工具,执行后可以安全删除内容字段,只保留路径
- 智能体需要时可以通过路径重新读取
摘要 是不可逆的:
- 当压缩无法提供足够的空闲上下文时才使用
- 使用结构化模式而非自由形式,定义固定字段让AI填写
- 摘要前先将关键上下文卸载到文件
- 保留最后几次工具调用的完整细节,避免模型改变风格
关键阈值管理:
- 模型硬性上限:100万token
- "腐烂前"阈值:128k-200k之间,通过评估确定
- 触发机制:接近阈值时先压缩最旧的50%工具调用,保留新调用的完整细节
上下文隔离的两种模式
借鉴Go语言的设计哲学,Manus提出了两种上下文隔离模式:
通过通信(Communication) :
- 子智能体只接收简短指令作为全部上下文
- 适用于有明确输入输出、不需要历史记录的任务
- 例如:在代码库中搜索特定代码片段
通过共享内存(Shared Context) :
- 子智能体可以看到完整的先前上下文和工具历史
- 但有自己独立的系统提示和行为空间
- 适用于需要完整历史记录的场景,如深度研究
- 代价是更高的输入token消耗和无法重用KV缓存
分层式行为空间:卸载工具本身
除了卸载工作上下文,Manus还创新性地提出了卸载工具定义的方法——分层式行为空间 :
第一层:函数调用
- 只保留固定数量的原子函数(10-20个)
- 包括读写文件、执行Shell命令、搜索、浏览器操作等
- 利用约束解码,模式安全
- 对缓存友好,函数间正交
第二层:沙盒工具
- 在完整虚拟机沙盒中运行的预装命令行工具
- 包括格式转换器、语音识别、MCP CLI等
- 好处:不触及函数调用空间就能增加功能
- 模型可以用--help了解新工具,用grep/cat处理大输出
- 权衡:对大输出友好,但低延迟交互较难
第三层:软件包与API
- 编写Python脚本调用预授权API或自定义包
- 适合需要大量计算但不需推送所有数据到上下文的任务
- 代码的可组合性可以在一步内链接多个操作
- 缺点:不是模式安全的,难以约束解码
关键洞察:从模型视角看,所有三层最终仍通过标准函数调用执行。沙盒工具通过shell函数访问,API脚本通过文件函数读写然后shell函数执行。这没有给模型增加额外负担 ,一切仍是模型熟悉的操作。
五个维度的相互作用
卸载、缩减、检索、隔离和缓存这五个维度并非相互独立:
- 卸载和检索使缩减更高效
- 稳定的检索使隔离变得安全
- 但隔离会减慢上下文传递,降低缩减频率
- 更多隔离和缩减会影响缓存效率和输出质量
上下文工程是一门艺术与科学,要求在多个可能相互冲突的目标之间找到完美平衡。
最重要的建议:避免过度工程
Pete在结尾强调了一个看似矛盾但至关重要的观点:
Manus上线以来六七个月里,最大的飞跃并非来自增加更多花哨的上下文管理层或巧妙的检索技巧,而是来自简化,来自移除不必要的技巧,以及每一次都对模型多一点信任。每当简化架构,系统就会变得更快、更稳定、更智能。
上下文工程的目标是让模型的工作变得更简单,而不是更难。
关键启示:少做加法,多做理解(build less and understand more)。
其他实用经验
评估策略 :
- 最重要:每个完成会话的用户1-5星评分
- 自动化:有可验证结果的内部数据集,侧重执行性任务
- 真人评估:用实习生评估视觉吸引力等难以量化的输出
架构演进 :
- Manus从三月上线至今已重构五次
- 每1-2个月审视一次架构
- 方法:固定架构,在强弱模型间切换测试
- 如果从弱模型切换到强模型能获得巨大提升,说明架构更具未来适应性
多智能体设计 :
- 不按角色划分(设计师、程序员、经理)
- 只有少数几个智能体:通用执行器、规划器、知识管理器
- 更多使用"智能体即工具"模式
- 主智能体定义输出模式,子智能体使用约束解码提交符合模式的结果
数据存储 :
- 优先考虑基于行的格式(便于grep和按行范围读取)
- 倾向于纯文本而非Markdown(避免某些模型输出过多项目符号)
这些来自生产环境的实战经验,为如何在实际应用中管理和优化上下文提供了宝贵的参考。核心思想始终是:在模型能力和上下文管理之间找到平衡,既要充分利用长上下文的优势,又要警惕其带来的各种失效模式。
添加微信，备注” LLM “进入大模型技术交流群
如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢
/ 作者：致Great
/ 作者：欢迎转载，标注来源即可