我的多模型 AI 接入架构与分层排障
针对多平台账号与模型限制零散的问题，我基于 CLIProxyAPI 和 NewAPI 搭建多模型接入架构，实现规范接入与统一分发。遇到故障时沿着调用链逐层排查。
- 多模型
- API 路由
- NewAPI
- CLIProxyAPI
资源零散引发的分层管理
随着用到的模型、订阅和 API 增多，平台账号、模型名称、额度与使用限制非常零散。如果每个客户端（如 Codex、Claude Code、Cherry Studio 等）都单独配置一遍，维护成本极高。
我需要一条稳定的调用链，把不同来源接入并整理好，统一分发给日常使用的客户端与 Coding Agent。
官方 API稳定、规则清楚
模型订阅通过官方客户端或授权接入
兼容接口补充模型与场景
接入层CLIProxyAPI
把适合代理的订阅整理成兼容接口
管理层NewAPI
统一渠道、模型映射、路由和调用入口
CodexClaude CodeCherry StudioOpenWebUI
出现问题时沿着“客户端 → 管理层 → 接入层 → 上游”逐层查看日志和返回。
三层架构的职责分工
整套架构分为三层：
- 接入层（CLIProxyAPI）：将适合代理的订阅与客户端授权整理为兼容接口。CLIProxyAPI 是我维护的开源接入服务，解决登录态与协议兼容问题。
- 管理与路由层（NewAPI）：统一入口、模型名称映射、额度控制与渠道路由。当某个上游发生变更时，只需要在 NewAPI 中调整映射，下游所有客户端保持配置不变。
- 调用端：按任务特点灵活选择（写代码用 Codex/Claude Code，日常对话用 Cherry Studio/OpenWebUI）。
故障排查：沿着调用链逐层定位
多层架构虽然减少了重复配置，但也增加了潜在的出错节点。比如遇到 Claude Code 返回 400 错误时，过去容易在客户端盲目猜测，现在建立了固定的分层排查机制：
- 先用最简单的请求测试 CLIProxyAPI，确认上游账号与 Token 登录态是否正常；
- 再测试 NewAPI，检查渠道协议与模型映射是否匹配；
- 最后检查下游客户端实际发出的参数与模型名称。
层层隔离后，能快速把故障定位在具体某一层。
事实资产与运维联动
长期来看，维护模型的重点在于账号状态、渠道健康和配置备份。公开分享时只讨论结构与排查方法，不公开真实 Token 和调用地址。
这套 AI 基础设施的服务位置、关联账号与备份策略，已纳入我的 Personal Ops Panel 统一管理。关于把数字资产收窄为面板的过程，见《从长报告到运维资产中枢：一次 AI 产品实践》。