多 LLM 供应商共用一个 API Key：带可观测候选评分回退的实践

文章描述一个媒体公司将多个 LLM 供应商置于同一 API Key 之后用于候选人评分，夜间页面提示文本分类队列延迟，值班人员看到 18,420 个已完成任务和正常的请求成功率，但编辑在 08:00 打开招聘看板时发现昨日申请者未被排序——请求成功了，分类结果却不可用。作者据此提出：单 key 多供应商网关能减少集成碎片化，但无法定义候选人评分的成功标准；应针对有效评分结果的时效与完整性告警，而非 HTTP 成功；要求统一的便携 JSON 契约，在每次模型响应后校验，将结果类别与供应商分开记录，并仅对另一供应商可安全修复的错误启用回退。

AI推荐理由 文章提出一个具体且可操作的运维教训：多 LLM 供应商单 key 网关能减少集成复杂度，但 HTTP 成功不等于业务成功，应以有效评分结果的时效与完整性作为告警依据，并建议统一 JSON 契约、逐次校验、按结果类别而非供应商记录、仅对可安全修复的错误做 fallback。这些是来自一线场景的工程经验，对构建 LLM 网关和 Agent 流水线的开发者有实际参考价值。局限在于内容为经验叙述，未提供可复现的指标或对照实验，18,420 等数字仅为场景描述。