Anthropic工程師自曝：多智能體系統90%故障源于傳話游戲

2024年，某大廠把客服系統拆成8個智能體（AI Agent）流水線作業。上線首周，用戶投訴量漲了340%。問題不在模型智商——每個單拎出來都是GPT-4級別——而在它們互相傳話的方式。

這不是模型故障，是context（上下文）故障。

原文作者打了個比方：智能體A提取數據，B總結，C格式化，D發送。四個環節，每個都在"自信地編造"。到D出手時，原始意圖已經變異得面目全非。就像小時候玩的傳話游戲，但每個參與者都覺得自己是對的。

這解釋了為什么多智能體demo在 controlled scenario（受控場景）里絲滑流暢，一到生產環境就崩。

結構化交接：別讓智能體寫小作文

最天真的設計是自然語言接力。A給B發一段文字，B理解后給C發另一段。損耗率驚人。

作者提出的第一條鐵律：用JSON schema或強類型對象，別用自然語言段落。自然語言是lossy（有損）的，結構化數據才可驗證。換句話說，智能體之間不該"聊天"，該"填表"。

具體怎么做？把Agent A → Agent B → Agent C的鏈式結構，改成全部指向同一個State（狀態對象）。A寫State，B讀State寫State，C讀State寫State。鏈變輪轂，所有漂移（drift）被鎖死在單一數據源里。

Model Context Protocol（模型上下文協議，簡稱MCP）的價值就在這里。它不是工具調用協議，是共享上下文協議。每個智能體從同一個MCP服務器讀取，消除記憶偏差。

顯式失敗：拒絕比猜測更安全

第二條鐵律關乎失敗處理。當前主流做法是：輸入模糊？模型硬猜一個。這開啟了信心螺旋——猜錯了還特自信，下游智能體在此基礎上繼續猜。

作者主張顯式失敗模式（explicit failure modes）。B收到垃圾輸入，應該拒絕，而非猜測。拒絕觸發人工介入或流程回滾，猜測則把錯誤埋進系統深處。

這反直覺。產品經理愛說"優雅降級"，但多智能體系統的優雅恰恰是"不優雅地卡住"。卡住了你能看見，猜錯了你很久才發現。

人工檢查點：鏈越長，人越要介入

第三條鐵律關于人機邊界。作者沒給具體比例，但邏輯清晰：步驟越多，越需要human-in-the-loop（人在回路）。

這不是技術債，是設計選擇。某自動駕駛公司把感知-決策-執行拆成三個智能體，中間不設檢查點。測試場完美，開放道路撞了。事后復盤：感知層把卡車陰影識別為障礙物，決策層基于此規劃繞行，執行層忠實執行——三個環節都沒錯，合起來是災難。

檢查點的位置比數量更重要。作者建議放在狀態轉換的關鍵節點，而非每步都卡。

狀態管理即編排

文章收尾的論斷很狠：多智能體系統不是協調問題，是狀態管理問題。搞定狀態，編排自然成立。

這解釋了為什么LangChain、LlamaIndex等框架早期版本讓人失望——它們忙著封裝模型調用，沒解決context漂移。新一代框架如AutoGen、CrewAI開始內置狀態共享機制，但作者暗示這還不夠底層。

MCP的提出者Anthropic顯然在押注這個方向。2024年11月開源該協議時，官方示例就是多智能體共享工具上下文。三個月后，OpenAI的Agents SDK跟進類似設計。

一個細節：原文評論區有人追問"模板功能是不是也能解決FAQ重復問題"，作者沒回復。這暴露了另一個斷層——開發者還在用舊思維（模板匹配）理解新范式（狀態共享）。

如果你的多智能體系統正在生產環境抽搐，先別換模型。檢查一下：它們是在互相寫小作文，還是在同一張表上填數？