2026 年 5 月 19–20 日 Google I/O 2026 上，Google 正式发布 Google Antigravity 2.0：一款面向开发者的独立 Agent 平台，支持桌面端多 Agent 并行编排、全新 Antigravity CLI，以及面向 Managed Agents 的 SDK 接入。同期亮相的 Gemini 3.5 Flash 成为 Antigravity 默认推理后端之一，官方也明确引导原 Gemini CLI 用户迁移到新 CLI。对大陆与部分亚太开发者而言，尝鲜路径往往是：先在桌面版里跑通一个 Agent，再在终端用 antigravity 调用 Gemini API 或托管 Agent——结果常见却是 ETIMEDOUT、Managed Agents 握手挂起、或「浏览器能登 Google、CLI 却连不上」。这与旧版 Gemini CLI 的排障逻辑有重叠，但 Antigravity 2.0 作为独立平台，域名集合与失败形态并不完全相同。本文以 Clash Verge Rev 为中枢，说明如何用代理分流、HTTPS_PROXY 与可选 TUN，让 Antigravity CLI 在 2026 年网络环境下稳定跑通。

Antigravity 2.0 是什么：和 Gemini CLI 差在哪

Google Antigravity 2.0 不是简单的「换皮 Gemini CLI」。桌面端强调多 Agent 并行：你可以在同一个工作区里让不同 Agent 分别处理代码审查、文档生成与测试编排；Antigravity CLI 则把同一套能力搬到终端与 CI，便于脚本化调用 Managed Agents。底层仍大量依赖 Gemini API（含 Gemini 3.5 Flash 等模型端点），流量仍会打到 generativelanguage.googleapis.com 一类主机；但 Antigravity 生态还可能额外访问 ai.google.dev、Google 账号鉴权链，以及 Agent 调度相关的 googleapis.com 子域。

因此，若你曾读过本站关于 Gemini CLI 的教程，HTTPS_PROXY 与 Clash 规则的大框架可以复用，但不能假设「Gemini CLI 能跑，Antigravity 一定也能跑」——请在第一次 CLI 调用时打开 Verge Rev 连接面板，记录实际出现的主机名，再按需补全白名单。官方迁移文档往往默认海外直连环境；在国内开发机上，终端进程是否走代理才是第一关。

你可能遇到的典型现象

第一类是纯链路超时：执行 antigravity chat 或等价子命令时出现 Read timed out、TLS 握手长时间无响应；桌面版同一账号下偶发能对话，CLI 却连续失败。第二类是Managed Agents 启动卡住：任务状态一直 pending，连接面板里能看到对 generativelanguage 或 ai.google.dev 的请求，最终策略却是 DIRECT。第三类最容易误导人：Antigravity 桌面应用正常，IDE 集成终端里的 CLI 不行——说明 GUI 走了系统代理或应用内网络栈，而 shell 子进程仍在裸连，或命中把 Google AI 全家桶送去直连的规则。

排障习惯：在 CLI 卡顿时，于 Verge Rev 连接列表搜索 generativelanguage、googleapis、ai.google.dev、oauth2。若最终策略一直是 DIRECT，应先改规则顺序或覆写片段，再谈换节点或升级 Antigravity 版本。

为什么「只开系统代理」常常救不了 Antigravity CLI

macOS 与 Windows 的系统 HTTP 代理主要影响声明遵循系统代理栈的应用；Antigravity 桌面版往往属于这一类。但 Antigravity CLI 由你在 Terminal、iTerm 或 VS Code 集成终端里启动，底层 Node 或 Go 运行时默认不读取系统代理，除非文档明确说明。更稳妥的做法是在 shell 中显式导出：

  • export HTTPS_PROXY=http://127.0.0.1:7890（端口换成你的 mixed-port）
  • 按需补充 HTTP_PROXY、ALL_PROXY；Managed Agents 若走 gRPC 或 WebSocket，仍多数回落到 HTTPS 代理语义

只有确认 Antigravity CLI 官方文档写明「继承系统代理」时，才可省略环境变量；否则请把显式 export当作第一步，再去看 Clash 规则。

小技巧：在同一终端标签页内先 export 再运行 antigravity；若从 GUI「在终端中打开」但未加载 ~/.zshrc，会出现「桌面版正常、CLI 无代理」的错觉。用 env | grep -i proxy 确认当前会话；Windows PowerShell 可用 $env:HTTPS_PROXY 对照。

规则分流与全局 TUN：Managed Agents 场景怎么选

代理分流的价值在于：国内站点、npm 镜像、企业内网 Git 保留 DIRECT，仅把 Gemini API、Antigravity 相关域名与必要鉴权主机送进代理策略组。对日常开发而言，这是性价比最高的默认——Managed Agents 的长连接与流式响应不必与晚高峰视频流量挤同一条全局隧道。

TUN／虚拟网卡在路由层更早接管，适合 CLI 或 Agent 运行时死活不认环境变量、或你希望减少漏网进程的场景；代价是要与其它 VPN、零信任客户端协调路由。一旦路由表被抢占，Antigravity CLI 仍表现为超时，根因却是「包没到 Clash」。

实操顺序：先用「系统代理或 HTTP 代理 + HTTPS_PROXY」跑通一次最短 Agent 对话；连接面板确认主机已走代理仍慢，再考虑换节点；仅当明确存在绕过用户态代理的后台进程时，再启用 TUN，并在每次变更后重启终端与 Antigravity CLI 会话。

Clash Verge Rev 侧：先对齐端口与当前配置

在 Clash Verge Rev 里先完成三件事：

  1. 确认当前激活的配置就是你编辑的那份；订阅自动更新若冲掉手写规则，会出现「昨天 Antigravity 能跑、今天 CLI 全直连」的跳转。
  2. 记下界面里的 mixed-port（或单独的 port／socks-port）；下例以 7890 为占位符。
  3. 本机用 curl -x http://127.0.0.1:7890 https://example.org 先行验证内核 alive；本机都不通时先修节点，不要归咎于 Gemini 3.5 Flash 或 Antigravity 版本。

若你依赖图形覆写（Override），把 Antigravity 相关规则放进覆写层，避免机场一键更新把片段顶掉——这与长期维护「开发者终端代理」是同一套习惯。

HTTPS_PROXY 写在哪：shell、IDE 与 Windows

macOS / Linux：常见做法是把通用代理写进 ~/.zshrc 或 ~/.bashrc，例如：

# Use your real mixed-port. Extend NO_PROXY for corp and mirrors.
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,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.local,your.corp.git

NO_PROXY 要按你的内网段、公司域名、私有 PyPI／npm 镜像迭代；漏写会让仓库误走代理变慢，写得太宽又可能把本该走代理的 Google 主机排除出去。Antigravity 项目在 monorepo 里常同时访问内网 Registry 与 Gemini API，建议以连接面板真实主机名为准逐步收紧。

仅对 Antigravity 项目生效时，可用 direnv 在项目根注入变量，避免污染全局。团队把「跑 antigravity 前先 source 某脚本」写进 README，能显著降低 I/O 2026 尝鲜期的试错成本。

Windows：可在用户环境变量里新增 HTTPS_PROXY，或在 PowerShell 会话中赋值；修改后重启终端与 Antigravity CLI。若使用 WSL，请在发行版内单独导出一份，WSL 不会自动继承 Windows 图形界面的代理开关。

Gemini API 与 Antigravity 相关的规则分流示例

下面是示意 YAML，请把 YOUR_PROXY_GROUP 换成真实策略组名，并把片段放在会在 MATCH 前生效、且不会被更宽泛的 DIRECT 截胡的位置：

# Override or rules — replace YOUR_PROXY_GROUP
rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,ai.google.dev,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,googleapis.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,google.dev,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,accounts.google.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,oauth2.googleapis.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,gstatic.com,YOUR_PROXY_GROUP

说明：Google 侧可能随 Antigravity 2.0 迭代增减辅助域名或使用边缘节点；以你机器连接列表里实际出现的主机为准做增量。若配置大量使用 RULE-SET，留意集合更新后规则顺序是否被插入新项。对大陆用户而言，GEOIP,CN,DIRECT 或某些「超大集合」放得太靠前，仍是最常见的「写了 DOMAIN 却仍直连」来源——务必在面板里看最终策略而不是想当然。

Managed Agents 与并行 Agent：多连接时的面板观察

Antigravity 2.0 强调多 Agent 并行，一次任务可能同时打开多条到 Gemini API 的流式连接，并在后台轮询 Agent 状态。若只有部分连接走代理、部分直连，你会看到「有时能回复、有时整轮超时」的间歇性故障。做法是：在 Verge Rev 里按进程或域名过滤，确认同一 CLI 会话产生的连接策略一致；若发现某个子域始终 DIRECT，单独补一条 DOMAIN-SUFFIX 即可，不必一上来全局 TUN。

桌面版与 CLI 同时运行时，连接数会叠加——这属于正常现象，但也会放大「规则不一致」的问题。建议先单独把 CLI 跑通，再开桌面多 Agent 工作区，便于对照面板。

鉴权流程与 NO_PROXY：别把登录域名挡在代理外

Antigravity 首次登录往往走 Google 账号 OAuth；流量可能经过 accounts.google.com、oauth2.googleapis.com、ssl.gstatic.com 等。若你把 google.com 全家桶写死直连，或 NO_PROXY 过宽排除了本应走代理的 Google 主机，常见表现是「浏览器能登、CLI 不能续期」或 Managed Agents 报鉴权失败——这与 API 超时不同，但在终端里同样令人沮丧。

做法是：先用面板确认 accounts／oauth2 命中策略，再决定是否要在公司网改用 Split Tunnel 或专用节点。公司 SSL 检查设备若插入路径，也可能导致 CLI 校验证书失败，需与网络管理员协调或改用可信节点。

DNS、fake-ip 与「解析看起来对、链路却不稳」

当规则显示 PROXY 但 Antigravity CLI 延仍抖动，复查 DNS：fake-ip 若与特定客户端不契合，可能出现偶发握手慢；DoH 上游若未走通代理，也会表现为解析阶段无限重试。建议顺序是先看连接面板域名与策略，再看 DNS 日志，而不是一上来全局关闭 fake-ip 扩大扰动面。

注意：启用 TUN 后若与公司 VPN 冲突，Antigravity CLI 常见症状是「偶尔能连、多数超时」。先退回 Rule 加环境变量定位，再逐项启用 TUN；不要在未备份配置的情况下并行折腾多款路由软件。

验证：怎样算 Antigravity CLI 真的稳了

  1. 重载 Clash 配置并确认无 YAML 语法错误。
  2. 新开终端执行 env | grep -i proxy，核对端口与协议。
  3. 使用 curl -v -x http://127.0.0.1:7890 https://generativelanguage.googleapis.com/ 与 curl -v -x http://127.0.0.1:7890 https://ai.google.dev/ 观察是否快速得到 TLS 反馈，而非长时间挂起。
  4. 启动 Antigravity CLI 进行最短一轮对话或 Managed Agent 调用；同时在 Verge Rev 里搜索 generativelanguage 与 ai.google.dev，确认连续请求为代理策略。
  5. 若仍失败，区分429／403／401与无响应：前者多半是配额、项目启用或 API Key 问题；后者再回到规则与代理链路。

延伸：别把配额、区域与代理混为一谈

当响应体已经明确提示配额、billing、API 未启用或区域限制时，继续在 Clash 里调顺序意义有限；应在 Google AI Studio 或 Cloud 控制台核对 Antigravity 项目与密钥。反之，若面板里长期 pending 且主机命中 DIRECT，应回到本文「规则」与「HTTPS_PROXY」两段处理。Gemini 3.5 Flash 作为新模型，偶发 503 也可能来自 Google 侧容量，与代理无关——但先确认链路已走代理，才能排除网络因素。

为什么 Antigravity 开发场景仍值得用 Clash 系客户端

单模式全局 VPN 往往难以兼顾细粒度域名分流、可读的连接日志，以及与本地开发共存的 NO_PROXY；浏览器插件又对 Antigravity CLI 完全无效，正好卡在新平台「桌面能用、终端不能用」的缝隙上。Clash Verge Rev 把 Mihomo 内核与覆写结合起来，让你能在不改 Antigravity 业务代码的前提下，把 Gemini API、ai.google.dev 与内网工具链拆开调度。与「遇事不决全局翻」相比，把 Google AI 相关主机稳定送进可用节点、其余流量按规则落在国内直连，通常更省延迟、也更易复盘。

相比之下，一些轻量代理工具要么只有全局模式、要么缺少连接级日志，很难在 Antigravity 2.0 多 Agent 并行时快速定位「哪条连接还在 DIRECT」。Clash 生态在规则模型、订阅维护与覆写工作流上更贴近长期开发者需求；若你同时维护 Gemini CLI 迁移前的旧脚本与 Antigravity 新 CLI，同一套 Clash 配置往往可以复用，只需按面板增量补域名即可。

立即免费下载 Clash，开启流畅上网新体验 →