失控的子代理：Claude 6/2 大當機與「無限迴圈」的工程教訓

快速摘要：2026 年 6 月 2 日，Claude 全線當機近六小時，據媒體歸因是 Claude Code 的 sub-agent 系統出 bug——子代理指數倍增、陷入無限迴圈、token 暴耗。fibon 的大管家／小助手委派有「來回上限 3 次」的硬限制，正是防這種失控；多供應商設計則對應「別把雞蛋全放一個 AI 籃子」。文末誠實標出 fibon 還缺的那塊。

可略過，如果：你不依賴任何單一 LLM 供應商、也不寫會自我委派的 agent。

那天發生了什麼

2026 年 6 月 2 日約 UTC 06:00 起，Claude 開始大規模離線。status 頁從 Opus 4.6 的 elevated errors 開始記錄，06:39 更新為「Identified」（找到 root cause、推送修復中），約 10:42 修復部署、進入監控，11:49 標記 Resolved。前後約近六小時。

影響範圍很廣：Opus 4.6、Sonnet 4.6 兩個模型，Claude 的 web 與 mobile、Claude Code 與 CLI、Claude API、developer console 全中。企業 API 端撞上一整面的 500 與 529 錯誤。TechRadar 實測時 Sonnet 4.6 卡在「gathering my thoughts」無限轉圈。

媒體普遍歸因的 root cause 是這樣一個故事：Claude Code 的 sub-agent 系統本來是把大型程式任務拆成平行子程序，但一個 bug 讓這些子代理指數倍增、陷入無限迴圈，token 消耗暴衝，把使用者數小時甚至數天的額度在幾分鐘內清空。Anthropic 事後對受影響的 Pro／Max 帳戶做了額度重置（退還被暴耗的 token）——這個動作和「token 暴耗」的歸因方向一致。

為什麼「無限迴圈」是 agent 架構的經典陷阱

就算細節未經官方證實，「自我委派的子代理失控倍增」這個故障類型本身，是任何做多代理系統的人都該背在心裡的。當一個 agent 能 spawn 另一個 agent，而 spawn 又沒有硬性的深度與次數上限時，你就埋了一顆遞迴炸彈：A 委派 B、B 覺得需要幫手又委派 C、某個環節判斷「還沒完成」於是再 spawn——只要終止條件有一絲模糊，加上 LLM 本來就不擅長穩定地判斷「夠了」，這條鏈就可能指數展開。

而 agent 的迴圈失控比傳統程式的死迴圈更貴：傳統死迴圈燒的是 CPU，agent 死迴圈燒的是真金白銀的 token。這把它和我前面兩篇講的「花費沒有剎車」接在了一起——失控的不只是運算，是帳單。

對 fibon 的意義

這題剛好打在 fibon 的多代理設計上，而 fibon 在這裡的選擇是從一開始就假設委派會失控。

fibon 的「大管家／小助手」階層（第 2 章）有幾道硬性邊界。大管家可以把任務委派給小助手，但委派來回有上限，預設 3 次，由資料庫的 delegation_rounds 表追蹤，超過就強制由大管家收手、不再來回。max_delegation_rounds 是寫在 agent 設定裡的欄位，不是靠 prompt 拜託 LLM「不要無限委派」——而是程式層的硬限制。這正是對「sub-agent 指數倍增」這個故障類型的結構性防禦：你可以遞迴，但遞迴有天花板。

第二個對照是供應商依賴。Thoughtworks 在事後評論裡點出這次當機真正的教訓：單一供應商依賴 = 單點失效。 把一家 LLM 的 endpoint 硬編進產品，在 2026 已經是商業連續性風險。fibon 的 Brain 從設計上就是多 LLM provider（llm_factory 支援 Anthropic／OpenAI／Google 等），模型可以在 session 層切換。這不是為了這次當機才做的，但它正好是當機論述要的那個答案——一家掛了，有路可退。

但我得對著這次事故，誠實標出 fibon 還沒蓋完的一塊：

這次當機最該帶走的，其實是 Thoughtworks 那句話的反面：AI 工具應該放大工程師的能力，而不該變成結構性的拐杖。 當 Claude 掛掉、無數開發者的工作流瞬間凍結時，暴露的不只是 Anthropic 的 bug，是整個產業把太多重量壓在單一 AI 上、卻用遠低於對待資料庫的韌性規格去對待它。fibon 能做的，是在自己這一畝地裡，把委派、供應商、成本三道剎車都接上——目前接好了兩道。