Teamwork：當 AI 成為研究夥伴
Antigravity 的 Teamwork 多代理框架正在推動數學、硬體模擬、開源最佳化等領域的突破。了解 Teamwork 如何應對具挑戰性的開放式問題。
今天，我們宣布對下列項目進行多項更新 Teamwork，Antigravity 中的多代理編排框架，我們 首度於 Google I/O 發表。在 Teamwork 中，代理會在數小時或數天內自主提議、批判並精進彼此的工作。這些功能建立在…的推出之上 Gemini 3.7 Flash，我們迄今最聰明的模型。
Gemini 3.7 Flash 為日常開發人員任務提供所需的速度與成本效益，但搭配 Teamwork 的前沿協調，可在研究與軟體工程的複雜長時程問題上釋放強勁效能。
在本文中，我們分享 Antigravity 團隊協作功能的最新更新，以及在各領域使用 Gemini 模型搭配團隊協作、以最大化智慧為目標所取得的顯著成果：
- 研究數學與理論電腦科學: 解決了七個開放問題 — 包括稀疏凸最佳化（JMLR）、子空間逼近（FOCS）、可證明的 LLM 量化、向量嵌入、前綴矩陣分解，以及 Knuth 循環猜想（已在 Lean 中驗證）— 並在 TCSBench 上達到 71%（我們內部測試中的最高分）。
- 系統工程：A 週期精確的 RISC-V CPU 模擬器 從零啟動作業系統的…
- 開放原始碼軟體：直接貢獻並合併至上游程式庫的效能最佳化，包括 Eigen 與 ParlayHash.
什麼是 Teamwork？
乍看之下，多代理設定似乎可以互換。對於例行任務，基本的多代理方法通常足夠——但在艱難的研究與工程問題上，多代理系統經常遇到編排問題。組織鬆散的代理很快就會偏離軌道，認同其他代理早期的錯誤，並在錯誤的想法上自信地建構。
許多研究與工程問題有著共同結構：產生候選方案、壓力測試，再將最佳想法組合成更強的候選方案。Teamwork 讓這個循環具體且可設定，自動化迭代過程，同時讓人類掌控目標與最終驗收。這項功能是為太大、太不確定或太開放、單一代理循環無法處理的問題而設計。今日已推出 /teamwork-preview 於 Antigravity，在所有付費方案中，Teamwork 將代理組成團隊，主動挑戰彼此的工作、在進一步建構前尋找缺陷，並將最強的部分組合成可行的解決方案——自主執行，歷時數小時或數天。
一個框架，多種模式
Teamwork 不是單一的代理團隊。不同的挑戰需要不同的團隊結構，我們將每種不同的組態稱為 模式— 藍圖，定義哪些代理參與、它們擔任什麼角色，以及工作推進所需的條件。
當您呼叫 /teamwork-preview，Gemini 會分析您的提示詞並自動選擇適當的模式。以下範例展示其中數個模式的結果，並深入介紹 Long Proof 模式。
Teamwork 模式的適應性仰賴根本的區隔： 協調邏輯與代理描述解耦。模式是規格而非可執行程式。它不包含自身的編排程式碼；相反地，框架會讀取模式並根據任務自動啟動合適的代理。因此，專門的機制——例如對抗式批判迴圈——可不經修改移植到完全不同的領域。
關鍵的是，模式是 在執行階段自適應。框架會根據任務需求動態決定產生多少代理，而非預設數量。隨著問題逐漸明朗，代理數量與團隊結構可在執行中途調整——使每次行動都成為有機的流程，而非固定的管線。
今天，Teamwork 推出專門化模式，會根據您的任務自動選取，每種模式針對不同類別的問題進行調校：
- 迭代式程式開發：適用於不可分解的問題，透過緊密的代理–測試–精煉循環解決。
- 分散式程式設計：適用於可分解的工程任務，透過平行工作者展開並接受評論者審查。
- 長證明：適用於開放式數學與理論電腦科學，每個候選方案在晉級前都須經過壓力測試。
- 自我驗證：適用於深度優先數學推理，在每個步驟進行嚴格的自我檢查。
- 文件審查：適用於論文與技術文件的結構化分析與評論。
例如，以下是分散式程式撰寫模式的運作方式：
雖然圖表呈現了涉及的核心角色，但實際執行是動態的——協調器會根據手邊的問題，決定要部署多少代理、執行多少輪次。
數學與電腦科學
解決數學與電腦科學中的開放問題
除了程式設計與機器學習任務，我們還針對長期博士級數學與電腦科學研究建立了兩種模式： 長證明 適用於透過競爭策略搜尋進行開放式問題解決，以及 自我驗證 適用於深度優先推理，每一步都嚴格自我檢查。延伸自我們的 先前的工作，Long Proof 模式最初是作為獨立研究框架開發，隨後移植到 Teamwork 框架。
長證明模式的運作方式
長證明將大量心力投入策略選擇，而不只是證明撰寫。對於開放問題，許多看似有希望的方法最終都會失敗，而缺陷要到嘗試深入後才會現形。該模式依賴以下核心設計原則：
- 競爭策略搜尋：許多候選策略會平行產生，每個都配對一個專門破壞它的反駁者。合成樹隨後結合候選方案與其報告。被反駁的路線仍保留在流程中並附上其異議 — 被破壞的路線可能仍包含有用的想法。
- 分解讓冗長的證明變得易於處理：選定的策略會展開為證明計畫，其子問題具有明確目標與顯式相依性。產生的相依圖讓獨立子問題可平行執行，相依者則依拓撲順序執行。
- 每個子問題都有自己的錦標賽網路：在合成樹中，每個節點會讀取候選方案樣本及其評論，並產生改善的解決方案。若合成的解決方案失敗，網路會帶著累積的異議重新執行。
- 它會跨回合學習：失敗的草稿會保留給下一次嘗試使用，驗證者的發現則會萃取為與答案無關的陷阱登錄檔。共用知識目錄會記錄已證明的結果、有用的觀察、失敗的方法與相關參考，供日後使用。
來自 Teamwork 長證明模式的結果
使用 長證明 模式——大幅強化並泛化我們的 推理工作流程 早期工作 — 我們已解決理論計算機科學中的數個開放問題，包括來自頂級會議的問題，例如 FOCS 和 JMLR，以及量化與向量嵌入等實務問題。以下我們呈現七個重要成果，已由人類專家審查並確認正確，Knuth’s Cycles 成果除外——其 40 頁證明已在 Lean 中正式驗證。五篇成果論文可在 arXiv 上取得。這些成果是使用…獲得的 Gemini 3.1 Pro，其中三個（問題 1、3、4）以…重現 Gemini 3.7 Flash — Flash 等級模型首次在合適的編排框架下產出如此博士級的數學研究。其中一些結果使用了高於預設的平行度。Antigravity 上提供的版本在成本與能力之間取得平衡，同時仍支援相同的工作流程。
| 問題 | 結果 | 問題與解決方案連結 |
|---|---|---|
| 1. Coresets for Lp Subspace Approximation | 改善 p>2 時 ℓp 子空間近似的 coreset 建構界 | 開放問題： FOCS 2025 解決方案： arXiv:2608.26047 |
| 2. Sparse Convex Optimization | 為稀疏最小平方法目標的條件數建立了條件下界 | 開放問題： JMLR 2021 解決方案： arXiv:2608.02588 |
| 3. Maximal Inner Product Embeddings | 幾乎彌合了單向量與多向量嵌入 Chamfer 相似度的複雜度差距 | 開放問題： Jayaram 2026 解決方案： arXiv:2607.20393 |
| 4. Provable Hadamard Quantization | 移除了第二階段量化，將前置常數降低了約 5.93 倍 | 開放問題： Feng et al. 2026 解決方案： arXiv:2608.02564 |
| 5. Erdős Unit Distance Problem | 獨立重現了單位距離指數的初始突破 | 解決方案： GitHub 在沒有網路連線的情況下重新發現了解決方案 |
| 6. Prefix-Matrix Factorizations | 前綴矩陣分解的近最佳下界 | 開放問題： Bulanek 等人 2026 解決方案： arXiv:2608.08238 |
| 7. Knuth’s Cycles Conjecture | 首次證明偶數整數情形的兩種較簡潔構造（超過 40 頁與超過 70 頁的證明）。 | 解決方案： GitHub |
使用 3.7 Flash 與 Teamwork 的理論電腦科學基準測試
Teamwork Long Proof 旨在透過協調眾多代理（而非仰賴單一更大的模型）來發揮 Flash 模型的極致效能。我們已在下列項目上進行測試 TCSBench，Google 內部獨立開發的理論電腦科學開放性挑戰問題評估套件。使用 Gemini 3.7 Flash 連同 3.1 Pro，Long Proof 模式達成 TCSBench 71% — 高於 TCSBench 論文中使用 Gemini 3.6 Flash 與 3.1 Pro 所回報的 67.7%，也是我們內部測試中的最高分。在 Long Proof 模式中結合 Flash 與 Pro 模型的能力將在即將推出的更新中登場。
使用 Aletheia 的自我驗證
Teamwork 還引入了 自我驗證 模式，迭代生成、驗證並修訂數學論證。此模式受 啟發 Aletheia 代理 今年稍早宣布，適用於 自主數學研究。Aletheia 在…中展現了研究級的數學能力 FirstProof 挑戰賽，我們現在正透過…將受此框架啟發的模式分享給數學家與科學家 /teamwork-preview 於 Antigravity。
系統
CPU 模擬範例
可開機啟動作業系統的 RISC-V 模擬器
使用 Gemini 3.7 Flash，Teamwork 從零打造了高精確度的週期級亂序執行（OoO）RISC-V CPU 模擬器，能成功將作業系統開機至 Shell（xv6），並成功模擬 100 多個 RISC-V 標準基準測試。團隊合作透過兩個獨立階段達成此目標：(1) 微架構功能正確性與 (2) 週期級時序驗證。在第一階段，代理開發核心執行邏輯，包括 亂序（OoO）管線 和 重新排序緩衝區 (ROB)。此階段著重確保模擬器能開機 OS，並在以功能 oracle 驗證時維持正確的架構狀態。在第二階段，Teamwork 會將效能特性與嚴格的時序 oracle 對齊。
Teamwork 會自主建置並驗證不同的微架構單元（例如 MSHR、 ROB，與 快取）透過執行架構微基準測試、推理自身產生的架構追蹤，並比較氣隙隔離…最終週期計數之間的差距 Boom 模擬器與 Teamwork 產生的解決方案。以 BOOM 硬體執行真值驗證，Teamwork 模擬器在未見過的測試工作負載上達到了平均 0.71% 的週期對齊誤差。
這項工作的範圍超越靜態軟體轉譯，深入到複雜、非確定性的時序硬體模擬。核心挑戰在於我們所謂的『靜默執行缺口」：一個長達數百個週期的視窗，微架構狀態可能在此期間靜默分歧，直到架構層級失敗變得可見。為防止作弊，我們將…沙箱化 尖峰 模擬器原始碼。Teamwork 的解決方案透過與氣隙隔離的 Spike 參考模擬器維持連續鎖步協同模擬，來解決執行缺口。
工程與程式設計
開放原始碼工程貢獻
效能最佳化：Eigen 與 ParlayHash
Eigen 是高度最佳化的 C++ 線性代數樣板函式庫，廣泛用於 Google 內部與更廣泛的社群。我們指示 Teamwork 不限制實作方式執行 Eigen 微基準測試套件——唯一要求是基準本身保持完整。
Teamwork 發現了 Eigen 中 GeMV 運算（矩陣只有單一列或單一欄時）的次優實作。它建立了專屬的快速執行路徑，實作直接資料存取與具備 4 向累加器展開的 SIMD 運算。我們在 Gemini 3.6 Flash 的協助下走完開源程式碼審查流程，並成功將該變更貢獻給上游 Eigen 函式庫。
此外，Teamwork 也參與了 Swiss Parlay 的構想發想，並納入了來自 Swiss Table 的最佳化， ParlayHash — 高效能開源並行雜湊表。與 ParlayHash 相比，Swiss Parlay 取得了以下成果：
- 2 倍吞吐量 於初始插入，64 個執行緒
- 1.5 倍吞吐量 整體使用單一執行緒
- 使用以下項目接近最佳循序表格效能（FlatHashMap） 記憶體用量減少 25% 每個元素
- 改善 已進入上游 ParlayHash 函式庫
這兩項變更已簽入以下開放原始碼程式庫（Eigen 提交, ParlayHash 分支）。這些並非僅限基準測試的結果——它們是透過標準開源程式碼審查、被外部維護者接受的真實貢獻。
後續規劃
我們在這裡展示的問題——開放的數學猜想、效能關鍵的函式庫程式碼，以及硬體模擬——傳統上都是深耕數月的專家領域。Teamwork 在讓專家主導方向與驗收的同時，壓縮了迭代週期。
Teamwork 由公開提供的 Gemini 模型驅動，我們正在將這些改進推廣至 /teamwork-preview 於 Antigravity，未來幾週。若您從事前沿創新任務，任何智慧增量都可能帶來差異，請試用 /teamwork-preview 於 Google Antigravity 探索多代理協作能為你自己的研究與工程挑戰帶來什麼。