成本上限 · 降級回退 · 通道與 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 雲端租賃通常是更優解：按週期彈性計費、區域可選、節點專用可審計，讓路由指標與成本討論建立在真實線上率之上，而不是口頭承諾。