我没有自研 AI 中转站：8 小时跑通 New API、DeepSeek 与 Codex Coding Plan

我没有自研 AI 中转站：8 小时跑通 New API、DeepSeek 与 Codex Coding Plan

过去几天，我用大约 8 小时完成了一次 AI 中转站实践。

项目开始时，我的设想很大：公司会接入多家 LLM，C 端用户又需要额度管理，如果继续按"调用次数"收费，同一次请求无论只消耗几十个 token，还是携带很长的上下文、推理 token 和缓存 token，都会被算成一次。

这显然不是一个稳定的成本口径。

所以我最初的问题是：

是不是应该做一个自己的 AI 中转站，把供应商、模型、用量、价格和用户额度全部管起来？

随着调研深入，我又产生了第二个疑问：

如果 New API 已经能实现这些能力，我继续做下去，是不是等于重新自研一个 New API？

最终我没有写一套新的网关，也几乎没有修改 New API 源码，但我完成了两个真实目标：

1. 托管 DeepSeek，并在 Claude Code 中通过统一入口聊天；
2. 托管我个人的 Codex Coding Plan，通过 CLIProxyAPI + New API 完成实际调用。

更重要的是，我把"按调用次数"拆成了可以观测的 token usage、可以执行的本地计价，以及仍需未来建设的供应商对账。

这篇文章不是一份安装手册，而是我从"可能要自研"到"知道什么时候不该自研"的完整实践记录。

一、为什么按调用次数不够用了

假设两个用户各调用一次模型：

请求 A：一句简单问候，只产生少量输入和输出 token
请求 B：携带长文档、长上下文、推理过程和缓存 token

如果两个请求都只扣一次额度，会出现几个问题：

• 短请求和长请求的用户消耗相同，不公平；
• 调用次数无法准确映射供应商成本；
• 本地额度和供应商账单难以对账；
• 接入图片、音频、视频后，"一次调用"更没有统一含义。

因此，我真正需要的不是一个简单反向代理，而是至少包含这些能力的统一入口：

• 用户 Token 与访问控制；
• 多供应商渠道；
• 稳定的对外模型名；
• 路由和模型映射；
• prompt、completion、reasoning、cache 等 usage；
• 模型价格和本地额度扣减；
• 可回查的调用日志；
• 管理后台。

如果从零实现，这已经是一个完整平台，而不是几百行转发代码。

二、真正的第一个决策：先调研，还是先写代码

我一开始把"建设中转站"自然地理解成"开发中转站"。

但调研 New API 后，我发现它已经覆盖了当前阶段的大部分通用能力。官方将它定位为大模型网关和 AI 资产管理系统；在我的本地验证中，用户、Token、渠道、模型映射、价格倍率、计费门禁、日志和管理后台都已经可以使用。

这让项目方向发生了变化。

原来的问题是：

我应该怎样实现一个多模型网关？

变化后的问题是：

New API 的已有能力能否覆盖我的真实场景？
标准 API 和订阅型上游能否放进同一个入口？
哪些差异值得自研，哪些差异只需要适配？

这个变化节省的不只是编码时间。

如果选择自研，我还要持续负责协议兼容、密钥管理、用户体系、计费规则、管理后台、数据库迁移、安全更新和供应商版本变化。只有当这些投入能产生明确差异化价值时，自研才成立。

三、我最终采用的结构：一个网关，两种上游

我的两个目标，实际上对应两类完全不同的供给方式。

上游类型	代表场景	接入方式	本地计费方式
标准 Token/API Key	DeepSeek	直接作为 New API 渠道	根据真实 token 和价格倍率扣费
OAuth/订阅/Coding Plan	个人 Codex Coding Plan	CLIProxyAPI 转换后接入 New API	记录 usage，不伪造 token 单价

最终结构如下：

                         ┌→ DeepSeek 等标准 API
Claude Code / 客户端 → New API
                         └→ CLIProxyAPI → Codex OAuth / Coding Plan

New API 是统一治理层：

• 对外只暴露统一入口和统一 Token；
• 根据稳定模型名选择渠道；
• 记录 usage 和调用日志；
• 对有可靠单价的模型执行额度扣减。

CLIProxyAPI 是非标准协议适配层：

• 完成 Codex OAuth；
• 管理 OAuth 凭据的加载与刷新；
• 将订阅型能力转换为兼容 API；
• 只监听本机回环地址，不对外暴露管理面。

这套结构背后的原则是：

稳定、通用、需要统一治理的能力放进核心网关；变化快、依赖特定账号形态的能力放进 sidecar。

如果未来不再使用 CLIProxyAPI，或者 OAuth 适配方式发生变化，只需要替换外围适配层，业务客户端与 New API 的模型入口不必跟着改变。

四、第一条链路：DeepSeek 不只是"调用成功"

DeepSeek 属于标准 API 上游，因此可以直接使用 New API 的内置渠道。

我为两个目标模型设置了稳定的对外名称，并配置输入、输出和缓存读取的价格倍率。调用方通过 New API Token 请求模型，不直接持有供应商 Key。

如果只验证接口返回一段文字，这个实验没有太大价值。我的重点是确认：usage 和计价是否真的符合预期。

1. 非流式和流式都要有完整 usage

我分别调用了非流式与流式接口。

流式场景并不能因为响应被拆成多个事件，就失去最终 usage。实测中，流式请求能够在结束阶段返回完整 usage，本地日志也能记录输入、输出、推理和缓存明细。

2. reasoning token 属于输出成本

模型返回的推理 token 不是免费的隐藏字段。

实际日志显示，reasoning token 被纳入 completion 口径，并按照输出价格参与本地计费。这意味着只查看最终展示给用户的文本长度，仍然可能低估真实消耗。

3. 缓存读取和缓存写入不能填反

这是我实际踩过的坑。

第一次配置时，我把缓存优惠价格填到了"缓存写入"字段。请求虽然调用成功，缓存命中量也被识别，但费用没有按预期下降。

修正为"缓存读取价格"、关闭缓存写入价格后，同样的命中 token 才按照读取优惠参与计算。

这件事给我的提醒是：

管理后台字段看起来相似，不代表业务语义相同。价格配置必须回到供应商口径，再用真实日志验算。

4. 我主动清空价格，验证门禁是否真实存在

正常调用通过后，我又做了一个反向实验：清空模型价格。

预期不是"请求成功但扣费为零"，而是请求在进入上游前就被拒绝。这样才能防止一个新模型因为漏配价格而持续产生无法归属的成本。

实际结果符合预期：价格轨道全部清除后，请求返回"模型价格未配置"，没有进入上游，也没有产生本地扣费。

恢复倍率后，两个模型重新返回成功。

5. New API 的固定价格和倍率是双轨的

这个门禁实验还暴露了一个不容易从 UI 看出来的细节：New API 同时存在固定价格和模型倍率。

ModelPrice：固定价格轨道
ModelRatio：倍率计价轨道

界面上清空固定价格，不一定会把倍率兜底一并删除。因此，测试"未定价模型是否拒绝"时，只操作一个界面按钮是不够的，必须检查两条轨道，并以真实请求结果为准。

这也是为什么我最后选择"配置 + 请求 + 数据库只读日志"三种证据一起看。

五、第二条链路：为什么 Codex Coding Plan 需要 sidecar

DeepSeek 接入完成后，我回到第二个目标：托管个人 Codex Coding Plan。

这类能力和标准 API Key 不同。它依赖 OAuth 登录和订阅权益，不能直接把某个普通 Key 填到 New API。

CLIProxyAPI 官方说明支持通过 OAuth 接入 OpenAI Codex，并向客户端提供 OpenAI、Responses 等兼容接口。这正好补上了 New API 与订阅型上游之间的协议差异。

我的实施顺序是刻意拆开的：

第一轮：只验证 CLIProxyAPI → Codex
第二轮：再验证 New API → CLIProxyAPI → Codex

这样做的好处是，如果请求失败，我能先判断问题发生在 OAuth 转换层，还是 New API 的渠道与模型映射层。

1. 先固定版本，再做 OAuth

我没有使用浮动的 latest 路径，而是固定 CLIProxyAPI 版本并核对发行包校验值。

随后通过浏览器完成一次 Codex OAuth，凭据只保存在本机私有目录。转换服务只监听本地回环地址，管理接口保持关闭，凭据和本地 API Key 都没有进入 Git 或文档。

2. 先绕过 New API，直测转换层

OAuth 完成后，我先直接请求 CLIProxyAPI：

• /v1/models 能发现当前可用模型；
• 非流式 /v1/responses 能返回完成状态与 usage；
• 服务重启后能够复用 OAuth 凭据，不需要重新登录。

这一步证明"Codex 订阅 → 兼容 API"成立。

3. 再把 sidecar 作为独立渠道接入 New API

转换层成立后，我在 New API 中新增一个独立兼容渠道：

• Base URL 指向本地 CLIProxyAPI；
• 使用唯一稳定模型别名；
• 将对外模型名映射到当前上游模型；
• 不设置其他付费渠道作为回退；
• 将本地模型倍率显式设为零。

这里的零倍率并不代表"没有用量"。

调用仍然记录输入和输出 token，只是不使用一个虚构的按量价格扣减本地额度。因为 Coding Plan 的成本来自订阅权益，而不是一个稳定、公开、可对账的单位 token 单价。

4. 我验证的不只是普通聊天

全链路接通后，我依次验证了：

验收项	目的
非流式 Responses	验证最小完整请求链路
SSE 流式 Responses	验证事件序列和最终完成事件
Function Tool	验证模型发起工具调用和结果回传
Chat Completions	验证常见客户端兼容入口
usage 与零倍率	验证有日志但本地不扣额度
sidecar 停止	验证明确失败和错误回退边界
sidecar 重启	验证 OAuth 凭据复用
DeepSeek 回归	验证新渠道没有影响旧渠道

最终这些链路都完成了真实请求验证。

六、工具调用中，我还遇到一个协议层细节

Function Tool 验证并不是一次请求就结束。

第一段响应中，模型生成工具调用：

get_weather({"city":"Beijing"})

客户端执行工具后，需要把结果再交回模型，才能得到最终自然语言答复。

我一开始尝试只使用 previous_response_id 关联上一段响应，上游却提示找不到对应的 call_id。

后来改为显式携带上一段 function_call，并同时提交 function_call_output，工具调用闭环才完成。

这个细节让我更清楚地看到：

• 兼容 /v1/responses 不只意味着能返回文本；
• 多轮工具调用还涉及调用标识、上下文传递和上游状态策略；
• sidecar、网关和客户端三层都可能影响最终协议行为。

因此，一个"模型聊天成功"的截图，不能代替对 Responses、流式和 Tool 链路的完整验收。

七、失败关闭比自动回退更重要

接入多个渠道后，一个常见想法是：上游失败时自动切换到其他模型。

但对我的 Codex Coding Plan 场景来说，这可能反而危险。

如果 sidecar 停止后，网关静默切换到一个真实按量付费渠道，用户看到的只是请求仍然成功，但后台已经开始产生意外费用。

所以我故意停止 CLIProxyAPI，再请求稳定模型别名。

实际结果是：New API 明确返回上游请求失败，没有切换到其他付费渠道。

这个结果虽然是"调用失败"，却是正确的系统行为：

当成本边界和账号来源发生变化时，明确失败比悄悄成功更安全。

八、为什么"零源码改动"仍然是一项工程成果

这次实践没有修改 New API 业务源码，也没有把 OAuth 逻辑塞进网关。

我完成的工作主要是：

• 调研并选择成熟基座；
• 固定组件版本；
• 设计标准渠道与 sidecar 的边界；
• 配置模型映射、倍率和故障隔离；
• 验证 usage 与计费公式；
• 覆盖成功、失败和回归路径；
• 记录运行边界与停止条件。

如果把"工程产出"只理解为新增代码行数，这个项目似乎没做什么。

但从结果看，它避免了重复建设一个完整网关，也没有形成难以跟随上游升级的私有魔改分支。

我现在更认可下面的优先级：

能配置解决 → 先配置
协议不兼容 → 增加外围适配层
配置和适配都无法提供差异化价值 → 再写核心代码

少写代码不等于少做工程。能在正确的层解决问题，本身就是工程判断。

九、我如何理解 usage、额度和最终成本

实践前，我容易把"拿到 token 数"理解成"成本问题已经解决"。

真正落地后，我把它拆成四层：

层次	回答的问题	本次状态
用量事实	输入、输出、推理、缓存各是多少	已验证
本地计价	根据价格或倍率扣多少额度	DeepSeek 已验证
额度账本	预占、结算、退款和余额变更如何审计	未建设
供应商对账	本地计算与最终账单是否一致	未建设

当前实现已经比"按调用次数"准确，但它还不是财务级成本系统。

供应商最终账单还可能受到缓存规则、套餐权益、峰谷价格、阶梯价格和后续价格调整影响。如果未来承担公司级额度管理，还需要不可变账本、价格版本快照和供应商账单对账。

这也是我没有把当前 PoC 包装成"企业 AI 中台"的原因。

十、我用 AI 完成实践，但没有把判断权交给 AI

这次项目也是一次"根据 AI 学 AI"的实践。

AI 在过程中承担了多个角色：

• 调研员：比较社区方案，梳理 New API 已有能力；
• 架构讨论伙伴：帮助拆分网关和 sidecar；
• 操作助手：协助配置渠道、模型映射与价格倍率；
• 测试助手：执行请求、检查 usage、读取日志、覆盖失败路径；
• 记录员：维护计划、落地记录、交接文档和复盘材料。

但几个关键判断始终由我完成：

• 当前真正要解决什么问题；
• 是否接受引入外围适配层；
• 哪些账号和凭据可以进入操作范围；
• 什么证据足以说明链路成立；
• 哪些生产能力不属于当前阶段；
• 什么时候项目已经足够，应该停止。

我没有把 AI 的口头判断当成实现事实，而是不断要求它回到可复核证据：

提出问题
→ 调研现成能力
→ 形成最小假设
→ 搭建最小实验
→ 查看响应与日志
→ 验证失败和回归路径
→ 修正认识
→ 达成目标后收口

对我来说，这比连续阅读一堆概念更有效。AI 不是替我"学会"，而是加快了真实问题从假设走向证据的过程。

十一、这套方案已经做到什么，还没有做到什么

截至项目收口，已经成立的是：

• DeepSeek 标准 API 能进入统一入口；
• Codex Coding Plan 能通过 OAuth sidecar 进入同一入口；
• 两类上游可以使用稳定模型名与统一 Token；
• DeepSeek 能记录真实 usage 并执行倍率计费；
• Codex 能记录 usage，同时保持本地零倍率；
• 非流式、流式、Tool、Chat Completions、重启和失败关闭均已验证；
• 新增订阅渠道没有破坏原有 DeepSeek 渠道。

尚未建设的是：

• 更多供应商的全面接入；
• 图片、音频和视频计费；
• 独立额度账本；
• 供应商账单自动对账；
• 批量用户与 Token 开通；
• 并发压测和容量规划；
• 高可用、进程守护、监控、告警和灾备；
• 多租户生产权限体系。

因此，最准确的描述不是"我完成了企业级 AI 中台"，而是：

我跑通了个人可用的统一 LLM 入口，并验证了标准 API 与订阅型上游可以用不同接入方式统一纳管。

十二、我为什么在这里结束项目

项目最初的范围很容易继续扩大：再接一家供应商、再做一个多模态价格、再写一个账本、再做一个服务器部署。

但我的两个真实目标已经完成：

• DeepSeek 可以托管，并能在 Claude Code 中聊天；
• 个人 Codex Coding Plan 可以通过 CLIProxyAPI + New API 托管。

同时，我已经获得了三个关键答案：

1. 多模型统一入口可以快速落地；
2. 标准 API 和 OAuth/订阅型能力可以统一纳管；
3. 当前没有必要从零自研 New API。

如果没有新的明确需求，继续扩建只会让一次验证项目自然膨胀成长期平台工程。

所以我选择主动收口，而不是为了让项目看起来更"大"而继续开发。

十三、这次实践留下的可复用方法

以后面对类似的 AI 工程问题，我会复用下面这条路径：

1. 写清真实问题：先描述成本、用户或工程痛点，不预设技术答案；
2. 盘点现成能力：确认开源项目和官方服务已经解决了多少；
3. 拆分不同上游：区分标准 API、兼容 API、OAuth 和订阅套餐；
4. 划定最小验证范围：只选择能够回答关键疑问的链路；
5. 用真实请求取证：同时看响应、usage、日志和上游行为；
6. 主动验证反例：移除价格、关闭服务、重启组件、回归旧渠道；
7. 明确成熟度边界：区分个人可用、内部 PoC 和生产平台；
8. 形成停止条件：关键问题有答案后及时结束。

这次实践真正留下的，不只是一套本地模型入口。

它让我建立了一个更稳定的工程判断：

不要因为看见一个完整问题，就默认必须自研一个完整系统。先确认成熟能力的边界，再把真正不同的部分放到正确的层。

最终成果不是"我自研了一个 New API"。

最终成果是：我用 New API 负责统一治理，用 CLIProxyAPI 适配非标准订阅，跑通了 DeepSeek 与个人 Codex Coding Plan，并且清楚知道这套个人可用方案距离公司级生产平台还差什么。

---

本文记录个人环境中的技术实践，不包含账号凭据、Token、本机路径或内部配置。涉及模型价格、项目版本和上游能力时，应以使用当日的官方文档为准。