Google Antigravity MCP 怎么部署？2026 云端 Mac 权限配置与验收

MCP 已经出现在配置列表里，但 Antigravity 不是调用超时，就是把不该开放的工具一起暴露出来。

最快的处理方式是：先在隔离的云端 Mac 或远程开发环境中部署，使用明确的远程 MCP 地址、最小工具白名单和逐项权限确认；不要把全局 MCP 权限直接用于生产任务。Google 官方文档目前同时覆盖远程 MCP、项目级工具配置、权限控制与安全钩子，因此部署重点不是“能不能连上”，而是“连上后能做什么”。(Google Antigravity Agent 官方文档)

这篇文章适合三类人：
想把 Google Antigravity 从本地试用迁移到云端 Mac 的开发者，可以按步骤完成连接与验收。需要为团队统一管理 MCP、密钥和执行权限的负责人，可以直接采用文中的权限矩阵。正在比较本地 Mac 与远程开发环境的 Agent 工作流人员，也能据此判断是否值得租用独立工作区。

先画出部署时间表，再开始配置

Google Antigravity MCP 部署不应从“把所有服务器都加进去”开始，而应按以下时间线推进：

这里需要先区分三个概念。Antigravity CLI 或 Antigravity IDE 是调用方，Gemini API Agent 是可以执行代码、处理文件并连接外部工具的 Agent 运行方式，而远程 MCP Server 则是提供外部工具的服务端；三者并不是同一个组件。Google 官方资料显示，远程 MCP 可以作为 Agent 工具注册，但不同运行表面的配置文件、认证字段和可用能力可能不同，不能把 CLI 示例原样复制到其他界面。(Google Antigravity Agent 官方文档)

本地 MCP 通常依赖云端 Mac 上的进程、脚本或本机端口，优点是数据路径短，缺点是会话退出、进程重启和端口暴露都需要自行维护。Streamable HTTP MCP 则通过远程 HTTPS 地址提供服务，更适合远程开发环境，但必须确认网络出口、TLS、请求头和服务端身份验证；当前 Antigravity Agent 文档明确说明，远程 MCP 不支持 SSE，应优先使用 Streamable HTTP。

第一步：完成云端 Mac 的边界检查

在创建 MCP 配置前，先把云端 Mac 当成一台可能被 Agent 操作的远程工作站，而不是普通的浏览器登录环境。至少需要确认以下项目：

• [ ] 项目目录与个人文件、SSH 密钥、浏览器配置分离。
• [ ] 云端 Mac 具备访问远程 MCP URL 的网络出口。
• [ ] 环境变量中没有直接写入长期有效的生产密钥。
• [ ] Antigravity 使用的项目目录只包含本次任务所需文件。
• [ ] 远程 MCP 服务端已经确认域名、协议和认证方式。
• [ ] 需要外部写入、删除、支付、发布的工具，已经列入人工确认范围。
• [ ] 测试环境与生产环境使用不同的凭证和不同的 MCP Server。
• [ ] 团队已经决定日志中哪些请求参数必须脱敏。

云端 Mac 运行 Antigravity 需要注意的并不只是 CPU 或内存。网络出口受限时，MCP 列表可能能显示服务器，但真正调用会因 DNS、TLS 或防火墙失败；环境变量存在但权限不足时，服务也可能返回认证成功后的资源拒绝。另一个隐性成本是凭证生命周期：如果把 API Key 写进项目配置并长期保留，后续轮换就不再是“改一处配置”，而是要检查备份、日志、历史提交和共享目录。

对于只读文档查询、结构化数据提取、测试代码生成，隔离云端 Mac 通常适合作为第一阶段环境。涉及源码仓库写入、外部工单修改、云资源变更、支付系统和客户数据的任务，则不能因为 MCP 连接成功就直接授予完整权限。

⚠️ 注意：MCP 的工具白名单只限制 Agent 是否看见或调用某个工具，不等同于服务端授权。Google Cloud 的远程 MCP 还需要 roles/mcp.toolUser 以及目标产品本身所需的资源权限；两层权限缺一不可。(Google Cloud MCP 访问控制文档)

第二步：注册一个最小可用的远程 MCP

把 MCP Server 加入 Antigravity 时，最稳妥的路径是先进入 MCP 管理界面，或打开项目级配置文件，再新增单个服务器定义。官方示例显示，Antigravity 可在项目目录的 .agents/mcp_config.json 中配置，也可以使用全局的 ~/.gemini/config/mcp_config.json；项目级配置更适合测试和团队隔离，全局配置则会扩大所有项目的可见范围。(Google Developers MCP 配置文档)

一个通用的最小结构可以写成：

{
  "mcpServers": {
    "readonly_docs": {
      "serverUrl": "https://example.example/mcp",
      "headers": {
        "Authorization": "Bearer ${MCP_TOKEN}"
      }
    }
  }
}

字段含义需要逐项确认：

• readonly_docs：服务器名称。名称应使用小写、数字或下划线，避免空格、大写字母和容易混淆的缩写。官方 Agent 文档特别提示，远程服务器名称必须严格使用小写字母和数字，否则可能出现笼统的 400 Bad Request。
• serverUrl 或 httpUrl：具体字段取决于 Antigravity 的运行表面与当前配置格式，不能仅凭社区旧示例判断；官方 Developer Knowledge MCP 文档同时展示了 IDE、扩展和 CLI 的不同写法。
• headers：放认证请求头，但不要把真实密钥提交到 Git、截图或共享配置。
• allowed_tools、allowedTools 或界面中的工具选择项：如果当前版本提供该字段或选项，只放行首次验收所需的一个只读工具；如果版本不识别该字段，应以界面工具选择和服务端权限为准，不要自行假设字段一定生效。

保存后不要立即执行复杂任务，先依次检查：

1. URL 是否为 HTTPS，域名是否与服务方提供的地址完全一致。
2. 请求头名称是否区分大小写，变量是否在当前会话中实际存在。
3. MCP 服务是否使用 Streamable HTTP，而不是当前不支持的 SSE。
4. Antigravity 的 MCP 列表是否显示服务器已加载。
5. 工具列表中是否只有预期的只读工具。
6. 云端 Mac 的出口策略是否允许访问目标域名。

如果列表中完全没有服务器，优先查配置文件路径、JSON 格式和名称字段；如果列表可见但刷新失败，优先查 URL、认证头和网络出口；如果刷新成功但工具调用返回 403 或权限拒绝，优先查服务端身份与资源权限。

第三步：把文件、命令和 MCP 权限拆开

权限设计应把“能读取文件”“能执行命令”和“能调用外部 MCP 工具”视为三个授权面，而不是合并成一个总开关。至少应拆成以下范围：

• 文件权限：允许访问哪些路径，是否包含项目外目录，是否能读取环境文件和密钥文件。
• 命令权限：允许哪些命令，是否能执行网络操作、安装依赖、删除文件或修改系统设置。
• MCP 权限：允许哪些服务器、哪些工具、哪些资源范围，以及是否需要每次人工确认。

Google Antigravity 的项目设置可以分别限制文件路径、URL、终端命令和具体 MCP 工具；官方 Codelab 也建议按项目调整权限，而不是让所有项目继承相同的全局能力。(Google Antigravity Codelab)

可采用下面三档策略：

开发档：允许当前项目目录内的读取与有限写入，MCP 只开放文档查询、状态读取或结构化提取工具。命令执行仍应限制在项目目录，禁止读取 ~/.ssh、云凭证目录和系统密钥链。

测试档：使用脱敏数据、独立测试账户和单独的 MCP Server，允许一次受控写入，例如向测试目录生成报告，但不能访问真实客户数据，也不能调用生产 API。每次扩大工具集合，都要重新记录工具名称、用途和回滚方式。

生产档：默认关闭写入与命令执行，使用精确的服务器名称和工具名称，必要时通过服务端 IAM 条件限制资源范围，并保留人工确认。Google Cloud 文档说明，MCP Tool User 只是调用 MCP 的一层权限，访问具体服务仍需要对应的产品权限；因此“授予 MCP 权限”并不等于“授予所有云资源权限”。(Google Cloud MCP IAM 权限文档)

全局通配符最容易造成误判。例如，允许所有 MCP Server 或所有工具，短期看似减少配置工作，实际会让新加入的服务器自动进入可用范围；允许所有命令，则可能使 Agent 在无法调用某个 MCP 工具时，尝试通过 Shell 绕过限制。对于高风险命令，可以使用 Agent Hooks 在工具执行前进行拦截，返回 deny 和具体原因，让 Agent 改用安全路径或停止操作。(Google Agent Hooks 文档)

第四步：用三次小任务完成首次验收

出现工具调用失败时，不要用“自动修复整个项目”这种复杂任务作为第一次验收。更可靠的方式是把调用链拆成三次逐步增加风险的测试。

第一次：只读查询。
要求 Agent 调用唯一的只读工具，返回一条明确记录或固定字段。验收重点是服务器是否真正收到请求、返回是否符合协议、Agent 是否选择了预期工具，而不是回答文字是否漂亮。

第二次：结构化提取。
让 Agent 从返回结果中提取固定字段，并输出 JSON 或表格。需要注意，结构化提取验证的是工具返回解析与模型理解，不代表远程服务具备写入权限；如果结果字段缺失，应区分服务端响应问题与模型解析问题。

第三次：一次受控写入。
只在测试目录或测试服务中写入一份无敏感信息的结果文件，写入前保留人工确认。成功标准包括：调用前出现确认、文件只出现在预定目录、日志能找到对应请求、重复执行不会覆盖不相关文件。

每次测试都记录以下内容：

• 连接是否成功，服务器名称是否一致；
• 实际调用的工具名称与参数摘要；
• 返回结果或错误码；
• 是否发生自动重试，重试后是否改变了参数；
• 云端 Mac 上的日志、文件变化和网络状态；
• 会话中断后能否恢复，恢复时是否重新要求授权。

错误归因可以按三层判断：如果 Agent 没有选择工具，先看工具描述、白名单与模型判断；如果工具被选择但服务端报错，检查 MCP 协议响应、认证头和服务端权限；如果请求根本没有离开云端 Mac，检查网络出口、DNS、证书、代理和本地进程。Google 的 Antigravity Agent 支持通过交互 ID 延续未完成会话，因此恢复测试也应验证会话状态，而不是简单地重新提交同一条提示词。(Google Antigravity Agent 官方文档)

第五步：扩大到团队工作流前，完成维护清单

当单个只读工具通过验收后，才可以考虑接入更多 MCP Server。团队负责人应把配置当成版本化资产管理，而不是一次性粘贴的本地文件：

• [ ] 为每个 MCP Server 记录负责人、用途、数据范围和撤销方式。
• [ ] 将服务器名称、远程 URL 和工具白名单纳入配置审查。
• [ ] 定期轮换 API Key、OAuth 凭证或云端服务账号权限。
• [ ] 检查日志是否意外记录请求头、密钥、源码或客户数据。
• [ ] 删除长期未使用的服务器和工具，避免配置持续膨胀。
• [ ] 为开发、测试、生产建立不同项目与不同凭证。
• [ ] 检查云端 Mac 的磁盘、并发会话、后台进程和闲置关机策略。
• [ ] 为失败重试、会话恢复和人工接管设置明确触发条件。

如果团队开始同时运行多个 Agent、需要集中审计工具调用、需要统一分发 MCP 白名单，或者多个云端 Mac 反复维护相同的凭证与配置，就不宜继续依赖单机工作区。此时应评估集中式 Agent 运行环境、统一身份管理和服务端策略控制。Google Cloud 的 MCP 访问控制支持项目级、资源级和条件式授权，可用于把“谁能调用”与“能访问哪些资源”进一步拆开。

对于个人开发者，云端 Mac 的价值在于可以保留独立项目目录、远程访问和持续运行能力；但它仍需要自行管理凭证、网络出口、日志和闲置资源。与本地 Mac 相比，远程环境多了会话恢复、远程连接和权限隔离的运维成本；与直接使用集中式 Agent 平台相比，单机云端 Mac 又可能缺少统一审计、团队策略和规模化凭证轮换。若只是短期测试 MCP、验证远程工具或临时搭建 Agent 工作区，租用 Vuncloud 的云端 Mac 往往比立刻购买一台长期闲置的 Mac 更容易控制试错范围；若任务是长期稳定重负载、必须接入物理 USB 设备，或要求完全掌控硬件生命周期，则应优先评估自购 Mac。

如果下一步需要把这套配置扩展到团队，可以先参考 Vuncloud 帮助中心 了解远程环境管理，再结合 Mac 云租用服务 判断独立工作区、测试节点与长期运行方案是否匹配。对于还没有固定环境的项目，先完成一次最小 MCP 调用，再决定是否需要长期租用，通常比先开放全部权限更稳妥。

博客

• 远程调用 Ollama：Mac 部署与安全配置指南
• 个人 AI 智能体架构：从工具调用到云端部署