AI 代理的記憶衰退：多輪對話為何會讓 LLM 崩潰

在建構我的審議系統⁹九十分鐘後，代理不再引用它三十分鐘前才討論過的架構。會話記錄顯示，Claude 為了騰出空間給新的工具輸出，已經把模組依賴關係圖壓縮掉了。代理仍持續寫程式碼，但那些程式碼已不再反映它在第一個小時裡建立的跨模組約定。測試通過，整合失敗。代理忘了自己的設計。

那次失敗讓我花了一整天除錯。如今研究解釋了它為何發生。

摘要

Microsoft Research 與 Salesforce 針對 15 個 LLM 進行了超過 20 萬次模擬對話測試，發現從單輪到多輪互動，效能平均下滑 39%。¹衰退最快在第二輪就開始。三種各自獨立的機制促成這場崩潰：脈絡壓縮丟棄了關鍵狀態、推理連貫性隨 token 預算縮減而碎裂，以及缺乏共享事實基準時代理之間的協作失靈。加大脈絡視窗對這三者都無濟於事。Ralph 迴圈模式（每次疊代重開全新脈絡，狀態存在檔案系統）繞開了壓縮造成的損失，但也帶來自己的代價。以下談研究本身、三種機制、您今天就能執行的偵測方法，以及一套建立多輪韌性的協定。

九十分鐘的斷崖

我那篇脈絡即架構⁸記錄了一套橫跨 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 等人把多輪衰退拆解成幾個彼此獨立的機制。這樣的區分很重要，因為每一種都需要結構上截然不同的介入。¹

機制一：脈絡壓縮

每一場 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

機制二：推理連貫性流失

MSR/Salesforce 的研究發現，多輪衰退可拆解成兩個成分：能力的小幅下滑，以及不可靠程度的大幅上升。¹能力衡量的是模型究竟能不能給出正確答案；可靠度衡量的是它能否穩定地做到。

在單輪模式下，模型在六項生成任務上的平均表現約為 90%。切換到多輪模式後，表現掉到約 65%，絕對值下滑 25 個百分點。最關鍵的發現是：「LLM 一旦在多輪對話中走錯一步，就會迷失方向，而且無法自行回頭。」¹

推理連貫性流失的表徵，是代理推翻自己稍早的決定。這並非因為系統把脈絡壓縮掉了（機制一），而是模型的推理鏈在輪次之間碎裂。每一輪的推理在局部都站得住腳，整體卻互相矛盾。

Du 等人關於認知決策路由的研究，正面處理了這個機制。²他們的系統受 Kahneman 雙歷程理論（快速直覺反應對上緩慢審慎推理）啟發，依任務需求調整推理深度。核心洞見是：並非每一輪代理動作都需要相同深度的推理；一律套用同樣深度，會在瑣碎步驟上浪費預算，又在關鍵決策上投入不足。

偵測方式： 留意會話前期與後期輸出之間的矛盾。若代理在第 15 分鐘主張做法 A、第 60 分鐘改口主張做法 B，卻對這個轉變隻字未提，連貫性已經衰退。

機制三：協作失靈

多代理系統會讓多輪衰退再疊加上協作失靈。當兩個以上的代理協力處理同一項任務，每個代理的脈絡各自獨立地衰退。一個已經忘掉共同約束的代理，自然無法圍繞它進行協作。

Bhardwaj 等人的 Agent Context Protocols 透過在代理之間建立結構化的溝通管道來處理這件事。³他們的框架為脈絡共享、錯誤傳遞與狀態同步定義了明確協定，在 AssistantBench 上達到 28.3% 的準確率。Krishnan 的 Unified Agent Communication Protocol 則進一步加上代理之間的零信任安全邊界。⁴

我在一場 10 代理審議中親身遇過協作失靈：三位審查者評估同一份程式碼變更。到了第四輪審查，代理們對「目前版本」長什麼樣已經各說各話。每個代理的脈絡裡都握著不同的快照。他們的審查意見彼此矛盾，不是因為看法相左，而是因為他們審的根本是不同的程式碼。

偵測方式： 在多代理工作流程中，比對每個代理各自持有的狀態假設。若不同代理引用了同一份產出物的不同版本，協作已經失靈。

加大脈絡視窗為何救不了

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

他們測試了一種「Concat」條件：把完整的多輪對話串接成單一提示詞呈現。Concat 條件達到了單輪表現的 95.1%。¹脈絡長度與多輪條件完全相同，資訊內容完全相同，唯一的差別在互動結構：一輪對上多輪。

那 39% 的衰退不是脈絡長度問題。把脈絡視窗從 20 萬 token 加倍到 40 萬，並不會消除衰退，因為衰退源自輪次邊界本身，而非空間用罄。

Concat 這項發現與我的生產環境資料吻合。Claude 運作時約有 200,000 token 的脈絡。我的脈絡視窗管理實測顯示，最長的單次會話（3 小時以上、大量使用工具）在觸發壓縮前約消耗 180,000 token。但品質早在視窗填滿之前就已經下滑。那道九十分鐘斷崖出現在脈絡使用率約 60-70% 之處，而非邊界上。隨之而來的認知債會不斷累積，因為代理產出程式碼的速度快過開發者能查驗的速度。這其實是同一個複合脈絡問題在另一種尺度上的展現：每一輪都添入資訊，而這些資訊與先前的內容以非線性的方式交互作用。

Du 等人的認知決策路由重新框定了這個問題：癥結不在模型能容納多少 token，而在模型如何在這些 token 之間有效率地分配推理資源。²他們的系統把簡單決策交給快速推理、複雜決策交給審慎推理，達成運算成本降低 34%、一致性提升 23%。

全新脈絡的解法（以及它的代價）

Ralph 迴圈解決了機制一（壓縮），並部分解決了機制二（連貫性）——做法是讓任何一場對話都短到來不及讓兩者現形。每次疊代都生成一個全新的 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

每次疊代都拿到完整的脈絡預算。沒有前幾輪留下的壓縮殘跡，沒有更早推理鏈碎裂後的殘片。檔案系統充當代理的外部記憶：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% 只需單次介入的偏差行為。偵測是即時的：Wink 在衰退模式浮現的當下就辨識出來，而不是等到失敗蔓延進整個程式碼庫才動作。

代價

重開全新脈絡並非免費。有三項代價：

1. 定位開銷。 每次疊代都得花 token 重讀上一次疊代早已理解的狀態。我的實測顯示，每次疊代約有 15-20% 的 token 預算耗在定位這一步：讀取狀態檔、掃描近期 git 歷史、重建足以接續下去的脈絡。一次 200K token 的疊代，起手可用容量大約只剩 160-170K token。

2. 隱性知識流失。 對話脈絡承載著檔案系統狀態捕捉不到的隱性知識：某個設計選擇背後的推理、曾被考慮又否決的替代方案、為何選 A 而非 B 的細微權衡。定位步驟注入的是事實（改了什麼、接下來做什麼），推理（為什麼）則在疊代之間蒸發。

3. 協作成本。 若多條 Ralph 迴圈同時運行（平行實作多個故事），每條迴圈各自維護獨立狀態。迴圈之間的協調需要明確的合併邏輯與衝突解決，而這些在單一長會話裡是隱含處理掉的。

成本效益的算式很清楚：60 分鐘以內的會話，單一對話比較有效率；超過 90 分鐘，即便揹上定位開銷，全新脈絡模式仍能產出更高品質的成果。交叉點落在哪裡取決於任務複雜度：跨檔案狀態愈重，交叉點愈早；孤立的單檔案工作則會把它往後推。

在衰退發作前先量出來

不必等到生產環境出事，才發現多輪衰退。以下三種方法，由簡到繁：

方法一：脈絡壓力監控

即時追蹤脈絡使用率。我的 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

方法二：跨檔案引用追蹤

監看代理每次輸出引用了多少個不同檔案。趨勢下滑就是壓縮流失的訊號：

# 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

方法三：矛盾偵測

比對代理在不同時間點對架構的陳述。若代理在第 20 分鐘說「模組 A 依賴模組 B」，到了第 70 分鐘卻說「模組 A 沒有外部依賴」，連貫性已經衰退。自動化的做法是：把代理在會話前期與後期輸出中的 EXPLAIN 陳述（或設計註解）拿來做差異比對。

多輪韌性協定

三個層級，各自對應一種機制。從第一層開始，視需要往上疊。

第一層：狀態存檔

每 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

一旦代理的行為開始劣化，從存檔點還原，別再帶著已經衰退的脈絡硬撐下去。

第二層：全新脈絡疊代

超過 60 分鐘的會話，改採 Ralph 迴圈模式。關鍵在定位這一步：注入足夠的狀態，讓新脈絡不必重讀整段對話歷史就能繼續有效工作。

定位步驟必備的狀態： 1. 目前的任務與驗收標準 2. 上一次疊代修改過的檔案（來自 git diff） 3. 架構決策及其背後的推理 4. 已知的約束與失敗模式

第三層：代理協作協定

多代理工作流程要建立一份共享狀態文件，供所有代理讀取與寫入。這份文件充當事實基準，避免我在審議評審中看到的那種分歧。

{
  "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 上限。¹
• 三種獨立機制需要三種不同的介入。 壓縮流失要靠狀態存檔，連貫性流失要靠全新脈絡疊代，協作失靈要靠共享狀態協定。
• 九十分鐘斷崖真實存在，而且量得出來。 追蹤脈絡使用率、跨檔案引用的多樣性，以及架構陳述的自相矛盾，就能在生產環境出事前先偵測到衰退。
• 全新脈絡疊代有效，但要付出 15-20% 的開銷。 Ralph 迴圈模式拿定位開銷換取每次疊代的完整脈絡預算。超過 60-90 分鐘，這筆交易划算。
• 依需求分配推理資源，勝過一律套用相同深度。 Du 等人的認知決策路由依任務需求匹配推理深度，達成成本降低 34%、一致性提升 23%。²

常見問題

參考資料