把模型调用放在自己的服务端
浏览器、移动端或插件不应直接持有平台 API Key。客户端请求先进入自己的服务端，由服务端完成用户鉴权、额度控制、内容拼装和模型调用。
这一层还能统一记录请求标识、模型、耗时和业务结果，为后续切换模型、成本分析和质量评测提供依据。
- 用户鉴权与权限控制
- Prompt 和上下文组装
- 模型路由与重试
- 用量、质量和错误记录
不同场景关注不同指标
聊天机器人重视首字速度、上下文连续性和安全边界；编程助手关注代码准确性、长上下文和工具调用；RAG 还需要独立评估文档解析、检索召回和引用准确性。
不要只比较单次演示结果。使用真实任务建立固定评测集，同时记录成功率、人工评分、延迟和单次成本。
为质量、成本和可用性留出切换空间
业务代码应依赖稳定的内部接口，而不是散落具体模型名称。通过配置为不同任务选择模型，并为关键请求准备经过验证的备选方案。
切换模型前要验证请求字段、输出格式和工具调用差异。故障切换不能替代业务幂等、超时控制和结果校验。
常见问题
关于统一 AI API 应用场景与架构方案的常见问题
前端应用可以直接请求模型 API 吗？
不建议。应由自己的服务端保存平台密钥并执行用户鉴权、限额和审计。
不同业务可以共用同一个模型吗？
可以，但应分别评测质量、延迟和成本，复杂任务与简单任务不必使用同一档模型。
统一网关是否会替代 RAG 检索系统？
不会。网关负责模型调用，文档解析、权限过滤、检索和引用仍由业务系统管理。
如何判断模型切换是否成功？
使用固定评测集比较成功率、质量、延迟和成本，并验证输出格式及工具调用兼容性。