Gui.Ge 魔鬼在人间
2026年4月23日 学习心得

AIClient-2-API 教程：把 Gemini CLI、Codex、Grok 等客户端模型统一转成 OpenAI 接口

鬼哥
AIClient-2-API Web UI 截图

如果你最近想把 Gemini CLI、Codex、Grok、Kiro 这类原本更偏客户端内部调用的大模型能力，统一转成可以被常见工具直接调用的 OpenAI 兼容接口，那 AIClient-2-API 就很值得认真部署一次。

这篇文章不再只停留在项目介绍，而是更偏“怎么把它跑起来、怎么用 Web UI 配好、怎么绕过部署中最容易踩坑的地方”。

AIClient-2-API Web UI 控制台截图
项目自带 Web UI 控制台，部署成功后很多配置都可以在界面里完成。

AIClient-2-API 到底适合什么场景

简单说，它适合已经进入“多模型、多工具、多账号”阶段的人。你不是只想在某个客户端里随便试一试，而是希望把这些原本分散在 Gemini CLI、Codex、Grok、Kiro 等入口里的能力，收拢成一个标准接口，统一给 Cherry-Studio、NextChat、Cline 或你自己的系统去调用。

如果你的目标只是偶尔本地玩玩模型，这个项目会显得有点重；但如果你已经在意统一接入、账号池、故障切换和长期稳定性，那它就不是“能不能跑”的问题，而是“值不值得做成服务层”的问题。

部署前先理解一件事

AIClient-2-API 的核心不是再做一个聊天页面，而是做一个 协议和提供商统一层。它把多种客户端能力统一成 OpenAI 兼容接口，再通过 Web UI、授权文件、账号池和日志能力让你真正把它当成一个服务去用。

所以部署时最重要的不是某个模型名字，而是这四件事：

  • 端口怎么映射
  • 配置目录怎么挂载
  • 授权文件放哪里
  • 后面怎么在 Web UI 里继续接入不同提供商

最推荐的部署方式：Docker 直接起

如果你只想尽快把系统跑起来，最省事的还是直接用 Docker。原因很简单：这个项目既涉及 Web UI 端口，也涉及多个 OAuth 回调端口，后面还会挂配置目录。容器化能把很多环境差异提前消掉。

docker run -d 
  -p 3000:3000 
  -p 8085-8086:8085-8086 
  -p 1455:1455 
  -p 19876-19880:19876-19880 
  --restart=always 
  -v "/你的本地目录:/app/configs" 
  --name aiclient2api 
  justlikemaki/aiclient-2-api

这个命令里最关键的几项你只要记住：

  • 3000 是 Web UI 端口。
  • 8085-8086、1455、19876-19880 这些是不同提供商的 OAuth / 回调端口。
  • /app/configs 是配置和授权文件的核心目录，后期也主要围绕它来管理。

如果你习惯 Docker Compose

README 里也给了更适合长期维护的 Compose 路径。如果你打算长期跑、以后还要加自己的反代、备份和运维动作，那 Compose 往往更舒服。

cd docker
mkdir -p configs
docker compose up -d

如果你不想用预构建镜像，而是想从源码自己构建，那么 README 的建议也很明确：

  1. 注释掉 image: justlikemaki/aiclient-2-api:latest
  2. 取消 build: 的注释
  3. 执行 docker compose up -d --build

这一步适合那些准备自己改代码、二开，或者对镜像来源和构建过程特别敏感的人。

启动后第一件事：先进 Web UI，不要先硬改文件

很多人部署完第一反应是去找配置文件，其实更高效的顺序是：先把服务拉起来，先访问 Web UI，再开始做配置。因为这个项目的控制台已经能直接处理很多平时必须手改文件的动作。

默认访问地址就是：

http://localhost:3000

README 里给的默认密码是：

admin123

这意味着什么？意味着你可以先登录进去，再决定下一步是填 API Key、上传 OAuth 凭据文件、切默认提供商，还是先看健康状态。对第一次部署的人来说，这个顺序比一上来手动摸配置目录更稳。

Web UI 里优先看哪几块

如果你是第一次上手，不用把每个菜单都点一遍。更实用的顺序是：

  1. 配置管理：先把你要接的提供商和基本参数填进去。
  2. 提供商池：看当前活跃连接和健康状态。
  3. 配置文件：确认 OAuth 凭据、API Key 和文件都在预期位置。
  4. 实时日志：一旦请求失败，这里最先给你答案。

说白了，这个控制台最值钱的地方不是“界面好看”，而是它把部署、授权和排错这三件事串起来了。

授权配置是部署里最容易卡人的地方

从项目说明看，不同提供商的授权方式并不一样，这也是为什么很多人会觉得这种代理项目“听起来很强，实际很乱”。AIClient-2-API 的好处，是把这些差异往统一目录和统一控制台里收。

但你在部署时还是要有心理预期：

  • Gemini CLI 走 Gemini CLI OAuth 配置
  • Codex 走 Codex OAuth 配置
  • Grok 走 Cookie / SSO 路线
  • Kiro 也有自己的配置方式

所以真正的部署重点并不是“有没有按钮”，而是你要先想清楚自己准备接哪几类模型，然后按项目文档逐项把授权走通。一个都没走通时，不要急着怀疑服务层本身，先看是不是授权路径没跑完。

本地运行用户要特别注意：TLS Sidecar

如果你不是走 Docker，而是直接在本地 Node.js 环境里跑，并且你又打算接 Grok 这类对 TLS / 指纹更敏感的服务，那么 README 里特别提醒的一点必须记住：要准备 Go 环境并编译 TLS Sidecar。

cd tls-sidecar
go build -o tls-sidecar
cd ..

这一步如果没做，很多人会误以为“服务能跑，为什么请求还是不通”。实际上不是服务层挂了，而是你缺了这一块 TLS 代理能力，某些目标服务不会正常放行。

账号池和故障转移，什么时候值得开

如果你只是单账号、单模型、本地自己试，那账号池管理暂时没那么急。但只要你开始让多个客户端一起接，或者你已经打算把这层代理长期跑着，账号池和健康检查的意义就会迅速上升。

项目说明里已经把这个方向讲得很明确：支持多账号轮询、自动故障转移和配置降级。对实际部署者来说，这等于是在告诉你：这个项目不是只适合“能跑一次”的演示，而是开始往“能长期扛请求”的方向走。

我建议的上手顺序

  1. 先选 Docker 或 Compose，把 Web UI 跑起来。
  2. 先别贪多，只接一个你最想用的提供商。
  3. 授权走通后，先在控制台里验证健康状态和日志。
  4. 再把第二个、第三个模型入口逐步接进来。
  5. 确认稳定后，再考虑账号池和更复杂的路由策略。

这个顺序的核心思想是：不要一开始就把所有能力都堆上去。越是这种支持多协议、多模型、多账号的项目，越要先小步跑通，再慢慢扩。

最值得收藏的几个链接

最后的判断

如果你已经在意多模型统一入口、客户端兼容、账号池、健康检查和长期可维护性，那么 AIClient-2-API 就不是一个“玩具中转项目”，而是一层很值得认真部署的基础设施。它最适合的，不是纯粹围观的人，而是已经开始真的把多个模型塞进工作流的人。