跳转至

上下文管理的核心挑战

概述

随着 AI 智能体处理的任务越来越长、累积的工具调用反馈越来越多，上下文窗口逐渐成为关键瓶颈。上下文质量的退化有其规律可循——理解这些失效模式，是在工程层面加以应对的第一步。

"上下文工程"这一概念在很大程度上由 Cognition（Devin 的开发团队）推广开来，他们将其描述为"实际上是构建 AI 智能体的工程师的第一要务"。Anthropic 也呼应了这一观点："智能体往往需要经历数百轮对话，这要求采用精心设计的上下文管理策略。"

五种上下文失效模式

这五种失效模式由 Drew Breunig 在 How Long Contexts Fail 中系统整理，并在社区中得到广泛引用：

上下文腐化（Context Rot）

随着上下文长度增加，模型性能出现退化。基于"大海捞针"基准测试的研究表明，随着 Token 数量增长，模型从上下文中准确召回信息的能力会下降——即便尚未超过官方声明的上下文窗口上限。

Anthropic 工程团队对其底层机制的解释是：Transformer 架构对于 n 个 Token 会产生 n² 级别的两两关系。随着上下文增长，模型捕捉这些关系的能力被不断稀释。此外，模型在超长序列上的训练经验相对不足，因此性能的退化是渐进式的，而非骤然跌落。

Pokémon 游戏 Gemini 智能体团队从实测中印证了这一点：当上下文超过约 100,000 个 Token 后，智能体开始倾向于重复过去的动作，而非综合规划新的行动方案——这正是上下文腐化引发上下文分心的典型表现。

上下文污染（Context Poisoning）

幻觉或其他错误一旦进入上下文，便会被后续步骤视为既定事实。由于智能体在决策时会持续引用历史上下文，单次错误输出可能在之后的多个步骤中不断传播和叠加。

Manus 工程团队将此列为不应清除上下文中错误记录的核心原因："抹掉失败等于消除证据。没有证据，模型就无法自我调整。"隐藏错误会阻止模型从失败路径中更新认知。

上下文分心（Context Distraction）

当上下文膨胀到一定规模后，模型会过度聚焦于累积的历史记录，忽视训练阶段习得的知识。具体表现为：智能体开始重复上下文历史中的行为模式，而非基于当前情境重新推理。

这与上下文腐化（整体性能退化）有所区别——分心特指模型被上下文内模式吸引，以牺牲训练知识与推理能力为代价。

上下文混乱（Context Confusion）

上下文中存在多余或无关信息，导致模型输出质量下降。工具描述是常见来源：研究表明，当工具数量超过约 30 个时，描述之间开始出现重叠，引发选择错误；超过 100 个工具后，失败率则会大幅攀升。

"Less is More"论文证明：给 Llama 3.1 8b 提供 46 个工具时，该基准测试失败；工具减少到 19 个后则成功通过。问题的根源在于信噪比：每增加一个工具，现有工具描述的区分度就会进一步降低。

上下文冲突（Context Clash）

当上下文的不同部分包含相互矛盾的信息，或新加入的工具与数据和早期上下文相悖时，便会引发上下文冲突。在多智能体系统中，子智能体基于不同假设运行，这一问题尤为突出。

Cognition 的 Walden Yan 将此列为简单多智能体架构的核心失效模式："行动承载着隐含的决策，相互冲突的决策必然带来糟糕的结果。"当子智能体在没有共享上下文的情况下并行工作时，各自的输出会反映出不兼容的假设，编排者随后不得不加以协调。

对智能体性能的影响

失效模式 主要症状 常见触发场景
上下文腐化 召回准确率下降、长程推理出错 对话轮次极长、工具调用次数过多
上下文污染 反复犯相同错误、错误叠加累积 幻觉内容未被纠正而留存于历史记录
上下文分心 重复历史行为模式、创新能力下降 上下文超过约 100K Token
上下文混乱 工具选择错误、输出偏离主题 工具数量过多、消息历史噪声过大
上下文冲突 输出前后不一致、决策相互矛盾 多智能体并行运行且缺乏共享上下文

记忆与上下文：根本区别

大多数团队将记忆和上下文视为同一概念，但两者并不相同——这一区别决定了系统能否规模化扩展。

维度 上下文（工作记忆） 记忆（长期存储）
成本 昂贵：每个 Token 都需付费，未缓存时成本增加 10 倍 低廉：存储成本可忽略不计
容量 有限：受上下文窗口约束 无限：可存储数百万文档
速度 即时：直接影响模型响应 较慢：使用前须先检索
持久性 易失：会话结束后清除 持久：跨会话保留
影响方式 直接：影响每一次模型决策 间接：须先加载到上下文才能生效
性能 超过约 30K Token 后开始退化 不退化：仅有检索开销

100:1 法则：智能体每生成 1 个 Token，大约需要处理 100 个输入 Token。因此，上下文管理是生产环境智能体系统的主要成本驱动因素。

哪些内容留在上下文，哪些存入记忆：

留在上下文 存入记忆
当前任务目标与约束 历史对话与决策记录
近期工具输出（最近 3–5 次调用） 习得的行为模式与偏好
当前活跃的错误状态与告警 大型参考文档
近期对话历史 中间计算结果
当前相关的关键事实 已完成任务的摘要

四种上下文类型

智能体需要处理四种不同类型的上下文，各类型具有不同的失效特征：

  1. 指令上下文 — 系统提示词、少样本示例、行为准则。通常较为稳定，但体积可能增大。指令上下文质量差会导致行为不一致。
  2. 知识上下文 — 事实信息、记忆、检索到的文档、用户偏好。动态变化，随任务而调整。可能迅速填满上下文窗口。
  3. 工具上下文 — 工具描述、工具调用的返回结果、错误信息。所有模型的性能都会随工具数量增加而下降（Berkeley 函数调用排行榜已有记录）。工具上下文管理至关重要。
  4. 历史上下文 — 过去的对话、历史决策、习得的模式。有助于保持连续性，但可能引入矛盾信息或过时内容。

各失效模式的实证依据

上下文污染——DeepMind Pokémon 智能体

DeepMind 团队通过其 Pokémon 游戏 Gemini 智能体记录了这一现象。该智能体曾一次性误判游戏状态，该错误被写入目标区域。由于目标在每次决策时都会被引用，这条错误信息不断自我强化。智能体持续数十轮追逐无法实现的目标，却无法自行纠正，因为被污染的上下文一直在为这个错误提供支撑。

领域级联模式： - 客服场景：误判产品型号 → 提供错误的故障排查建议 → 引用了错误的产品手册 → 推荐了不兼容的配件 - 代码生成：导入错误的库版本 → 调用了已废弃的 API → 产生不兼容的语法 → 引发级联类型错误 - 研究场景：误解研究范围 → 检索错误领域 → 引用无关文献 → 得出错误结论

一旦污染形成，几乎无法恢复。清空整个上下文虽然有效，但会丢失所有进度。智能体对自身上下文的信任程度高于外部纠正。

上下文分心——Gemini 2.5 团队

Gemini 2.5 团队观察到，当智能体上下文超过 100,000 个 Token 时，智能体停止生成新颖解法，转而重复历史记录中的动作，即使这些动作并不适用于当前问题。Databricks 研究人员发现，当模型达到分心阈值后，往往会完全无视指令，转而对上下文内容进行归纳总结。

上下文混乱——Berkeley 函数调用排行榜

一个量化的 Llama 3.1 8B 模型（上下文窗口 16,000 Token）被提供了 GeoEngine 基准测试中的 46 个工具（约 3,000 Token 的上下文）。智能体的上下文空间充裕，但完全失败。当工具减少到 19 个后，它成功完成了任务。问题在于信噪比：每增加一个工具，现有工具描述的区分度就会进一步降低。

上下文冲突——Microsoft 与 Salesforce 研究

研究人员将标准基准测试任务分散到多轮对话中，而非放在单个提示词里。结果显示，所有被测模型的平均性能下降了 39%。当模型在对话中走错方向后，就会迷失且无法自行恢复——上下文中同时包含错误和纠正，而智能体无法稳定地优先采纳纠正而非错误。

上下文冲突与上下文污染的区别：污染是单一错误不断传播；冲突则是多条相互矛盾的信息同时竞争影响力。

上下文规模阈值与推荐方案

上下文规模 推荐方案
< 10K Token 仅追加（append-only）的简单方式，配合基础缓存
10K–50K Token 在边界处添加压缩，结合 KV 缓存优化
50K–100K Token 引入外部记忆卸载机制，配合智能检索
> 100K Token 考虑多智能体隔离架构

常见反模式

反模式 后果 正确做法
忽略错误信息 智能体反复犯相同错误 保留错误上下文以支持自我修正
修改已有上下文 缓存失效，成本成倍增加 采用仅追加设计以保留缓存
过早过度工程化 引入不必要的复杂性，后续模型能力提升后反而需要推倒重来 从简单开始，按需增加复杂度
一次性加载所有工具 工具数量增加后性能下降 根据任务动态选择工具
激进裁剪且无恢复机制 信息永久丢失 压缩与卸载结合使用

参见

参考资料