一、I/O 2026 之後：Antigravity 2.0 實際會打出哪幾條流量？
與偏重「個人助理對話」的 Gemini Spark 不同，Antigravity 2.0 把焦距放在多 Agent 工作流編排：你可以在獨立桌面應用裡規劃任務、用 Antigravity CLI 在 CI 或本機腳本觸發動作，並透過 Gemini API 的 Managed Agents 把長時間推理與工具呼叫放到雲端。維運上至少應拆成四類連線：CLI／安裝程式下載與更新（常見為 HTTPS 大檔或分段下載）、桌面應用與其背景同步、AI Studio 或開發者控制台（編輯 workflow、管理金鑰），以及程式化 API（如 generativelanguage.googleapis.com 及相關 oauth2.googleapis.com 相依主機）。
若你先前只為「打開 gemini.google.com」寫過規則，往往在安裝 Antigravity CLI 時會遇到腳本 curl 逾時，或桌面版能登入、終端機卻ETIMEDOUT——這不是 Google「還沒開放」，而是不同行程沒有共用同一套出口策略。本篇刻意把除錯順序寫成可貼進團隊 Runbook 的步驟，避免在 I/O 熱度期間靠猜規則換節點。
二、症狀分類：CLI 下載失敗、API 逾時與帳號限制
動規則前，請把現象寫成可重現描述：antigravity 安裝指令是在哪一步失敗——解析主機、TLS 握手、還是下載到一半重置？桌面應用能否完成 Google 登入但 Agent 面板空白？Managed Agents 回傳的是配額／權限錯誤，還是無回應逾時？若錯誤已指向工作區政策、API 金鑰無效、或專案未啟用 API，請優先回到 Google Cloud Console，而不是把整段 googleapis.com 無差別推進代理。
當錯誤偏向連線逾時、憑證異常、或隨節點地區變化，才較值得在 Clash Verge Rev 檢查規則命中、DNS 與出站品質。許多「只在瀏覽器裝擴充套件」的方案能短暫打開新聞稿連結，卻難以讓 Go 版 CLI 與背景 Agent 行程共用可稽核策略——這正是開發者平台場景與消費者網頁場景的分水嶺。
三、建議納入規則矩陣的公開域名（以你實際日誌為準）
下列為與 Antigravity 2.0、Gemini API 與 Google 開發者工具並行敘事相關的高頻方向，並非對未來命名的保證；請以CLI 安裝當下、桌面版連線紀錄、以及 AI Studio 網路面板做增量補強：
- 身分與登入：accounts.google.com、myaccount.google.com，以及企業 Workspace 的 SSO 跳轉。
- CLI 下載與更新：安裝腳本實際連線的發佈主機（常見於 github.com、objects.githubusercontent.com 或 Google 官方 CDN，請以終端機輸出為準）。
- Antigravity 桌面與 Web 控制台：產品文件列出的應用 API 與前端主機（可能與 aistudio.google.com、cloud.google.com 子路徑並用）。
- Gemini API 與 Managed Agents：generativelanguage.googleapis.com、oauth2.googleapis.com，以及你專案啟用的其他 *.googleapis.com。
- 靜態資源：gstatic.com、googleusercontent.com 等家族——登入與編輯器載入常依賴，漏補會表現為「登入成功但面板白畫面」。
建議維護《Antigravity 出站矩陣》：標註哪些主機「必須走研發節點」、哪些「區網直行」、哪些「可直連但不影響 CLI」。當 Google 在 I/O 後快速調整 CDN 或 Agent 端點時，你能只補缺口、不整包重寫規則。
四、設定檔片段：讓 CLI、桌面版與 API 明確可走 PROXY
Clash 家族核心強項是以域名為中心的策略匹配。可為 Google／Antigravity 相關後綴建立具名群組（例如 GOOGLE_DEV），與影音、其他模型供應商分離，方便在節點波動時只切換受影響段落。若 CLI 下載走 GitHub，可另設 GITHUB_DEV，避免與 Google API 混在同一節點卻未做延遲測試。
# Example rules snippet — replace group names with your profile
rules:
- DOMAIN-SUFFIX,google.com,GOOGLE_DEV
- DOMAIN-SUFFIX,googleapis.com,GOOGLE_DEV
- DOMAIN,generativelanguage.googleapis.com,GOOGLE_DEV
- DOMAIN,aistudio.google.com,GOOGLE_DEV
- DOMAIN-SUFFIX,gstatic.com,GOOGLE_DEV
# CLI installer hosts — add from your terminal logs
- DOMAIN-SUFFIX,github.com,GITHUB_DEV
- DOMAIN-SUFFIX,githubusercontent.com,GITHUB_DEV
# ... LAN / private / geo rules ...
- MATCH,DIRECT地雷提醒：勿未核對就把整段 google.com 送代理，可能把企業內部 Google 服務硬繞遠路；MATCH 兜底要與團隊文件一致；對 Managed Agents 的長連線互動，節點延遲穩定度往往比峰值頻寬更能決定成敗。
五、系統代理 vs. TUN：桌面 Agent、Go CLI 與 API 怎麼選？
系統代理對多數尊重作業系統 HTTPS 設定的瀏覽器與部分 Electron 桌面殼已足夠：在 Clash Verge Rev 開啟系統代理後，再操作 Antigravity 桌面版或 AI Studio，通常能讓登入跳轉與主要 UI 資源走混合埠。但若你主要用終端機執行 antigravity 子命令、或在 CI 跑安裝腳本，常會遇到「網頁正常、CLI 掛」——因為 Go 程式預設不讀瀏覽器擴充套件，也未必繼承 shell 的代理變數。
TUN把符合條件的封包先交給核心再依規則決策，對「多行程、多協定堆疊」較省心，適合桌面背景服務 + CLI + 本機 SDK並行。代價是與公司 VPN、零信任客戶端或其他虛擬網卡可能互斥；請在維護窗口演練一鍵關閉 TUN、恢復原生路由。節點選型上，對 Managed Agents 這類可能涉及長連線與重試的呼叫，優先選延遲穩定、丟包低的線路，而非只看測速峰值。
六、Antigravity CLI 安裝與更新：把下載主機寫進規則
I/O 後大量搜尋集中在「CLI 下載失敗」：安裝腳本往往先連發佈 CDN 或 GitHub Releases，再寫入本機。除錯時請在失敗當下執行帶 -v 的 curl 或開啟核心連線紀錄，記下最後一個失敗的 Host，再決定加入 GITHUB_DEV 或 Google 群組，而不是假設「開了 Google 規則就涵蓋 CLI」。
若公司網路對 github.com 另有閘道，可能出現一半流量走公司隧道、一半走 Clash 的登入或下載分叉；此時要比對直連、系統代理、TUN三種模式下腳本輸出是否一致。安裝成功後，用官方建議的最小健康檢查指令（依文件版本為準）驗證 CLI 能連到 API，並在日誌確認命中 GOOGLE_DEV。
七、Gemini API 與 Managed Agents：程式化路徑別只靠瀏覽器規則
Managed Agents 把部分推理與工具執行放在雲端，本機 SDK 或 CLI 仍要穩定呼叫 generativelanguage.googleapis.com 等端點。請在取得 API Key 後，用最小 curl（依官方文件路徑與標頭）測試，並對照 Clash Verge Rev 連線紀錄。若瀏覽器能開 AI Studio、Python／Node SDK 卻逾時，優先檢查HTTPS_PROXY 是否對齊混合埠與是否需 TUN，而非重複堆疊十條相同域名規則。
Agent 編排常伴隨多次往返與串流回應；若僅「首包成功、後續 chunk 失敗」，除節點外也要檢查中介設備對長連線 idle 逾時是否過短。整理問題時請附上：作業系統、代理模式、節點地區、失敗 Host、代表性 curl 輸出與是否使用 Managed Agents。
八、對齊環境變數：讓 CLI、SDK 與桌面版走同一出口
在互動式 shell 設定檔或專案腳本中，可匯出與 Clash 混合埠一致的變數（實際鍵名以工具鏈為準）：
# Example — adjust port to match your Clash mixed-port
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1變更後請重開終端機，並重啟已啟動的 Antigravity 桌面版或 IDE 外掛子行程。若混用 SOCKS 與 HTTP，請確認 Go／Node 客戶端實際讀取的變數名稱；對 gRPC 風格通道，錯誤代理型別有時只表現為無訊號長逾時。
九、節點選型與除錯順序：由近到遠
建議固定順序，寫進 Runbook：
- 本機監聽與埠占用：確認混合埠未被占用，防火牆未攔截回環。
- 帳號、專案與 Agent 配額：排除金鑰、計費、Managed Agents 權限問題。
- CLI 下載 Host：從安裝日誌補規則，區分 Google 與 GitHub 線路。
- DNS：比較直連與走節點時對 API 主機的解析。
- 規則命中：確認未遭 GEOIP 或關鍵字規則改寫到非預期群組。
- 節點交叉驗證：對長任務 Agent 以另一組穩定節點重試。
- 並行 VPN：公司隧道是否只覆蓋部分 Google 主機。
對「研發出口」節點，可優先選對 Google API 延遲低、丟包少的線路；避免把 CLI 下載與串流 API 綁在從未測過的冷門節點上。
十、與黑箱加速器、以及 Gemini Spark 場景的差異
一鍵加速器或瀏覽器擴充套件往往只能覆蓋部分分頁，難以讓 Antigravity CLI、Managed Agents 與本機 CI 共用可稽核策略。相較之下，以開源核心 + Clash Verge Rev 為基礎，你能記錄「哪些主機走哪個群組、TUN 關閉時如何還原、CLI 下載與 API 分別如何驗證」——當 Antigravity 2.0 快速迭代時，較容易判斷是規則漏補還是節點品質。若你同時關注消費者向 Gemini Spark，可另參考站內 Gemini 分流教學；本篇則專注開發者 Agent 平台與 API／CLI，避免混用同一套過於粗略的「Google 一條規則」。
若你正在尋找可把圖形介面易用性與核心日誌可觀測性結合的路線，可先從本站 下載頁取得正式安裝包，再配合 教學演練訂閱匯入、系統代理／TUN 切換與連線紀錄閱讀，把 Antigravity 桌面版、CLI 與 Gemini API 出口梳理到同一張架構圖上。
常見問題
Antigravity CLI 安裝或更新一直失敗，一定是代理問題嗎？
不一定。請先確認官方發佈的安裝指令、作業系統架構與磁碟權限；若錯誤為連線逾時或 TLS 握手停滯，且會隨是否啟用代理而變化，才較值得在 Clash Verge Rev 檢查規則命中與節點品質，並在日誌中補齊 CLI 實際連線的下載主機名稱。
使用 Antigravity 2.0 與 Managed Agents 一定要開 TUN 嗎？
不一定。若你主要在桌面應用或瀏覽器操作 Agent 編排，且程式尊重系統 HTTPS 代理，系統代理搭配精準域名規則通常就足夠。TUN 適合讓 Go 版 CLI、不讀代理的背景服務預設被接管，但需處理驅動權限與其他 VPN 軟體互斥。
規則已命中 PROXY，但 Gemini API 或 Managed Agents 仍逾時怎麼辦？
先切換延遲穩定的節點排除單點故障，再檢查本機時間與憑證；比較直連與走節點時的 DNS 解析結果；確認 API 金鑰、專案配額與 Agent 執行權限正常。若僅長連線或串流請求失敗，也可能是中介設備對長連線逾時過短，需與網路管理員確認。
這篇與 Gemini Spark 分流教學有什麼不同？
Gemini Spark 偏重消費者向的 Gemini 應用與對話體驗；Antigravity 2.0 則聚焦開發者 Agent 編排平台，包含獨立桌面應用、Go 版 CLI、SDK 與 Gemini API Managed Agents。兩者可能共用部分 Google 域名，但除錯時應分別盤點 CLI 下載、Agent 執行與 API 呼叫三條路徑，避免只開瀏覽器規則卻漏掉終端機流量。