隨著 AI 編碼代理（coding agent）逐步進入企業開發流程，一個結構性矛盾也跟著浮現：代理的能力越強，往往越依賴雲端大型語言模型，這意味著越多原始碼與內部邏輯必須離開開發者的機器、送往外部服務。對金融、醫療、國防等受監管產業，或單純對智慧財產高度敏感的團隊來說，這道門檻足以讓導入計畫停擺。Google 近期在 Antigravity SDK 中加入本地模型支援，正是針對這個痛點提出的解法：讓開發者能在自己的機器中建立並執行代理式工作流（agentic workflow），同時保留彈性，把較高層次、需要大量上下文推理的任務交給雲端模型處理。換句話說，這不是全雲端或全本地的二選一，而是依任務性質把兩者分工。這項消息由 InfoQ 報導，作者為 Sergio De Simone。
為什麼要把模型搬到本機
要理解這項更新的意義，得先回到代理式工作流的成本結構。這類系統之所以強大，是因為模型能在單一上下文裡掌握大量檔案、相依關係與測試結果，但這個能力同時也是開銷來源：上下文越長，消耗的 Token 越多，費用與延遲越高，資料外送的範圍也越廣。當代理被用來審查程式碼、修補漏洞或跑回歸測試時，它必須頻繁讀寫原始碼，而這段過程往往占了整體運算量的大宗。若全部送到雲端，除了成本難以預測，網路依賴與合規風險也隨之上升。把這些程式碼密集的環節留在本機，雲端只負責高階規劃，正是 Antigravity SDK 這次設計的核心思路。
架構師在雲端、構建者在本地
這套機制的關鍵在於混合代理編排（hybrid agent orchestration），它把 Google 提出的 Architect-Builder 模式搬到雲地混合的運算環境。所謂架構師（architect），是一個具備高上下文能力的主代理，負責掌握宏觀的系統視野，包括相依關係、架構護欄（architectural guardrails），以及具體的規格與實作計畫。當架構師擬定策略後，它並不需要碰觸原始碼本身，而是用檔名與任務描述把工作拆解成較小的單位，交由下游執行。
真正動手的是一群可平行運作的專門代理，也就是構建者（builders）。這些構建者在彼此隔離的環境中獨立執行離散、範圍狹窄的任務，例如重現安全漏洞、提出程式修補、審查候選補丁、執行回歸測試。工作流中還能加入額外的專門本地代理，對照測試套件驗證變更是否成立。由於構建者在本機執行，整個流程裡程式碼密集的階段都留在裝置端，只有規劃所需的少量資訊會上雲。這種分層讓「需要廣度」與「需要深入程式碼」兩件事各由適合的模型承擔。
技術實作與模型選擇
Google 用一個稽核並修補三個含漏洞 Python 模組的示範來說明成效：整體約 3400 個 Token 中，只有 95 個用於雲端規劃，其餘 97.2% 都在本地消耗，而且沒有任何原始碼被上傳到雲端。這個數字的價值在於它拆解了「代理一定得靠雲端」的預設，顯示本地模型足以勝任重複性高、需要讀寫程式碼的勞動。
在技術層面，Antigravity SDK 的初始版本聚焦於透過 Google 自家的 LiteRT 執行 Gemma 4 26B A4B 模型。LiteRT 是一套針對裝置端推論最佳化的執行環境，目的在讓模型直接在本地硬體上跑得動、跑得有效率。不過開發者並非只能綁定 LiteRT，SDK 也透過 LocalOpenAIAgentConfig 支援與 OpenAI 相容的本地推論伺服器，包括 Ollama、LM Studio 與 vLLM，這讓既有的本地模型基礎設施可以直接接上，不必砍掉重練。
社群觀點與實務限制
社群對這項宣布的反應正面，但並不盲目。Reddit 使用者 ambassadortim 指出，這讓企業對自家 AI 模型握有更多控制權，包括何時更換模型；使用者 Latter_Crazy 則表示，這讓他做到以前在雲端規則下做不到的事，並認為成本、速度與品質都還會持續改善。
不過也有務實的提醒。使用者 FollowingTop3534 認為，雲端 Token 佔比並不是全貌，應該同時衡量補丁接受率（patch acceptance）、實際耗時（wall time）與能耗，因為「97.2% 的 Token 在本地執行」雖然吸睛，卻無法說明在你的硬體上這次執行是否更快或更便宜。他也點出官方建議的 24GB 以上 VRAM 或統一記憶體是一道真實門檻，並非所有開發機都能跨過。這提醒了本地推論的隱性成本：硬體投資、維運與模型更新，都會以另一種形式回到團隊身上。
SDK 與 IDE 的區別
另一件容易混淆的事，是 Antigravity SDK 與 Antigravity IDE 的分別。後者是一套由 Antigravity SDK 驅動的整合開發環境；兩者共用底層的代理基礎設施，但定位不同。SDK 的目的是讓開發者以程式化方式打造自己的 AI 代理，而不只是拿現成工具來寫程式。對於想在受控環境中建立客製化審查、修補或測試流程的團隊而言，這個區別決定了他們是把 Antigravity 當成產品使用，還是當成可組裝的基礎元件。
整體來看，Antigravity SDK 的本地模型支援，把資料隱私、推論成本、網路依賴與算力分配這四個長期糾纏的問題，放進同一個架構裡權衡。它的價值不在於宣稱本地一定優於雲端，而在於提供了可按任務切割的混合選項，讓開發者自行決定哪些環節必須留在機器裡、哪些可以交給雲端。實際效益終究取決於硬體條件與工作負載型態，這也正是社群呼籲以更完整指標評估的原因。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。