AI Agent跑了2000轮对话，我终于搞明白它为什么越聊越蠢

部署 OpenClaw 一个月，处理了 2000+ 轮多轮对话。前 3 轮回答质量很高，从第 4 轮开始明显下降。我翻了调用日志，找到了三个被忽视的性能杀手。

一个月前我觉得 AI Agent 已经很好用了

自从跑了 OpenClaw，日常消息处理、文档摘要、代码 review 都交给它。一开始体验很好——响应快，回答准，偶尔还能给出一些我没想到的角度。

但跑了一两周之后，我开始注意到一个规律：同一个会话里，Agent 的回答质量随着对话轮次增加而下降。

不是那种慢慢变差，而是有个明显的拐点。前 3 轮还好好的，第 4 轮开始它经常答非所问，或者重复之前说过的话。到了第 7-8 轮，它的表现跟刚聊时判若两人。

我以为是模型的问题。换了两个模型，DeepSeek V4 和 Qwen3.5-Plus，现象一模一样。

这说明问题不在模型，在上下文。

实验：按对话轮次统计回答质量

我从 OpenClaw 的 SQLite 数据库里拉了一个月的对话日志，一共 2147 轮对话（去掉纯指令和系统消息后），按轮次分组，人工标注了每轮回答的质量（1-5 分）。

标注标准：

• 5 分：准确回答问题，有补充信息
• 4 分：基本准确，但信息不够完整
• 3 分：部分准确，有遗漏或偏离
• 2 分：答非所问，或重复之前内容
• 1 分：完全错误或废话

我标注了 400 轮（每个轮次段各 50 轮），结果：

从 4.6 降到 2.3，衰减幅度超过 50%。而且不是线性下降——第 3→4 轮的跌幅最大，从 4.1 直接掉到 3.5。

三个真正的原因

翻日志之前我以为是"上下文太长模型处理不了"。但实际上 8 轮对话的 token 量通常只有 4000-8000，远没到任何模型的上限。

真正的问题是上下文的质量，不是长度。

原因一：工具调用的返回值污染上下文

这是最大的杀手。

OpenClaw 在处理消息时会调用各种工具——搜索网页、查数据库、读文件。每次工具调用的完整返回值都会写进上下文。

一次网页搜索可能返回 2000-3000 token 的原始内容，其中可能只有 2-3 句话是有用的。8 轮对话下来，上下文里塞了 5-6 次工具调用的结果，总共一两万 token 的噪音。

模型的注意力被这些噪音稀释了。这就是为什么 token 量不大但质量下降——不是上下文太长，是信噪比太低。

我做了个对比实验：

# 实验：对比有无工具结果摘要的回答质量# 方案 A：原始工具返回值直接塞进上下文# 方案 B：工具返回值先做摘要，只保留关键信息defsummarize_tool_output(raw_output,max_tokens=200):"""把工具返回的原始文本压缩到 200 token 以内"""# 用一个轻量模型做摘要resp=client.chat.completions.create(model="deepseek/deepseek-v4",messages=[{"role":"system","content":"提取以下工具返回值中与用户问题相关的关键信息，压缩到3句话以内。"},{"role":"user","content":f"用户问题：{user_question}\n\n工具返回：{raw_output}"}],max_tokens=200)returnresp.choices[0].message.content

加了这一层摘要之后，第 6 轮的平均质量分从 2.9 提升到了 3.8——提升了 31%。代价是每次工具调用多花一次轻量模型的费用（大约 $0.001）。

原因二：“Lost in the Middle” 效应

这个现象学术界讨论了很久，但在 Agent 场景里表现得特别明显。

模型对上下文的注意力分布不均匀：开头和结尾的内容被重视，中间的内容被忽略。在多轮对话中，早期的对话内容恰好落在上下文的"中间地带"。

上下文结构： [系统提示] ← 开头，注意力高 [第1轮 Q&A] ← 还行 [第2轮 Q&A] ← 开始被忽视 [第3轮 Q&A] ← 注意力最低区域 [工具调用结果] ← 被忽视 [第4轮 Q&A] ← 被忽视 ... [当前用户消息] ← 结尾，注意力高

我设计了一个测试来验证这个效应：在第 2 轮对话中告诉 Agent 一个关键信息（“项目代号是 Phoenix”），然后在第 6 轮问它"项目代号是什么"。

测了 30 次：

• 如果中间只隔 1 轮（第 2 轮说，第 4 轮问）：回忆率87%
• 如果中间隔 3 轮（第 2 轮说，第 6 轮问）：回忆率43%
• 如果中间隔 5 轮（第 2 轮说，第 8 轮问）：回忆率17%

隔 5 轮之后，接近六分之五的概率它会忘掉你说过的关键信息。

原因三：错误的自我修正会恶化上下文

这个最隐蔽。

当 Agent 在某一轮给出了不太准确的回答，用户纠正它，它会道歉并修正。这个"道歉 + 错误回答 + 修正"的过程写进了上下文。

问题是：错误的回答还留在上下文里。后续轮次中，模型看到上下文里同时存在错误版本和正确版本，它的行为变得不确定——有时候会被之前的错误回答"拉回去"。

我在日志里找到了 23 例"回退"现象：Agent 在第 5 轮被纠正后给出了正确答案，但在第 7 轮又给出了第 4 轮的错误答案。

解决方案：三层上下文管理

基于上面的分析，我在 OpenClaw 的配置里加了三层处理：

第一层：工具输出摘要

上面已经展示了代码。每次工具调用的返回值先经过轻量模型做摘要，再放进上下文。

效果：上下文噪音减少约 60%，第 6 轮质量提升 31%。

第二层：滚动窗口 + 关键信息提取

不要把所有历史对话都塞进上下文。只保留最近 3 轮的完整对话，更早的对话做摘要保留。

defbuild_context(messages,current_turn):context=[]# 系统提示永远保留context.append(messages[0])# 超过 3 轮前的对话 → 压缩成摘要ifcurrent_turn>3:old_messages=messages[1:current_turn-3]summary=summarize_conversation(old_messages)context.append({"role":"system","content":f"[之前对话摘要]{summary}"})# 最近 3 轮完整保留context.extend(messages[max(1,current_turn-3):])returncontext

这样做的好处：

1. 上下文总长度可控
2. 关键信息在摘要里不会丢
3. 最近的对话保持完整，细节不损失

第三层：清除错误回答

当用户纠正了 Agent 的错误回答后，把错误的那轮 Q&A 从上下文里删掉，只保留修正后的版本。

defhandle_correction(messages,corrected_turn):"""用户纠正了 Agent 的回答后，清理上下文"""# 删除错误的那轮回答messages.pop(corrected_turn)# 删除错误的 assistant 回复# 保留用户的纠正和 Agent 的修正回复returnmessages

简单粗暴，但很有效。"回退"现象从 23 例降到了 3 例。

优化前后对比

三层处理全部上线后，又跑了两周，重新统计质量分：

第 8 轮的质量从 2.3 提升到 3.3，接近优化前第 3 轮的水平。虽然还是有衰减，但拐点从第 4 轮推迟到了第 6-7 轮。

一个反直觉的结论

跑完这些实验之后，我的核心认知变了：

上下文窗口越大 ≠ 对话质量越好。

现在各家都在卷上下文长度——100 万、200 万 token。但在 Agent 场景里，上下文的信噪比比长度重要得多。一个经过精心管理的 8K 上下文，表现可以超过一个随意堆砌的 100K 上下文。

这也意味着：不要因为模型支持长上下文就把所有东西往里塞。工具调用结果、错误的历史回答、冗长的系统提示——这些都是噪音，会拉低每一轮的回答质量。

对于跑 AI Agent 的开发者，我的建议是：

1. 工具返回值先摘要再入上下文
2. 超过 3-4 轮的历史对话做滚动压缩
3. 错误回答及时清理，不要让它留在上下文里
4. 监控"每轮对话的上下文 token 增量"——如果每轮增加超过 2000 token，说明有东西需要压缩

这些优化不依赖具体的模型——不管你用 DeepSeek、Qwen 还是 Claude，上下文管理的原则是一样的。如果你同时用多个模型，可以通过 API 网关统一管理调用，在网关层做 token 统计和路由。

TheRouter — 多模型 API 网关，一个 Key 调 30+ 模型。内置 token 统计和模型路由，适合需要管理多模型 Agent 的场景。