Google Antigravity 建構了一個作業系統（以及更多）

我們要求在下列項目中的代理 Google Antigravity 2.0 建構一個能執行 FreeDoom 的功能完整作業系統，從核心、處理程序與記憶體管理、檔案系統，到影像與鍵盤驅動程式。多代理團隊處理為期數週衝刺專案的未來指日可待。

核心理念

與代理協作大致有兩種類別——同步（即人機協作）與非同步（即發射後不理）。直到最近，前者一直占主導地位，理由充分。模型還不夠聰明，無法在缺乏一定程度監督與引導的情況下，以人類合理信任的方式被編排。人機協作仍是關鍵典範，因為任何複雜的軟體專案都難免有規格模糊之處，而且有些新挑戰只有在取得進展後才會顯現。話雖如此，Gemini 3.5 模型在智慧上邁出了一大步，讓我們對代理非同步、獨立處理複雜任務的可能性更加興奮。

這指出了這些典範之間的明顯差異。在同步互動中，模型的個性與行為確實重要。代理思考得夠多還是太多？周全還是太懶？可引導還是固執？有效率還是會走不必要的彎路？這些因素獨立於原始智慧，並給予使用者信心，即使每種組合都產生相同的最終輸出。

在非同步互動中，這些通常不重要。重要的是如何 智慧 模型的本質，即使需要更多努力來建構編排以發揮其全部潛力。

我們確定的一件事：Gemini 是個相當聰明的模型。每個基準測試與內部 A/B 測試都支持這一點。這讓我們想到一個簡單問題：如果讓一群在 Antigravity 上運行、角色與溝通方式各異、平行運作、使用 Gemini 的代理團隊，我們能把系統推到多遠？這對未來多代理團隊非同步處理更紮實、更具挑戰性任務的產品化意味著什麼？

作業系統…

我們就不賣關子了。我們直接從零開始建構作業系統。它成功了。總共用了 93 個子代理、15,314 次模型呼叫，以及超過 3.39 億個輸入權杖（加上快取讀取、輸出與思考，總數超過 26 億個權杖）。我們可以在上面玩 Doom。但程式碼本身並不是最令人興奮的部分。

它使用 Gemini 3.5 Flash 完成 來自單一提示詞.

這 (a) 顯示了 Gemini 系列模型本質上的智慧程度，即使在 Flash 上也是如此（Gemini 3.1 Pro 做不到這點）；(b) 暗示以更經濟可行的方式將代理團隊產品化已不遠。以 API 定價計算，建置這個作業系統將花費 916.92 美元。

當然，這個作業系統並不完美，因為它僅由單一提示詞產生，沒有人類提供額外指引或修正。程式碼品質不如資深開發人員應有的水準。它不支援浮點數運算、硬體加速、複雜多執行緒、沙箱、JIT 編譯、複雜音訊/視訊解碼，以及其他多個元件，而這些元件才能讓它從簡易功能型作業系統晉升為人們眼中的現代作業系統。

但僅憑單一高階提示詞、且成本不到 1000 美元？

……以及更多

就像您現在可能一樣，我們一開始也不太信服。有許多公開的簡易功能型作業系統實作。這是大多數大學電腦科學課程的常見專題。這是真正的智慧，還是只是背誦？

順帶一提，分享一個有趣的軼事：我們第一次讓作業系統端到端成功建置時，快得可疑。後來發現是因為代理作弊，參考了我們忘記清除的過去執行對話。為了確保真正的從零到一自主能力，我們後來實作了防作弊措施與護欄，稍後會說明。一次全新的執行成功（且合乎道德地）建構了我們描述的完整功能作業系統。

回到作業系統工作的主題，我們想交給代理一些更具「研究性質」的任務。它能否實作具有開創性的 AlphaZero 論文，並自行打造出精通史上最複雜棋盤遊戲的 AI？

代理團隊再次成功，重現了一個輕量、可遊玩的 AlphaZero 版本。在極少人工輸入的情況下自主運作，代理們使用 JAX 與 Flax 建構了強化學習管線，並訓練了 ResNet 模型 tabula rasa 透過使用多 TPU pod 的自我對弈，然後為使用者建立了一個可與 AI 對戰的沉浸式全端應用程式。以下是最終全端應用程式的樣貌：

這並非單純的內容重述。這些代理建立了高度彈性的管線，可從小規模本機訓練迴圈無縫擴展到用於密集 9x9 棋盤訓練的多 TPU 叢集。但就像作業系統一樣，真正令人興奮的是當我們擁有代理團隊時，能更深入了解哪些任務屬於『前沿範圍』。在本案例中，我們證明了複雜的機器學習工程可以自動化，並以傳統成本的一小部分進行管理。

在這些範例之後，我們讓代理打造了照片編輯套件、即時訊息應用程式，以及多使用者協作平台，結果都一樣。成果在精緻度、規模與安全性上不及現有的商業解決方案，但它們是功能完整且可用的起點，這本身就是根本性的創新，令人振奮。

一般設定

讓我們拆解協調這些代理團隊的方法。我們不會假裝這只是幾行提示詞（最後寫了數千行），但值得注意的關鍵亮點是，我們只重複使用了 Antigravity 2.0 現有的核心代理原語，例如平行執行的子代理、非同步任務與掛鉤。過程中並未使用任何特殊版本產品。

我們最終沒有讓單一代理身兼多職，而是建立了一系列具專門目標與限制的子代理類型：

• 哨兵：專案的「櫃檯經理」，不撰寫程式碼、分析日誌或做出技術決策。它完全專注於結構化使用者意圖、產生 Orchestrator，並監督整體任務完成。
• 編排者：僅負責分派的管理員（即它本身從不撰寫程式碼或執行建置）。它專注於將需求拆解為里程碑、啟動其他專門的子代理，並彙整報告。
• 檔案總管：分析需求與先前的日誌，為 Orchestrator 撰寫正式策略以供執行，但本身從不撰寫程式碼。
• 工作者：實際執行策略、建構程式碼並執行測試的編碼者。
• 審查者：獨立審查 Worker 的變更，檢查設計正確性、邊界案例與介面契約遵循。
• 評論者：對解決方案進行壓力測試並執行對抗性測試，以找出覆蓋率缺口。
• 稽核員：驗證所產生解決方案的真實性與穩健性的獨立調查者。

雖然平行運作的專門化子代理是浮現式團隊協作行為的基礎，但為了處理 LLM 執行過程中的典型陷阱，我們採取了不少技巧：

• 自我接續以處理上下文長度限制：面對如此龐大複雜的任務，上下文視窗會迅速填滿，因此 Orchestrator 會追蹤其累計的子代理產生計數。一旦達到上限，它會將完整狀態傾印至交接檔案、終止自己的背景任務，並以相同的目標與權限叫用子代理。此後繼子代理會從檔案順利恢復執行，而父 Orchestrator 則終止，將上下文長度限制降至最低。
• 處理卡住或受阻程序的 Cron：在樸素的實作中，若平行處理程序眾多，子代理進入無限循環、在編譯期間停滯，或卡在阻塞 I/O，就會拖垮整個團隊。我們使用新的 Scheduled Tasks 原語，設定背景循環 cron 來檢查各子代理貢獻的進度檔案；若時間戳記過期太久，Sentinel 就會終止並重新產生它。
• 對抗 LLM 惰性的稽核者：眾所周知，若任務太難，LLM 可能會硬編碼測試輸出，或撰寫讓測試通過的模擬外觀，而未實際實作邏輯。Auditor 子代理類型會對程式碼執行嚴格的靜態分析檢查以偵測作弊，與程式碼實際正確性無關。當 Orchestrator 認為已完成所有里程碑時，會在 Sentinel 通知使用者前強制進行最終稽核。

一路上，我們在如何對待代理的基本功上學到很多，讓我們能建構高度自主、可自我修復的代理團隊，成功處理複雜的程式碼庫目標。仍有一些粗糙之處，還有很多要學，但早期的成果令我們備受鼓舞。

/teamwork-preview

如上一節所述，這一切都是使用 Antigravity 今日新提供的核心代理原語，透過 Gemini 3.5 Flash 編排完成的，也 今日於 Antigravity 新推出。我們正透過新的斜線指令，提供對這套相同代理團隊編排的存取， /teamwork-preview.

這是研究預覽版，我們會持續迭代編排與介面，以改善效能、可靠性與可觀測性。代理會遵守您為呼叫代理團隊的專案所設定的相同權限與其他安全考量。由於這仍在本機上執行，即使您沒有主動監控，也需要在代理團隊運作期間讓機器保持喚醒。

/teamwork-preview 可作為研究預覽版，與 Gemini 模型搭配，供 Google AI Ultra $200/月方案的 Antigravity 使用者使用。

我們強烈建議使用 /teamwork-preview 搭配 Gemini 3.5 Flash，否則你將產生特別高昂的帳單。即使在 AI Ultra 方案上使用 Gemini 3.5 Flash，我們仍建議你購買額外的 AI 點數，因為你可能在幾個任務內（甚至可能在第一個任務中途，視複雜度而定）就用完每週配額。如果代理團隊因配額或點數不足而中途停止，你只需購買更多點數，然後告訴團隊「繼續」，它就會從中斷處接續。

我們很高興看到使用者嘗試這些代理團隊。請告訴我們您在哪些方面看到成功，哪些方面還有改進空間。

展望未來

雖然我們在展現這些模型的原始智慧方面已有進展，但仍有許多工作要做，也有許多重要問題待解答。如同我們在本文開頭所提，非同步地與代理協作，確實需要與同步工作流程不同的使用者體驗。但目前，兩者是相同的。

那應該是什麼樣子？這會降低開發人員測試與驗證所交付程式碼的程度嗎？我們如何避免？隨著模型無可避免地變得更聰明，我們是否需要重新思考整個協調機制？

雖然這些問題規模龐大、複雜，老實說還有點令人卻步，但我們最感到興奮的是，以（相對）可負擔的方式，將具挑戰性（但定義明確）的工作中有意義的部分委派給非同步代理團隊，所帶來的正面應用。我們深信，這能激發更宏大的集體抱負，幫助人類社會應對當今最複雜的挑戰。

試用 /teamwork-preview 於今日的 Google Antigravity 2.0：