模型执行回退
状态： 提案 · 创建日期： 2026-08-10
问题
端点重试和被动异常剔除可以选择同一逻辑模型的另一副本。它们不能安全切换到另一逻辑模型，因为提供商翻译、凭证、上下文限制、成本策略、输出格式和会话连续性可能变化。
提案
在模型选择之后引入执行编排边界。它拥有有界的跨模型尝试，而不重新匹配语义决策。
每次尝试记录：
- 逻辑模型和物理端点；
- 可安全重试的失败类别；
- 响应字节是否已提交；
- 提供商请求标识符；
- 观察到的 token 或成本用量；
- 会话和对话身份；以及
- 剩余尝试次数和先前访问过的模型。
回退候选必须由已匹配路由声明为兼容。编排器不能扩大决策的模型池。
所有权
| 层 | 职责 |
|---|---|
| 信号和决策 | 选择预期路由和候选策略。 |
| Selection 和路由学习 | 选择初始逻辑模型。 |
| 数据面可靠性 | 在该模型的后端内重试或剔除副本。 |
| 执行编排器 | 决定失败的逻辑模型尝试是否可以转到兼容回退。 |
跨模型回退不是又一次决策 Engine 遍历。
安全规则
- 响应字节已提交后不要切换模型。
- 认证和格式错误的请求失败默认不重试。
- 上下文窗口或策略失败只能回退到显式兼容的模型。
- 流式需要预提交边界和声明的部分输出策略。
- 每次尝试有自己的超时，整条链有一个截止时间和成本预算。
- 回放和计费必须标识每一个尝试过的模型。
- 切换前应用会话和工具循环连续性保护。
范围与非目标
本提案覆盖上游执行失败后的逻辑模型变更。它不替代同模型传输重试、熔断、异常剔除或普通语义选择。
待决问题
- 兼容集在哪里声明？
- 哪些提供商失败可以安全重放？
- 失败尝试已消耗 token 时如何对账用量？
- 哪些流式协议暴露可靠的提交点？
- 保护状态如何记录由回退驱动的切换？