Codex外接Gemini模型实战：反代配置全流程解析

为什么要给Codex外接Gemini模型

如果你同时用过OpenAI的Codex和谷歌的Antigravity（视频作者音译为"反重力"），大概会有一个共同的困惑：两款AI Agent编程工具各有优势，但模型被各自的生态锁死，无法互通。

Antigravity作为谷歌推出的、与Codex平行的AI编程/办公代理工具，内置了Gemini系列模型和Claude Code模型；而Codex则捆绑OpenAI自家的GPT系列模型。视频作者的核心思路很直接：把Antigravity里的Gemini模型"搬"进交互体验更好的Codex，从而在Codex的界面里自由调用两套模型库。

这样做的动机主要有两点：一是Codex的软件交互与控制器体验更顺手；二是额度层面的考量——作者提到自己订阅的20美元Codex套餐额度越来越不够用，而Gemini这边同样价位的额度更充裕，两边打通后单个项目可用的额度显著增加。

成本基础：学生套餐的"白嫖"逻辑

整套方案能成立的前提，是低成本获取Antigravity的模型使用权。作者指出，谷歌每年都有面向学生的套餐，在闲鱼等平台大约花30元就能办到一年的学生资格，相当于以极低成本拿到接近谷歌Pro会员的模型额度。

需要提醒的是，这类第三方渠道办理的学生套餐存在合规与账号安全风险，本文仅作技术方案的客观转述，不构成使用建议。读者若要复现，应自行评估平台政策与账号风险。

在作者的实测中，这套Gemini模型库（从Gemini 3.x到Claude Code）"很能打且性价比很高"，接入后基本等于免费获得了一年的额外模型额度。

核心技术：CLIProxyAPI反向代理

这套方案的技术核心，是一个GitHub上拥有约5.1万星标的开源项目——作者称之为"CLIProxyAPI"（音译，实际项目名以其提及的Gemini/Codex/Claude统一授权转换工具为准）。它的作用是统一转换Gemini、Codex、Claude的CLI授权，并支持流式工具调用。

作者坦言，最初他考虑过CC Switch这个成熟的开源切换框架，但觉得它"有点重"，于是转而寻找更轻量的反代方案。经过与AI的多轮探索式对话，最终敲定了这个代理项目作为技术底座。

从请求流向看，方案存在两条线路：

• 官方直连线路：走OpenAI后端的官方API，调用Codex原装模型。
• 外接代理线路：走本地代理，通过CLI代理服务对接谷歌Antigravity的Gemini模型。

作者特别说明，官方线路理论上也能做反向代理，但他没有那么做，认为绕圈子没必要。这套架构还可以进一步扩展——外接代理不限于Gemini，理论上可以混合接入更多第三方API。

反向代理（Reverse Proxy）在这里的作用值得简单说明。通常我们说的"代理"是客户端代理，帮用户访问外部服务；而反向代理则架在服务端一侧，接收客户端请求后转发给真正的后端服务，对调用方来说看起来像一个统一的入口。在这个方案里，CLIProxyAPI在本地启动一个监听端口，对外伪装成兼容OpenAI接口格式的服务端，Codex发来的API请求被它接收后，自动完成格式转换，再转发给谷歌Antigravity的Gemini后端。这样Codex不需要原生支持Gemini的鉴权协议，只要"以为"自己在跟一个标准OpenAI兼容接口通信即可。这类"OpenAI兼容层"是当前多模型生态整合中最常见的技术手段，LM Studio、Ollama等本地模型工具也采用相同思路。

让Agent自己配置自己

整个配置过程最有意思的一点，是作者反复强调的方法论：不要自己动手，让Agent配置它自己。

具体做法是，直接把上述开源项目的关键词和需求，用大白话丢给Codex，让它自行完成安装、对接和配置。中途唯一需要人工介入的，是Antigravity的授权环节——当配置脚本触发授权时，跳转到已登录Antigravity的浏览器窗口点一下授权即可。

这种"让AI工具配置AI工具"的思路，某种程度上降低了普通用户的操作门槛。用户不需要理解每一步的技术细节，只需提供正确的技术方案关键词，剩下的交给Agent推进。

这种"让AI配置AI"的方式本质上是把Agent当作有上下文理解能力的脚本执行器来使用。用户提供的"关键词"相当于高层级的任务描述，Agent自行查阅相关文档、推断依赖关系、生成并执行安装命令。与传统的手动照着教程操作相比，这种方式的优势在于容错——Agent可以在命令报错后自行尝试修复，而不是让用户去排查错误信息。局限则在于，Agent的推断依赖训练数据中的项目信息，若开源项目近期有重大接口变更，Agent给出的配置步骤可能已经过时，仍需人工核验关键步骤的准确性。

模型切换脚本：Codex Switch

配置完成后，作者遇到一个实际问题：模型接进来了，但没有便捷的切回官方模型的方式。这源于Codex本身的加载机制——它每次启动时会通过配置文件加载一次模型列表，运行中无法原生混合两套模型。

作者解释，Codex下拉菜单之所以无法原生混合两套模型，主要是跨服务商冲突：GPT模型走本地反代会报错。因此需要一个切换机制来回避这个限制。

解决办法同样交给了Codex——让它编写一个名为"Codex Switch"的切换脚本。脚本原理非常简单：你有几个模型或几种转换需求，就做几个对应的切换命令。

使用时，在终端输入Codex Switch即可查看可用命令，例如切换到官方模型或切换到Gemini模型。切换后有一个关键动作：必须重启Codex，否则它无法重新加载模型列表。重启后进入，模型列表就会更新为对应的模型集合。

作者建议，这些切换命令不必记忆，复制粘贴即可，并且最好把整个配置过程沉淀成一份文档指南——包括安装、切换脚本，以及一份卸载复原说明，方便日后清理或迁移。

方案价值与实用提醒

经过作者实测，这套方案运行稳定，实现了最初设想：在Codex体验良好的界面里，既能用原装模型，又能外接一套低成本的Gemini/Claude Code模型库，在单个项目里获得更充裕的可用额度。

从技术角度看，这个案例的启发意义大于操作本身——它展示了如何用开源反代工具打通不同厂商的AI Agent生态，以及"让Agent自我配置"这种降低门槛的实践思路。

不过也需客观看待几点局限：其一，方案依赖第三方渠道的学生套餐，合规性与账号安全存在不确定性；其二，跨服务商反代可能随官方策略调整而失效；其三，视频中的项目名称多为音译，读者复现时需核对准确的开源项目与配置细节。整体而言，这是一个有参考价值、但需谨慎评估风险的进阶折腾方案。