我搭了一个 AI API 聚合平台，最后决定停下来

项目信息

项目：自建 AI API 聚合网关

状态：部分可用，停止继续开发

搭建时间：2026 年 8 月

技术组成：New API、Docker、Nginx、Cloudflare、acme.sh、1Panel、CC Switch

项目性质：个人自托管实验，未部署成公开商业服务

本文作者：Henry

最初的想法很简单：把常用的几个模型服务接进一个统一的 API 地址。

DeepSeek 用一套 Key，小米 MiMo 用另一套 Key，以后可能还会有其他模型。每个客户端都要单独配置供应商、地址和模型名，一旦想换模型，就要在 Codex、Chatbox、Cherry Studio 之间分别修改。

我不喜欢这种重复劳动。

所以我想要一个自己的网关：只维护一个地址、一套令牌，就能把不同模型分发给不同客户端。

它看起来像一个很标准的自托管项目。真正做下去之后，我才发现，问题根本不在“把几个 API Key 填进后台”，而在协议、工具调用、客户端兼容性和长期维护。

最后，这个项目没有完全烂掉，但也没有完成。

我想解决的不是“调用模型”

如果只是偶尔调用一次 API，官方的 OpenAI 兼容地址已经足够。

我遇到的问题更像是“入口分裂”：

Codex 使用 Responses 协议，并且会发送自己的工具定义；
聊天客户端大多只使用 Chat Completions；
不同模型的 reasoning 字段、工具调用格式和上下文限制并不完全一样；
同一套配置在 A 客户端能用，换到 B 客户端就可能报错。

我真正想要的是中间那一层：

Codex / Chatbox / Cherry Studio / 其他客户端
                    │
                    │ OpenAI-compatible API
                    ▼
              自建 API 网关
                ├── DeepSeek 官方
                ├── 小米 MiMo
                └── 以后可能接入的其他模型

理想状态下，客户端只认识网关，网关负责认证、路由、模型映射和计费记录。模型服务怎么变，客户端都不需要知道。

这也是 New API 这类项目吸引我的地方。

为什么选择 New API

市面上当然有现成的聚合服务。OpenRouter、七牛云 AI、硅基流动都提供了统一入口，也支持不少模型。

但对个人折腾来说，自建有几个直接的好处：

请求不经过第三方聚合商；
模型渠道和 Key 完全由自己控制；
可以自己设置令牌、额度、渠道权重和模型映射；
以后想接入新的上游，只需要在后台加一个渠道；
它本身是开源的，出了问题至少能看代码、查日志。

New API 提供了 OpenAI、Claude、Gemini 等格式的兼容能力，也有现成的 Docker 镜像和管理后台。对于“个人使用、少量渠道、希望能自己掌控”这个场景，它比从零写一个网关现实得多。

于是我在自己的服务器上跑起了 New API，用 Docker 托管，前面放 Nginx，外面套 Cloudflare，证书用 acme.sh 自动续期。

服务器侧的结构大概是：

Cloudflare
    │ HTTPS
    ▼
Nginx :8443
    │
    ▼
New API :3000
    ├── DeepSeek 官方
    └── 小米 MiMo

为了不影响服务器上已有的项目，我单独使用了新的子域名，并且只增加对应的 Nginx 配置和证书。数据库、管理后台和调用令牌都放在服务器本地。

到这一步为止，一切都还算顺利。

已经跑通的部分

这个项目并不是完全没有成果。

1. 统一的 OpenAI 兼容入口

网关起来以后，普通聊天客户端只需要填写：

Base URL
API Key
模型 ID

就能像调用 OpenAI 一样调用后面的 DeepSeek 或小米模型。

DeepSeek 渠道是最稳定的一个。deepseek-v4-flash、deepseek-v4-pro 这些模型通过网关的 /v1/responses 接口完成了多轮对话和推理测试，返回结果正常。

2. 浏览器管理后台

New API 自带的管理后台可以查看渠道、模型、令牌和调用情况。对一个自托管项目来说，这比手写 YAML 再重启服务舒服很多。

3. 可以复用的部署结构

Nginx 负责反向代理，Cloudflare 负责公网入口，acme.sh 负责证书续期，Docker 负责运行网关。

这套结构本身是成立的。即使后来停止继续开发，它仍然可以作为一个可用的单模型入口。

4. 可回滚的客户端配置

为了避免把 Codex 的配置改坏，我另外准备了两个脚本：

一个把 Codex 切换到自建网关；
一个恢复为 DeepSeek 官方直连。

切换前自动备份 config.toml，出问题可以直接回滚。这是整个项目里我最满意的部分之一：它没有解决所有问题，但至少没有把原本可用的环境弄坏。

真正让我停下来的是协议

如果用一句话总结这次失败，大概是：

把 API 地址聚合起来很容易，把不同客户端的协议语义聚合起来很难。

Responses 不是 Chat Completions 的另一个名字

很多聊天客户端使用的是 Chat Completions：

POST /v1/chat/completions

但 Codex 使用的是 Responses：

POST /v1/responses

两者看起来都是“给模型发消息”，实际上请求结构、流式事件、工具调用和 reasoning 字段并不一样。

网关需要把 Codex 发出的 Responses 请求翻译成上游能理解的格式，再把上游结果翻译回来。翻译层只要漏掉一个字段，客户端就可能直接报错。

我最初还保留着 CC Switch，希望由它负责一部分本地代理和模型切换。后来发现，CC Switch 和 New API 实际上都在做转换。两层转换叠在一起，路径变成：

Codex
  │ Responses
  ▼
CC Switch
  │ Chat Completions
  ▼
New API
  │ 再转发
  ▼
上游模型

问题也出在这里：中间层没有完整保留 reasoning 相关内容，多轮请求最终变成 400。

去掉 CC Switch、让 Codex 直接连接 New API 之后，DeepSeek 的链路才重新稳定下来。

这让我第一次意识到：转换层不是越多越好。每多一层，就多一个可能丢字段、改语义、制造兼容性债务的地方。

小米 MiMo 的限制

小米 MiMo 在普通聊天客户端里是能用的。

它支持常规的 function 工具，走 Chat Completions 没有问题。但 Codex 会发送 custom 类型的工具，例如 shell、apply_patch 和 web_search。MiMo 在当时的网关阶段不接受这些工具类型。

我甚至用小米官方提供的接入方式做过对照测试，结果仍然报同样的错误。这说明问题不在 New API 的配置，而在上游接口本身的支持范围。

所以最终的状态是：

DeepSeek 可以在 Codex 中使用；
小米 MiMo 可以在普通聊天客户端中使用；
小米 MiMo 不能在 Codex 中作为完整的编码 Agent 使用。

这不是换个模型名或者改一个 Base URL 能解决的。

还有一类很小、但很消耗耐心的问题

除了协议，部署过程里还有大量“不复杂，但很烦”的事情。

DNS 和 Cloudflare Origin Rule

服务器所在网络对 80/443 端口不友好，公网入口需要通过 Cloudflare 的橙云代理，再用 Origin Rule 转发到源站端口。

API 子域名曾经出现过一种很奇怪的状况：记录在 Cloudflare API 里存在，边缘代理也能访问，但权威 DNS 一直返回 NXDOMAIN。换记录、换解析方式都没有彻底解决，最后只能换一个新的子域名重新来一遍。

这类问题不会出现在项目介绍里，却会占据真实开发时间的大部分。

模型目录和显示名称

CC Switch 曾经把模型列表显示成一串完全不相干的内部名称。排查后发现不是模型坏了，而是缺少对应的模型目录，客户端回退到了内置的模型元数据。

这类问题也让我意识到：一个“能发请求”的网关，不等于一个“用户能正确理解和操作”的产品。

维护成本

New API 本身是成熟的，但自建网关意味着下面这些东西都归我维护：

Docker 容器和数据库；
Nginx 配置；
Cloudflare DNS 和规则；
证书续期；
上游渠道变更；
模型目录；
客户端配置；
出问题时的日志排查。

只为两三个模型做这些，投入和收益并不成正比。

我为什么没有继续

项目停下来，不是因为某一行代码写不出来，而是因为我重新算了一次收益。

如果我只需要 DeepSeek，那么官方直连最稳定，少一层代理、少一个容器、少一套证书。

如果我需要很多模型，商业聚合平台已经解决了大部分兼容性问题，付费买到的其实是“别人替你维护转换层”。

而我自己搭网关，最合适的场景应该是：

有多个项目共享模型额度；
需要内部计费或权限隔离；
对数据路径有明确要求；
愿意长期维护服务器和上游兼容性。

我当前的使用规模还没有到那个程度。

继续做下去当然也有方案：可以给 New API 打补丁，把 Codex 发出的 custom 工具改写成 function，或者自己维护一个专门的转换服务。但这需要构建自定义镜像，并且每次上游变化都要跟着修。

我判断这笔维护成本不值得。

于是最后的选择是：

Codex 继续使用 DeepSeek；
小米留给普通聊天客户端；
网关保留，作为一个可用的 DeepSeek 入口；
多模型统一接入暂时停止。

这不是一个漂亮的结局，但比为了“完成一个项目”而长期维护一堆不会每天使用的基础设施更合理。

这次失败留下的东西

虽然项目没有完成，但它留下了几个很具体的经验。

1. API 兼容不等于行为兼容

所有平台都说自己兼容 OpenAI，但 Responses、Chat Completions、工具调用、reasoning、流式事件之间仍然有大量细节差异。

真正的兼容性，不是“能返回 200”，而是“客户端的多轮任务能完整跑完”。

2. 不要为了统一入口而堆转换层

每多一层代理，就多一份字段丢失和语义变化的风险。

如果某个客户端已经能直接连接上游，就不要再为了“统一管理”强行把它塞进另一个转换层。

3. 先验证最难的场景

这个项目里，最容易验证的是普通聊天，最难验证的是 Codex 的工具调用。

应该先拿最难的场景做 PoC。如果 Codex 这条链路一开始就走不通，后面那些漂亮的部署结构就没有意义。

4. 自建不等于更便宜

开源软件没有 license 费用，但服务器、时间、证书、监控、故障排查都是成本。

如果只是想省 API 费用，自建网关通常不是答案。

现在的状态

这个项目没有完全删除。

服务器上仍然保留着可运行的网关、DeepSeek 渠道和调用令牌；Codex 的切换脚本、回滚脚本和配置样例也还在。以后如果真的有多个项目需要共享模型额度，它可以重新被捡起来。

但它不再是我日常使用 AI 的必经入口。

我最终接受了一个更简单的结构：

Codex ───────── DeepSeek
Chat 客户端 ─── 小米 / 其他模型

不是所有东西都需要被统一。

有时候，停止维护一个“看起来应该做下去”的项目，比继续往上叠功能更接近正确的工程决策。

开源项目与第三方组件声明

这个项目使用了以下开源软件或第三方服务。相关名称、代码和商标归各自作者与项目所有。

New API

项目：New API
维护者：QuantumNous 及贡献者
仓库：github.com/QuantumNous/new-api
许可证：GNU Affero General Public License v3.0
用途：作为自建 API 网关，负责渠道管理、令牌管理和协议兼容。
说明：本项目通过 Docker 使用 New API，没有修改其源码，也不代表 New API 官方。

One API

项目：One API
作者：songquanpeng 及贡献者
仓库：github.com/songquanpeng/one-api
许可证：MIT License
说明：One API 是同类 LLM API 管理项目，也是 New API 的设计来源之一。本项目没有直接部署 One API。

CC Switch

项目：CC Switch
作者：farion1231 及贡献者
仓库：github.com/farion1231/cc-switch
许可证：MIT License
用途：早期用于管理 Codex 等客户端的供应商配置。后来这条链路被移除，项目改为直接连接网关。

Nginx

项目：Nginx
官网：nginx.org
许可证：BSD-2-Clause
用途：反向代理、HTTPS 入口和上游转发。

acme.sh

项目：acme.sh
仓库：github.com/acmesh-official/acme.sh
许可证：GPL-3.0
用途：自动申请与续期 TLS 证书。

1Panel

项目：1Panel
仓库：github.com/1Panel-dev/1Panel
许可证：GPL-3.0
用途：服务器管理与 Nginx 配置托管。

第三方服务

DeepSeek API、小米 MiMo API：由各自服务商提供的闭源商业 API，本项目仅按照其公开接口接入，不代表或关联官方。
Cloudflare：用于 DNS、代理和 Origin Rules，属于第三方商业服务。
Docker：用于运行 New API 容器。

本文中的配置脚本和项目整理由 Henry 编写，仅用于个人实验记录，目前没有单独发布为开源项目。文中不包含真实 API Key、管理密码或服务器凭据。