Agent 上下文污染排查：为什么系统会“越聊越笨”
许多 Agent 系统在短对话里表现良好，但一旦轮数增加、工具调用变多、记忆层开始写入，效果就迅速下滑。本文从污染源识别、症状分层、实验定位与治理策略四个层面，系统解释为什么 Agent 会“越聊越笨”，以及如何把问题从感觉层面的抱怨，变成可诊断、可验证、可回归测试的工程问题。
📷 Photo by AlphaTradeZone via Pexels
一、“越聊越笨”不是玄学，而是一个典型的系统退化信号
很多团队都会遇到类似反馈：
- 第一轮回答很好，后面越来越偏
- 工具越调越多，结果越不稳定
- 明明已经拿到正确数据，Agent 却还在问旧问题
- 多轮之后开始忽略系统约束或用户确认
这些现象常被笼统地称为“模型变笨了”。但如果你把它理解成模型心情不好，就很难解决；如果你把它理解成上下文污染，就能开始建立排查路径。
所谓上下文污染，是指本应帮助推理的信息，因组织方式不当，反而干扰了模型判断。它的危险在于：
- 初期看起来只是偶发
- 随着轮数增长会不断累积
- 一旦混入记忆层，还会跨轮传播
因此，它不是单轮 prompt 优化问题，而是系统信息流治理问题。
二、四类最常见的污染源
1）历史消息污染：过期约束没有退出上下文
最常见的情况是：
- 用户早期提出过临时需求
- 中途已经被修改或推翻
- 但系统仍把它和最新目标一起注入
结果模型会同时看到互相冲突的约束，从而出现：
- 答案摇摆
- 无法收敛
- 不断自我修正又再次偏离
2）工具日志污染：把执行痕迹当成决策依据
Agent 系统会积累大量 traces：
- API 原始返回
- 错误堆栈
- 中间解析结果
- 重试日志
这些信息对排障有价值，但不等于都应该进入下一轮决策上下文。大量底层日志会稀释真正关键的业务事实。
3）记忆污染：错误、临时或敏感信息被长期复用
这类问题在接入长期记忆后会明显增多。典型表现：
- 一次猜测被写成长期事实
- 临时偏好在后续任务中反复出现
- 不同用户或不同会话的内容被错误召回
这也是为什么 记忆写入策略：什么时候写、写什么、写到哪，才不会把记忆库写脏 必须先于大规模记忆接入。
4）计划污染：旧计划没有被淘汰，新计划又叠加进来
Agent 常常在多步骤任务中一边执行、一边重规划。如果系统没有明确淘汰旧计划，就可能把：
- 初始计划
- 修正版计划
- 临时 fallback 计划
全部混在一起。模型看到多个“下一步”，自然更难做出一致动作。
三、识别症状：不是所有错误都叫污染
为了避免把所有问题都归到一个桶里，建议把症状分成三层。
第一层：注意力漂移
表现为：
- 忽略最近一轮最关键约束
- 抓住不重要但高频出现的信息
- 输出看似相关，实际答非所问
这通常说明上下文中有效信息密度下降了。
第二层：状态错乱
表现为：
- 重复执行已完成动作
- 从错误阶段继续任务
- 对“是否已经确认过”判断失真
这类问题往往与长任务分段和阶段快照缺失有关，可结合 会话分段与阶段总结：超长任务下，Agent 为什么必须学会“分段生存” 一起治理。
第三层：跨轮传播
表现为：
- 一次错误被后续轮次不断引用
- 错误记忆被召回，导致系统每轮都从错误前提开始
- 修正过的问题在新会话里再次出现
这是最危险的一层，因为问题已经不再局限于当前 prompt，而是进入系统长期状态。
四、为什么“上下文更长”并不会自动解决污染
很多团队看到上下文不够，就希望换成长上下文模型。但更大的窗口只是提高容量，不会自动提高信息卫生。一个被污染的 prompt，即使能塞进更多内容，也只是把更多噪声一起塞进去。
可以把它理解成：
- 上下文窗口解决的是“能装多少”
- 上下文治理解决的是“该装什么”
如果没有筛选、分段、摘要、检索排序和证据回溯机制，长窗口只是推迟问题爆发的时间。
五、排查方法：从“感觉”变成“实验”
排查上下文污染时，最关键的是控制变量。建议至少做四组对照。
对照一：全量上下文 vs 精简上下文
如果精简后质量显著提升，说明当前系统很可能存在历史噪声过多的问题。
对照二：禁用记忆层 vs 启用记忆层
如果禁用记忆后错误明显减少，优先检查：
- 写入阈值是否过低
- 检索排序是否失真
- 是否存在跨会话误召回
对照三：保留业务事实 vs 去掉工具原始日志
如果去掉 traces 后结果更稳定，说明工具日志在稀释主任务信号。
对照四：单阶段执行 vs 多阶段持续执行
如果单阶段稳定、多阶段退化，问题往往不在某一条 prompt，而在阶段状态管理。
这四组实验的目标，不是一次性找到所有问题，而是先定位污染主要来自哪里。
六、治理策略：清理不是“删得越多越好”，而是让每类信息回到自己的位置
1）给上下文分层
至少区分：
- 当前任务必须信息
- 当前阶段摘要
- 可选参考记忆
- 原始证据与工具日志
不要把所有信息都放在同一优先级里。
2）对历史约束做显式失效
只追加新消息，不淘汰旧约束，是污染累积的根源之一。系统应明确标识：
- 哪些约束已被替换
- 哪些仅在某一阶段有效
- 哪些需要用户再次确认才能沿用
3）限制工具日志进入主 prompt
原始日志可以保留在旁路存储中，只把必要结论和关键证据摘要注入主上下文。
4）把记忆召回从“默认注入”改为“条件注入”
尤其是涉及偏好、身份、权限或历史行为的记忆，不应因为“有点像”就进入当前任务。
5）建立污染回归测试
常见指标包括：
- 多轮成功率
- 重复动作率
- 已确认约束违背率
- 误召回率
- token 成本 / 有效信息比
没有这些指标，治理措施很容易变成“靠感觉删 prompt”。
七、一个简化的排障顺序
如果你只能先做最小排查，建议按以下顺序：
- 先看是否注入了过期约束
- 再看是否混入了过长工具日志
- 再看是否存在错误记忆召回
- 最后看计划状态是否多版本并存
这个顺序的原因是：前两者通常更常见、也更容易修复；后两者更偏系统性，需要跨模块改造。
八、真正的目标不是“上下文更短”，而是“上下文更干净”
很多团队把治理理解成压缩 token，但真正重要的不是短，而是干净。一个 4k token 的脏上下文，可能比一个 1.5k token 的清洁上下文更差；同样，一个 32k token 的大窗口，如果组织良好，也可能比小窗口稳定得多。
因此，判断治理成效的核心问题不是：
- 我们删掉了多少内容？
而是：
- 我们是否让模型更容易看见当前真正重要的信息？
九、结论：把“越聊越笨”当成可治理的系统债，而不是模型宿命
上下文污染的本质，是系统没有为不同类型的信息建立边界、时效和优先级。历史消息、工具日志、记忆条目和计划状态一旦混成一团，再强的模型也会开始漂移。
真正成熟的 Agent 团队，不会把“越聊越笨”视为无法解释的黑箱现象，而会把它拆成可观测症状、可复现实验和可回归验证的问题。这才是从 demo 走向产品的分水岭。
联动阅读：