# 起因:额度都锁在客户端里
现在手里能用的 AI 额度,一多半是跟着客户端走的:某个 IDE 送的、某个 CLI 登录后才有的、某个网页版账号每天签到的。这些额度要么只能在它自家的客户端里点,要么协议各说各话 ——OpenAI 的 Chat Completions、Responses,Anthropic 的 Messages,还有一堆只有自家才认的私有接口。
想把这些额度接进 Cherry Studio、Open WebUI、LobeChat,或者接进自己的脚本里跑点自动化,就得有个东西站在中间,把客户端的登录态接过来,翻译成标准的 OpenAI 兼容接口。这就是所谓「AI 反代」。
试过几个之后,这段时间一直在用的是 Agent2API( aimod-cc/agent2api ),记录一下。
# 项目基本情况
- 仓库:https://github.com/aimod-cc/agent2api
- 定位:本地 AI 路由网关 + Agent 客户端接管
- 协议:AGPL-3.0
- 形态:桌面端(Windows /macOS/ Linux)、无头服务器(Windows Server / Linux)、Docker(amd64 /arm64)
- 默认端口:3065,同一个端口既是管理面板也是 OpenAI 兼容网关
一句话概括它的思路:复用各家客户端的登录态,用一个 base_url 调 50 多家模型额度,统一 OpenAI / Anthropic / 生图接口,多账号选路、签到、余额和请求报表全在一个面板里。
# 功能介绍
1. 统一模型接口
同时提供 OpenAI 的 Chat Completions、Responses、Images 和 Anthropic 的 Messages 接口,模型目录统一管理。也就是说 Cherry Studio 这种只认 OpenAI 的客户端,和 Claude Code 这种只认 Anthropic 的,可以共用同一个网关、同一个 key。生图和参考图编辑也在里面(小浣熊、Loomy、Antigravity、ModelScope、WorkBuddy、豆包工作台这些来源)。
2. AI 路由
模型映射、账号优先级、负载均衡、会话粘性和故障切换放在一处配。实际用起来最舒服的是「会话粘性」—— 同一轮对话固定走同一个账号,缓存命中率会好看很多。
3. Agent 客户端接管
这个是我觉得最省事的部分。它不只是给你一个 URL,还能管理本地客户端的多套连接配置:一键导入现有设置、预览将要写入的内容、在「走网关」和「走官方」之间切换。改完即时生效,不用手工去翻各个客户端的 json 配置文件。
4. Provider 插件化
50 多家 provider 不是全塞在主程序里,而是按插件独立安装、独立更新。主程序升级不会把 provider 的实现冲掉;自定义 provider 则不需要装插件。
5. 出口代理
可以给每个账号单独选代理池出口。多账号场景下这点很关键 —— 同一个 IP 上挂一堆账号,风控基本躲不过。作者还和 ProxyLane 有合作,用优惠码 AGENT2API25 首购 25% off(这个按需,不是必须)。
6. 网关安全
网关 key 支持作用域划分;面板登录可以开人机验证;没配 key 的时候模型请求默认直接拒绝,不会出现部署完就裸奔的情况。
7. 请求报表
请求量、成功率、token 消耗、缓存命中率,还有账号和 provider 的排行、用量环形图、365 天活跃热力图。趋势页是双轴的:24 小时缓存命中率折线 + token 消耗面积图。排查「到底是谁在烧额度」比翻日志快多了。
8. 后台维护
模型目录定时刷新、凭证维护、更新检查,外加每日自动签到 —— 按 provider 各自的时间窗跑(Qoder 10:01,ZCode 19:01,其它按设定时间),之后还有一轮补签,只补没签到的账号。
9. 手机端
浏览器打开 http://<网关IP>:3065/m 就是移动端面板,可以「添加到主屏幕」当 PWA 用;也有独立的 apk /ipa(iOS 那个未签名,要自己签)。
# 适合什么场景
- 把 IDE / CLI 送的额度接进 Cherry Studio、Open WebUI、LobeChat、new-api 之类的地方统一用
- 多账号轮着用,顺手看余额、签到、用量统计
- 给自己的脚本、机器人、内部小工具提供一个稳定的统一入口
反过来,如果只是想把几个正规的 API key 聚合成一个入口做分发,那 one-api /new-api 更合适,不需要 Agent2API 这套「接管客户端」的机制。
# 如何下载
Release 页面:https://github.com/aimod-cc/agent2api/releases
按用途挑一个就行:
1 | # 桌面端 |
桌面端的用法:添加自定义 provider 和账号 → 建一个网关 key → 到 Agent 页面应用连接配置,或者直接把客户端指向 http://127.0.0.1:3065/v1 并填上 key。
服务器版的安装:
1 | # Linux |
1 | # Windows Server(管理员 PowerShell) |
# Docker 安装
方式一:一条命令跑起来
1 | docker run -d --name agent2api --restart unless-stopped -p 3065:3065 -v ./data:/data aimodcc/agent2api:latest |
注意 ./data 建议换成绝对路径,比如 -v /opt/agent2api/data:/data ,不然换个目录执行 compose/run 就找不到原来的数据了。ARM 的机器(群晖、树莓派、ARM 云主机)直接拉就行,镜像本身就是多架构的。
方式二:docker compose(推荐)
1 | services: |
1 | docker compose up -d |
方式三:面板和网关分端口(想把面板留在内网)
设了 AGENT2API_PANEL_PORT 之后,管理面(界面 + /api/* )单独监听那个端口,主端口只剩 /v1/* 网关。这时候只把网关暴露到公网,面板绑回环:
1 | environment: |
验证部署
1 | # 连通性检查 |
返回正常就打开面板 http://<主机IP>:3065/ ,首次打开会提示注册管理员账号(如果 compose 里预置了账号密码,启动时会自动转成 bcrypt 哈希入库,直接登录即可)。
首次配置流程
- 面板里添加 provider,选版本后网页登录授权(登录态就存在本地库里了)
- 到「网关 Key」页创建一个 key,按需要划作用域
- 客户端填
base_url = http://<主机IP>:3065/v1,key 用上一步建的 - 模型名在「模型管理」页的目录里选,填对应的映射名
验证一下能不能通:
1 | curl http://127.0.0.1:3065/v1/chat/completions \ |
升级与备份
1 | # 标准升级:拉新镜像重建容器 |
1 | # 备份 = 打包 data 卷 |
面板里的「软件更新」替换的是容器内的文件,compose 里的镜像 tag 没变,所以下次 up -d 重建容器会退回旧版本。要么就用 docker compose pull 升级,要么就别开自更新。
# 几个实际踩到的点
- 端口冲突:3065 不算冷门,装之前先
ss -lntp | grep 3065看一眼。 - 账号要配出口:不配代理直接跑,多账号很容易触发风控。账号页里一个账号一个出口,别图省事共用。
- 别公网裸奔:面板默认就在 3065 上,公网暴露的话至少开人机验证、给 key 划作用域;能绑内网就绑内网。
./data里是敏感数据:SQLite 库里存着加密后的账号凭证,导出和备份文件可能是明文级别的东西,别往 Git、网盘、群聊里丢。- 出问题先看日志:
docker compose logs -f agent2api基本能定位到是鉴权、供应商还是网络的问题。 - 模型名对不上:客户端里报 model not found,多半是模型目录里的名字和映射没对上,回「模型管理」页看一眼实际可用列表。
# 使用须知
- 项目是 AGPL-3.0,商用、修改、分发都允许,但对外提供网络服务时要按要求提供对应源码。
- 凭证虽然在库里加密,但导出、备份、key 文件仍可能含敏感信息。
- 复用客户端登录态这件事,各家服务条款的态度并不一致,仅建议个人研究自用,别拿去对外卖 token 做中转站,封号风险自担。
- 项目本身 as-is 提供,不担保可用性、稳定性和安全性。
# 小结
Agent2API 属于那种「装上就一直在后台待着」的工具:平时想不起来它,但每次要换客户端、要加账号、要看这个月谁烧了多少额度,都会去面板点两下。对于手里额度散落在十几个客户端里的人,省下来的配置时间比它占的那点内存值多了。
如果只是想聚合几个正规 API key,one-api /new-api 更轻;如果要接管客户端登录态、还要多账号调度和报表,那这个目前是我用过最顺手的。