Google Antigravity MCP 怎麼部署？2026 雲端 Mac 權限配置與驗收

遇到的症狀通常是：Antigravity 能啟動，但 MCP Server 不回應，或工具一開通就要求過大的檔案與指令權限。

最快的解法是：先在隔離的雲端 Mac 或遠端開發環境中，使用明確的遠端 MCP 位址、單一隻讀工具與逐項權限確認完成 Google Antigravity MCP 部署；不要把全域 MCP 權限直接套用到生產工作。

這篇文章適合三類讀者：想把 Antigravity 從本機試用搬到雲端 Mac 的開發者、需要統一管理 MCP、金鑰與執行權限的技術負責人，以及正在比較本地 Mac 與遠端開發環境 Agent 工作流程的人員。完成下列驗收後，讀者可以更準確判斷哪些工作適合租用獨立雲端環境，哪些工作仍應留在受控的本地工作站。

先畫出部署時間軸與隔離邊界

Google Antigravity 的 CLI、Gemini API Agent 與遠端 MCP 並不是同一層。CLI 負責啟動與管理開發工作流程，Agent 負責理解任務並決定何時提出工具呼叫，而 MCP Server 則提供可被 Agent 使用的外部工具。官方文件已確認 Antigravity 可管理 MCP Server、連接遠端 MCP，並配合權限控制；實際可用模型、版本行為與相容性仍應以Google Antigravity Agent 官方文件為準。

部署前先把環境拆成四個邊界：

• 執行環境：雲端 Mac 的作業系統、使用者帳戶、專案目錄與硬碟剩餘空間。
• 網路出口：雲端 Mac 是否能連到遠端 MCP URL，DNS、TLS 憑證、代理伺服器與防火牆是否允許該請求。
• 身份憑證：API 金鑰、OAuth Token、請求標頭與環境變數的來源，不能直接寫入 Git 儲存庫。
• 操作範圍：read_file、command 與 MCP 工具權限必須分開審查，不能因為需要讀取一個專案檔案，就一併開放任意指令執行。

本地 MCP 通常與 Agent 位於同一個開發環境，依賴本機程式、Socket 或子程序；streamable HTTP MCP 則透過遠端 URL 提供串流式 HTTP 通訊。兩者的故障位置不同：本地型態優先檢查啟動程式與檔案權限，遠端型態則要另外確認 URL、認證標頭、協定回應及雲端 Mac 的網路出口。MCP 存取控制與授權概念可參考Google Cloud MCP 存取控制文件。

部署前檢查清單

• [ ] 建立不含生產密鑰、支付資料或客戶資料的測試專案目錄。
• [ ] 確認雲端 Mac 可解析並連線至指定的 MCP URL。
• [ ] 將金鑰放入受控的環境變數或密鑰管理機制，不放進設定檔提交紀錄。
• [ ] 先決定第一個只讀工具，不從完整工具清單開始。
• [ ] 為開發、測試與生產環境分開保存權限設定。
• [ ] 確認涉及源碼、金鑰、支付或外部寫入的動作必須人工確認。

按官方欄位完成最小 MCP 註冊

Google Antigravity MCP 部署的第一個可驗收目標，不是讓 Agent 執行完整任務，而是讓它成功呼叫一個可預期、無副作用的只讀工具。Google 的 MCP 設定文件列出遠端伺服器所需的核心欄位，實際格式應以Google Developers MCP 設定文件中的現行說明為準。

設定時可先建立一個最小項目，包含：

名稱格式應保持穩定，建議把環境、用途與服務角色放進名稱，而不是用會隨部署人員改變的暱稱。allowed_tools 應視為白名單，不是顯示用的標籤；若文件或版本支援精確工具名稱，就優先使用精確匹配，避免以全域通配符一次放行整個 MCP Server。

最小連線可以依照下列順序完成：

1. 在雲端 Mac 建立獨立工作目錄，確認 Antigravity CLI 可以正常啟動。
2. 登錄 MCP 名稱與遠端 URL，先不加入寫入或指令型工具。
3. 加入必要的請求標頭，並以環境變數注入敏感值。
4. 將 allowed_tools 限定為一個只讀工具。
5. 啟動 Agent，要求它執行單純的查詢或結構化資料擷取。
6. 保存連線結果、工具名稱、回應格式與錯誤訊息，然後才決定是否增加下一個工具。

若連線失敗，不要先重試完整 Agent 任務。先分層檢查：URL 是否拼寫正確、認證標頭是否由正確環境變數提供、伺服器是否回傳 MCP 預期協定內容，以及雲端 Mac 是否經由錯誤的代理或受限出口發出請求。Google 提供的Antigravity 入門 Codelab可用來對照基本啟動與操作流程，但不能取代對遠端環境的網路與權限驗收。

注意： MCP 連線成功只代表服務可達，不代表工具安全。能讀取檔案、執行命令或寫入外部系統的權限，必須在連線驗收後另外審核。

用三層權限矩陣限制 Agent 行為

Antigravity MCP 權限配置應把三種能力分開：read_file 管理檔案讀取，command 管理命令執行，MCP 權限則管理遠端工具呼叫。將三者放在單一全域規則中，會讓一次「讀取設定」意外擴大成「可以執行命令並呼叫外部寫入工具」。

可採用以下策略作為初始矩陣：

全域通配符的風險在於它會把未來新增的工具也納入既有規則；當 MCP Server 更新工具名稱或加入新的寫入能力時，原本看似方便的設定可能在沒有重新審查的情況下擴大權限。Google 的MCP IAM 權限文件可作為團隊審查角色與權限分工時的參考。

因此，較穩妥的做法是先允許「某一個 MCP Server 的某一個工具」，並將 command 的精確命令與工作目錄一併列入審查。任何需要讀取源碼、接觸金鑰、處理支付資料或向外部系統寫入的任務，都應保留人工確認，不應只依賴模型判斷。

首次呼叫按驗收順序逐項排錯

雲端 Mac 運行 Antigravity 時，建議用三個逐步增加風險的任務驗證工具呼叫鏈，而不是直接交給複雜的多步驟 Agent 任務。

第一項是只讀查詢，例如取得測試服務的狀態或列出允許範圍內的資料。此時要記錄 MCP Server 名稱、實際工具名稱、回應是否符合預期，以及 Agent 是否嘗試呼叫白名單之外的工具。

第二項是結構化資料擷取，例如要求 Agent 把一個固定格式的回應整理成欄位。這一步可觀察模型推理與工具回應是否被混淆：若服務已正確回傳資料，但模型欄位解析錯誤，問題屬於 Agent 推理或輸出格式，不應歸咎於遠端 Mac。

第三項才是一次受控寫入，而且寫入目標必須是測試檔案、測試資料庫或可回復的模擬服務。完成後確認實際變更、回復方式、日誌內容與人工確認紀錄。若工具回傳錯誤，應區分三種來源：

• 模型推理失敗：工具本身回應正常，但 Agent 選錯工具、參數格式錯誤或錯誤解讀資料。
• MCP 服務失敗：URL 可達，但協定回應、認證、工具註冊或服務內部處理失敗。
• 遠端 Mac 環境失敗：CLI 未啟動、環境變數未載入、目錄權限不足、磁碟狀態異常或網路出口受限。

驗收紀錄至少應包含連線成功與否、工具返回內容、錯誤重試、日誌留存位置及工作階段恢復結果。不要只記錄「Agent 成功」；沒有工具名稱與回應內容，就很難在團隊環境中重現問題。

擴大到團隊工作流前完成維護清單

單機雲端 Mac 適合用來驗證 Antigravity、MCP 工具與權限邊界，但當團隊開始共用同一套 Agent 工作流，維護責任會從單次設定變成持續管理。以下檢查可放入每次設定變更的審查流程：

• [ ] 為 MCP 金鑰建立輪換週期，輪換後確認舊金鑰已撤銷。
• [ ] 工具不再使用時立即從白名單移除，而不是僅在提示詞中要求 Agent 不要使用。
• [ ] 新增 MCP Server 前，核對來源、URL、認證方式、資料流向與寫入能力。
• [ ] 將設定檔以版本控制保存，但排除金鑰、Token 與個人工作階段資料。
• [ ] 檢查連線日誌是否暴露請求標頭、源碼片段或個人資料。
• [ ] 監察雲端 Mac 的硬碟空間、並發工作階段與長時間閒置狀態。
• [ ] 為閒置工作區設定關閉或回收流程，避免無人管理的 Agent 長期保留權限。
• [ ] 每次 Agent、CLI 或 MCP 文件更新後，重新做一次只讀工具驗收。

若團隊需要集中管理多個專案、統一審計工具呼叫、分離不同環境的金鑰，或需要讓多位開發者共用一致的權限政策，便應評估從單機雲端 Mac 升級到集中式 Agent 執行環境。相反地，若工作仍以單一開發者的短期測試、需要圖形化 Mac 工作區，或必須保留特定本機工具鏈，獨立雲端 Mac 仍可能較容易控制。

對想了解雲端 Mac 租用與遠端開發環境的人來說，真正需要比較的不只是能否啟動 Antigravity。自建本地 Mac 需要自行處理硬體閒置成本、多人共用時的權限分離與遠端連線維護；一般遠端開發環境則可能缺少 macOS 專屬工具鏈、圖形化工作區或團隊需要的隔離方式。若目標是短期測試 MCP、驗證 AI Agent 工作流，或為團隊建立一個可回收的獨立工作區，租用 Vuncloud 的雲端 Mac 通常比先購置一台長期閒置的設備更容易先完成驗收；正式導入前，仍應依照幫助中心的環境與使用說明確認實際交付方式與管理責任。

博客

• AI Coding、Personal AI 與 Agent 編排的三層架構
• Mac 雲主機安裝與驗收 OpenClaw：SSH、VNC 與節點配置
• macOS 雲端開發環境映像的腳本化管理與驗收