Golang

很多团队做 AI 产品，第一阶段都很顺利： 调通一个模型； 写几个 API； 跑出一个 demo。 但到了第二阶段，问题会集中爆发： 客户要稳定，单一上游不稳定； 成本要可控，调用量上来后账就乱了； 用户要分层，个人、团队、管理员权限都不一样； 运营要可视，出了问题要知道是谁、哪个 key、哪个渠道、哪个模型； 商业要闭环，充值、订阅、额度、结算要打通。 这时你会发现，真正难的不是“会调模型”，而是“把模型能力做成一个能长期运营的系统”。 我这几天把 new-api 关键代码路径完整过了一遍，结论是：它的价值不在于“支持 40+ 上游”这句话本身，而在于它把 AI 网关最难的工程问题做成了一整套闭环。 这篇文章我不做功能清单，而是按“工程决策”的视角，讲我为什么推荐它。 先说结论：new-api 适合什么团队？ 如果你符合下面两条以上，我建议认真评估 new-api： 你不是做一次性 demo，而是要长期运营 AI 服务； 你已经或即将接入多个模型提供商； 你需要用户体系、令牌体系、额度体系； 你需要计费可解释、可审计、可对账； 你希望业务团队只写业务，不反复改模型适配代码。 一句话：new-api 更像“AI 能力运营底座”，不是“API 转发脚本”。 一、我如何理解它的架构：分层清晰，但核心复杂度集中在中继闭环 从目录结构看，它是标准分层： 路由层：router/ 控制器层：controller/ 服务层：service/ 模型层：model/ 中继适配层：relay/ 这个结构不新鲜，但 new-api 做对的一点是：把复杂度集中在中继闭环中，而不是让复杂度溢出到业务端。 关键入口我看的是这几处： 启动与后台任务：main.go 管理 API：router/api-router.go Relay API：router/relay-router.go 分发中间件：middleware/distributor.go 中继主流程：controller/relay.go 通道重试：service/channel_select.go 计费会话：service/billing_session.go 在 main.go 里能看到它不是“起个 HTTP 服务就完了”，还挂载了多种后台任务： 自动测试渠道； 渠道上游模型更新检测； 订阅额度重置任务； 凭证刷新任务（例如某些 OAuth 型渠道）； 可选性能观测、缓存同步等。 这说明它天然按“在线系统”而不是“代码示例”来设计。 ...