上回说到，我把终端工具的网络问题搞定了——用 Clash TUN 模式让所有流量都走代理，终于能在终端里正常访问外网。但故事远没有结束：网通了只是第一步，要真正在本地的 OpenCode 里同时用上 GitHub Copilot 和 Google Antigravity 的免费大模型额度，后面还有一连串的坑等着我。
这篇就是续集，记录我从「能上网」到「能白嫖双份 AI 额度」的全过程。
1. 网络层的遗留问题：TUN 开了，Git 推不动了
上篇已经确认：系统默认的代理设置对底层直接走 Socket 的终端工具没用，得开 TUN 模式，让代理软件在系统底层生成虚拟网卡、重写路由表，把电脑里所有流量都强制劫持到代理节点。
听起来很完美，但全局劫持也带来了新麻烦。
我在用 Hexo 部署博客的时候发现：hexo d 死活推不上去。排查后发现，Git 默认用 SSH 协议走 22 端口，而大部分代理节点会直接丢弃 22 端口的流量（安全策略）。
解决办法很简单：把 Git 的远程仓库地址从 SSH 换成 HTTPS（走 443 端口）。443 是 HTTPS 的标准端口，代理对它非常宽容，切换之后一切正常，TUN 模式开着也能顺利推代码。
经验总结：全局代理虽好用，但 SSH（22 端口）和一些冷门协议可能被代理节点拦截，遇到连不上的情况先检查端口和协议。
2. Antigravity 的 400 报错：差一个 Project ID
网络通了之后，我迫不及待地打开 Google Antigravity，想直接用里面的免费大模型。结果迎面一个 HTTP 400 Bad Request，报错信息写着：
1 | Invalid project resource name projects/ |
翻译成人话就是：你没告诉我你是哪个项目的，我不给你用。
这里有个容易踩的坑：这个 “Project” 不是你本地的代码文件夹名，而是 Google Cloud Console 里分配给你的那个全局唯一的 GCP Project ID（长得像 true-gradient-xxx 这样的字符串）。Google 底层的 gRPC 接口需要这个 ID 来定位资源和计算配额，本地软件发请求时这个字段是空的，所以被直接拦了。
修复步骤：
- 登录 Google Cloud Console，找到你的 Project ID
- 打开 Antigravity 软件，找到设置底部的 [Dev] GCP Project ID 字段
- 把真实的 Project ID 填进去
填完之后，Antigravity 发请求时会自动把这个 ID 拼到寻址路径里，400 报错消失，免费的大模型额度正式激活。
3. 最终整合：让 OpenCode 同时调用两家模型
在这之前，我已经通过 GitHub 学生包的优惠，给 OpenCode 接上了 Copilot 的基础大模型额度。现在 Antigravity 也激活了，问题来了：怎么让 OpenCode 同时用上这两家的模型？
答案是一个开源项目：opencode-antigravity-auth。
别被名字骗了，这个插件干的事情远不止”转发 API”那么简单。它其实是一个跑在本地的反向代理 + 协议转换引擎，大致做了三件事：
3.1 拦截请求（进程内劫持）
插件直接在 OpenCode 内部拦截了原生的 fetch() 请求。也就是说，你的请求还没出本机，就被它截住了。
3.2 自动登录（本地 OAuth 闭环）
插件会在本地起一个临时的 HTTP 服务器，自动完成 Google 账号的 OAuth 授权流程，静默拿到 Token。你不需要手动复制粘贴任何密钥。
3.3 协议翻译（格式转换）
这是最核心的部分。标准的 API 请求格式和 Antigravity 后端要求的格式不一样，插件负责：
- 剥掉 Antigravity 不支持的 JSON Schema 字段
- 重新组装思维链（Thinking Blocks）
- 把前面拿到的 Google 凭据附加上去，然后转发给云端
通过这套架构，我的 OpenCode 实现了底层模型的无缝切换——写代码时可以随时在 Copilot 和 Antigravity 的模型之间来回跳，同时享受两家的免费额度。
写在最后
回顾整个过程：从网络层的死循环排查，到云端鉴权的补齐，再到本地 IDE 里的流量劫持和协议重写——每一步都不是玄学，而是对计算机底层机制的理解和验证。
感谢 Gemini 在排错过程中提供的客观分析，帮我避免了大量无意义的盲目试错；也感谢开源社区，特别是 opencode-antigravity-auth 的维护者，提供了协议转换方案，让”在本地同时用多家大模型”这件事真正变成了现实。
