把路由放进云上日常：预算闸门与只读执行
装完插件只是开始。模型路由工作台（Alice-Marx/dsh-model-router，社区插件，非官方）真正的用法是把它放进每天的工作流：先在本地把任务拆开、比一遍已配置的路线，再决定这一轮用哪个模型、走哪条执行通道、花多少钱。
在云上做这件事，最容易错的一步是把"预算"当成"账单上限"。这个前提不摆正，后面所有配置都会歪。
预算闸门有三道，一道比一道松
第一道是单轮目标。规划时填一个估算预算，单位美元，填 0 表示移除这条约束。它只影响这一次规划的候选筛选。
第二道是日/月检查。插件的「预算与安全」页里有日预算和月预算，超了之后有两种处置：降级到省钱优先（economy）预设，或者暂停等你确认。降级不是偷偷换个便宜模型跑完，它会重走一遍分配搜索：省钱预设把质量/费用/延迟权重分别乘以 0.75/1.6/1.1，下限降低 0.04。
第三道是你自己的账。0.15.0 起保留最多 90 个有数据日期与 24 个月的支出聚合，只记金额与计数，不含任务或回复内容。被裁剪的详细运行、被重试替换的结果，花费仍然保留。
关键的一句：这三道都是本地核算与估算控制，不是厂商侧的硬性账单上限。规划器的 token 是按文本长度估的（max(80, ceil(n/3.7)) 起步，输出基础 900、最少 220），不是厂商 tokenizer；价格是你手填的美元/百万 token。厂商账单才是权威。
还有一个细节值得记住：正预算下若找不到可行分配，插件仍可能返回最小费用备选，但会标 budgetFeasible: false。显示了计划，不代表预算已满足。
三种执行边界，别把名字记混
这三个词在插件里是硬边界，不是风格偏好。
只读：routed
工作台选「模型路由（只读）」，对应会话工具 model_router_execute。它按执行/计费策略走受支持的无头 CLI 或 Harness 模型 API，记录结果，不改文件。云上日常的绝大多数检查都该停在这一层：看仓库结构、列布局问题、审一遍计费边界。
注意只读不等于"只看工作区"。README 明确提示，只读 CLI 标志不一定把读取限制在工作区内，Codex 的可读范围尤其广，装之前该看一眼「安全边界」。
workspace-write：隔离 worktree
可编辑团队走这条：需要干净的 Git 根目录、需要有 HEAD 提交、需要 Host 批准。插件会创建一个 detached 的隔离 worktree，各包在里面顺序执行，全部成功后才对源目录算二进制 diff，git apply --check 通过再应用补丁，不自动提交。
worktree 的作用是分离和收集修改，它不限制 OS 访问。把它当成沙箱是常见的误解：只有你选的 Harness 环境才提供操作系统边界。
cli-native：沙箱外，用你的 OS 用户权限
只有"可编辑官方团队 + workspace-write + 厂商 CLI 正常环境"这一种组合能选它，而且单独要求确认。它以当前用户权限运行，sandboxEnforcement: "none"，在 Harness 进程沙箱之外。厂商 CLI 自己的 skills / MCP 在支持并加载时可以使用，能影响到工作区以外的文件或服务。
这条路上还有两个容易忽略的点：它不会自动切换环境，也不会自动回退到 API。以及每次新启动、每次重试都要重新给写入或免沙箱授权——预览不是长期有效的审批令牌。
也正因为这条路在沙箱外，安全档位要看清楚：🔵 扫描记录 158 处敏感能力证据，人工评估仍是空白，站点亦未给出风险分级。扫描是能力清单不是危险判定，但 cli-native 这条路应当少用、短用。
订阅优先、冷却，以及那句 ask
默认策略是优先用已检测到的 CLI 账号订阅，或已配置的 coding-plan 路线。尝试 CLI 订阅时会移除 API-key 环境变量，避免两套计费混在一起。billing 可以设成 subscription-first、api-only、subscription-only 三种。
跑着跑着会遇到两类失败，处置完全不同：
配额耗尽 / 限流。 该订阅进入冷却，可以按策略在它配置的 API 路由上重试这一步。冷却状态写在 state.json 里，重启不会丢。
其它订阅失败。 默认暂停，也就是 onSubscriptionFailure: "ask"。暂停后你在历史里三选一：API 重试、订阅重试、取消。记住一句：托管的可编辑、单工具、团队运行不会自动在 API 上重试，所以云上挂着跑时"卡住等人"是设计行为。
记账口径：CLI 上报的金额优先
这是最容易把账算错的地方。规则是分层的：
CLI 上报的合法 USD 金额（包括明确的 0）优先于 token 计价。没有上报金额时，才按 token 算，而按 token 算需要三个条件同时成立：用量完整且已归一化、价格已知且非负、报告的实际模型能匹配某个已配置模型或其显式 CLI 映射。缺一个，金额就是 null——不是 0。
null 和 0 的区别在日预算上是致命的：0 会被算成"这轮免费"，null 才是"不知道"。同理，价格栏未知就留空，填 0 会污染成本估算。
经适配器归一化后，输入、输出、缓存读取、缓存写入四类计数互不重叠，别把缓存 token 再加到已包含缓存的输入上。订阅运行显示 referenceCostUsd，costUsd 保持 null，参考费用不计入 API 支出。
云上日常怎么排
我的建议是三层分工，按"花钱"和"碰文件"两个维度切：
第一层，规划在本地。 生成路由建议是纯本地启发式算法，不启动厂商 CLI、不发起付费调用。这一层可以随便跑，改任务、改模式、改预算反复试都行——改任务文本或路线配置会让旧建议失效，那也是免费的。
第二层，只读检查在云端。 常开的 ECS 适合跑 routed 这一层：网络稳定、出网策略可控、失败了不影响本地环境。跑完看历史里的通道、费用与失败原因。
第三层，重活留在受控环境。 需要改文件、需要多包依赖、需要跑很久的，放回你自己的开发机或一个专门的受控工作区，用 workspace-write 加干净的 Git 仓库。cli-native 只在明确知道后果时用，不要设成默认。
再配两条纪律：每轮开始前看一眼日预算余额；每周翻一次历史，把"费用未知"的路线补上价格或干脆删掉。剩下的交给冷却和 ask 就够了。
总结
把路由放进云上日常，核心不是省钱，而是让每一次花钱都有据可查：预算闸门管住上限感，只读执行管住手脚，订阅优先与 ask 管住意外。
适合与不适合
适合：每天要跑多轮文本/代码任务、想按任务难度分配模型的团队；已经有订阅又有 API 额度、需要决定先走哪条计费通道的人；在云上跑只读检查、把可编辑执行留在受控环境的团队；愿意手工维护价格与质量分的人。
不适合：要求预算必须等于厂商账单上限的人——这里全是本地估算；想靠它自动管住成本的团队——质量分要自己填、价格要自己填，填错就一路错；需要开箱即用的托管执行的人——0.22.2 没有已验证的端到端厂商执行。
标签：模型路由工作台、DeepSeek Harness、阿里云、预算控制、执行边界
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
