技術分享
AI 系統可靠性工程：用熔斷、降級與重試把停機成本壓到最低
AI 系統把最不穩定的 LLM 與外部 API 放進主要路徑，限流、逾時與故障每個月都會遇上，等出事才反應，停機損失往往已經造成。本文從停機成本的商業視角出發，說明熔斷、降級與重試三個設計模式如何串成防護鏈，讓系統在依賴故障時自動撐住而不是整條倒下。
多 Agent 卡住的另一個原因：狀態沒有共享好
當多個 AI Agent 一起工作，訊息怎麼傳、誰先誰後有通訊協定在管；但即使協定正確，系統仍可能出錯——因為 Agent 各自握著不完整、甚至互相矛盾的 context。A 更新了客戶資料，B 卻還在用舊版；研究 Agent 查到的結論，撰寫 Agent 根本沒拿到。這不是個別團隊的手氣差：加州大學柏克萊分校的 MAST 研究（Cemri 等人，NeurIPS 2025）分析 7 套主流多代理框架的 1,642 條執行軌跡，歸納出 14 種失敗模式，其中近四成屬於「代理間不對齊」——上下文沒接上、彼此假設衝突、早先的決定被後面的 Agent 遺忘。開發 Devin 的 Cognition 團隊在 2025 年的工程手記裡說得更直接：多代理系統的失敗，多半可以歸結為「系統裡缺了該有的 context」。本文不談訊息的傳遞規則與協作拓撲，只談 Agent 之間的 context、記憶與任務狀態該放在哪、怎麼傳、怎麼保持一致——這是多 Agent 系統真正的資訊骨架。
先分清三層要共享的狀態
把「狀態」一詞拆開，才知道各自該用什麼機制管理。多 Agent 系統裡至少有三層：
- 工作 context（短期）：當前任務的即時脈絡——使用者最初的需求、目前進度、上一步的輸出。生命週期短，任務結束即可丟棄。
- 任務狀態（中期）：整個任務的進度看板——哪些子任務完成、卡在哪、各自產出什麼。所有 Agent 靠它知道「現在整體到哪了」。
- 長期記憶（跨任務）：跨越單次任務、需要累積的知識——客戶偏好、過往決策、企業規則。它讓下一次任務不必從零開始。
主流框架的設計正好印證這個分層。LangGraph 提供兩套並行的持久化機制：checkpointer 負責單一執行緒內的短期狀態（對話連續性、中斷續跑），Store 負責跨執行緒的長期記憶（使用者偏好、累積知識），官方明確建議兩者並用而非混用。CrewAI 則把記憶功能分成四類：短期記憶、長期記憶、專門追蹤人事物的實體記憶，再加一層負責組裝的 contextual memory；舊版分別以 ChromaDB、SQLite 儲存，現行版本已整合為單一 Memory API。而這整套分層的理論源頭，可以追溯到柏克萊 2023 年的 MemGPT 論文（Packer 等人，arXiv 2310.08560）：它借用作業系統的記憶體階層概念，把有限的上下文視窗當作「主記憶體」，放不下的移到外部儲存，讓 LLM 自己呼叫函式在兩層之間搬移資料——這套「虛擬 context 管理」後來發展成 Letta 框架，成為 Agent 記憶架構的重要參照。混用三層是常見錯誤：把短期 context 塞進長期記憶，知識庫會充滿雜訊；把長期知識硬塞進每次對話，又會撐爆上下文視窗。
兩種共享機制：共享儲存與交接載體
Agent 之間傳遞狀態，實務上是兩種模式的組合。
共享儲存（黑板模式）：所有 Agent 讀寫同一份中央狀態，任一 Agent 更新，其他 Agent 都看得到最新版本，適合任務狀態這種需要全體同步的資訊。優點是單一真相來源，代價是要處理並行寫入與存取權限。
交接載體（context handoff）：Agent 完成一段工作後，把成果精煉成結構化的交接物——摘要、關鍵欄位、結論——傳給下一棒，而不是把整段推理過程全部倒給對方。Anthropic 在 2025 年公開其多代理研究系統的工程紀錄，就是這兩種機制並用的實例：主導 Agent 會先把研究計畫存進外部 Memory（因為上下文視窗超過 20 萬 token 就會被截斷，計畫必須放在視窗之外才保得住），而各個子代理則像「智慧濾網」，自己跑完大量搜尋後只把濃縮過的發現交回主導 Agent 彙整。代價也很具體：這類多代理系統的 token 用量約是單純對話的 15 倍；但換來的是以 Claude Opus 4 為主導、Sonnet 4 為子代理的系統，在內部研究評測上比單一 Opus 4 高出 90.2%。
共享多少才夠？兩派實務經驗的張力
該共享到什麼程度，業界有兩種看似相反的答案。Cognition 的原則是「盡可能共享完整 context」：不只傳結論，連完整的行動軌跡都要傳，因為任何被省略的細節都可能改變下游對任務的解讀；他們甚至因此主張，能用單一 Agent 串到底就不要急著拆多代理。Anthropic 的做法則是「精煉再交接」：子代理只回傳濃縮後的發現，避免主導 Agent 被原始資料淹沒。兩者其實不矛盾——差別在資訊流的方向。往下游派工時，寧可多給 context（任務目標、邊界、已知假設），避免下游用錯誤假設開工；往上游回報時，則要先精煉，只交結論與關鍵證據。一個可操作的分界：
| 資訊類型 | 建議範圍 | 理由 |
|---|---|---|
| 任務目標與進度 | 全域共享 | 所有 Agent 需對齊同一目標 |
| 各 Agent 的最終產出 | 共享（精煉後） | 下游要用，但只需結論不需過程 |
| 中間推理、草稿 | 私有 | 屬雜訊，共享只會干擾他人 |
| 長期知識、企業規則 | 共享唯讀 | 共用基準，不該被單一 Agent 隨意改 |
長期知識設成唯讀還不夠周全時，可以再進一步：全體唯讀、僅指定的記憶管理 Agent 可寫，由它負責彙整與更新，兼顧一致性與可維護性。
一致性：別讓任何 Agent 用到過期的 context
共享狀態最危險的失敗，是「陳舊讀取」——A 已更新，B 卻還拿著舊版繼續做，兩者結論從此分岔。MAST 歸類的「代理間不對齊」失敗裡，有一型正是「遺忘其他 Agent 提供的資訊」。幾個實務對策：
- 單一真相來源：同一份狀態只有一個權威副本，所有 Agent 都指向它，不各自快取一份放到走樣。LangGraph 的做法是讓共享狀態由框架統一持久化，而不是散在各 Agent 的對話裡。
- 版本或時間戳：每次更新標記版本，下游拿到時能判斷手上是不是最新，過期就重讀。
- 精煉再共享：寫入共享狀態前先摘要、去蕪存菁，別把原始長文全丟進去——Anthropic 的 15 倍 token 用量提醒我們，未經節制的共享會直接反映在成本上。
共享狀態的目標不是「什麼都記、什麼都傳」，而是讓每個 Agent 在需要時，剛好拿到正確且最新的那一份 context。
恩梯科技：把 Agent 的資訊骨架設計對
Gartner 預估到 2028 年，33% 的企業軟體會內建代理式 AI（2024 年還不到 1%），但同時也警告超過四成的代理式 AI 專案會在 2027 年底前被取消——差別往往就在基礎工程有沒有做對。多 Agent 系統要穩定，光有正確的通訊協定不夠，還要有一副設計良好的資訊骨架——狀態放哪、記憶怎麼分層、context 如何精煉交接、一致性怎麼守住。恩梯科技的 AI 系統顧問服務，會協助企業盤點各 Agent 需要的共享與私有狀態，設計分層的記憶架構與交接機制，讓多個 AI Agent 真正在同一份最新事實上協作，而不是各持己見、越跑越亂。
參考資料
- Cemri et al.，《Why Do Multi-Agent LLM Systems Fail?》（MAST），NeurIPS 2025。arxiv.org/abs/2503.13657
- Cognition，《Don't Build Multi-Agents》，2025。cognition.com/blog/dont-build-multi-agents
- LangChain，《Persistence》（LangGraph 官方文件）。docs.langchain.com/oss/python/langgraph/persistence
- CrewAI，《Memory》官方文件。docs.crewai.com/en/concepts/memory
- Packer et al.，《MemGPT: Towards LLMs as Operating Systems》，arXiv:2310.08560，2023。arxiv.org/abs/2310.08560
- Letta，《MemGPT Is Now Part of Letta》。letta.com/blog/memgpt-and-letta
- Anthropic，《How we built our multi-agent research system》，2025。anthropic.com/engineering/multi-agent-research-system
- Gartner，《Agentic AI is reshaping enterprise software》預測轉引，2025（原始預估：2028 年 33% 企業軟體內建代理式 AI，2024 年不到 1%）。orbilontech.com/ai-agents-enterprise-applications-implementation-2028
- Gartner，《Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027》，2025-06-25。martech.org（引述 Gartner 原始預測）
