SaaS / AI 应用怎么接入多模型 API：后端路由、租户记账与降级实操
用 OpenAI 兼容接口接 Claude、GPT、Gemini，拆清模型路由、租户预算、密钥和重试职责，先验收再上线。
1. 先画清请求经过哪些边界
建议的路径是：用户请求 → 你的后端鉴权 → 租户预算检查 → 任务路由 → 模型请求 → 结果校验 → 业务保存。这个顺序让每一笔调用都能找到发起人和业务任务。不要由浏览器直接携带平台 key 发请求，否则一个用户就可能绕过你设置的额度或调用别的型号。你自己的接口只接受业务参数，例如商品编号和语言；model、最大输出长度、工具列表由服务端按允许清单生成。先用一类不涉及敏感动作的功能验证整条路径，再扩到客服、内容生成或 Agent。本文的租户账本和策略路由是实现建议，不是 cocodot 控制台中的现成功能。
2. 多模型路由先用配置表，再谈智能分类
起步用可解释的规则：商品字段提取走路线 A，多语言文案走路线 B，需要工具的任务走路线 C。每条配置包含完整型号、允许的输入类型、输出上限、校验器版本和备用路线。先用 Claude Sonnet 5.5（mcs-7）做候选，也可用 GPT-5.6 Sol（mog-8-s）或 Gemini 3.6 Flash（mgg-12）跑同一组样本；这里列的是在售型号，不是性能排名。能收到正常响应只是接通，字段完整、语言正确、工具参数可执行才算业务验收。把失败案例加入固定样本集，每次改提示词或换模型都回放一次。路由表应带版本，出问题时才能复现当时为什么选了这个型号。
3. OpenAI 兼容入口怎么接，哪些仍需验证
将 OpenAI 兼容客户端的 base URL 设为 https://cocodot.co/api/ai/v1，服务端以 Authorization: Bearer 携带 key；Claude 原生结构使用 Anthropic 兼容 base URL https://cocodot.co/api/ai，请求 /v1/messages，鉴权也接受 x-api-key。兼容协议不等于厂商每个参数都可用：你的服务应逐项验证流式读取、结束状态、用量字段和工具调用。工具只接受函数工具；搜索、查库存或执行代码由你的程序完成，再把结果交回模型。先做最小纯文本请求，再单独增加每一项能力，出错时容易定位。完整参数入口看 https://cocodot.co/docs，别直接把旧项目的全部可选字段一股脑搬进来。
const response = await fetch("https://cocodot.co/api/ai/v1/chat/completions", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.COCODOT_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
model: "mcs-7", // Claude Sonnet 5.5
max_tokens: 1000,
messages: [{ role: "user", content: "Draft a short product title." }]
})
});
if (!response.ok) throw new Error(`HTTP ${response.status}`);
const result = await response.json();
// Validate result and record usage inside your application.4. 降级是另一条产品路径，不能偷偷换结果
为每种任务预先规定可降级条件。例如商品标题生成可以改为短标题草稿，涉及订单状态的客服答复则应暂停自动发送、转人工处理。备用型号必须独立验证相同的输入与输出契约，不能只因协议兼容就认定能力相同。应用应保存请求型号、路线版本、切换原因和实际验收结果。实时流式内容已经展示给客户时，不建议在同一段文字中拼接另一模型的回答；明确结束本次尝试，提供重新生成入口。预算耗尽也不该自动升级到更贵路线。更多异常分类见 /hub/ai-api-errors-china-fix；本文的备用策略需你自行实现与演练。
5. 命名 key 管服务边界，租户归属另建账
cocodot 的 key 创建时可命名，也可单独吊销，一个账号最多同时持有 10 把。建议用 prod-content、prod-support、staging 之类用途名区分服务，把 key 存在服务端配置中，日志只记你自己的配置别名。租户很多时不要设想给每位客户发一把平台 key：你的后端应记录 tenant_id、job_id、attempt_id、route_version、请求型号、用量和验收状态。平台命名 key 便于凭证管理，不代表独立余额或租户权限。轮换时先在测试环境验证新凭证，再部署使用新凭证的服务，确认旧凭证没有依赖后吊销；发现泄漏时应立即吊销泄漏凭证并排查使用范围。
6. 把限流、重试和预算预留放在同一处
在后端同时设租户并发数和整个服务的并发数，批量任务排队，不让一个大客户挤占交互请求。为每个业务任务设总截止时间、尝试次数上限与累计预算。临时错误才考虑带抖动退避；认证、参数和余额问题先修原因，不循环重发。应核对 SDK 和业务循环各自是否重试，避免叠加。多 worker 并发时，“先读预算再发请求”可能一起放行：建议在你自己的数据库中原子预留本次预算，结算后再释放差额。该预留是应用侧保护估算，不能替代实际费用核对。更细的并发排查见 /hub/api-429-rate-limit-concurrency-china。
7. 用量记账按业务任务合并，别只看一次请求
同一个客户点击可能触发检索摘要、正文生成和校验三次调用，备用与重试还会增加次数。建议每次尝试单独落账，再按 job_id 汇总到一个业务任务，记录是否已交付。输入输出用量按响应实际字段保存；没有完整用量时标为待核对，不能用可见文本长度填成“零成本”。按租户统计已发生费用、在途预留和待核对金额，预算判断同时考虑三者。余额用完后 cocodot 新请求会被拒，已发出的请求仍可能计费;用量缺失时可能按接口兜底规则估算,最终以账单为准，因此平台余额不能代替你的租户预算。长链路保护方法见 /hub/agent-api-cost-runaway。 单位交付的算法见 /hub/team-ai-api-cost-per-task。
8. 先验证交付闭环，再逐步接入持续流量
先挑一小组脱敏的真实业务输入，覆盖正常、超长、空输入、工具参数错误、余额不足与备用路线。验收标准写成可检查的条件：字段是否齐全，失败任务是否可重新领取，重复回调是否会重复保存结果，租户能否看到明确任务状态。接入 cocodot 的路径是注册、验证邮箱、完成实名认证、按所需型号准备余额、创建 key、在服务端调用；免费体验额度只可调部分低价型号。充值方式为支付宝 / 微信支付(人民币)、USDT / USDC。Claude / GPT / Gemini 各线挂牌价不超官网，逐型号以价格页实时标价为准。先在 https://cocodot.co/pricing 核所选型号，再逐步增加真实任务，监控队列年龄、验收结果和每次交付费用，达到自己设定的门槛后再扩大范围。
| 应用任务 | 路由依据 | 应用侧验收 |
|---|---|---|
| 客服草稿 | 知识范围与语言 | 答案有依据，敏感操作转人工 |
| 商品内容生成 | 字段与目标市场 | 字段齐全，禁止词检查 |
| Agent 工具调用 | 工具契约 | 参数校验，操作去重 |
| 跨模型备用路径 | 同一能力要求 | 独立跑过相同样本 |