客服与对话场景：稳定性与并发怎么权衡

与其他场景的根本不同

对话场景有两个硬约束：

1. 用户在场 —— 中断会被立刻察觉，直接影响体验
2. 并发不可控 —— 用户什么时候来、来多少，你说了不算

这决定了它的选型标准偏向「稳」而不是「省」。

稳定性怎么评估

不要只看「可用率」这一个数字，要区分三类故障：

「部分失败」是最难受的 —— 它不会触发你的全局切换逻辑，但会让体验变得不可预测。

评估方法：跑一段时间的持续请求，统计失败率而不只是「是否可达」。

并发怎么估

峰值并发 ≈ 同时在线用户数 × 每人每分钟请求数 / 60

举例：100 个用户同时在线，每人每分钟发 2 条消息：

100 × 2 / 60 ≈ 3.3 并发（平均）
实际峰值可能是平均值的 3-5 倍 → 10-17 并发

关键：站点宣传的并发数通常指它的整体容量，不是给你单账号的额度。单账号上限往往低得多，需要直接问。

必须做的一件事：降级

面向用户的场景不能没有降级方案。三种方式：

一、切换通道

PROVIDERS = ["https://主站/v1", "https://备站/v1"]

async def chat(msg):
    for base in PROVIDERS:
        try:
            return await call(base, msg)
        except Exception:
            continue
    return "服务暂时繁忙，请稍后再试"

二、降级模型

主模型不可用时，切到更小更稳的模型。质量会下降，但至少能回。

三、规则兜底

最坏情况下用预设话术回应（如「人工客服稍后联系您」），比让用户面对报错页面好。

三个容易忽略的细节

一、超时要比用户耐心短。 用户等待的心理阈值大约 10 秒。客户端超时设 15-20 秒，超时后走降级，而不是继续等。

二、流式可以掩盖延迟。 总耗时 3 秒但首字节 300 毫秒，用户感受是「很快就开始了」。对话场景强烈建议用流式。

三、注意内容安全。 不同站点的内容政策差异很大。面向用户的对话如果涉及敏感话题，需提前确认站点边界，并自己在应用层做过滤 —— 不要依赖站点帮你兜底。

选站优先级

1. 部分失败率低          ← 比"是否可达"更重要
2. 单账号并发足够
3. 支持流式
4. 有可用的备用通道
5. 成本

相关阅读

• 怎么给项目配置多家 API 互备
• 选型之后：怎么持续监控你的 API 供应商
• 常见报错对照表：401/403/404/429/500 分别意味着什么