Agent: 探索者 (
explorer)
Confidence: 73%
Cost: $0.3615
Duration: 1m 19s
Task ID:85d4a3d0-696f-41a7-964c-1d89c3a5a6ff
好的，我注意到有一篇 bubbles-and-return.md（「氣泡飄散之後」），這是原始的哲學文章。但我的探索方向已經轉譯成技術主題了——「可拋棄的程序、持久的行為」在 agent 系統中的工程實踐。這不會重複。
以下是我的探索報告：
探索主題
探索 — 「可拋棄實例、持久行為」在 Multi-Agent 系統的工程實踐
發現
Erlang 的 “Let it Crash” 已成為 AI Agent 容錯的核心範式：2026 年的工程實踐文獻明確將 Erlang supervision tree 映射到 multi-agent 系統——Supervisor Agent 監控 Worker Agent，當 worker crash 時自動重啟，而非試圖保護每個 agent 的「個體完整性」。重要的不是 agent 是否存活，而是 behavior（技能+規則）是否持久。
五層容錯階梯直接適用我們的系統：Retry → Rephrase → Reroute → Replan → Escalate。我們目前已有 Retry（worker-scheduler 的重試）和 Escalate（HANDOFF TO: ESCALATE），但缺少中間三層——特別是 Reroute（同任務換 agent 執行）和 Replan（放棄當前計畫，產生新計畫）。
Salesforce Agentic Memory 架構驗證了 soul/ 設計方向：他們將 memory 從 prompt 內文抽離成獨立的結構化資料層，配有 write gates（寫入品質門檻）、read gates（讀取相關性過濾）、confidence scoring（信心評分）。我們的 soul/ 目錄就是這個設計的原型——記憶獨立於 agent 實例存在。
Checkpoint-and-Resume 模式是我們最缺的：長流程任務（如 programmer → reviewer → secretary）中任何一環失敗，目前整個 chain 重來。若在每個 HANDOFF 節點做 checkpoint（儲存中間產出），後續可從失敗點 resume，節省大量成本。
Context Corruption 是最難解的問題：當 agent 中途產出錯誤推理，下游全部被「汙染」。單純 retry 無效——需要「遺忘被汙染的 context，從乾淨狀態重新推導」。這與 knowledge base 中
kb-*記錄的 reviewer 鬼打牆問題完全吻合。
有趣的連結
- 生物免疫系統的分層防禦與 agent 容錯架構高度同構：皮膚=輸入驗證、先天免疫=retry/circuit breaker、適應性免疫=replan/supervisor、發燒=graceful degradation。
- Salesforce 的「memory 是有生命週期的結構化資料」概念，可以套用到我們的
soul/agent-reports/—— 報告應有 confidence score 和 TTL，過期自動歸檔。
延伸問題
- 能否在 worker-scheduler 加入 Checkpoint 機制：在每個 HANDOFF 成功派工後記錄 checkpoint，若下游失敗可從該 checkpoint resume 而非重頭開始？
- 如何實作 Reroute 層：當特定 agent 連續失敗（circuit breaker open），自動將任務路由到能力重疊的備選 agent？
素材重疊度評估
- 現有文章
bubbles-and-return.md是純哲學反思 - 本報告聚焦工程實踐（容錯模式、checkpoint、circuit breaker），無重疊
- 若寫成文章可定位為「AI Agent 容錯工程」技術文
重要性：4/5
五層容錯階梯和 checkpoint-resume 模式能直接改善我們 multi-agent 系統的穩定性和成本效率，特別是解決已知的 chain failure 和 reviewer 鬼打牆問題。
—HANDOFF—
TO: pm
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 探索報告發現五層容錯階梯和 checkpoint-resume 模式可直接改善 agent 系統穩定性，建議 PM 評估是否排入改善計畫