AI Agent 記憶衰退：為何多輪LLM對話會崩潰

在建構審議系統的九十分鐘後，Agent 停止引用三十分鐘前討論過的架構。對話紀錄顯示Claude為了騰出空間容納新的工具輸出，已將模組依賴圖壓縮掉。Agent 繼續撰寫程式碼，但這些程式碼不再反映它在第一個小時建立的跨模組契約。測試通過了，整合卻失敗了。Agent 遺忘了自己的設計。

那次失敗讓我花了整整一天除錯。如今研究已經解釋了箇中原因。

**AI Agent 記憶在多輪對話中衰退達39%**，原因來自三種機制：上下文壓縮丟棄了較早的狀態、推理一致性在不同輪次間碎片化，以及多 Agent 協調在缺乏共享事實基礎時瓦解。更長的上下文視窗無法解決此問題。以檔案系統持久化狀態搭配全新上下文的迭代方式是最有效的緩解策略，代價是15-20%的定向開銷。

摘要

Microsoft Research 與 Salesforce 在超過200,000次模擬對話中測試了15個LLM，發現從單輪到多輪互動的平均效能下降了39%。¹ 衰退最少只需兩輪就會開始。三種獨立機制驅動了崩潰：上下文壓縮丟棄關鍵狀態、推理一致性隨著 token 預算縮減而碎片化，以及 Agent 之間的協調在缺乏共享事實基礎時瓦解。更長的上下文視窗無法解決上述任何問題。Ralph 迴圈模式（每次迭代使用全新上下文搭配檔案系統狀態）能避開壓縮損失，但也引入了自身的成本。以下內容涵蓋：研究發現、三種機制、您今天就能執行的偵測方法，以及多輪韌性協議。

90分鐘斷崖

我的上下文即架構文章記錄了一個橫跨650個檔案的七層上下文系統。建構該系統需要長時間的程式撰寫會話，Agent 必須維持複雜的架構狀態：模組邊界、依賴鏈、hook 執行順序，以及跨檔案契約。

我在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 等人將多輪衰退分解為獨立的機制，這項區分至關重要，因為每種機制需要結構上截然不同的介入措施。¹

機制一：上下文壓縮

每次 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

機制二：推理一致性喪失

MSR/Salesforce 的研究發現，多輪衰退可分解為兩個面向：輕微的能力損失與顯著的可靠性下降。¹ 能力衡量的是模型能否產生正確答案；可靠性衡量的是它是否能持續做到。

在單輪模式下，模型在六項生成任務中達到約90%的平均效能。在多輪模式下，效能降至約65%：絕對值下降了25個百分點。關鍵發現：「當LLM在多輪對話中走錯方向時，它們會迷失且無法自行恢復。」¹

推理一致性喪失表現為 Agent 自相矛盾——並非因為系統壓縮掉了上下文（機制一），而是因為模型的推理鏈在不同輪次間碎片化了。每一輪的推理在局部上合理，但在全域上卻不一致。

Du 等人關於認知決策路由的研究直接針對此機制。² 受 Kahneman 雙重歷程理論（快速直覺反應 vs. 慢速審慎推理）啟發，他們的系統根據任務需求調整推理深度。核心洞見：並非每個 Agent 輪次都需要相同深度的推理，統一深度會在瑣碎步驟上浪費預算，同時在關鍵決策上投入不足。

偵測方式： 尋找會話早期與晚期輸出之間的矛盾。如果 Agent 在第15分鐘主張方案A，在第60分鐘主張方案B卻未說明變更原因，一致性已經衰退。

機制三：協調失敗

多 Agent 系統在多輪衰退之上又疊加了協調失敗。當兩個或更多 Agent 協作同一任務時，每個 Agent 的上下文各自獨立衰退。一個已遺忘共享約束的 Agent 無法圍繞該約束進行協調。

Bhardwaj 等人的 Agent Context Protocols 透過在 Agent 之間建立結構化通訊管道來解決此問題。³ 他們的框架在 AssistantBench 上達到28.3%的準確率，方法是定義明確的上下文共享、錯誤傳播和狀態同步協議。Krishnan 的 Unified Agent Communication Protocol 進一步擴展了零信任安全邊界。⁴

我在一次10個 Agent 的審議中遭遇了協調失敗，當時三位審查者評估同一段程式碼變更。到了第四輪審查，各 Agent 對「當前版本」的程式碼已產生分歧。每個 Agent 的上下文持有不同的快照。它們的審查相互矛盾——不是因為意見不同，而是因為審查的是不同版本的程式碼。

偵測方式： 在多 Agent 工作流程中，比較每個 Agent 持有的狀態假設。如果各 Agent 引用同一成品的不同版本，協調已經失敗。

為何更長的上下文視窗無法解決問題

面對多輪衰退，直覺反應是「給模型更多 token」。MSR/Salesforce 的研究透過巧妙的實驗設計推翻了這一直覺。

他們測試了一個「Concat」條件：將完整的多輪對話作為單一串接提示呈現。Concat 條件達到了單輪效能的95.1%。¹ 上下文長度與多輪條件相同。資訊內容也相同。唯一的差異在於互動結構：一輪 vs. 多輪。

39%的衰退並非上下文長度問題。將上下文視窗從200K翻倍到400K token 並不能消除衰退，因為衰退來自輪次邊界本身，而非空間不足。

Concat 的發現與我的生產數據一致。Claude運作時擁有約200,000個 token 的上下文。我的上下文視窗管理測量顯示，最長的單次會話（3小時以上、大量工具使用）在壓縮觸發前消耗約180,000個 token。但品質在視窗填滿之前就已衰退。90分鐘斷崖大約出現在上下文使用率60-70%時，而非邊界處。由此產生的認知負債隨著 Agent 產出程式碼的速度超過開發者驗證速度而持續累積。這與複合上下文問題本質相同，只是尺度不同：每一輪新增的資訊與先前內容產生非線性交互作用。

Du 等人的認知決策路由重新界定了問題：關鍵不在於模型能容納多少 token，而在於模型如何在這些 token 之間有效分配推理資源。² 他們的系統透過將簡單決策導向快速推理、複雜決策導向審慎推理，實現了34%的計算成本降低和23%的一致性提升。

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

Ralph 迴圈解決了機制一（壓縮），並部分解決了機制二（一致性），方法是永遠不讓對話執行到足以讓任一機制顯現的程度。每次迭代產生一個擁有完整200K token 上下文的全新Claude實例。狀態透過檔案系統持久化，而非對話記憶。

# 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 的 Recursive Language Models 採取了互補的方式：不是產生全新實例，而是將上下文卸載到Python REPL 環境中，以程式碼而非 token 空間進行上下文推理。⁵ RLM-Qwen3-8B 在長上下文任務上比基線高出28.3%，方法是將長提示當作外部資料結構而非內部記憶處理。Ralph 迴圈將狀態外部化到檔案；RLM 將狀態外部化到程式碼。兩種模式透過不同機制解決了同一個壓縮問題。

Nanda 等人的 Wink 系統則處理衰退已經發生後的情況。⁶ 分析超過10,000條真實世界的 Agent 軌跡後，他們發現約30%的會話中會出現異常行為（規格偏移、重複迴圈、工具呼叫失敗）。Wink 觀察 Agent 的軌跡並提供針對性的路線修正，解決了90%的單次介入異常行為。偵測是即時的：Wink 在衰退模式浮現時就加以識別，而非等待失敗擴散到整個程式碼庫。

代價

全新上下文迭代並非免費。有三項成本：

1. 定向開銷。 每次迭代需要花費 token 重新閱讀上一次迭代已經理解的狀態。我的測量顯示，每次迭代的 token 預算中有15-20%用於定向步驟：讀取狀態檔案、掃描近期 git 歷史、重建足夠的上下文以繼續工作。一次200K token 的迭代實際只有約160,000-170,000個 token 的可用容量。

2. 隱性知識流失。 對話上下文承載了檔案系統狀態無法捕捉的隱性知識：設計選擇背後的推理、被考慮過又否決的替代方案、選擇方案A而非方案B的細微原因。定向步驟注入的是事實（什麼改變了、下一步是什麼）。推理（為什麼）在迭代之間蒸發殆盡。

3. 協調成本。 如果多個 Ralph 迴圈同時運行（平行故事實作），每個迴圈維持獨立的狀態。迴圈之間的協調需要明確的合併邏輯和衝突解決，而這些在單一長會話中是隱式處理的。

成本效益的計算十分明確：60分鐘以內的會話，單一對話更為高效。超過90分鐘後，全新上下文模式儘管有定向開銷，仍能產出更高品質的結果。交叉點取決於任務複雜度：高度跨檔案狀態將交叉點提前；獨立的單檔案工作則將其推後。

在衰退發生前加以量測

不必等到生產環境出問題才偵測多輪衰退。以下三種方法，由簡到繁：

方法一：上下文壓力監控

即時追蹤上下文使用率。我的 context-pressure.sh hook 在每次工具呼叫後執行，當使用率超過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

方法二：跨引用追蹤

監控 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

方法三：矛盾偵測

比較 Agent 在不同時間點的架構陳述。如果 Agent 在第20分鐘聲稱「模組A依賴模組B」，在第70分鐘又聲稱「模組A沒有外部依賴」，一致性已經衰退。自動化版本：對比 Agent 在會話早期與晚期輸出中的 EXPLAIN 陳述（或設計註解）。

上下文衰退模型：在單一長會話中，品質在上下文使用率超過60%後大致呈線性衰退。在全新上下文迭代中，品質每個週期重置但損失15-20%的定向開銷。全新上下文模式優於單一會話的交叉點出現在60至90分鐘之間，取決於任務複雜度。

多輪韌性協議

三個層級，分別針對不同機制。從第一層開始，視需要逐步疊加。

層級	針對機制	介入措施	實施成本
1	壓縮	每30分鐘將狀態檢查點存入檔案系統	低：5分鐘設定
2	一致性	60-90分鐘後採用全新上下文迭代	中等：需要狀態序列化
3	協調	Agent 之間的明確狀態同步	高：需要協議設計

第一層：狀態檢查點

每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 行為衰退，從檢查點恢復，而非在衰退的上下文中繼續。

第二層：全新上下文迭代

對於超過60分鐘的會話，切換至 Ralph 迴圈模式。關鍵在於定向步驟：注入足夠的狀態，讓新的上下文能高效地繼續工作，而無需重讀整段對話歷史。

定向步驟所需的狀態： 1. 當前任務與驗收標準 2. 前一次迭代修改的檔案（從 git diff 取得） 3. 架構決策及其推理過程 4. 已知約束與失敗模式

第三層：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 之間的協調在各自上下文獨立衰退時失敗。Microsoft Research 和 Salesforce 記錄了15個LLM在超過200,000次對話中平均39%的效能下降，衰退最少僅需兩輪就會開始。

更長的上下文視窗能解決多輪衰退嗎？

更長的上下文視窗無法解決多輪衰退。MSR/Salesforce 的研究測試了一個「Concat」條件，將完整對話作為單一提示呈現，達到了單輪效能的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. ↩