每一个用过不止一个 AI 提供方的开发者都懂这种痛苦OpenAI 有自己的 API keyAnthropic 有自己的计费面板Google 有自己的 SDKDeepSeek 有自己的速率限制如果你想用 4 个不同的模型就得管理 4 个账号、4 张发票和 4 套文档。这不只是烦人——这是一个瓶颈它阻碍开发者去尝试新模型。我构建了SarangAI来解决这个问题。它是一个统一的 AI 网关把所有请求路由到 200 个模型全部通过一个兼容 OpenAI 的端点。在这篇文章里我会带你过一遍它背后的架构、我做的设计决策以及遇到的技术挑战。高层架构在高层面上SarangAI 由 4 个主要组件组成API 网关API Gateway— 接收来自客户端CLI、IDE 或任何应用的请求路由器Router— 决定哪个模型来处理请求提供商适配器Provider Adapters— 把 OpenAI 兼容格式翻译成每个提供商的格式计费与速率限制器Billing Rate Limiter— 管理预付费余额和按用户速率限制流程很简单客户端 → API 网关 → 路由器 → 提供商适配器 → AI 提供商 ↓ 计费与速率限制器为什么要兼容 OpenAI这是我做过的最重要的设计决策。当我开始构建 SarangAI 时有两个选项选项 1构建我自己的 API 格式、我自己的文档、我自己的 SDK。选项 2使用 OpenAI 格式它已经成为事实上的标准。我选择了选项 2。原因如下零迁移— 如果你的代码已经在用 OpenAI SDK只需要改 base URL 和 API key。搞定。庞大的生态— 成千上万的库和工具已经支持 OpenAI 格式。熟悉— 开发者不需要学习新的 API。这就是让 SarangAI 能在几分钟内而不是几小时内上手的原因。技术挑战 #1归一化响应每个提供商的响应格式都不一样。OpenAI 用choices[0].message.contentAnthropic 用content[0].textGoogle 又是另一种结构。解决方案适配器模式。每个提供商都有一个适配器它负责把请求从 OpenAI 格式翻译成该提供商的格式把响应从该提供商的格式翻译回 OpenAI 格式处理错误和重试逻辑这让客户端代码保持干净——他们不需要知道正在使用哪个提供商。技术挑战 #2流式传输流式响应很棘手。每个提供商发送分块的方式都不一样OpenAI 使用带data: {...}的服务端事件SSEAnthropic 有自己的事件类型content_block_delta等Google 又有另一种流式格式在 SarangAI 中我把所有流式传输都归一化成与 OpenAI 相同的 SSE 格式。这样客户端只需要处理一种流式格式。技术挑战 #3速率限制与计费由于 SarangAI 使用预付费 IDR 充值模式我需要跟踪每一个请求并基于 token 用量计算成本实时从用户余额中扣减处理并发请求时的竞态条件为此我使用了Redis用于快速余额检查和数据库用于审计追踪的组合。技术挑战 #4模型路由SarangAI 的主要特性之一是即时切换模型。用户可以不用重启应用就更换模型。这意味着路由器必须从请求中读取模型配置校验该模型是否可用路由到正确的适配器在提供商宕机时处理回退我把这个路由器设计成无状态的这样它就可以无问题地水平扩展。CLI 工具sarangai-cli除了 API 网关我还构建了一个可以直接在终端使用的 CLI 工具npm install -g sarangai-cli sarang这个 CLI 连接到 SarangAI 端点给你一个交互式工作空间。你可以用一条命令切换模型查看 token 用量查看你的余额这对那些活在终端里的开发者尤其有用。学到的经验1. 标准很重要。选择 OpenAI 兼容格式是我做过的最好的决定。它让采用变得飞快。2. 适配器模式救命。没有干净的适配器每新增一个提供商都是一场噩梦。3. 对开发者工具来说预付费 订阅。开发者讨厌月度订阅。预付费给他们一种完全掌控的感觉。4. 文档本身就是一种功能。无论你的架构多好如果文档很烂没人会用。自己试一试如果你经常使用多个 AI 模型试试 SarangAIhttps://sarangai.id安装 CLInpm install -g sarangai-cli我很好奇你目前是怎么处理多个 AI 提供商的你用库吗还是一个一个管理欢迎在评论区分享——我很想听听其他开发者是怎么处理的。相关阅读延伸外链以下为推荐的相关技术教程来自致知笔记如何将笔记本电脑连接到外接显示器如何检查 IP 地址是静态还是动态Static/Dynamic IP如何在 Windows 11/10 中创建密码重置盘