Antigravity /swarm 開放預覽：AI 代理如何分工、互審，配額與工作區要注意什麼？
Antigravity /swarm 開放預覽，讓代理共同分工與驗證。解析 Pro、Ultra 資格、共享工作區、看板、配額與可驗收任務的安排。
Antigravity /swarm 面向需要多人分工的軟體任務，一個需求牽涉數個模組時，把修改、測試與回報放進同一段 AI 對話，常讓責任交纏，拆成多個代理後仍需要管理。
Google Antigravity 在 2026 年 11 月 10 日推出 /swarm 預覽，讓協調者安排具名工作者與驗證者，透過共同看板交接。
它帶來的不是單純多開幾個聊天視窗，而是把工作分配、問題回報與互相檢查放到同一條可追蹤的對話紀錄。
依目前文件，/swarm 適用 App 與 CLI 的 Google AI Pro、Ultra 方案，仍屬預覽，Carbon 模型本身的方案資格需另外分清。多名代理也會更快消耗配額。
工作者預設共享工作區，必要時可安排各自副本，真正要管理的仍是檔案歸屬與最後合併，不能把隔離當成自動完成的保證。
我會先交給它能按檔案分工、又有既有測試的小型需求，確認交接真的清楚，再考慮把更大的修改交給整個團隊。
Antigravity /swarm 是什麼，這次新增了哪種分工？
新 /swarm 把工作分配、工作者回報與驗證集中到同一個看板，適用 Antigravity App 與 CLI，因此使用者能看到一項需求如何被拆開與交接。
App 是圖形介面，CLI 則是在終端機用指令對話，兩個入口都可以用 /swarm 描述任務，再讓目前對話成為協調者。
協調者會把工作拆成不容易互相碰撞的部分，例如不同檔案、套件或研究問題，並為各部分安排具名工作者，讓它們能同時推進。
這和讓一名代理處理所有事情不同，因為工作者各自有對話與任務脈絡，回報再放回共同看板，其他成員能看見進度與問題。
但多個代理仍可能一起誤解需求，看板只提供可追蹤的協作方式，不會自動保證原本的目標合理、測試充分或產出正確。
如果需求本身緊密相依，例如前一步結果決定後一步怎麼寫，強行拆成多人同時處理，可能增加等待與反覆修改，未必比較快。
因此適合的起點是能切出清楚責任的工作，再讓看板協助保存交接，若只是單一小問題，普通對話或一個背景子代理可能更直接。
延伸閱讀：GitSwarm 是什麼？Meta 用共享 Git 記憶讓 AI 代理接力，團隊如何借用這套方法
協調者、工作者與驗證者，各自負責什麼？
協調者負責拆任務與判讀回報，工作者實作，驗證者檢查差異與執行測試，因此不能只用最後一句完成通知來代替整體驗收。
官方文件說明，工作者會取得公開任務說明，交代自己擁有哪些範圍、不得碰哪些內容，以及什麼結果才算完成，這些內容會一起貼到看板。
這讓另一名代理能發現任務交界，例如一人改資料格式，另一人改使用該資料的畫面時，可以直接在共同紀錄中提出問題。
協調者通常每兩到四名工作者安排一名驗證者，讓它讀取改動、執行測試，再把發現的問題交回原作者修正，並不是固定只能採某一種人數配置。
另外還有監看角色，在整個團隊沒有進度、工作又尚未完成時提出提醒，它平時等待，不是持續替每個人重做一次工作。
對使用者而言，最有用的紀錄不只是誰說完成，而是誰改了哪個範圍、測試跑了什麼，以及驗證者是否真的看過最新版本。
如果驗證者回報的是舊版本，而工作者之後又改了檔案，就需要重看受影響部分，有互審角色不代表任意後續修改都已一起通過。
/swarm 哪些方案能用，和 Carbon 資格相同嗎？
目前操作文件列出 Google AI Pro 與 Ultra 都可使用 /swarm，Carbon 模型的 Ultra 資格是另一個條件，因此選用協作功能和選用模型要分開確認。
這次公告同時介紹 Gemini 4 Carbon，容易讓人把整批更新都理解為同一套資格，但 /swarm 的入口仍是 App 與 CLI，不能直接推成所有 IDE 擴充套件都有相同介面。
工作者預設使用目前對話的模型，若要讓某個角色改用其他模型，需要明確提出，而且該模型必須是帳號可以在選單中選擇的模型。
官方也允許稍後替等待中的工作者切換模型，讓它保留對話繼續做，但這是依可用模型調整，不能藉此突破原本帳號沒有的使用資格。
實務上，可以把高推理需求放在協調或審查角色，例行檔案修改用較快的模型，不過這只是配置方法，總成本仍要依實際使用紀錄比較。
Google 在公告中分享自己的使用經驗與展示，能說明預期工作方式，卻不能直接證明每個專案都會得到相同速度或品質改善。
每個代理都有隔離工作區嗎？
工作者預設共享工作區，協調者可在並行編輯或建置時安排各自的工作副本，因此不能假設一啟動 /swarm，就已把所有衝突完全隔開。
工作副本可以讓不同工作者在同一份程式庫的不同檢出目錄上修改，減少直接覆蓋檔案，但最後仍要把變更整合回可使用的版本。
如果兩名工作者修改同一個資料格式，即使檔案不在同一處，也可能產生邏輯不一致，這種衝突需要協調者理解交界，不能只靠 Git 合併成功判斷。
官方也說明，移除工作者會刪除它的工作副本，因此需要先讓成果落地，再清除角色，避免把還沒整合的修改一起丟掉。
對資料庫移轉或共用設定這類變更，提示應指定由哪一名代理負責，其他人先讀取，等格式確定後再繼續，這比單純增加人數更能降低返工。
如果工作含公開部署或修改正式資料，也應另外限制允許操作的環境，因為程式碼副本的隔離，不能自動隔開外部帳號與服務的真實影響。
怎麼寫一個可驗收的 /swarm 任務？
合適的提示同時指定目標、檔案歸屬與測試方式，讓工作者知道要改什麼，也讓驗證者知道哪些要求不能為了通過而降低。
例如可以要求，分別為日期工具與金額格式加入測試，各安排一名工作者，保留現有斷言，由驗證者執行既有測試命令，遇到需求不明先回報。
這個例子的目的，是把工作切成可獨立完成的範圍，同時保留共同驗收，而不是要求代理看到失敗就刪除測試、改成較容易通過的標準。
另一類適合的任務是只讀調查，讓不同工作者分別查啟動速度、設定載入與外掛發現流程，提出檔案位置及時間證據，再彙整可能原因。
這時應明確寫出不修改程式，否則調查者可能順手修理自己看到的問題，導致尚未釐清原因前，專案狀態已經改變。
驗證標準也要貼近真正目標，例如改善匯入速度不能只要求程式不報錯，還要能用相同輸入、相同量測方式比較前後結果。
需求縮小不代表只能做簡單事，而是先把驗收做清楚，讓團隊有共同完成標準，之後才有條件擴大到更多套件與較長任務。
看板怎麼追蹤，用量與暫停又怎麼處理？
等待中的成員不使用 token，但多名工作者同時運行會比單一對話更快消耗配額，因此等待免費不能理解成整場協作免費。
App 的 Swarm 面板可查看訊息看板、成員與互動圖，圖形回放能追蹤誰提到誰，讓使用者辨認問題在哪個交接環節停住。
CLI 則可用 /swarm board 開啟看板，支援的終端機也可按 Alt 加 S，在 macOS，Option 是否送出 Alt 訊號會影響快捷鍵，但指令入口仍可使用。
若有工具操作在等待人員批准，需要回到提示處理，不能把所有等待都當成代理自己會恢復，也不要為了消除等待就一次放行不明操作。
當某個成員用完配額，文件說它會暫停，不會不斷自動重試，即使額度更新，也不會自行重新開始，需要新訊息、切換模型或使用者介入。
這對長任務很重要，因為團隊可能看起來還存在，實際上部分角色已經停住，協調者應把完成部分和待處理部分分開回報。
第一次測試可以記錄整體完成時間、模型用量、互審發現及人工修訂次數，並和原本單一對話的相同需求比較，才知道協作成本是否有回報。
延伸閱讀：AI 代理協作研究整數乘法：GitHub 的新界線，為何不能當成實際倍速？
Swarm、Boost 與 Teamwork，該選哪一種？
官方把多代理工作分成不同路徑，/swarm 著重能平行切開的工作，因此不是遇到任何複雜需求，都應使用相同的協作指令。
如果只要在背景查一份文件或跑一次測試，一個子代理就能回報給發起者，不一定需要共同看板與多個角色。
/boost 則面向難題本身，例如複雜錯誤、演算法與棘手重構，讓不同推理路徑被檢查，重點不是把檔案平均分給更多人。
/teamwork 面向跨多個里程碑的工作，會先釐清範圍，再依計畫與稽核關卡推進，適合時間更長、需要規格交接的任務。
相較之下，/swarm 更適合數個檔案或問題可以同時前進，而且使用者希望看著團隊運作、隨時調整的情境。
選錯方式的代價可能是多出協調工作，例如只想找一個函式的用途，卻啟動完整團隊，結果花在交接的時間比閱讀程式還長。
使用者怎麼介入，又不打亂共同紀錄？
範圍或優先順序有變化時，可以先告訴協調者，由它把指示放到對應工作者的看板訊息，讓其他成員也知道交界已經改變。
直接進工作者對話的訊息，依文件不會自動貼到共同看板，因此若答案會影響其他角色，應再讓協調者同步，而不是以為所有人都看到了。
例如測試要求改變，不能只告訴驗證者，否則工作者可能繼續按舊規格實作，最後才發現雙方對完成的定義不同。
批准工具操作也應看當下請求，確認目標與影響範圍，再決定是否允許，不能從同意某個任務，推成後續任何外部操作都已被授權。
Antigravity /swarm 常見問題
每次都應該開越多代理越好嗎？
不需要，工作若不能分開，額外成員可能增加協調與用量，應依檔案範圍和驗收方式決定，而不是把人數當成能力指標。
驗證者說通過，就能直接公開部署嗎？
驗證者只涵蓋它實際檢查的版本與標準，公開部署仍要依專案原有授權和流程處理，不能從測試成功推定已取得其他操作許可。
等待中的工作者要手動刪除嗎？
沒有事情時可以等待而不消耗 token，但要移除前應確認成果已整合，因為移除成員也會刪除其工作副本，不能將它當成暫時收起視窗。
結語：先讓交接可查，再追求更大的平行工作
/swarm 的價值在於把分工與互審放進可以追蹤的流程，適合能明確切開的程式工作與調查，但它仍需要具體需求和最後負責驗收的人。
我會先用一項小型、已有測試的需求比較工作紀錄與返工，再決定增加角色是否值得，這樣較能分辨協作真的帶來幫助，還是只是多了幾個同時運行的對話。
原始資料來源
資料核對於 2026 年 11 月 11 日，依官方公告與文件整理，未自行部署或獨立驗證產品效能。
