前几天，我把一个更便宜的模型接进多 Agent 工作流。原计划是让它先执行，遇到难题再交给 Codex。
评测尚未完成，小时额度已经耗尽。执行过程中又数次偏离目标，需要 Codex 打断、纠正并重新指派。
调用单价确实便宜，但等待、重试和人工接管加在一起，交付反而更贵。
这次经历改变了我对模型成本的看法：成本指标应从单次调用价格，转向单位合格结果成本。
分流依赖可验证的失败
微软最近公布了一套多模型安全系统。它没有让最强模型处理所有步骤，而是把专用模型放进漏洞管理流程。微软称，新配置在 CyberGym 上达到 96%，相对现有商用配置节省接近 50%。
这个数字是微软自报，也只适用于它的安全工作流，不能直接套到其他系统。但它证明了一条值得验证的路线：常规任务由便宜或专用模型处理，少数难题再升级。
Together AI 的 DeepSWE 实验把这条路线拆得更细。研究者对 113 个编程任务跑了 904 次测试：单次执行时，GPT-5.6 Sol 成功率更高；多次尝试时，Kimi K3 覆盖更广、单次成本更低。
更值得关注的是组合方式：先让 Kimi K3 执行，测试失败后再升级到 Sol，在这组数据中达到约 85.6%，平均每个任务约 7.30 美元。
这套方法有一个不能省略的前提：测试必须能够判断结果是否失败。
如果没有单元测试、规则校验或明确的验收条件，系统根本不知道何时应该升级。所谓模型分流，就会退化成“先用便宜模型试试，不行再靠人发现”。
这也说明，可靠的分流并不是在任务开始前猜一次“哪个模型最合适”。更实用的做法是设置两道闸门：先根据风险决定任务能否进入自动流程，再让执行结果接受测试。测试通过就交付；测试失败、超过重试次数或触碰风险条件，才升级到更强模型。前一道闸门控制错误代价，后一道闸门提供升级证据。
例如，修复一个有完整回归测试的内部工具，可以先交给低成本模型；测试不过，再升级。给客户解释退款政策则不同：语句是否通顺很容易检查，政策是否准确却未必有可靠的自动判定条件。此时把便宜模型放在第一棒，可能只是把审核压力转给客服。
而我那次 K3 实测，成本正是这样产生的。它不是一场受控横向评测，不能说明某个模型总体更强或更弱；它只说明，没有可靠验收时，省下的调用费很容易被等待和人工纠偏吃掉。
任务风险决定模型去向
设计模型分流时，我现在只问三个问题。
第一，失败能否被机器明确检测？
有测试套件、格式校验或业务规则，结果可以自动判定，适合让便宜模型先跑。只能靠经验判断“看起来对不对”，就不适合自动升级。
第二，错误是否容易撤销？
生成草稿、整理数据、本地改代码，失败后通常可以重试。对外回复、修改权限、执行交易或发布内容，一次错误的代价可能已经超过模型差价。
第三，重试和纠偏是否仍然划算？
如果一个任务需要多次执行，还要投入人工监督、修改与重新派发，就应直接使用更稳定的模型。
这三个问题可以迁移到 Coding Agent、企业客服、批量数据处理和安全扫描。失败明确、容易重试的任务，便宜模型先跑；难验收或错误代价高的任务，强模型直达；不可逆且责任敏感的动作，保留人工确认。
模型分流的本质是为任务划定边界。测试套件决定系统何时升级，人工纠偏决定节省是否真实存在。
需要持续优化的，是单位合格结果成本。
