把模型调用收进后端，应用才真正掌握安全与成本

浏览器能直接调用模型，不代表产品应该这样交付。密钥暴露、预算失控和故障难以定位，往往都源于客户端承担了过多责任。更稳妥的链路是让前端只访问自有后端，再由后端完成鉴权、请求转发和用量记录。下面按实际落地顺序，把这条链路逐步搭起来。

第一步先把前端请求收敛为稳定的业务契约

先选一个边界清楚的场景，例如摘要生成。前端提交原文和必要选项，后端返回结果、任务状态及请求标识。不要直接允许客户端传入任意模型、系统指令或输出额度，否则业务接口很容易变成不受约束的转发入口。

明确输入长度、允许的附件类型和输出上限，并定义用户可理解的错误类别。这样即使以后更换模型，前端也不必跟着重写交互逻辑。

第二步让服务端独占上游凭据并执行用户权限

把上游密钥保存在服务端秘密管理系统中，避免进入浏览器资源、移动端安装包或普通日志。开发环境与生产环境分别使用凭据，并准备轮换和撤销流程。

每次请求先验证登录状态，再检查用户权限、并发数及预算余额。登录成功不等于可以无限调用；按用户设置速率限制，才能减少账户被盗或自动化滥用带来的损失。

第三步核对模型能力再接入统一的转发入口

本文发布于 BestRelay。它是以质量为先的接口中转服务，按请求中指定的名称转发至对应官方模型，不进行替换，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen 和 Grok 等系列。

后端接入时，将服务地址与凭据集中管理，并从控制台确认实际可用的模型标识，例如 Gemini 2.5 Flash。BestRelay 可配合 Claude Code、Codex、Gemini CLI 及任意 OpenAI SDK 使用，但工具兼容不代表各模型的参数和能力完全一致；仍应逐项验证流式输出、工具调用和结构化结果。

第四步先跑通普通响应再处理流式输出生命周期

先用普通响应完成一次端到端测试，确认中文内容、错误映射和用量数据都能正确返回，再增加流式输出。后端应逐段转发内容，避免先缓存整段答案再发送，让流式接口失去意义。

同时设置连接超时与总处理时限。用户关闭页面或点击停止时，后端应尝试取消上游请求；取消是否及时生效需要实测，不能承诺已经生成的内容不会计费。响应开始发送后，也要有明确的中断状态，避免把半段答案标记为成功。

第五步把重试范围限制在能够安全恢复的故障

对限流和暂时性故障采用有上限的退避重试，并遵守上游返回的等待提示。参数错误和权限错误不应重试；已经收到部分输出的请求，也不宜自动重新生成，否则可能产生重复内容和额外费用。

为每次业务操作分配内部标识，防止用户连点造成并发重复请求。但不要把内部去重误当成上游幂等保证。若要启用备用模型，必须作为明确的产品策略告知用户，而不是在失败时悄悄替换。

第六步依据实际用量建立可核对的成本账本

记录内部请求标识、模型、耗时、状态及上游报告的词元用量，默认不记录完整提示词和回答。BestRelay 按量计费，以提供方报告的词元数为依据，缓存读取与写入分别计价，因此不能只按输入和输出总量粗略估算。

预算控制应结合调用前预留额度与调用后核对，并为缺失用量的失败请求保留待核对状态。需要动手验证时，可以创建一个 BestRelay 账户。会员邀请他人充值可获得推荐佣金，但这项收入应与应用调用成本分开记账。

第七步用故障演练确认后端边界真正有效

上线前至少测试凭据失效、超时、限流、客户端断开和预算耗尽，检查前端是否收到清楚的状态，也确认日志没有泄露敏感内容。先开放小规模流量，观察延迟、失败率和单次任务成本，再逐步扩大范围。真正值得保留的不是一层薄薄的转发，而是一条可限制、可观察、可核账的业务边界。