API 返回 200，业务却失败了：AI 调用链里的静默错误与重复计费

做 AI 调用链路监控时最容易忽略的一类问题：接口返回 200，客户端以为成功，业务实际上失败了。这类静默错误不只是体验问题——叠加重试机制后，它会直接变成账单上的真金白银。

三类常见的静默错误

1. 内容安全层拦截后返回空结果。 请求通过网关、通过鉴权、模型也响应了，但输出在内容安全层被拦，返回了空字符串或占位内容，状态码仍是 200。客户端拿到的「成功响应」里没有任何可用的译文/生成结果。

2. finish_reason 异常但被忽略。 模型因为上下文超限或异常终止，finish_reason 不是正常的 stop，很多调用方只取 content 不看 finish_reason，截断的输出被当成完整结果入库。翻译场景下表现为「文档后半段凭空消失」。

3. 网关兜底返回默认值。 上游超时后，部分网关/SDK 配置了降级响应（缓存结果或默认文案），调用方拿到 200 和一段「看起来像回事」的文本，完全没有失败感知。

静默错误怎么变成重复计费

静默错误真正的杀伤力在重试链路。典型场景：

1. 客户端拿到 200 但业务层校验失败（空结果）→ 发起重试
2. 重试请求因为幂等键缺失，在网关层被当成新请求
3. 网关自己的超时重试策略又叠一层
4. 最终同一个业务请求消耗了 2~4 次模型调用，全部计费

我们统计过一个批量翻译任务：一次夜间批处理因为目标端内容安全拦截率偏高，重试放大后实际计费 token 超出理论值 20% 以上。按量计费模式下这笔钱是直接可见的——如果按订阅包月的思路，这笔浪费就被平摊到看不见的地方了。

工程解法

请求 ID 幂等键是第一优先级。 业务请求生成唯一 ID，透传到网关和模型调用层；网关对同 ID 的重试返回缓存结果而不是重新计费调用。这一条能消掉 80% 的重复计费。

失败分类要进账本。 把每次调用标记为「业务成功 / 业务失败-已重试成功 / 业务失败-未恢复」，月末看账单时按业务成功口径核算成本，静默错误的真实代价才会显形。

重试要有预算上限和退避。 客户端重试次数 ≤2、指数退避，并且重试请求必须带同一个幂等键——否则重试从「兜底」变成「放大器」。

内容拦截前置化。 对批量任务，先跑一遍轻量级预检（敏感词/格式校验），把大概率被拦的请求筛出去，比事后重试便宜得多。

结语

AI 调用链的可靠性监控不能只看状态码，要看「业务口径的成功率」。200 不代表成功，计费成功更不代表业务成功——把这三个口径对齐，账单里那些对不上的差额自然会现形。