CLIProxyAPI 管理 AI 账号，顺便给 OpenClaw 接了个统一入口

问题描述：

最近在折腾 CLIProxyAPI
一开始主要是想把手头几个 AI 账号收口一下，别散在不同客户端里
后面顺手把 OpenClaw 也接了进去，结果发现这样用起来还挺顺
就把过程和踩过的坑记了下来

我这次主要做了两件事：

• Codex Team 账号接进 OpenClaw
• OAuth 账号收口成一个本地 OpenAI 兼容接口

这样上层工具直接走标准 API 就行，账号和认证也不用散在不同客户端里
后面如果还要接别的模型或者别的工具，也能继续共用这一层

所以最后的链路大概就是这样：

• 底层是 Codex Team / OAuth 账号
• 中间是 CLIProxyAPI
• 上层是 OpenClaw

如果只看结果，大概就是这样：
openclaw_flowchart900×620 20.8 KB

我自己现在觉得，这种接法最大的好处就是上层会干净很多
OpenClaw 不需要知道 OAuth 那堆细节，只要认一个本地 OpenAI 兼容接口就行
后面要换模型、换账号、加账号，也都在代理层处理

我这边实际环境比较简单：

• Windows 11
• Docker Desktop 29.2.1
• 工作目录放在 C:\Users\Lenovo\.cli-proxy-api\

前置条件也没什么特别的：

• Docker Desktop 能正常启动
• 手里有能登录的 AI 账号
• 我这里用的是 OpenAI Codex Team

这次我没走源码构建，最后直接用的官方预编译镜像
主要也是图省事，网络环境已经够折腾了，能少绕一圈就少绕一圈

先把目录准备好

mkdir -p /c/Users/Lenovo/.cli-proxy-api/{auths,logs}

最后目录大概长这样：

C:\Users\Lenovo\.cli-proxy-api\ ├── docker-compose.yml ├── config.yaml ├── auths\ │ └── codex-你的账号标识-team.json └── logs\

config.yaml 我这边是这么写的：

host: "" port: 8317 remote-management: allow-remote: true secret-key: "这里填你自己的管理密码" auth-dir: "~/.cli-proxy-api" api-keys: - "这里填你自己的 API key" debug: true usage-statistics-enabled: true

这里几个关键项其实不复杂：

• port: 8317 是本地代理监听端口
• secret-key 是管理面板登录密码
• api-keys 是给 OpenClaw 这类上层客户端调用的 key
• auth-dir 是 OAuth 认证信息保存目录

我本地实际测试时填的是自己的真实值
发帖这里就不原样贴了，没必要给自己加风险

compose 文件长这样：

services: cli-proxy-api: image: eceasy/cli-proxy-api:latest container_name: cli-proxy-api environment: DEPLOY: ${DEPLOY:-} ports: - "8317:8317" volumes: - ./config.yaml:/CLIProxyAPI/config.yaml - ./auths:/root/.cli-proxy-api - ./logs:/CLIProxyAPI/logs restart: unless-stopped

这里先提前说一个我后面踩到的坑
config.yaml 挂载路径一定要是：

./config.yaml:/CLIProxyAPI/config.yaml

不是 /app/config.yaml
这个问题我后面卡了挺久，一开始还以为是别的地方写错了

服务先跑起来

docker pull eceasy/cli-proxy-api:latest cd /c/Users/Lenovo/.cli-proxy-api docker-compose up -d

看日志：

docker-compose logs -f

先测一下服务是不是活了：

curl http://localhost:8317/

正常的话会返回类似：

{"endpoints":["POST /v1/chat/completions","POST /v1/completions","GET /v1/models"],"message":"CLI Proxy API Server"}

到这里基本说明服务已经起来了

image1360×760 52.3 KB

然后把 Codex Team 接进去

服务起来以后，我是直接走管理面板加的

地址就是：

http://localhost:8317/management.html

进去之后输管理密码，然后走 OAuth 登录，把 OpenAI Codex Team 接进去
认证成功以后，文件会自动落到 auths/ 目录下面
里面会有一份 codex 的认证文件，包含 token、账号标识、过期时间这些信息

image1920×966 79.5 KB
image1920×968 91 KB

然后我会先测一下模型列表：

curl -s http://localhost:8317/v1/models \ -H "Authorization: Bearer 这里填你自己的 API key"

如果返回正常，能看到类似这些模型：

• gpt-5.4
• gpt-5.3-codex

那说明代理这层已经把 Codex Team 识别到了

image1464×371 39.8 KB

OpenClaw 这边怎么指过去

我这边改的是：

C:\Users\Lenovo\.openclaw\openclaw.json

在 models.providers 里加一个新的 provider，指向本地的 CLIProxyAPI：

"custom-cliproxy": { "baseUrl": "http://localhost:8317/v1", "apiKey": "这里填你自己的 API key", "api": "openai-completions", "models": [ { "id": "gpt-5.4", "name": "GPT-5.4 (CLIProxy)", "reasoning": false, "input": ["text", "image"], "cost": { "input": 0, "output": 0 }, "contextWindow": 200000, "maxTokens": 32000 }, { "id": "gpt-5.3-codex", "name": "GPT-5.3 Codex (CLIProxy)", "reasoning": false, "input": ["text", "image"], "cost": { "input": 0, "output": 0 }, "contextWindow": 200000, "maxTokens": 32000 } ] }

别忘了 agents.defaults 里把主模型切到 custom-cliproxy/gpt-5.4

"agents": { "defaults": { "model": { "primary": "custom-cliproxy/gpt-5.4", "fallbacks": [] } } }

改完以后重启 OpenClaw
这一步做完，模型列表里就能看到 GPT-5.4 (CLIProxy) 和 GPT-5.3 Codex (CLIProxy)
到这里整条链路就串起来了

image1483×315 15.3 KB

我踩过的几个坑也顺手记一下

先是 Docker 镜像源挂了，这个是最先让我怀疑人生的，报错大概就是：

502 Bad Gateway

不是 compose 写错，也不是镜像名错了，单纯是镜像源不行
一开始我还以为是自己哪一步写错了，结果折腾半天才发现根本不是自己的锅

我最后就是换掉失效镜像源，直接走官方源或者别的可用源

然后是容器内路径写错，这个坑很典型，我一开始写成了：

./config.yaml:/app/config.yaml

结果日志直接报：

failed to load config: open /CLIProxyAPI/config.yaml: no such file or directory

到这里才反应过来，官方镜像预期的路径根本不是 /app/，而是：

./config.yaml:/CLIProxyAPI/config.yaml

说白了就是路径挂错了
不是没挂进去，是挂到了错误的位置

还有一个很容易踩的地方是 compose 改完以后，restart 不生效

我一开始改完 docker-compose.yml，顺手就跑了：

docker-compose restart

结果发现配置没生效
后面才反应过来，我改的是 volumes 挂载，这种情况 restart 不会按你想象的重新创建容器

最后正确姿势是：

docker-compose down docker-compose up -d

另外还有一次是 Docker Desktop 根本没启动

报错是：

failed to connect to the docker API at npipe:////./pipe/dockerDesktopLinuxEngine

这个就更直接了
不是配置错，也不是服务炸了，而是 Docker Desktop 根本没起来

Windows 下跑 Docker，有时候先别急着改文件，先看看右下角那个鲸鱼是不是活着

网友解答：

---

--【壹】--：

感谢大佬教程

---

--【贰】--：

感谢大佬的教程,虽然没看明白

---

--【叁】--：

感谢佬，已经一步步按照你的教程用上了，很方便

---

--【肆】--：

同款，交给k2.5实现口喷运维

---

--【伍】--：

我也统一了入口，但是我用的new-api，我把cliproxyapi接到了new-api后面。

---

--【陆】--：

感谢大佬教程

---

--【柒】--：

感谢，写的很详细

---

--【捌】--：

不错，很详细的教程