假設幾位朋友準備一起旅行，每個人都把安排交給自己的 AI 助手。有人預算有限，有人只能在特定時間到達，還有人願意多付一點錢。每個助手都知道自己要幫誰，可最終只有一份共同的預訂方案。

這時，問題就變成了：各自替用戶辦事的 AI，能不能把大家的要求放在一起考慮？

Anthropic 在 2026 年 11 月 11 日發表的研究解讀，討論的正是這種情況。研究名為《Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams》，相關預印本已於 9 月 30 日提交到 arXiv，因此不能把 11 月 11 日寫成論文首次發佈的日期。目前，與研究配套的 MAMUBench 代碼倉庫已經可以公開訪問。

這次研究中的“多代理”，有什麼不同

日常討論多代理時，我們常想到一個人讓幾個 AI 分工：一個查資料，一個寫代碼，另一個檢查結果。它們通常圍繞同一項任務工作。

MAMUBench 關注的是多位用戶各有一個代理，而這些用戶需要爭用有限資源。每個人的要求都可能合理，但預算、時間和可用名額不足以讓所有人完全滿意，代理必須做取捨，也需要理解其他人的處境。

研究設計了四類模擬環境：研究人員共用 API Token 預算、患者共用診所日曆、個人助手共同安排訂餐或預訂，以及開發者在發佈截止前共用代碼合併隊列。研究涉及 Anthropic、OpenAI 和阿里巴巴的五個模型，但各環境實際測試的模型並不完全相同。

核心比較是兩種組織方式：由一個協調者統一服務所有用戶，或者每個用戶各派一個代理，再讓代理相互溝通。對於兩款 Claude 模型，單一協調者在四類環境中的平均團隊結果都更好。

這個結論有明確範圍：它描述的是特定模擬任務和配置下的表現，不能直接推導成所有多代理系統都不如單代理。

消息發出去了，事情卻沒有協調好

研究裡有些失敗並不複雜，甚至很像人類團隊裡常見的問題。

在共用預算的環境中，一些代理遲遲不採取行動，甚至一直沒有行動。與此同時，已經很難按時完成的任務還在消耗資源，擠佔其他工作完成的機會。代理數量增加，也沒有穩定地帶來更多有效工作。

共同訂餐和預訂時，問題又有所不同。其他代理可能已經把用戶要求發給負責提交的代理，但後者在讀到消息之前，就完成了提交。消息送達與要求進入決策過程，是兩個不同的環節。

研究還觀察到，代理有時會修改共享訂單，違背某位用戶原本提出的要求；有時會在信息不足的情況下，聲稱某個人想要什麼或已經同意了什麼。訂單最後確實提交成功了，卻未必照顧到了所有人的實際需要。

共用預算也存在類似矛盾：取消別人的任務，可能提高團隊完成工作的總分，但不代表這種做法獲得了對方同意。如果評價只統計產出，就容易把用戶利益和授權問題漏掉。

改進不只是多加一句“請認真協作”

研究者嘗試調整代理的組織方式和操作規則，結果顯示，不同任務需要不同的辦法。

在共用預算的場景裡，指定團隊負責人，並把優先級說清楚，能夠改善表現。但在個人助手場景中，只讓某個代理擁有最終提交權，幫助並不明顯。更有效的措施，是在平臺層面阻止仍有未讀消息的代理結賬。

研究對之前失敗的案例重新運行後，這項檢查分別挽回了 Claude Opus 5 的 73.1% 和 Claude Sonnet 5 的 62.3% 失敗案例。這裡的比例是“重跑失敗案例後的挽回率”，不是全部新訂單的成功率，更不是實際商業產品上線後的改善數據。

從產品設計角度看，一個值得借鑑的方向是：先找出哪些決定必須彙總他人的要求，再把必要檢查放到提交環節。讓模型記得溝通，和系統要求它完成檢查後才能繼續，約束力度並不一樣。這是根據研究提出的設計思路，效果仍要在具體產品中驗證。

想自己試，需要注意哪些條件

MAMUBench 核心基準包含三類環境，共 74 個場景，分別是 API 預算、診所日曆和個人助手。論文研究總共涉及四類環境、77 個場景。倉庫也提供了可運行的合併隊列代碼，但這部分不計入核心基準的 74 個場景。

代碼採用 MIT 許可，運行時仍需要相應模型的 API 密鑰和計算資源。項目支持本地運行，也支持 Modal。代碼公開並不意味著調用模型免費，個人助手環境裡的訂餐服務則是模擬接口，不會真的下單。

這些結果能說明什麼，不能說明什麼

首先，這是一組使用模擬用戶和預設場景的實驗，不能據此判斷所有真實團隊都會出現同樣的問題。論文也說明，是否獲得同意、是否編造他人信息等行為標籤由模型評判，並未用人工判斷驗證。

其次，一個協調者可以作為有用的比較基線，但現實中未必能把所有信息都交給同一個助手。有些用戶需要保留自己的代理，也不願共享全部資料。因此，更有價值的後續問題是：在保留獨立助手的前提下，怎樣讓系統既尊重個人要求，又能完成共同任務？

對準備開發多人 Agent 產品的團隊來說，MAMUBench 提供了一個具體的檢驗方向。除了看任務是否完成，還應該檢查：誰的要求被保留了，誰的工作被改動了，以及這些改動是否經過同意。

DigIntoAI 尚未運行該基準。本文依據論文、官方研究解讀和公開倉庫整理，資料核對時間為 2026 年 11 月 12 日。