AI代理记忆退化：多轮对话中的LLM为何崩溃

在构建审议系统⁹的第90分钟，代理不再引用它半小时前讨论过的架构。会话日志显示，Claude为了给新的工具输出腾出空间，把模块依赖图压缩掉了。代理仍在继续写代码，但那些代码已不再体现它在第一个小时里确立的跨模块契约。测试通过了，集成失败了。代理忘记了自己的设计。

那次失败让我搭进去整整一天调试。如今，研究给出了它发生的原因。

摘要

Microsoft Research与Salesforce在超过200,000次模拟对话中测试了15个LLM，发现从单轮交互转向多轮交互，平均性能下降39%。¹ 退化最早在两轮之后就会开始。驱动这场崩溃的是三种彼此独立的机制：上下文压缩丢弃关键状态；推理连贯性随token预算收窄而碎片化；缺乏共享事实基准时，代理之间的协调随之瓦解。更长的上下文窗口对这三者都无效。Ralph循环模式（每次迭代使用全新上下文，状态存放在文件系统）绕开了压缩损失，却也带来了自己的成本。以下依次是：研究本身、三种机制、今天就能跑起来的检测方法，以及一套多轮韧性协议。

90分钟悬崖

我那篇《上下文工程即架构》⁸记录了一套横跨650个文件的七层上下文体系。构建它需要长时间的编码会话，而代理必须在其间持有复杂的架构状态：模块边界、依赖链、钩子执行顺序，以及跨文件契约。

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实例；状态从文件系统注入；绝不依赖跨越单次迭代的对话记忆。这个模式确实有效。但2025年5月发表的MSR/Salesforce研究揭示，问题的结构性远超上下文窗口大小本身。

多轮崩溃的三种机制

Laban等人把多轮退化拆解成了几种互相独立的机制。这个区分之所以重要，是因为每一种都需要结构上截然不同的干预。¹

机制1：上下文压缩

每一次AI对话都在有限的token预算内进行。随着对话变长，系统会压缩较早的轮次，为新内容腾出空间。这种压缩是有损的。第3轮记录下来的架构决策，未必能活到第15轮。

构建审议系统时，我当场抓到了这一幕。最初的20分钟里，代理确立了一张模块依赖图：deliberation_engine.py依赖consensus_calculator.py，后者又依赖vote_aggregator.py。到第75分钟，代理已经把这条依赖链压缩掉了，写出了一个循环导入。代码在语法上完全合法，而这个循环导入引发了运行时崩溃。

检测方法： 按时间追踪代理输出中跨文件引用的占比。当代理不再提及先前讨论过的文件时，往往意味着压缩已经丢掉了相关的上下文。

# 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的研究发现，多轮退化可以拆成两个分量：小幅的能力（aptitude）下降，以及大幅的可靠性（reliability）恶化。¹ 能力衡量的是模型究竟能不能给出正确答案；可靠性衡量的则是它能否稳定地给出。

在单轮模式下，模型在六项生成任务上的平均性能约为90%。切换到多轮模式后，性能降至约65%——绝对值下降25个百分点。最关键的结论是：”LLM一旦在多轮对话中走错方向，就会迷失，并且不会自行找回来。”¹

推理连贯性的丧失，表现为代理与自己先前的决策自相矛盾。原因不是系统把上下文压缩掉了（那是机制1），而是模型的推理链在轮次之间碎裂了。每一轮的推理在局部都站得住脚，放到全局却前后不一。

Du等人关于认知决策路由的工作，正面针对了这一机制。² 受卡尼曼双系统理论（快速直觉反应对比缓慢审慎推理）的启发，他们的系统会根据任务需求调整推理深度。其洞见在于：并非代理的每一轮都需要同等深度的推理；一律采用相同深度，既会在琐碎步骤上浪费预算，又会在关键决策上投入不足。

检测方法： 比对会话前期与后期输出之间的矛盾。如果代理在第15分钟主张方案A，到第60分钟改主张方案B，却对这一转变只字不提，说明连贯性已经退化。

机制3：协调失败

多代理系统会在多轮退化之上，再叠加一层协调失败。当两个或更多代理协作完成一项任务时，每个代理的上下文都在独立退化。一个已经忘掉共享约束的代理，自然无法围绕它展开协调。

Bhardwaj等人的Agent Context Protocols通过在代理之间建立结构化的通信通道来应对这一点。³ 该框架为上下文共享、错误传播和状态同步定义了明确的协议，在AssistantBench上取得了28.3%的准确率。Krishnan的Unified Agent Communication Protocol则在此基础上，为代理之间加入了零信任安全边界。⁴

我在一次10代理审议中撞上了协调失败：三位评审代理评估同一份代码改动。到第四轮评审时，它们对代码的”当前版本”到底长什么样已经产生了分歧——每个代理的上下文里各自存着一份不同的快照。它们的评审意见彼此冲突，不是因为观点不同，而是因为它们评审的根本不是同一份代码。

检测方法： 在多代理工作流中，比对每个代理各自持有的状态假设。如果不同代理引用了同一产物的不同版本，协调就已经失败了。

为什么更长的上下文窗口解决不了问题

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

他们设置了一个”拼接”（Concat）条件：把完整的多轮对话拼成单个提示词一次性呈现。拼接条件下的表现达到了单轮性能的95.1%。¹ 上下文长度与多轮条件完全相同，信息量也完全相同。唯一的差别是交互结构：一轮，还是许多轮。

这39%的退化不是上下文长度的问题。把上下文窗口从20万token翻倍到40万，也消除不了它——退化来自轮次边界本身，而不是来自空间耗尽。

拼接实验的结论与我的生产数据吻合。Claude的上下文约为200,000个token。我在上下文窗口管理的测量中发现，最长的单次会话（3小时以上、密集调用工具）在触发压缩前大约消耗180,000个token。但质量的退化远早于窗口被填满：90分钟悬崖出现在上下文利用率约60-70%的位置，而不是在边界上。由此累积的认知债会不断滚大，因为代理产出代码的速度已经超过开发者核验的速度。这与复合上下文是同一个问题，只是尺度不同：每一轮都会加入新信息，而这些信息与此前的内容以非线性的方式相互作用。

Du等人的认知决策路由重新框定了这个问题：症结不在于模型能装下多少token，而在于模型在这些token之上分配推理资源的效率。² 他们的系统把简单决策交给快速推理、把复杂决策交给审慎推理，从而将计算成本降低34%，一致性提升23%。

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

Ralph循环解决了机制1（压缩），也部分解决了机制2（连贯性）——办法是让任何一次对话都不会长到足以让它们显形。每次迭代都启动一个全新的Claude实例，配备完整的20万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

每次迭代都拿到完整的上下文预算。没有来自前几轮的压缩残留，也没有来自早期推理链的连贯性碎片。文件系统充当代理的外部记忆：jiro.state.json记录当前故事，jiro.progress.json跨迭代记录已完成的工作，git diff则提供关于”到底改了什么”的事实基准。

Zhang、Kraska与Khattab提出的递归语言模型（Recursive Language Models）走了一条互补的路线：不再启动新实例，而是把上下文卸载到Python REPL环境中，在代码空间而非token空间里对上下文进行推理。⁵ RLM-Qwen3-8B把长提示词当作外部数据结构而非内部记忆，在长上下文任务上比基线高出28.3%。Ralph循环把状态外置到文件，RLM则把状态外置到代码。两种模式以不同的机制，解决的是同一个压缩问题。

Nanda等人的Wink系统处理的是退化已经开始之后该怎么办。⁶ 他们分析了超过10,000条真实的代理轨迹，发现约30%的会话中出现了不当行为：偏离规格、反复兜圈子、工具调用失败。Wink会观察代理的轨迹并给出有针对性的纠偏，解决了90%只需单次干预的不当行为。它的检测是实时的——退化模式一冒头就被识别出来，而不是等到故障扩散到整个代码库。

代价

全新上下文迭代并非没有成本。代价有三：

1. 定向开销。 每次迭代都要花token去重读上一次迭代早已理解的状态。我的测量显示，每次迭代有15-20%的token预算消耗在定向（orient）这一步：读取状态文件、扫描最近的git历史、重建足以继续工作的上下文。一次20万token的迭代，实际可用容量大约从16万至17万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：跨引用追踪

监控代理每次输出中引用了多少个不同的文件。数量呈下降趋势，就是压缩损失的信号：

# 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：矛盾检测

把代理在不同时间点关于架构的陈述放在一起比对。如果它在第20分钟说”模块A依赖模块B”，到第70分钟又说”模块A没有外部依赖”，连贯性就已经退化了。自动化的做法是：取出会话早期与后期输出中代理的EXPLAIN语句（或设计注释），做一次差分。

一套多轮韧性协议

共分三层，各自对应一种机制。请从第1层开始，按需逐层叠加。

第1层：状态检查点

每隔30分钟，把代理当下对架构的理解序列化到一个文件里。不是整段对话，而是结构性的状态：有哪些模块、它们如何连接、有哪些约束在生效。

# 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

一旦代理的行为开始退化，请从检查点恢复，而不是带着已经劣化的上下文继续往下走。

第2层：全新上下文迭代

会话超过60分钟，就切换到Ralph循环模式。关键在定向这一步：注入的状态要恰好够新的上下文继续高效工作，又不必重读整段对话历史。

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

第3层：代理协调协议

在多代理工作流中，请建立一份所有代理都读写的共享状态文档。这份文档充当事实基准，避免我在审议评审中见到的那种分歧。

{
  "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}
  ]
}

每个代理在自己这一轮开始时读取该文档，结束时更新它。发生冲突就触发一次协调暂停，而不是任由分歧悄悄扩大。最好的代理会以这种方式无声运转——正如《隐形的代理》中所探讨的，目标是让基础设施在开发者毫无察觉的情况下发挥作用。

核心要点

• 多轮退化是结构性问题，而非上下文长度的问题。 MSR/Salesforce的研究表明，即便上下文长度保持不变，39%的退化依然发生。造成崩溃的是轮次边界，不是token上限。¹
• 三种独立的机制，需要三种不同的干预。 压缩损失要靠状态检查点，连贯性丧失要靠全新上下文迭代，协调失败要靠共享状态协议。
• 90分钟悬崖真实存在，而且可以测量。 追踪上下文利用率、跨引用的多样性以及架构层面的矛盾，就能赶在生产故障浮出水面之前捕捉到退化。
• 全新上下文迭代有效，但要付出15-20%的开销。 Ralph循环模式是用定向开销换取每次迭代完整的上下文预算。超过60-90分钟，这笔交易开始划算。
• 自适应分配推理资源，优于一刀切的固定深度。 Du等人的认知决策路由通过让推理深度匹配任务需求，将成本降低34%，一致性提升23%。²

常见问题

参考文献