以下文章来源于意流织境 ，作者沧海的兰瓜罐头

意流织境 .
连接即世界！欢迎来到 VibeWeave🌿，一个为开发者打造的温暖技术社区，聊技术、做东西、交朋友。期待与你一起分享灵感、碰撞想法、携手创造。❤

不少朋友会问到这样一个问题：“为什么 Agent 用着用着就变傻了？明明开始挺聪明的，用久了就开始胡乱输出。”
这其实是上下文管理的经典问题。信息过载会导致模型性能下降。
前一阵读到一篇很棒的文章 How to Fix Your Context[1]，作者总结了六种上下文管理策略，很有启发。结合这次分享的内容和自己的实践经验，我把这些复杂的策略用大家更容易理解的“加减乘除”四个核心法则来归纳，让你的 AI Agent 告别“失忆症”。

TL;DR（太长不看版）

1. 上下文管理是必要的：上下文不是免费的，信息过载会导致 Agent “失忆”、重复、胡言乱语。大窗口 ≠ 可以乱塞信息。
2. “加减乘除”法则：加法（精准添加相关信息）、减法（移除干扰和无关信息）、乘法（分解并行处理）、除法（压缩精华外置细节）。
3. 实战验证：LangChain 的 Open Deep Research 项目通过动态调整上下文管理的策略，其 V2 版本在 Deep Research Bench 上进入前 10 名、位列开源项目第一。

先说说为什么 Agent 会“失忆”

AI Agent 的“失忆”有四种典型症状：
• 上下文中毒：错误信息被反复引用，影响后续判断
• 上下文分心：过度关注历史对话，忽略训练知识
• 上下文混乱：无关信息干扰正确判断
• 上下文冲突：新旧信息矛盾，导致输出不一致
这就是经典的“垃圾进，垃圾出”问题。上下文不是免费的，每个 Token 都会影响模型的行为。
所以我们在这里给出一个好记的”加减乘除”上下文管理法则。

➕ 加法：精准添加相关信息

上下文检索增强：精准而非全量加载
每次有新模型发布超长上下文窗口，就有人喊“RAG 已死”。Llama 4 Scout 搞了个 1000 万 Token 的窗口，又有人说：“直接全塞进去不就行了？”
根据查询需求精准添加相关文档和知识才是正确做法。把上下文当垃圾桶使，垃圾就会影响你的输出。这就是为什么 RAG 不仅没死，反而更重要了。
工具检索调用：精准选择和配置工具
Berkeley Function-Calling Leaderboard[2] 的数据揭示：即使是最顶尖的模型，工具调用的综合准确率也刚刚超过70%。
• 第 1 名 GLM-4.5 (智谱AI)：70.85%
• 第 2 名 Claude-Opus-4：70.36%
• 第 3 名 Claude-Sonnet-4：70.29%
工具调用仍然是 AI 模型的一大挑战，即使是最先进的模型也有近 30% 的失误率。在 MCP 生态和各种工具大量涌现的今天，精准选择和配置工具比拥有更多工具更重要。

➖ 减法：移除干扰和无关信息

上下文修剪：移除无关内容
上下文修剪就是主动删除与当前任务无关的历史信息、冗余描述和过时数据。例如：
• 时间窗口限制：只保留最近 N 轮对话，删除过早的交互记录
• 相关性过滤：使用语义相似度筛选，移除与当前查询无关的内容
信息过滤：阻止垃圾信息进入
信息过滤是在信息进入上下文之前就进行筛选。例如：
• 质量检测：过滤掉明显错误、自相矛盾的信息
• 权威性验证：优先选择可信来源的信息
信息过滤主要防止上下文中毒和冲突，而修剪则解决混乱和分心问题。

✖️ 乘法：分解并行处理

上下文隔离：分而治之
Anthropic 的多智能体研究[3]系统展示了这一策略的威力：子智能体在各自的上下文窗口中并行工作，探索问题的不同方面，然后为主研究智能体压缩最重要的信息。最终在实验中得到 90.2% 的性能提升！
多智能体系统：专业化分工
将复杂任务分解到独立线程中处理，利用专业化分工提升整体效能。这不是简单的任务分配，而是让每个智能体能具备独立的上下文环境并在自己的专业领域发挥最大价值。

➗ 除法：压缩精华外置细节

上下文摘要：压缩信息精华
Google 的研究发现：超过 10 万 Token，Agent 就开始“怀旧” —— 总是重复历史动作，而不是制定新计划。
这时候就需要压缩精华：将累积信息压缩为精华摘要，特别适用于超过 100K Token 的场景。
上下文卸载：使用外部存储
Anthropic 的 Think 工具[4] 就是给 AI 一个外部存储空间。
效果惊人：最高 54% 的性能提升！
将信息转移到外部工具存储，计算过程不会干扰最终答案的呈现。

加减乘除：让复杂变简单

操作
口诀
具体做法
加
添加精准
RAG 检索 + 精选工具
减
删除无关
上下文修剪 + 信息过滤
乘
分解并行
上下文隔离 + 多智能体系统
除
压缩精华
上下文摘要 + 外置存储

实战案例：Open Deep Research 的进化启示

以 LangChain 团队基于 LangGraph 开发和开源的 Open Deep Research[5] 项目为例，展示上下文管理策略的动态调整过程。

版本
背景
加法
乘法
效果
V0
工具调用不可靠
上下文窗口小
彻底避免工具调用
编排器任务分解
稳定但受限
V1
工具调用改善
MCP 生态发展
重新引入工具调用
接入MCP 生态
升级多智能体架构
能力提升但缺乏连贯
V2 版本：上下文管理的成功实践

V2 版本按三个核心流程阶段重新设计了上下文管理的策略，我们把它总结为：
步骤 1：主题提炼与目标确定
• ➗ 上下文压缩：将 N 轮用户对话压缩为核心编写目标的 Brief
步骤 2：并行研究与信息收集
• ✖️ 多智能体并行：Supervisor 架构驱动多个 Research Subagent 同时收集资料
• ➖ 结果精简：Subagent 只向 Supervisor 提供最终结果和引用，不提供中间过程
步骤 3：集中写作与内容生成
• ➕ 精准添加：基于主题和资料，只挑选必要内容进行集中写作
结果？在 Deep Research Bench[6] 上得分 43.5，成功进入前 10 名（总排名第 6，开源排名第 1）。
这个 V2 版本的精髓在于：每个阶段都有明确的上下文管理目标，前两个阶段为最后的集中写作创造最优条件。
这个案例同时也告诉我们：上下文策略不是一成不变的，要随着模型能力的提升动态调整组合。

结语：上下文管理是门手艺

上下文工程说到底，就是信息管理的手艺活。
Andrej Karpathy 说：“要把上下文窗口填得恰到好处。不是越多越好，而是要精准有效。“
所以可以记住我们的公式：
高效上下文 = (相关信息 + 必要工具 - 无关内容) × 并行处理 ÷ 智能压缩

如果你的 Agent 还在“失忆”，不妨试试这套“加减乘除”。LangGraph 作为底层 Agent 框架，天然支持状态管理和上下文控制，非常适合实现这些上下文管理策略。本文作者的新书《LangGraph实战》就是一个很好的入门选择。