你已经能跑通 OpenClaw Gateway，下一步往往是生产里「钱和延迟怎么同时管住」：modelRouting 允许在请求进入模型前，按估计上下文规模把流量分层到不同档位，而不是永远用同一个大模型硬扛。本文说明它解决什么问题、在 openclaw.json 里与 agents.defaults、fallback 的边界、如何把 SLO 映射到 maxTokens 阶梯，并给出六步落地清单与误配对照；与站内安装、systemd、Docker 篇互补。
在生产里，OpenClaw 的请求往往同时携带系统提示、历史对话、工具输出、RAG 片段。若始终把这一切丢给单一高阶模型，账单与尾延迟都会失控；若只依赖失败后的 fallback，又会在「已经成功烧掉大上下文」之后才发现不该走这条路。modelRouting 的定位是：在真正发起上游推理前，用估计的上下文 token 规模选择合适档位，让「轻问轻答、重问重答」成为默认策略，而不是事后补救。
下面六条是团队里最常见的「痛点信号」——若命中多条，就应该把路由策略写进配置评审，而不是只在 Grafana 里骂模型贵：
长尾延迟：同样 QPS 下，p95/p99 与均值差距拉大，且与「对话变长」高度相关，说明大上下文路径被过度使用。
成本曲线非线性：流量只涨了三成，账单却涨了一倍，常见于「所有会话默认顶格模型」。
工具调用放大上下文：一回合里多轮工具输出把 token 顶穿，触发隐式截断或意外重试。
fallback 链路过长：用户无感，但内部已经在同一请求上串了多模型，延迟与计费双重叠加。
缺乏路由可观测性：只能看到「最终模型名」，看不到「为何命中这一档」，排障靠猜。
多租户/多 Agent 隔离不足：共享 Gateway 时，重会话拖垮轻会话的 SLO，需要按上下文分流的硬闸。
读完站内 OpenClaw 安装与部署系列后，你应当已经解决了「进程是否常驻、端口与隧道是否健康」。本稿解决的是同一常驻进程内部的模型选择策略——它与远程执行层（例如自托管 Runner 或独占远程 Mac）是正交关系：路由管「用哪档脑力」，执行层管「脑力跑在哪台机器上」。
另一个误区是把 modelRouting 当成「再套一层负载均衡」。它更接近基于上下文形状的路由：先估计规模，再选模型；而不是随机轮询。否则你会得到「看起来很聪明、账单很诚实」的意外组合。
二者不是互斥关系，但职责必须拆开：fallback 更适合处理「当前模型不可用/报错/限流」这类失败语义；modelRouting 更适合处理「这次请求到底有多重」这类成本/延迟语义。混在同一链条却不写边界，就会出现「路由先选了大模型，失败后又 fallback 到小模型」的双倍折腾。
| 维度 | primary + fallbacks（经典链路） | modelRouting（上下文分层） |
|---|---|---|
| 触发条件 | 错误码、超时、可重试的失败 | 估计上下文 token 规模阈值（如 context-size 策略） |
| 主要收益 | 可用性：把请求从故障模型上救回来 | 效率：让轻会话不吃重模型价签 |
| 典型风险 | 链路过长导致尾延迟与重复计费 | 阈值设错导致「该重的被轻判」或反之 |
| 观测重点 | 失败率、重试次数、模型切换原因 | 路由命中分布、阈值附近的误判率、token 分位 |
| 与 agents.defaults 关系 | 常在 defaults 上声明主模型与回退列表 | 在 defaults 下增加 routing 块，读取前即分流 |
把「失败才换模型」与「还没失败就先选对模型」写在两张纸上，你的 on-call 会少一半玄学排障。
落地时建议把路由决策日志（命中哪一档、估计 token 区间、最终模型 ID）打到结构化日志里；否则线上只会看到「最终模型」，无法复盘阈值是否合理。下文给六步清单，把这一步变成发布验收项。
下面六步面向「已经能改配置并上线」的工程师；每一步都对应可检查产物，避免 modelRouting 变成一次性 JSON 涂鸦。
冻结 SLO 口径：写下目标 p95 延迟、单会话可接受成本上限、以及「重会话」业务占比假设。没有 SLO，阈值只能拍脑袋。
抽样估计 token：用真实对话与工具输出样本估计上下文分布（含长尾）；不要只用平均会话长度。
先画三档模型：轻/中/重各绑定一个模型 ID，并明确「哪类任务永远不允许落在轻档」（例如多步工具编排）。
配置 modelRouting 与观测：把路由命中、估计 token、最终模型写入结构化日志；对接现有指标栈。
灰度与对照：先小流量双写对比（旧策略 vs 新策略），观察成本与延迟分位再全量。
回滚开关：保留一键回到「仅 defaults + 短 fallback 链」的配置快照，避免路由误配拖垮全局。
{
"agents": {
"defaults": {
"model": { "primary": "anthropic/claude-sonnet-4-5" },
"modelRouting": {
"enabled": true,
"strategy": "context-size",
"thresholds": [
{ "maxTokens": 4000, "model": "anthropic/claude-haiku-4-5", "description": "轻量" },
{ "maxTokens": 100000, "model": "anthropic/claude-sonnet-4-5", "description": "中等" },
{ "maxTokens": null, "model": "anthropic/claude-opus-4-5", "description": "超大上下文" }
],
"fallbackOnOverflow": true
}
}
}
}
提示：以上为结构与字段语义示例，真实键名与默认值请以你所用 OpenClaw 版本文档为准；升级 Gateway 前请 diff 配置并跑集成夹具。
实践上推荐的心智模型是：defaults 声明「默认主模型与通用回退」；modelRouting 在读取 defaults 之前或与之协作（取决于实现版本）完成按上下文的分流；fallback 仍然处理上游故障。上线前请在预发验证三件事：路由是否会在健康情况下频繁切换模型（若是，说明阈值过密）；fallback 是否在路由之后仍然符合预期；日志里能否区分「路由命中」与「失败切换」。
与远程算力结合时，常见拓扑是：Gateway 跑在 Linux VPS 或容器里，重工具链或 macOS 专属步骤通过队列派发到独占远程 Mac 执行层；modelRouting 只管 Gateway 内推理档位，不负责跨机器调度——后者仍应由你们的队列/Runner 解决。
若你把多租户 Agent 放在同一 Gateway，建议为不同租户配置独立路由画像或隔离密钥，否则「重租户」会话的上下文估计会抬高整体路由水位，拖累轻租户。
注意：fallbackOnOverflow 之类开关要与业务语义对齐：它是「模型上下文装不下时的兜底」，不是「省钱开关」。误用会导致悄悄截断或隐性重试。
下列症状与对策用于 on-call 快速分流；若持续出现「估计 token 与上游计费严重偏离」，优先检查工具输出是否未纳入估计或日志采样丢失。
fallbackOnOverflow 语义。把 Gateway 只放在一台「临时笔记本」或没有容量条款的机器上，路由再漂亮也会被 CPU 争用与磁盘抖动拖垮；而缺少独占、长期在线、可合同化的 macOS 执行平面时，工具链与本地构建步骤也很难稳定并入自动化链路。对需要把 OpenClaw 与 iOS/macOS 构建、CI 或 Agent 工作流长期绑在同一条生产 SLO 的团队，把重执行层放到独占远程 Mac 节点通常比反复堆叠临时环境更稳。综合路由策略与执行平面成本，NodeMini 的 Mac Mini 云端租赁适合作为底座：Gateway 侧用 modelRouting 控推理档位，执行侧用可独占节点承接重工具链，再把密钥与容量写进 Runbook。