路由与切换

大多数接入失败不是因为“不会调用”，而是因为上线后要切模型、回滚或扩容时，没有提前设计切换面。

一开始就把 3 层分开

1. 业务层：只表达任务和输出要求
2. 接入层：只处理统一 SDK、鉴权和调用结构
3. 路由层：只处理当前走哪个模型、哪个上游、哪条 fallback

如果这三层混在一起，任何一次模型调整都会变成代码改造。

推荐的配置方式

CLAWSOCKET_MODEL_PRIMARY=
CLAWSOCKET_MODEL_CANARY=
CLAWSOCKET_MODEL_FALLBACK=
CLAWSOCKET_REQUEST_TIMEOUT_MS=45000

你可以先让少量低风险请求走 CANARY，确认稳定后再切到 PRIMARY。如果结果质量、延迟或错误率不合格，直接回退到 FALLBACK。

什么时候该切模型

• 你需要新的能力，但不确定副作用
• 旧模型稳定，但成本或时延不再合适
• 上游有明显的版本迭代或弃用信号

不要因为“看起来是新版本”就直接全量切。预览版、实验版和主流生产版应该使用不同标签。

切换时看什么

至少盯住 4 个指标：

1. 成功率
2. 平均时延
3. 成本变化
4. 结果稳定性

后两个经常被忽略，但实际最影响业务体验。一个便宜但结果波动大的模型，最后往往更贵，因为返工成本会被转移到人工和补偿逻辑上。

最小回滚方案

你至少要满足下面三点：

• 回滚只改配置，不改代码
• 回滚后可以立刻复用同一套日志
• 回滚路径是上线前就验证过的

没有验证过的回滚，不算回滚方案，只算想象。