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
这次我没走源码构建,最后直接用的官方预编译镜像
主要也是图省事,网络环境已经够折腾了,能少绕一圈就少绕一圈
最近在折腾
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
这次我没走源码构建,最后直接用的官方预编译镜像
主要也是图省事,网络环境已经够折腾了,能少绕一圈就少绕一圈

