AIREITER一個證明用了 5,000 萬行 Lean 4、兩週寫出 80 萬行安全 Rust，TPU 核心平均快了 4.09 倍——Google 在 11 月 13 日發布的研究更新，展示了 Antigravity Teamwork 的能力。不過，Teamwork 並不是日常小任務的萬用解；它通常只在需要執行數小時甚至數天、而且能拆成多個里程碑的專案中真正划算，因為一次執行就可能吃掉每週配額的大半。
Antigravity Teamwork 到底是什麼？
Antigravity Teamwork 是 Google 為 Antigravity 設計的多代理協作流程，專門處理規模大、需要嚴格驗證的工作。輸入 /teamwork 後，系統會啟動一支由 Sentinel、Project Orchestrator、Explorers、Workers、Critic、Challenger、Auditor 和 Success Auditor 組成的團隊，在專用專案目錄中按里程碑推進，並在每個里程碑交接前進行獨立驗證。
Teamwork 分成兩個階段。第一階段是範疇訪談，由主代理記錄目標、需求、驗證方式、驗收標準和專案目錄，預設位置為 ~/teamwork_projects/{PROJECT_NAME}。第二階段則依靠結構化產物——需求、專案計畫和進度紀錄——自主執行；每個 Worker 和 Critic 擁有專屬檔案範圍，交接前還要通過 Challenger、Auditor 和 Success Auditor 的關卡（Teamwork 文件）。
訪談期間選擇的完整性模式，會決定驗證嚴格程度：
development（預設）：快速迭代，可重用程式碼與框架，但會拒絕捏造輸出和只有表面功能的實作。demo：以可重現的展示為目標；禁止直接複製開源專案的核心邏輯、把核心工作交給外部服務，或透過閱讀測試原始碼來找答案。benchmark：最嚴格的模式，要求使用該語言標準函式庫從零實作，並透過獨立的基準真值進行評估。
系統也會根據工作類型自動調整團隊組成：
- 一般分散式程式設計（預設）：適合多檔案工程與重構。
- 迭代式程式設計：適合提示中明確要求「保持小範圍」的單一、封閉修正。
- 文件審查：從多個角度批判論文和設計文件。
- 數學／證明與數學／大型證明團隊：處理形式化推理和大型猜想研究。
在 Antigravity App 和 CLI 的付費方案中，Teamwork 通常是以數小時到數天為執行週期（Teamwork 文件）。
Teamwork、Swarm、Boost 和 subagents 怎麼選？
只有當工作需要里程碑、稽核關卡和專用目錄時，才值得使用 Antigravity Teamwork。大多數日常任務其實更適合輕量工具；選錯模式，最直接的結果就是白白消耗配額。
| 工具 | 適合用途 | 啟動方式 | 工作空間 | 驗證方式 | 典型執行時間 | 方案 |
|---|---|---|---|---|---|---|
| Subagents | 明確的側邊任務：研究儲存庫、檢查瀏覽器、執行測試 | 自動啟動或使用 @subagent | 目前工作空間 | 由主代理檢查回覆 | 數秒到數分鐘 | 所有方案 |
Boost（/boost） | 困難但範圍狹窄的問題：競態條件、棘手錯誤、演算法 | /boost <task>，立即啟動 | 目前工作空間，使用隔離的上下文 | Worker 互相挑戰並重新驗證，由協調器抽查 | 數秒到數小時 | 付費方案 |
Swarm（/swarm） | 可清楚拆分的廣泛工作：檔案、套件、測試套件 | /swarm <task>，立即啟動 | 目前工作空間或每個 Worker 的副本 | 專屬的 @verifier 審查差異並執行測試 | 數分鐘到數小時 | Google AI Pro 和 Ultra |
Teamwork（/teamwork） | 多里程碑專案：遷移、模擬、形式化證明 | /teamwork <goal>，再進行範疇訪談 | 專用的 ~/teamwork_projects/{PROJECT_NAME} | 由 Critic、Challenger、Auditor、Success Auditor 設置關卡 | 數小時到數天 | 付費方案 |
例如，跨數十個檔案、要求完整測試覆蓋率的 REST-to-Fastify 遷移，或需要 Lean 4 檢查的形式化證明，都適合交給 Teamwork。若只是替三個互不相依的 API handler 加上驗證，可以用 Swarm，讓每個檔案分配一名 Worker，再由 verifier 執行 npm test。單一競態條件，或一個依賴前後順序、由「挑戰—修正—驗證」處理效果更好的重構，則適合 Boost。至於背景研究，就交給 subagents，主對話可以繼續進行。
大家會搞混並不奇怪。正如一名 Antigravity 使用者所說：
「agy 現在的模式實在太多了，老實說越來越讓人困惑。目前有……/teamwork（長時間、帶稽核關卡的里程碑專案）……現在又有動態工作流程……公平地說，我們真的不需要全部。模式越少，就越不容易搞混……」
— @Heamanth_alturi（X）
簡單判斷：如果任務只有一個完成標準，而且一次工作階段就能收尾，Teamwork 就是大材小用。若任務需要計畫產物、進度產物，並且每個里程碑都要由作者以外的人簽核，那就適合 Teamwork。
11 月研究更新真正證明了什麼？
11 月 13 日發布的 Google Research 更新 是成果報告，不是產品上市公告。Teamwork 早已以付費方案的 /teamwork-preview 形式存在；這次更新記錄的是使用 Gemini 4 Argon、Carbon 和 Hydrogen 的里程碑團隊完成了哪些工作。人類仍然負責定義問題、限制條件和評估設定，再由從乾淨上下文重新開始的 Critic 進行審查。
| 領域 | 專案範例 | 代理規模 | 公布成果 |
|---|---|---|---|
| 數學 | Courtade–Kumar 猜想證明（Google、CUHK、USC、CMU） | 長篇證明模式、Lean 4 形式化 | 完整證明約使用 5,000 萬行 Lean 程式碼 |
| 化學 | 從 NMR 資料推導分子結構 | 30 個專用代理 + 物理模擬器 | top-1 精確比對率 95%，top-3 精確比對率 100% |
| 系統 | Zircon 從 C++ 重寫為 Rust | Argon 執行兩週的專案 | 約 80 萬行安全 Rust，並在 arm64 上成功啟動 |
| ML 硬體 | TPU 核心最佳化（DuoDiscover） | 代理評估器（23 秒，相較於 7–32 分鐘） | 在 17 個 JAXBench 核心上平均加速 4.09 倍 |
Google 也開放申請，讓 10,000 名學術研究人員取得頂級方案六個月的使用權。不過，文章中部分流程仍在陸續向外部使用者推出，因此這張表應該視為能力證據，而不是每個專案都能重現相同成果的保證。
官方頁面沒告訴你的配額代價
Antigravity 的定價頁面列出 Individual 方案為每月 $0，提供不限量 Tab completions 和基本每週限制；Pro 與 Ultra 則提供更高限制和彈性的 AI credit pool，但官方沒有公布確切請求數。Pro 和 Ultra 的配額每五小時刷新一次，直到碰到每週上限；超出部分可以使用購買的 credits，並可設定 Never 或 Always（方案文件）。Teamwork 和 Boost 需要付費方案；Swarm 則需要 Pro 或 Ultra（Swarm 文件）。Google 自己的 OS 文章也警告，幾個複雜的預覽任務就可能吃掉整週配額（Antigravity OS 文章）。
以下是使用者的個案回報，不具代表性，但也足以看出消耗量可能差異很大：
「天啊，這在大約 5 分鐘內就把我的全部配額吸光了（3.5 Flash（high））」
— u/Several_Bag_3665（Reddit）
「其實在 Ultra 訂閱上非常好用。我讓一個使用 gemini flash medium 的 teamwork preview 連續跑了 50 分鐘左右，只用了五小時配額的約 20%，而且確實完成了大規模重構」
— u/ningkaiyang（Reddit）
兩項機制可以解釋這種落差。Antigravity 在 /swarm 文件中說明，每個 Worker 都是獨立代理；等待中的 Worker 不會消耗 token，而配額用盡的 Worker 會暫停，不會自動重試，除非出現新的 board post、切換模型或收到直接訊息（Swarm 文件）。Teamwork 文件沒有發布同樣的恢復說明，因此只能先把它視為多代理共通行為，並在自己的方案上確認。Teamwork 還會產生大量中間產物——需求、計畫和進度紀錄，以及各代理的暫存筆記和驗證日誌（Teamwork 文件）——這些是預期的狀態紀錄，不代表每一份都是實際進度。
第一次跑 Teamwork，先別把一週配額燒光
啟動 Teamwork 只需要一個指令，但真正決定成本的是範疇訪談。在 App 中開啟專案對話，輸入 /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation。在 CLI 中，從專案目錄執行 /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests。你可以透過 subagent 面板或 CLI 狀態列監看進度，按下 Alt+J 前往核准項目，並即時檢視計畫與進度產物（Teamwork 文件）。
把第一階段當成成本控制點。描述「要做什麼」，而不是「要怎麼做」：說明目標、使用情境（demo、production 還是 benchmark）、硬性限制，以及每項需求的一個客觀檢查方式，例如測試套件或指標腳本。需要迭代時選 development；只有在成果必須適合展示，或必須證明是從零完成時，才使用 demo 或 benchmark，因為更嚴格的驗證代表更多代理工作。按下核准前，也要確認專用專案目錄的位置。
執行期間，範圍控制仍應集中處理。所有需求變更都交給協調器，移除 Worker 前先合併它的修改，並以里程碑關卡和測試證據，而不是檔案數量，來判斷進度。第一次執行時，建議在設定中把 AI-credit 超額使用設為 Never，讓基礎配額用完後直接停止，而不是默默消耗 credits（方案文件）。在方案文件允許的情況下，也可以用較強的模型負責規劃、較便宜的模型負責實作——Ultra 支援 Orchestrator (Carbon) 和 Orchestrator (Argon)，分別使用 Gemini 4 Carbon 或 Argon 規劃，再由 Gemini 4 Hydrogen 實作（定價頁面）；這種取捨也能在 Carbon 與 Argon 比較中看到。
常見問題
/teamwork 和 /teamwork-preview 有什麼差別？
/teamwork-preview 是早期研究預覽版的名稱。目前的 Teamwork 文件在付費方案中使用 /teamwork；Google 尚未發布獨立的一般可用性公告。
配額用完後，Teamwork 可以暫停或恢復嗎？
有文件記載的 /swarm 行為是：配額用盡的 Worker 會暫停，直到出現新的 board post、切換模型或收到直接訊息（Swarm 文件）；Teamwork 文件沒有確認相同的恢復路徑。重新啟動前，先檢查 ~/teamwork_projects/{PROJECT_NAME} 中的方案和進度產物，因為已完成的部分里程碑會以檔案形式保留。
Teamwork 會產生哪些產物？
包括需求、專案計畫和進度產物，以及每個代理的暫存筆記、輔助腳本和驗證日誌（Teamwork 文件）。大量 Markdown 輸出是正常現象；請用里程碑關卡和測試證據判斷進度，不要只數檔案。
Teamwork 適合用在 production 儲存庫嗎？
Teamwork 會在專用目錄中隔離工作，搭配檔案專屬權限和稽核關卡，有助降低衝突風險（Teamwork 文件）。但即使要用於 production，合併前仍需要人工審查驗收標準、測試證據，以及最後的 Success Auditor 結果。
輸入 /teamwork 前的 30 秒檢查表
只有在以下五點全部成立時，才輸入 /teamwork：工作橫跨多個里程碑、每個里程碑都有客觀檢查方式、專用目錄能帶來幫助、獨立稽核關卡確實重要，而且一次高配額消耗的執行成本低於數週人工工作。否則，平行化的廣泛工作用 Swarm，困難但狹窄的錯誤用 Boost，背景側邊任務用 subagents——把 Teamwork 留給真正需要一支團隊的專案。