Google Antigravity 推出 /swarm：AI 編程從單 Agent 執行走向多 Agent 團隊協作的 4 類角色解讀

作者注：本文結合 Google Antigravity 的官方博客和使用文檔，說明 /swarm 中多 Agent 的分工方式、協作機制、可視化管理和使用邊界。

2026 年 11 月 10 日，Gemini 4 Carbon 正式開放。同一天，Google Antigravity 團隊推出了 /swarm 多 Agent 協作功能（Preview）。這條指令可以把一次對話變成一支 AI 工程小隊：有人拆任務，有人寫代碼，有人做檢查，還有人負責發現進度卡住。

這項功能有公開依據。Antigravity 的官方博客和 Swarm 使用文檔都已上線，Google 還表示其工程師已在內部使用約 5 周。/swarm 的重點也不是同時開幾個聊天窗口，它嘗試建立一套能自主拆解任務、並行執行、共享進度、相互驗證並持續修復的協作系統。

核心價值：讀完本文，你會了解 /swarm 的具體執行機制、各個角色怎樣配合、用戶如何觀察和干預，以及它在額度和權限上的實際限制。

Google Antigravity /swarm 關鍵術語 to know

/swarm 引入了好幾個角色名詞。先把這些概念對齊，後面的機制會好理解很多。

什麼是 Google Antigravity /swarm：核心信息速覽

/swarm 和 Gemini 4 Carbon 的正式開放一起發佈，但兩者是不同的東西。前者是 Antigravity 中的多 Agent 編排功能，後者是一個模型。下表彙總了目前官方已經公開的信息。

爲什麼單 Agent 難以承擔大型工程任務

單個 Agent 處理一個函數、一個 Bug 時效果很好。任務一旦擴展到幾十個文件、多個模塊之間的依賴，或者需要反覆運行測試，一個 Agent 就要在同一段上下文裏記住所有細節。上下文越拉越長，前面的約束容易被後面的執行細節擠掉。

任務分配也是一個難點。單 Agent 只能順序執行，A 模塊的修改沒做完，B 模塊的調查就得等着。很多工程任務本身可以拆開並行，比如分別修復不同軟件包的失敗測試，串行執行會浪費時間。

最容易被忽略的是驗證。寫代碼的 Agent 檢查自己的代碼，很容易沿用原來的假設，發現不了思路上的偏差。人類團隊的做法是讓另一個人做 Code Review，/swarm 把這套分工搬進了 AI 編程流程。

Google Antigravity /swarm 如何啓動一個 Agent 團隊

根據官方使用文檔，/swarm <task> 運行後會按下面的順序推進：

1. 當前對話轉變爲 Coordinator：你正在對話的這個 Agent 成爲協調者，負責理解總任務。
2. 拆分工作內容：Coordinator 根據任務結構劃分出若干子任務。
3. 創建獨立 Worker：每項工作對應一個 Worker，每個 Worker 獲得獨立上下文和一份公開的任務說明。
4. 執行與驗證：Worker 修改代碼或開展調查；Verifier 檢查代碼修改、執行測試，把問題反饋給對應的 Worker。
5. 修復循環：Worker 根據反饋修改，修改後再次接受檢查。
6. 彙總報告：Coordinator 整合各成員的結果，向用戶報告。

每個 Worker 的上下文是獨立的，只裝着自己那部分任務的信息，長上下文互相污染的問題因此減輕。任務說明是公開的，其他成員可以知道誰在做什麼，分工就有了明確邊界。

/swarm 團隊分工：Coordinator、Worker、Verifier 與 Monitor

官方文檔中，一個 Swarm 團隊通常包含四類角色。需要說明的是，這是官方描述的典型組織方式，並不是所有任務都套用的固定架構。具體創建幾個 Worker、是否需要額外成員，由 Coordinator 根據任務決定。

/swarm 中的 Verifier 與 Monitor 機制

官方博客把 Verifier 稱爲“對抗式驗證 Agent”。它的任務是找出問題：檢查其他 Agent 的修改，運行測試，對不合理的改動提出質疑。Worker 收到反饋後修復，再次提交檢查，執行和驗證就構成了閉環。

Monitor 處理的是另一類風險。多個 Agent 協作時，可能出現所有成員都在等待、誰也不往前推的局面。Monitor 平時休眠，一旦發現團隊整體停止活動而任務還沒完成，就會喚醒相關成員。有了它，團隊卡住時不必完全依賴用戶手動介入。

/swarm 的不同角色可以使用不同模型

Google 在官方博客中建議按角色特點分配模型，而不是讓所有 Agent 都使用最昂貴的模型：

• 使用 Gemini 4 Carbon：總體架構設計、任務協調、安全審查、複雜代碼審計
• 使用更快、更輕量的模型：常規代碼實現、並行文件修改
• 使用專門的驗證 Agent：自動測試與驗證

官方文檔的示例中，也有讓不同模型分別負責代碼實現和獨立驗證的用法。這是一種成本和能力的平衡思路：複雜判斷交給強模型，大批量的執行工作交給快模型。

💡 選擇建議：如果你在自建的多 Agent 流水線裏也想按角色搭配模型，可以先通過 API易 apiyi.com 用同一個 API Key 測試不同模型在規劃、實現、審查環節的表現。確定每個角色的合適人選後再固化配置，切換時只需要改 model 參數。

/swarm 多 Agent 如何協同而不互相干擾

共享消息板：Agent 之間的公開溝通

各 Agent 共用一個追加式的共享消息板（Shared Message Board），協作過程和任務進度都記錄在上面。消息只追加、不覆蓋，團隊的溝通曆史完整可追溯。Agent 在等待其他成員時可以休眠，需要輸入時再被喚醒，Google 稱空閒等待不消耗 Token。

這種設計比讓 Agent 私下互相調用更透明。Verifier 給 Worker 的反饋、Coordinator 的調度決定都擺在明面上，用戶事後覆盤時能看清問題出在哪一環。

共享工作區與獨立工作副本的區別

這部分官方博客和使用文檔的表述有所不同，容易寫錯。博客強調並行 Worker 可以在隔離的 Git Worktree 中工作，避免直接改同一個目錄。使用文檔則說明了更細的規則：

• 默認情況：Workers 共享當前工作空間。
• 按需隔離：多個 Worker 需要同時修改或構建項目時，Coordinator 可以爲它們分配獨立的代碼工作副本。
• 移除即刪除：移除某個 Worker 時，它的工作副本會被刪除，所以要先把成果合併或提交。

所以準確的說法是：系統會根據並行任務的需要安排隔離的工作副本，而不是所有 Agent 天然各自擁有完全獨立的 Git Worktree。只做調查、不改文件的任務，共享工作區就夠用；多個 Worker 同時改代碼、跑構建時，獨立副本能減少文件衝突。

如何在 Antigravity 中觀察和控制 /swarm 團隊

多 Agent 並行工作，最怕的是用戶不知道里面在發生什麼。Antigravity 爲此提供了三種核心視圖，CLI 中也有對應的快捷操作。

用戶的控制權不限於看結果。通過這些入口，你可以查看每個 Agent 的工作軌跡，直接進入某個 Worker 進行干預，也可以調整 Coordinator 的任務要求。Alt + J 和 Ctrl + K 說明工具調用審批仍然保留在人的手裏，Agent 需要執行敏感操作時會停下來等確認。

/swarm 能夠解決哪些複雜工程任務

Google 披露的內部使用場景主要有三類：多軟件包遷移、跨子系統根因調查和複雜軟件架構重新設計。它們的共同點是：工作量大，可以拆分，並且需要驗證。

官方使用文檔給出的例子更貼近日常開發：

• 分別修改多個 API Handler，併爲每個 Handler 配置測試；
• 並行調查 CLI 啓動緩慢的根本原因；
• 把大型項目中失敗的測試按軟件包分組，分配給不同 Agent 修復；
• 讓不同模型分別負責代碼實現和獨立驗證。

Google 還展示過一個官方演示：藉助 Antigravity 的多 Agent 協作，Carbon 處理了 7 份公開的城市規劃 PDF，提取出 206 個工程圖視圖，最終生成約 906,000 個三角面的交互式 Three.js 建築模型，整個過程經歷了 10 輪夜間迭代。這是 Google 的官方案例，不屬於獨立第三方驗證，但能看出多 Agent 在長週期任務中的分工方式。

/swarm 的成本、權限與 Preview 限制

多 Agent 的額度消耗

空閒等待的 Agent 不消耗 Token，但這不代表 /swarm 省錢。每個 Worker 都是獨立 Agent，多個成員同時執行時，整體額度消耗會明顯快於單一對話。Google 自己也提醒了這一點。

還有一個容易踩的坑：某個 Worker 耗盡額度後會暫停，之後額度恢復了，它也不會自動繼續執行，需要用戶手動處理。長時間運行的大任務開始前，最好先估算額度是否夠用。

Swarm 功能權限 ≠ Carbon 模型權限

這是最容易混淆的一點。能用 /swarm，不代表能在 Swarm 裏使用 Carbon。

換句話說，Pro 用戶可以體驗 Swarm 的協作機制，但 Agent 能用哪些模型，仍受各自訂閱的模型權限約束。

影響分析：/swarm 推動 AI 編程從助手走向團隊

對開發者的影響

• 角色轉變：開發者從“向模型提問的人”變成“組織 AI 團隊的人”，任務拆分質量和驗收標準會直接影響結果。
• 驗證前置：Verifier 機制讓測試和審查成爲流程的默認環節，不再是生成之後的補救動作。
• 成本管理變重要：多 Worker 並行意味着要關注額度、模型搭配和任務粒度，不能只看單次對話體驗。

對行業的影響

• 多模型協作成爲部署方向：強模型負責規劃和審查、快模型負責批量執行，這種分工會被越來越多的 Agent 框架借鑑。
• 競爭焦點轉向任務交付：模型競爭正在從單輪問答分數轉向長週期任務的規劃、執行、驗證和交付能力。

用 API 復現 /swarm 多 Agent 思路：極簡示例

想在自己的項目裏試試“協調者拆分 + 工作者執行”的思路，可以用 OpenAI 兼容接口寫一個最小原型。下面的代碼只演示協作結構，不是 Antigravity /swarm 的實現，模型名請替換爲你賬戶中可用的模型。

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

def ask(model, prompt):
    resp = client.chat.completions.create(
        model=model, messages=[{"role": "user", "content": prompt}]
    )
    return resp.choices[0].message.content

plan = ask("STRONG_MODEL", "把“修復 3 個 API Handler 的失敗測試”拆成獨立子任務，每行一個")
for task in [t for t in plan.splitlines() if t.strip()]:
    print(ask("FAST_MODEL", f"完成這個子任務並給出補丁：{task}"))

import concurrent.futures as cf
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

COORDINATOR_MODEL = "STRONG_MODEL"   # 規劃與彙總，換成推理能力強的模型
WORKER_MODEL = "FAST_MODEL"          # 批量執行，換成快速輕量模型
VERIFIER_MODEL = "REVIEW_MODEL"      # 獨立審查，建議與 Worker 不同
board = []                           # 追加式共享消息板

def ask(model, system, prompt):
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": prompt}],
    )
    return resp.choices[0].message.content

def worker(task, max_rounds=3):
    patch = ask(WORKER_MODEL, "你是 Worker，只負責分配給你的子任務。", task)
    for i in range(max_rounds):
        review = ask(VERIFIER_MODEL,
                     "你是 Verifier，檢查補丁問題。沒有問題只回復 PASS。",
                     f"任務：{task}\n補丁：\n{patch}")
        board.append(f"[Verifier] {task[:20]}... 第{i+1}輪：{review[:60]}")
        if review.strip().startswith("PASS"):
            return patch
        patch = ask(WORKER_MODEL, "根據審查意見修復補丁。",
                    f"任務：{task}\n原補丁：{patch}\n意見：{review}")
    return patch + "\n# 未通過驗證，需人工檢查"

goal = "爲 users、orders、payments 三個 API Handler 補充輸入校驗並修復失敗測試"
plan = ask(COORDINATOR_MODEL, "你是 Coordinator，把目標拆成互不重疊的子任務，每行一個。", goal)
tasks = [t.strip() for t in plan.splitlines() if t.strip()]
board.append(f"[Coordinator] 拆分爲 {len(tasks)} 個子任務")

with cf.ThreadPoolExecutor(max_workers=4) as pool:
    results = list(pool.map(worker, tasks))

summary = ask(COORDINATOR_MODEL, "彙總各 Worker 結果，列出完成情況與風險。",
              "\n\n".join(results))
print("\n".join(board))
print(summary)

🚀 快速開始：搭建這類多角色原型時，推薦通過 API易 apiyi.com 獲取 API Key 和新用戶免費測試額度。平臺提供 OpenAI 兼容接口，可以在一套代碼裏調用 OpenAI、Claude、Gemini 等模型，方便驗證“強模型規劃、快模型執行、異構模型審查”的組合是否適合你的項目。

常見問題 FAQ

Google Antigravity /swarm 核心要點 Key Takeaways

• 執行機制：/swarm <task> 讓當前對話變爲 Coordinator，拆分任務並創建獨立 Worker
• 典型分工：Coordinator、Worker、Verifier、Monitor，通常每 2—4 個 Worker 配一個 Verifier
• 協同方式：追加式共享消息板公開溝通，空閒等待的 Agent 不消耗 Token
• 工作區規則：默認共享工作空間，並行修改時按需分配獨立工作副本
• 可視化控制：Board、Members、Graph 三視圖，加上 /swarm board、/agents 等 CLI 操作
• 現實邊界：Preview 狀態，多 Worker 額度消耗快，Swarm 權限不等於 Carbon 權限
• 自建實踐：可通過 API易 apiyi.com 用統一接口組合多個模型，搭建自己的多角色原型

總結

Google Antigravity /swarm 的核心要點：

1. 從並行到協作：/swarm 的價值在於任務拆分、獨立上下文、對抗式驗證和進度監控形成的完整循環，並行執行只是其中一部分。
2. 隔離按需分配：共享工作區和獨立工作副本按任務需要切換，用戶需要關注合併時機。
3. 能力與成本並存：多 Agent 提升了複雜工程任務的處理能力，也帶來了更高的額度消耗和更復雜的資源管理，目前仍是 Preview。

對開發者來說，/swarm 意味着工作方式在變化：不只是向模型提問，而是組織一支能分工、執行、驗證和交付的 AI 團隊。即使暫時用不上 Antigravity，這種“按角色分配模型、讓驗證獨立於執行”的思路也可以用在自己的 Agent 系統裏。推薦通過 API易 apiyi.com 快速驗證多模型組合的效果，平臺提供免費測試額度和多模型統一接口。

📚 參考資料

1. Google Antigravity Swarm 官方文檔：/swarm 執行機制、角色配置、工作副本與 CLI 操作
2. 鏈接： antigravity.google/docs/swarm

3. 說明： Coordinator、Verifier、Monitor 細節以及 Board / Members / Graph 視圖的一手資料

4. Google Antigravity 官方博客：Gemini 4 Carbon in Google Antigravity

5. 鏈接： antigravity.google/blog/gemini-4-carbon-in-google-antigravity

6. 說明： /swarm 發佈信息、多 Agent 架構、模型角色分配建議

7. Google 官方公告：Gemini 4 Carbon is now available

8. 鏈接： blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available

9. 說明： Carbon 正式開放範圍與 /swarm 預覽發佈背景

10. Google AI 訂閱權益頁面：AI Pro 與 Ultra 的模型權限

11. 鏈接： one.google.com/about/google-ai-plans

12. 說明： 區分訂閱等級與 Carbon 模型訪問權限

13. The Verge 發佈報道：Google releases Gemini 4 Carbon with agent swarm feature

14. 鏈接： theverge.com/ai-artificial-intelligence/1030787/google-gemini-4-carbon-public-rollout
15. 說明： 獨立媒體視角的發佈背景與訪問限制

作者: APIYI 技術團隊
技術交流: 歡迎在 API易 apiyi.com 網站首頁聯繫我們交流多 Agent 實踐，更多接入資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• Gemini 4 Carbon 發佈解讀：59 分反超 Opus 5.5，17 項贏 15 項卻調不到:Gemini 4 Carbon 在 Artificial Analysis 綜合智能指數拿到 59 分登頂，官方 17 項對比贏 15 項。但它沒有 API 型號 ID，也沒有開放時間表。本文按口徑拆清分數，說明現階段爲什麼調不到，以及國內開發者現在可以先用 gemini-4-argon。