讓上千個 AI 一起開發軟體，誰來拆任務、分工作、處理程式碼衝突？
微軟研究院在一項實驗中，拿掉了負責統籌的中心智能體，讓 1024 個 AI 自己認領任務、協商分工、編寫和審查程式碼。在斷網、限時 6 小時的條件下，這支隊伍從零復現文件轉換工具 pandoc 的行為，最終通過了 55.06% 的隱藏測試；單個智能體的成績則是 33.89%。
這項實驗尚未完整重建 pandoc，但它展示了一種值得關注的變化：使用相同的底層模型，調整協作方式、增加參與者，也能讓團隊更快達到一定的測試成績，並在時限結束時完成更多工作。
支撐這支隊伍的是微軟提出的多智能體框架 Agensh。它沒有設定統一派活的主管，而是讓每個智能體遵循相同的協作循環，通過程式碼倉庫、即時消息和共享看板，自主尋找下一項工作。
一、AI 團隊的上限，可能卡在層級管理上
單個智能體開發大型軟體，需要不斷閱讀材料、呼叫工具、編寫程式碼和驗證結果。許多步驟只能依次推進，任務越複雜，耗時就越長。
多智能體可以把部分工作平行展開，但也帶來了新的協調問題：誰負責那一塊？兩個智能體修改了同一段程式碼怎麼辦？各自完成的模組，最後由誰整合？
論文將 Codex 子智能體、Claude Code 的相關協作模式和 Copilot fleet 等列為常見方案：由一個主智能體規劃任務，再交給其他智能體執行。
這種結構分工明確，但隨著參與者增加，主智能體需要處理的任務安排、進度更新和整合工作也隨之增多。團隊能擴展到多大，可能受到主管協調能力的限制。
Agensh 嘗試把這些工作分散給團隊成員：每個智能體既負責寫程式碼，也參與發現任務、協調依賴和整合成果。
左側為主管統一分發的中心編排架構，右側為依靠共享基礎設施與協作循環自組織運轉的 Agensh 架構。
二、AI團隊從「主管派活」，轉向「協商自治」
Agensh 把原本集中在主管身上的任務選擇、分工協調和成果整合，交給成員共同完成。每個智能體都遵循同一套五步協作循環：收集上下文、認領子任務、執行並分享發現、驗證結果、合併進展。
一個智能體開始工作前，先查看共同目標、現有程式碼和其他成員的進度，找出尚未完成的部分，再在共享看板上發佈認領聲明，說明自己準備負責什麼。
如果兩項認領發生重疊，相關成員可以直接發消息協商，調整各自的範圍。完成開發後，智能體驗證結果、合入共享程式碼，再發佈變更說明，繼續尋找下一項任務。
整個過程非同步進行，成員不需要等其他人完成同一輪工作，便能繼續推進。
成員能夠自主分工，前提是彼此的工作狀態可見，已經完成的成果也能被其他人接著使用。Agensh 用三類基礎設施，把這套協作循環落到具體操作上。
首先是程式碼倉庫 Gitea。智能體在各自的工作目錄和分支中開發，再將成果整合到主分支。版本控制記錄程式碼的變化，也暴露需要處理的合併衝突。
其次是即時通訊工具 Mattermost。公共頻道用於發佈團隊公告，直接消息用於處理任務重疊、依賴衝突等需要及時協商的問題。兩類消息按不同優先順序送達。
第三是共享上下文看板。成員把已經觀察到的行為、確認的事實、失敗方案、正在處理的任務和完成的修改，分別記錄下來。其他成員既能讀取近期更新，也能搜尋歷史記錄，減少重複探索。
這套協作循環寫在每個智能體的提示詞中，除身份編號外，成員收到的操作說明相同。認領任務、處理衝突和交接成果都有共同的操作規則；具體認領那項任務、與誰協商，則由成員根據工作進度自行決定。
Agensh 負責組織層面的通訊和協作，底層單智能體框架則負責呼叫模型、執行工具和維持各自的工作過程。協調工作由成員和共享系統共同承擔，無需中心主管逐項派發任務、彙總進展。
三、組織規模，也成了 AI 能力的一個變數
底層模型不變，AI 團隊的整體測試表現仍能隨著協作規模擴大而提高。
研究團隊選擇了 ProgramBench 中最難的五項任務，包括 FFmpeg、pandoc 和 PHP-src 等大型開放原始碼軟體。
任務要求智能體在無法聯網獲取原始實現的條件下，從零編寫程序，復現參考軟體的行為。實驗統一使用 GPT-5.6-sol（high），底層單智能體框架為 Copilot，總時限為 6 小時。
從 1 個智能體增加到 128 個，五項任務的平均最終隱藏測試通過率由 19.31% 提升至 28.78%，增加了 9.47 個百分點，相對提升約 49%。
在 pandoc 任務上，研究團隊進一步擴大了規模：單個智能體的最終通過率為 33.89%，128 個智能體達到 50.94%，1024 個智能體達到 55.06%。
更大的隊伍也更早達到了一定的測試成績。在 pandoc 任務中，128 個智能體在第 30 分鐘的檢查點已超過 30% 通過率；32 個和 8 個智能體分別到第 60 分鐘、第 90 分鐘的檢查點才超過這一水平，單智能體在前兩小時內始終未達到。
四、崗位不必預先設定，專業分工也能自行形成
除了最終分數，研究團隊還查看了智能體的運行記錄，觀察它們如何組織協作。
在 8 個智能體的隊伍中，成員已經會協商技術介面，再分頭實現相關模組；遇到任務重疊，也會溝通後調整範圍。
到了 32 個智能體，多個成員開始共同參與同一項程式碼貢獻的審查和整合。一次 PHP-src 任務中，一項修改起初獲得了認可，隨後另一名成員發現反例，先前的認可被撤回，作者修復問題後再次接受審查。
在 128 個智能體的隊伍中，成員開始根據相關經驗選擇審查者，並重複使用已經建立的合作關係。pandoc 任務中，一些成員還約定了更新分支、測試、交給同伴驗證和合併的流程，其他成員隨後沿用並調整了這套做法。
當規模擴大到 1024 個智能體，團隊中出現了多名專門承擔程式碼整合工作的成員。開發者可以聯絡候選整合者，確定接手者後再移交程式碼；某項嘗試失敗後，具備相關經驗的成員也能接續工作。
這些記錄展示了比「自己認領任務」更進一步的協作：成員會選擇合作對象、形成相對穩定的分工，並根據遇到的問題修改工作流程。
不過，自組織仍建立在預設條件之上。研究者已經提供協作循環、通訊工具、任務認領方式和驗證要求；成員自主形成的是更具體的合作關係、專業角色和整合流程。 論文第 2、3 節及附錄 A（https://arxiv.org/html/2609.26781v1）
寫在最後
Agensh 的實驗說明，在這些受控的軟體重建任務中，使用相同的底層模型，讓更多智能體通過共享程式碼、消息和記錄協作，可以提高時限內的測試成績，也能縮短達到一定成績所需的時間。
規模擴大的收益也值得繼續觀察。在 pandoc 上，從 128 個增加到 1024 個智能體，最終通過率由 50.94% 提升至 55.06%。更多參與者帶來了進步，但人數增長與成績增長並不同步。
接下來需要回答的，是這套方式能否用於更廣泛的任務，以及獲得這些進步需要付出多少資源。進入實際開發後，團隊還需要判斷需求、維護程式碼、追蹤錯誤，並明確誰對最終結果負責。
這項實驗已經展示了上千個智能體如何自主分工。要把它變成日常可用的開發方式，還需要進一步驗證協作效果、資源投入與維護成本之間的關係。 (Datawhale)