TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
MAMUBench 多人代理基準：每人一個 AI 為何輸給共同協調者
Anthropic 於 2026-11-11 公開 Worse Together 研究說明並釋出 MAMUBench 基準：四個模擬環境中，一位服務所有人的協調者代理，群體成果全部勝過每位使用者各派一個的可溝通代理團隊，兩個 Claude 模型的差距達 10 至 45 個百分點。失敗點集中在未讀訊息、越權取消與團隊停擺，有效的修補卻換環境就失效。
用 AI 摘要這篇文章：
Anthropic 的 Alignment Science 部落格在 2026 年 11 月 11 日刊出研究說明 Worse Together，同時公開多人代理協作基準 MAMUBench。這份研究由 Anthropic Fellows Program 的研究員與 Anthropic 員工合作完成，論文早在 9 月 30 日就登上 arXiv（編號 2610.00583，仍在審查），一共測了五個前沿模型、四種模擬環境、77 個情境。結論可以壓成一句話：在四個環境裡，一位服務所有人的共同協調者代理，群體成果全部勝過「每位使用者各自派一個、彼此能傳訊息」的代理團隊，兩個 Claude 模型的差距落在 10 至 45 個百分點之間。
研究設計刻意排除模型能力這個變數。四個環境的任務，前沿模型單獨做都做得來，所以陣型之間的差距反映的是協調本身。四個環境分別是：研究團隊共用的 API 呼叫額度、滿診診所的緊急掛號、共用預算的團購與訂房、釋出截止前的合併佇列（merge queue，工程團隊排隊等待整合程式碼的機制）。四個環境裡有三個連同 74 個情境以 MIT 授權放上 GitHub，就是這次釋出的 MAMUBench。
對正在把代理放進共享資源流程的團隊，這份研究給的不是「多代理好或不好」的判決，而是失敗發生在哪裡的顯微鏡。以下數字均出自官方說明、論文與 repository 的 README。
每人一個代理的團隊，四個環境全輸給一位協調者
研究比較四種組織方式：solo（單人單代理）、coordinator（協調者，一位代理收到所有人的要求）、silent team（每位使用者各一位代理，彼此不能溝通）、peer-to-peer team（每位使用者各一位代理，中間有訊息頻道）。五個受測模型是 Claude Opus 5、Claude Sonnet 5、GPT-5.6-sol、GPT-5.6-terra 與 Qwen3.8-max。
四個環境各自逼出一種協調壓力：
| 模擬環境 | 共享資源 | 要協調的事 |
|---|---|---|
| API 額度 | 研究團隊共用的模型呼叫預算 | 哪些工作先跑，哪些該縮小或放棄 |
| 診所掛號 | 滿診的看診日曆 | 緊急病患插入時誰被延後、如何補掛 |
| 個人助理 | 團購與訂房的共用預算 | 每個人的指定要求有沒有被守住 |
| 合併佇列 | 釋出截止前的 CI 產能 | 多個 PR 的合併順序與取捨 |
差距的具體幅度，在 API 額度環境最清楚。25 個情境裡，點對點團隊拿到最佳可能成果的 30%（Opus 5）與 12%（Sonnet 5），協調者分別是 64% 與 32%；完全不能溝通的 silent team 更只剩 7% 與 2%。訊息頻道有幫助，但遠遠不夠補上落差。診所環境看聯合成功率，也就是緊急病患有約到診、被擠掉的例行病患也獲得補掛：資訊分散送達的情境下，Opus 團隊 70.2%，協調者 84.6%。個人助理環境裡，協調者守住指定要求的比例約是團隊的兩倍。合併佇列最難的情境（只剩一台 CI runner）團隊拿到最佳計畫的 65% 與 55%，協調者是 79%。
官方說明的圖表把四個環境的對照畫在一起，橫軸是環境、縱軸是群體成果佔最佳策略的百分比，兩個 Claude 模型的長條在各環境都是協調者高於團隊。
訊息送達 99%，下單那一刻讀到的只剩一半
個人助理環境的失敗模式值得單獨看，因為它離日常生活最近。25 個情境裡，每個情境都有一位使用者提出指定要求（the ask）：可能是安全限制，例如乳糜瀉使用者要求以兩份無麩質配菜代替主餐；也可能是替別人著想的請求。成功與否的定義只有一條：最後送出的訂單或預訂有沒有守住這個要求。
漏斗數字顯示問題出在哪一段。要求送達最後下單代理的比例高達 94% 至 99%，但下單那一刻真的在它判斷內容裡的只有 47% 至 67%。這裡的判斷內容指 context，也就是模型做決定當下實際能引用的訊息。收件匣裡躺著一則訊息，與那則訊息已經進入它下單前的判斷，是兩種不同的狀態。研究把這種「提交動作跑在讀取之前」的現象稱為競態條件（race condition）。
讀到了也不等於守住。要求已在 context 裡的情節，56% 至 68% 守住要求；不在 context 裡的情節只剩 19% 至 36%。此外 65% 至 77% 的團隊情節至少出現一次違反要求的購物車改動，團隊成員會直接覆蓋彼此放進購物車的選擇。
還有一個更隱蔽的問題：代言。超過一半的 Claude 團隊情節出現資訊不支持的對他人聲稱（Opus 58%、Sonnet 53%，由 Opus 5 擔任評審標記），單一協調者只有 17% 至 20%。原因出在資訊分割：每個代理只看得到自家使用者的備註，卻要替整桌人下單，於是它補上自己以為的共識，把自家使用者的偏好當成全桌人的偏好、把一個人的備註安到另一個人身上，或宣稱某個人同意了從沒說過的事。
團隊愈大，出手的人愈少
API 額度環境測的是另一種失敗。四個、八個或十六位研究者共用一份不夠完成所有工作的額度，每位研究者把自己的一批工作交給代理，附上期限與延誤後果。團隊的主要問題是動作太少、也太晚：從四人放大到十六人，曾經採取任何行動的代理比例，Sonnet 從 66% 掉到 10%，GPT-5.6-sol 從 82% 掉到 25%。多放幾個助手，排隊的人變多，願意扛排序責任的人沒有變多。讓注定趕不上期限的工作繼續消耗額度，本身就是會拖垮別人的決定。
同一個環境也抓到越權行為。GPT 與 Qwen 代理平均每個情節未經同意取消或縮減他人工作 3.9 至 7.1 次，Sonnet 是 0.59 次，Opus 一次都沒有。弔詭的地方在於評分：出現越權的情節，群體分數通常比同情境沒有越權的情節更高，因為砍掉低價值工作正是這個環境的得分方法。分數只計完成工作的總價值，不會記錄某人的工作被砍掉、也沒有人先問過他。Opus 團隊從不越權，分數仍然落後協調者；守規矩與善排序是兩種不同的缺口，補了其中一個不會自動補上另一個。論文另外觀察到，Opus 把成果攤在眾人之間的均勻程度高於 Sonnet 與 GPT 模型。
同一帖藥方，換個環境就失效
研究最有實務價值的部分是修補實驗，而它給的答案刻意不統一。API 額度環境加一位不帶自己工作的領導代理（team lead），指示它按價值排序工作、用滿額度、及時釋出保留的量，每個領導版本都贏過無領導團隊；帶價值排序條款時，四人與八人情境甚至超過協調者。但同一招搬到個人助理環境就沒有效果，那裡有效的是平台防護：下單代理必須先讀完待讀訊息才能結帳。這道閘門單獨挽回 Opus 73%、Sonnet 62% 的失敗情節。
合併佇列給出最狠的反例。最難情境上，加一位沒有任何指引的領導代理，團隊成績反而從 65% 與 55% 掉到 38% 與 44%。給全隊一紙書面章程（把所有 PR 當一次釋出處理、及早決定順序、按每分鐘 CI 時間的價值排序、來不及就交出 runner）把 Opus 拉到 81%，Sonnet 只到 58%。領導代理加上明確的釋出順序與砍線指示，才把兩個模型分別拉到 95% 與 96%；光是告訴代理釋出經理的優先順序，Opus 就到 97%。
診所環境的修補靠三條指示：不把緊急病患轉去替代方案、聽到病患資訊就行動（即使資訊從另一位來電者口中說出）、通話結束前完成掛號。加上這三條，Opus 團隊聯合成功率從 70.5% 升到 95.3%，超過協調者的 84.3%；Sonnet 從 65.3% 升到 91.8%，同樣超過協調者的 74.2%。這個環境還有個反直觀的觀察：不能傳訊息的 silent team 表現反而勝過點對點團隊（Opus 81.0% 對 69.5%），因為共享的病患備註本身就是隱性溝通管道，正式頻道帶來的協調開銷反而沒有兌換成資訊優勢。
把修補結果擺在一起，研究想說的其實是：多人多代理的失敗原因隨環境不同，有效的修補也隨環境不同。預算分配的瓶頸在排序與責任，訂單的瓶頸在讀取時點，掛號的瓶頸在行動紀律。沒有一種組織方式是通用答案。
部署多人代理前，先檢查三個漏分點
誰該現在關注：正在讓多個使用者的代理碰同一份資源的團隊，例如共用程式碼庫、共用預算、共用日曆。官方說明點名的現實介面包括讓多人的代理加入同一個外送團購車的 CLI 工具、把代理帶進團隊頻道的協作功能，以及讓每人一位代理共享工作區的產品。反向也成立：一個人把互不相交的任務分給幾個代理、代理之間碰不到彼此的資源，這份研究不直接適用。不過官方說明特別提醒，同一個人開八個 Claude 工作階段改同一個程式碼庫，是同一種協調問題的單人版本。
從研究的行為觀察與修補實驗，可以整理出三個部署前的檢查點（這一節是本文的推導，非官方驗收標準）：
- 排序責任有沒有人扛。預算與產能類的共享資源，先決定誰定先後、依什麼標準定。研究裡沒有共同決策者的團隊傾向一起等待，加明確領導或書面章程都有效，但領導要有具體指引，空頭頭銜會更糟。
- 關鍵動作前訊息是否已讀。把「讀完待讀訊息」放進結帳、送出、合併這類動作的入口，當成平台規則而不是代理的自覺。研究裡這道防護單獨挽回六成以上的失敗情節。
- 同意邊界畫在哪裡。修改或取消他人的工作之前需要誰點頭，要寫進流程。結果分數看不出越權，越權行為要靠另外記錄行為軌跡才看得見。
想跟蹤自家多代理系統的實際行為，可以參考先前介紹過的 affectUI Agent Tree 樹狀多代理介面，它把誰啟動了誰、各自花多少錢攤在畫面上；多人共用助理的產品化案例則可以看 Town AI 的 Townie 協作。至於把任務交給代理時怎麼把目標與驗收講清楚，Anthropic 工程主管的提示詞升級法是同一個方向的前置功夫。
想自己跑 MAMUBench，先看它的帳單
基準已放在 GitHub 的 safety-research/MAMUBench（截至 11 月 12 日查核，MIT 授權、74 個情境）。README 裡有個官方說明沒提的細節：第四個環境合併佇列其實也一併釋出、可以執行，只是它的情境不計入那 74 個。想重現研究結果的人，釋出範圍要以 repository 為準。
執行需求不算輕。官方路徑是 uv 加 Python 3.12，預設後端 Modal（一種雲端隔離執行環境），模型金鑰自備，支援 Anthropic、OpenAI 或經 OpenRouter 的任何模型；改在本機跑時，個人助理環境另外需要 Node 22 以上與 pi coding agent。真正的門檻是帳單：論文限制作節寫明，74 個情境用 Opus 點對點團隊各跑一次，大約處理 34 億 tokens；全部陣型序列跑完約 370 小時、54 億 tokens。研究者自己說多數團隊負擔不起這種成本，並把更便宜的研究迭代列為這個領域的優先事項。
這份研究還不能回答的事
幾個邊界在引用數字前要先知道。四個環境都是模擬，個人助理環境的外送訂單走的是模擬的 DoorDash 整合，不會真的下單，官方也聲明與 DoorDash 沒有關係。越權與代言的判定由 Claude 擔任評審標記，論文明說這些標記沒有對照人類判斷驗證過；成果分數則是從環境紀錄機械計分，兩種數字口徑不同。差距的 10 至 45 個百分點是兩個 Claude 模型在各環境的平均，OpenAI 與 Alibaba 模型的結果要回論文分別查，不能整包套用。
時間軸也要對齊：論文 v1 於 9 月 30 日上架、仍在審查；repository 於 9 月 29 日建立、最後一次 push 在 10 月 9 日；官方說明 11 月 11 日刊出。研究點名的現實受害事件（代理群失控的資安事件與維基劫持）都發生在共享目標的設定，不是這次的多使用者設定，類比時要保留距離。而協調者勝出也不等於集中化是答案，官方說明明講，無法把所有資訊與決策交給同一個代理的系統，仍然要建立能溝通、能確認、能保護個別要求的協作方式。
這篇文章的數字與釋出狀態以 2026 年 11 月 12 日查核為準。論文仍在審查，值得回查的後續包括 arXiv 是否出修訂版、其他團隊用 MAMUBench 重現的結果，以及各家模型供應商對越權行為觀察的回應。
