AI Agent 记忆退化：为何多轮LLM会崩溃

在构建审议系统的九十分钟后，Agent停止引用三十分钟前讨论过的架构。会话日志显示Claude为了给新的工具输出腾出空间，压缩掉了模块依赖关系图。Agent继续编写代码，但代码不再反映它在第一个小时建立的跨模块契约。测试通过了，集成却失败了。Agent忘记了自己的设计。

那次失败让我花了整整一天调试。现在的研究解释了原因。

**AI Agent在多轮对话中记忆退化达39%**，原因涉及三种机制：上下文压缩丢弃了早期状态，推理连贯性在多轮交互中碎片化，多Agent协调在缺乏共享事实基准时崩溃。更长的上下文窗口无法解决这些问题。以全新上下文迭代并结合文件系统持久化状态是最有效的缓解方案，但需付出15-20%的定向开销。

摘要

Microsoft Research和Salesforce对15个LLM进行了超过200,000次模拟对话测试，发现从单轮到多轮交互平均性能下降39%。¹ 退化最早可在两轮之后开始。三种独立机制驱动了这一崩溃：上下文压缩丢弃关键状态，推理连贯性随token预算缩减而碎片化，Agent间的协调在缺乏共享事实基准时失效。更长的上下文窗口无法修复其中任何一个。Ralph循环模式（每次迭代使用全新上下文并结合文件系统状态）可绕过压缩损失，但也引入了自身的成本。以下内容涵盖：研究背景、三种机制、可立即运行的检测方法，以及一套多轮韧性协议。

90分钟悬崖

我的上下文即架构文章记录了一个横跨650个文件的七层上下文系统。构建该系统需要长时间的编码会话，Agent需要保持复杂的架构状态：模块边界、依赖链、钩子执行顺序和跨文件契约。

我在2026年1月和2月的30次Ralph循环迭代中测量了会话质量。数据呈现出一致的模式：

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

无论任务类型如何，质量悬崖都会出现。长时间重构、测试套件构建和文档编写都在同一条曲线上退化。差异在于严重程度：需要更多跨文件状态的任务更早触及悬崖，而孤立的单文件工作受影响较轻。

我将这一模式归因于上下文窗口压力，并构建了Ralph循环来绕过它。每次迭代生成一个全新的Claude实例；从文件系统注入状态；永远不依赖超过一次迭代的对话记忆。这个模式有效。但MSR/Salesforce于2025年5月发表的研究揭示，问题远比上下文窗口大小本身更具结构性。

多轮崩溃的三种机制

Laban等人将多轮退化分解为独立的机制，这一区分至关重要，因为每种机制需要结构上完全不同的干预措施。¹

机制1：上下文压缩

每次AI对话都在有限的token预算内运行。随着对话增长，系统会压缩早期轮次以腾出空间。压缩是有损的。第3轮记录的架构决策可能无法存活到第15轮。

我在构建审议系统时直接遇到了这个问题。Agent在前20分钟建立了模块依赖图：deliberation_engine.py依赖consensus_calculator.py，后者依赖vote_aggregator.py。到第75分钟，Agent已经压缩掉了依赖链，写出了循环导入。代码在语法上是合法的，但循环导入导致了运行时崩溃。

检测方法： 跟踪Agent输出中跨文件引用的比例变化。当Agent不再引用之前讨论过的文件时，压缩很可能已丢弃了相关上下文。

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

机制2：推理连贯性丧失

MSR/Salesforce的研究发现，多轮退化可分解为两个组成部分：轻微的能力下降和显著的可靠性降低。¹ 能力衡量的是模型能否产生正确答案，可靠性衡量的是模型能否持续做到这一点。

在单轮模式下，模型在六项生成任务中平均性能约为90%。在多轮模式下，性能降至约65%：绝对值下降了25个百分点。关键发现是：”当LLM在多轮对话中走错方向时，它们会迷失且无法恢复。”¹

推理连贯性丧失表现为Agent自相矛盾。并非因为系统压缩掉了上下文（机制1），而是模型的推理链在多轮间碎片化。每一轮的推理局部合理，但全局不一致。

Du等人关于认知决策路由的工作直接解决了这一机制。² 受Kahneman双过程理论（快速直觉反应vs.慢速审慎推理）启发，他们的系统根据任务需求调整推理深度。核心洞察是：并非每个Agent轮次都需要相同的推理深度，统一深度会在琐碎步骤上浪费预算，同时在关键决策上投入不足。

检测方法： 对比会话早期和晚期的输出，寻找矛盾。如果Agent在第15分钟主张方案A，第60分钟转向方案B却未说明原因，则连贯性已退化。

机制3：协调失败

多Agent系统在多轮退化之上叠加了协调失败。当两个或更多Agent协作完成任务时，每个Agent的上下文独立退化。忘记了共享约束的Agent无法围绕该约束进行协调。

Bhardwaj等人的Agent上下文协议通过在Agent之间建立结构化通信渠道来解决这一问题。³ 他们的框架在AssistantBench上达到了28.3%的准确率，定义了上下文共享、错误传播和状态同步的显式协议。Krishnan的统一Agent通信协议进一步扩展了Agent间的零信任安全边界。⁴

我在一次10-Agent审议中遇到了协调失败，当时三个审查者评估同一处代码变更。到第四轮审查时，Agent们对”当前版本”代码的理解已经出现分歧。每个Agent的上下文持有不同的快照。它们的审查结果相互矛盾——不是因为意见不同，而是因为审查的代码不同。

检测方法： 在多Agent工作流中，比较每个Agent持有的状态假设。如果Agent引用同一构件的不同版本，则协调已失败。

为什么更长的上下文窗口无法解决问题

面对多轮退化的直觉反应是”给模型更多token”。MSR/Salesforce的研究通过一个巧妙的实验设计推翻了这一直觉。

他们测试了一个”拼接”条件：将完整的多轮对话作为单个拼接提示呈现。拼接条件达到了单轮性能的95.1%。¹ 上下文长度与多轮条件相同，信息内容也相同。唯一的区别是交互结构：一轮vs.多轮。

39%的退化不是上下文长度问题。将上下文窗口从200K翻倍到400K token也不会消除退化，因为退化源自轮次边界本身，而非空间不足。

拼接实验的发现与我的生产数据吻合。Claude运行时大约有200,000 token的上下文。我的上下文窗口管理测量显示，最长的单次会话（3小时以上、大量工具使用）在压缩触发前消耗约180,000 token。但质量在窗口填满之前就已退化。90分钟悬崖出现在约60-70%的上下文利用率时，而非边界处。由此产生的认知债务随着Agent生成代码的速度超过开发者验证的速度而不断累积。这与复合上下文问题本质相同，只是规模不同：每一轮添加的信息与之前的内容产生非线性交互。

Du等人的认知决策路由重新定义了问题：关键不在于模型能容纳多少token，而在于模型如何在这些token间高效分配推理资源。² 他们的系统通过将简单决策交给快速推理、复杂决策交给审慎推理，实现了34%的计算成本降低和23%的一致性提升。

全新上下文方案（及其代价）

Ralph循环解决了机制1（压缩）并部分解决了机制2（连贯性），方法是永远不让对话运行到足以让这两者显现的程度。每次迭代生成一个全新的Claude实例，拥有完整的200K token上下文。状态通过文件系统持久化，而非对话记忆。

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

每次迭代获得完整的上下文预算。没有来自前几轮的压缩伪影，也没有早期推理链的连贯性碎片。文件系统充当Agent的外部记忆：jiro.state.json跟踪当前故事，jiro.progress.json记录跨迭代的已完成工作，git diff提供实际变更的事实基准。

Zhang、Kraska和Khattab的递归语言模型采取了互补策略：模型不是生成全新实例，而是将上下文卸载到Python REPL环境，以代码而非token空间进行推理。⁵ RLM-Qwen3-8B在长上下文任务上比基线高出28.3%，方法是将长提示视为外部数据结构而非内部记忆。Ralph循环将状态外化为文件，RLM将状态外化为代码。两种模式通过不同机制解决了同一个压缩问题。

Nanda等人的Wink系统解决的是退化已经开始后的问题。⁶ 通过分析超过10,000条真实Agent轨迹，他们发现异常行为（规格漂移、重复循环、工具调用失败）出现在约30%的会话中。Wink观察Agent的轨迹并提供有针对性的纠偏，解决了90%的单次干预异常。检测是实时的：Wink在退化模式出现时即识别，而非等待故障扩散到代码库中。

代价

全新上下文迭代并非没有代价，主要有三项：

1. 定向开销。 每次迭代都要花费token重新读取上一次迭代已经理解的状态。我的测量显示，每次迭代15-20%的token预算用于定向步骤：读取状态文件、扫描近期git历史、重建足够的上下文以继续工作。一个200K token的迭代实际可用容量约为160,000-170,000 token。

2. 隐性知识丢失。 对话上下文承载着文件系统状态无法捕获的隐性知识：设计选择背后的推理、考虑并否决的替代方案、选择方案A而非方案B的微妙原因。定向步骤注入的是事实（什么变了、下一步做什么），而推理（为什么）在迭代间蒸发。

3. 协调成本。 如果多个Ralph循环并发运行（并行故事实现），每个循环维护独立状态。循环间的协调需要显式的合并逻辑和冲突解决，而单个长会话能隐式处理这些。

成本效益分析很明确：60分钟以内的会话，单次对话更高效；超过90分钟，全新上下文模式尽管有定向开销，仍能产出更高质量的输出。交叉点取决于任务复杂度：高跨文件状态需求使交叉点提前；孤立的单文件工作使交叉点推迟。

在退化发生前检测它

无需等到生产故障才检测多轮退化。以下三种方法，从简到繁：

方法1：上下文压力监控

实时跟踪上下文利用率。我的context-pressure.sh钩子在每次工具调用后运行，当利用率超过60%时发出警告：

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

方法2：跨引用追踪

监控Agent每次输出中引用的不同文件数量。下降趋势表明压缩损失：

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

方法3：矛盾检测

比较Agent在不同时间点的架构陈述。如果Agent在第20分钟声称”模块A依赖模块B”，在第70分钟声称”模块A没有外部依赖”，则连贯性已退化。自动化版本：对比Agent在会话早期和晚期输出中的EXPLAIN语句（或设计注释）的差异。

上下文退化模型：在单次长会话中，质量在上下文利用率超过60%后大致线性退化。在全新上下文迭代中，质量每个周期重置，但因定向开销损失15-20%。全新上下文方案优于单次会话的交叉点出现在60到90分钟之间，取决于任务复杂度。

多轮韧性协议

三个层级，分别针对不同机制。从第1层开始，按需叠加。

层级	针对机制	干预措施	实施成本
1	压缩	每30分钟将状态检查点写入文件系统	低：5分钟设置
2	连贯性	60-90分钟后切换到全新上下文迭代	中：需要状态序列化
3	协调	Agent间显式状态同步	高：需要协议设计

第1层：状态检查点

每30分钟，将Agent当前的架构理解序列化到文件中。不是完整对话，而是结构化状态：存在哪些模块、它们如何连接、适用哪些约束。

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

如果Agent行为退化，从检查点恢复，而非在退化的上下文中继续。

第2层：全新上下文迭代

对于超过60分钟的会话，切换到Ralph循环模式。关键在于定向步骤：注入足够的状态，使新上下文无需重读整个对话历史即可高效继续。

定向步骤所需的状态： 1. 当前任务和验收标准 2. 上一迭代修改的文件（来自git diff） 3. 架构决策及其推理 4. 已知的约束和失败模式

第3层：Agent协调协议

对于多Agent工作流，建立所有Agent读写的共享状态文档。该文档充当事实基准，防止我在审议审查中观察到的分歧。

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

每个Agent在轮次开始时读取此文档，结束时更新它。冲突触发协调暂停，而非静默分歧。最优秀的Agent能让这一切隐于无形——正如隐形Agent一文所探讨的，目标是让基础设施在开发者毫无感知的情况下运转。

核心要点

多轮退化是结构性问题，而非上下文长度问题。 MSR/Salesforce的研究表明，即使上下文长度保持不变，退化仍达39%。驱动崩溃的是轮次边界，而非token限制。¹
三种独立机制需要三种不同的干预。 压缩损失需要状态检查点。连贯性丧失需要全新上下文迭代。协调失败需要共享状态协议。
90分钟悬崖真实存在且可测量。 通过跟踪上下文利用率、跨引用多样性和架构矛盾，可在生产故障出现前检测退化。
全新上下文迭代有效但有15-20%的开销。 Ralph循环模式以定向开销换取每次迭代的完整上下文预算。超过60-90分钟后，这一权衡有利于全新上下文。
自适应推理分配优于统一深度。 Du等人的认知决策路由通过将推理深度与任务需求匹配，实现了34%的成本降低和23%的一致性提升。²

常见问题

为什么LLM在多轮对话中会退化？

LLM在多轮对话中通过三种独立机制退化。上下文压缩为在token预算内容纳新内容而丢弃早期信息。推理连贯性在模型的思维链跨越多轮时碎片化，产出局部合理但全局不一致的结果。多Agent间的协调在每个Agent的上下文独立退化时失效。Microsoft Research和Salesforce记录了15个LLM在200,000+次对话中平均39%的性能下降，退化最早可在两轮后开始。

更长的上下文窗口能否修复多轮退化？

更长的上下文窗口无法修复多轮退化。MSR/Salesforce的研究测试了"拼接"条件，将完整对话作为单个提示呈现，达到了单轮性能的95.1%。同样的内容拆分为多轮后性能降至约65%。退化源自轮次边界本身，而非上下文长度限制。将上下文窗口翻倍也无法消除39%的性能差距。

什么是AI Agent的全新上下文迭代模式？

全新上下文迭代在每个工作周期生成新的AI实例，而非继续单个长对话。状态通过外部存储（文件系统、数据库）而非对话记忆持久化。每次迭代读取当前状态、执行工作、写回更新后的状态。该模式以15-20%的"定向"步骤开销（新实例读取和处理外部状态）为代价，消除了压缩伪影和连贯性碎片化。生产数据表明，对于超过60-90分钟的任务，该模式优于单次会话方案。

如何在故障发生前检测多轮退化？

三种检测方法在实践中有效。上下文压力监控跟踪token利用率，超过60%时发出警告（质量退化可能），超过80%时建议开始新会话。跨引用追踪监控Agent每次输出中引用的不同文件数量；下降趋势表明压缩损失。矛盾检测比较Agent在不同时间点的架构声明；如果Agent对模块依赖的理解在会话早期和晚期之间发生变化而未经明确决策，则连贯性已退化。

LLM性能在多少轮后开始退化？

根据MSR/Salesforce对15个LLM超过200,000+次对话的研究，性能退化最早可在两轮后开始。严重程度随对话长度增加：实测数据显示，在持续Agent交互约60-90分钟时出现一致的质量悬崖。需要跨文件架构状态的任务退化更快，而孤立的单文件工作退化较慢。关键发现是：一旦LLM在多轮对话中"走错方向"，它不会自我纠正——错误在后续轮次中不断累积。

参考文献

Laban, Philippe, et al., “LLMs Get Lost In Multi-Turn Conversation,” arXiv:2505.06120, May 2025. arxiv.org. Microsoft Research and Salesforce Research. Tested 15 LLMs across 8 model families on 200,000+ simulated conversations. ↩↩↩↩↩↩
Du, Y., et al., “Cognitive Decision Routing in Large Language Models: When to Think Fast, When to Think Slow,” arXiv:2508.16636, August 2025. arxiv.org. Achieved 34% reduction in computational costs with 23% improvement in consistency. ↩↩↩
Bhardwaj, et al., “Agent Context Protocols Enhance Collective Inference,” arXiv:2505.14569, May 2025. arxiv.org. Introduces structured communication protocols for multi-agent coordination, achieving 28.3% accuracy on AssistantBench. ↩
Krishnan, “Beyond Context Sharing: A Unified Agent Communication Protocol,” arXiv:2602.15055, February 2026. arxiv.org. Proposes standardized agent-to-agent orchestration with zero-trust security boundaries. ↩
Zhang, Alex L., Tim Kraska, and Omar Khattab, “Recursive Language Models,” arXiv:2512.24601, December 2025. arxiv.org. MIT CSAIL. RLM-Qwen3-8B outperforms baseline by 28.3% on long-context tasks by offloading context to a Python REPL environment. ↩
Nanda, Rahul, et al., “Wink: Recovering from Misbehaviors in Coding Agents,” arXiv:2602.17037, February 2026. arxiv.org. Misbehaviors occur in approximately 30% of all agent trajectories; Wink resolves 90% of single-intervention cases. ↩
Author’s session quality measurements across 30 Ralph loop iterations, January-February 2026. Data collected from jiro.progress.json session logs and git diff --stat output per iteration. Orient overhead measured by token count of state injection vs. total iteration budget. ↩
Author’s context-is-architecture system. Seven-layer hierarchy across 650 files documented in Context Engineering Is Architecture. ↩
Author’s multi-agent deliberation system. 10-agent consensus with 3-reviewer autonomous code review documented in The Deliberation System. ↩