成本上限 · 降级回退 · 通道与 cron 边界 · 可复现 Runbook
当 Gateway 已监听、通道能收消息、工具链能跑通，团队仍会看到「夜间 cron 把配额打光导致白天人工对话失败」「热修通道与批处理任务抢同一模型路由」「429 后无限重试把账单翻倍」。根因是路由决策没有与任务类型、渠道 SLA 和预算同级建模；与三段式排障和多通道加固强相关，缺字段时只能凭感觉调参。
单档模型税：所有入口共用一条路由，长上下文任务与轻量通知抢同一后端，表现为延迟尖峰与不可预期的排队。
无上限重试税：通道回调失败或 429 时客户端指数退避未封顶，账单与下游限流同时恶化。
主备倒挂税：备用模型能力或上下文窗口与主路不匹配，切换后 silently 截断或工具 schema 不兼容。
渠道与模型混责税：Webhook 超时与模型 TTFT 混在同一告警里，排障只能猜「是不是又挂了」。
观测缺口税：只记 token 总量不记 route_id 与 channel_id 维度，评审无法回答「哪条入口在烧钱」。
把以上五条写成上线前闸门，再进入下一节对照配置结构，才能把 OpenClaw 从「能跑」升级到「可验收的生产形态」。与安装与 doctor 排障交叉阅读时，请区分装机阶段与运行期路由调参的不同证据链。
没有放之四海皆准的 JSON，但有可评审的字段最小集：谁触发、走哪条路由、失败换谁、何时熔断、如何计费归因。下表刻意保持抽象，便于你对照自家 openclaw 或等价配置层的实际键名。
| 维度 | 主路径 | 备路径 |
|---|---|---|
| 触发源 | 人机对话、cron、Webhook、子代理 handoff 各自独立路由表 | 共享默认路由仅作兜底并带更低并发上限 |
| 模型档 | 高推理档、标准档、低成本档与任务标签映射写死 | 备模型上下文与工具白名单与主路对齐校验 |
| 成本上限 | 按日或按渠道 token 与调用次数双阈值 | 触顶后只读模式或排队而非静默失败 |
| 回退顺序 | 同厂商不同 SKU → 跨厂商兼容端点 → 人工工单 | 每步必须记录 failover_reason 枚举 |
| 校验路径 | 配置校验命令与 dry-run 写进 CI | 灰度环境用固定回放用例集比对延迟与成本 |
路由是否可靠，取决于「失败时能否解释为什么换了路」而不是「成功时能否偶尔跑完」。
若你已在实践多通道生产加固，把本表字段与通道白名单、技能审计表放在同一评审包，可避免「加固做了但路由仍是黑盒」的半截工程化。
下面六步可在半天内由新同事复验：每一步对应一条变更记录与回滚点；与运行期排障组合时，请把 request_id 与路由决策写进日志信封。
冻结入口清单：列出人机、cron、Webhook、子代理四类入口及各自 SLA 与可接受最大排队秒数。
写路由矩阵：任务标签 × 渠道 × 模型档 × 主备四列，禁止「默认全走最强模型」。
配置成本闸门：日预算、渠道预算、单次最大输出 token 与退避上限写进同一小节。
实现软回退与硬熔断：软回退换备模型并打点；硬熔断停止自动重试并强制告警到人。
对齐通道重试：Webhook 与 Gateway 的重试策略不得放大模型侧 429；必要时在通道层排队。
演练配额耗尽：人为调低测试环境限额，验证只读模式、排队与人工工单三条路径可观测。
{
"routes": {
"interactive": { "primary": "model-a", "fallback": "model-b", "max_tokens_out": 4096 },
"cron": { "primary": "model-c", "fallback": "model-b", "daily_token_cap": 500000 }
},
"retry": { "max_attempts": 4, "base_ms": 400, "cap_ms": 8000 }
}
提示：示例键名需映射到你实际使用的配置形态；关键是 主备、限额、退避封顶 三角与入口维度一致。
没有分层指标就没有分层 SLO。建议至少按 Gateway 请求生命周期、通道投递与回调、模型与工具调用 三段采集延迟与错误码；否则 429 与 TLS 握手失败会混在同一曲线里。排障顺序与三段式分流一致：先判定落在哪一段，再下钻到路由或通道参数。
Gateway 先看：gateway_request_latency_p95 与路由选择日志是否一致；异常升高时先查监听面与反代。
通道再看：回调可达性、签名校验与队列深度；与白名单与 TLS 检查表对齐。
模型最后：配额、速率与工具 schema；切换主备后比对输出结构与下游消费者契约。
注意：硬熔断后若仍静默重试通道层，会把「已止血」的事故重新点燃；熔断必须跨层一致。
下列三条来自大量 Agent 生产落地的经验区间，用于立项前核对而非性能保证；你应用真实账单与延迟直方图替换它们。
route_id 承担超过 70% token 且存在第二入口，应拆分档或加渠道预算。| 团队规模 | 调用形态 | 更稳的第一选择 |
|---|---|---|
| ≤ 5 人 | 以人机为主 | 两档模型 + 明确日预算；cron 单独低档 |
| 6–20 人 | 多通道 + 自动化 | 入口级路由表 + 软回退 + 通道层排队 |
| 20 人以上 | 多租户与审计 | 强制路由审计字段 + 不可变配置版本 + 分环境回放 |
| 强合规 | 数据出境敏感 | 区域化端点 + 禁止公共回调 + 日志留存与责任人字段 |
本地笔记本与间歇在线机器在休眠、更新与钥匙串隔离上会持续欠账；即便路由表设计正确，底层不稳定也会让回退路径失真。相较之下，可合同化的云端 Mac 常驻节点才能把 Gateway 进程、心跳与 SLA 落在可验收条款上。
常见误区：把「对话流畅」当成「自动化健康」；批处理与交互对延迟与成本假设相反，混用同一路由会拖垮预算。
若团队既要稳定 OpenClaw 自动化，又要控制 token 与可用性，自建单机往往卡在休眠与运维窗口；纯本地开发机难以满足 7×24 与密钥轮换。对需要生产级路由与可观测回退 的场景，VpsMesh 的 Mac Mini 云端租赁通常是更优解：按周期弹性计费、区域可选、节点专用可审计，让路由指标与成本讨论建立在真实在线率之上，而不是口头承诺。