多智能体工作流跑起来之后，钱到底从哪来？最显眼的开销是模型调用——尤其是当你把所有子任务都丢给最贵的那个 frontier 模型。但「该用哪个档位的模型」这件事，在绝大多数框架里是甩给下游组件的：某个节点自己决定调谁，或者挂一个级联路由器现场猜。9 月 26 日提交 arXiv 的论文 Planner-as-Router（PaR，编号 2609.32917），提了个反直觉的安排：把选模型这件事直接织进规划阶段，任务还没跑，谁用大模型、谁用小模型就定好了。
PaR 的思路不复杂，但位置换了。规划器把一个问题拆成若干子任务的同时，给每一步标注一个模型档位——small、mid 还是 frontier，按能力和价格排序。于是子任务之间的依赖关系在任何人动手之前就摊开了：哪些步骤吃推理、哪些只是机械搬运，一眼可见。这和逐节点级联路由（cascade routing）是两回事。级联路由每到一个节点才看一眼当前上下文决定模型，既看不到整条依赖，往往还需要一个单独的路由器模型或训练数据；PaR 不需要这些，它只是把「选档位」变成规划的一个输出字段。
为什么要这么做？论文给的判据很实：成本。评测用的是 EntBench，一套覆盖七类、共 54 个企业级智能体任务的基准，打分方式不是空谈——真把生成的 SQL 和 MongoDB 查询丢到线上库里跑。在 1157 次评测、横跨 8 个路由器和 3 个随机种子的结果里，PaR 稳稳落在观察到的成本-准确率前沿上：相对「全用 frontier」的路由，它砍掉 44% 成本，只让出 2.9 分准确率；和一个只在末端节点用 frontier 的启发式（sink-frontier）花一样的钱，准确率还基本持平；比起忠实的 FrugalGPT 级联，成本更低。
但这里要泼半盆冷水。54 个任务的样本量下，几个准确率差距大多落在正负 6 分的置信区间里。换句话说，PaR 的优势更像是「站位」——它站在前沿上，同样的预算更稳——而不是在准确率上碾压谁。论文也老实交待了一个初步观察（明确说是假设、不是结论）：便宜路由在组合型工作流上可能藏着复利式的隐性惩罚。这恰恰提醒工程团队，路由策略不是银弹，组合任务的长期账还得自己量。PaR、EntBench 和全部评测代码都已开源，复现门槛不高。
把这篇放回 9 月的成本管理脉络看，位置就清楚。前几周业内一直在吵「frontier 模型和最便宜模型价差已经拉到百倍」「单默认模型是最贵的使用方式」——话都对，但落地的旋钮在哪？PaR 给了一个具体旋钮：别在节点层临场选模型，去规划层统一选。它和「小模型干例行、大模型干难活」这种老生常谈的区别，在于把依赖图显性化，让省下来的每一分钱都有出处。对企业的可操作建议很直接：如果你的多智能体工作流已经上量，先统计每个子任务的真实成本-准确率贡献，再决定哪些步骤值得上 frontier——而不是默认全上。这种「先量化、再分级」的顺序，比任何现成的路由模板都更经得起规模考验。
留一分清醒：44% 与 2.9 分都是论文自报数字，基准是 EntBench 七类企业任务，跨出该分布的表现要靠社区复现；「组合工作流的复利惩罚」目前只是假设，尚未经验证；论文未给出不同档位模型供应商组合下的边际变化。但方向值得记一笔：当模型价差被拉到百倍，路由从「运行时即兴」升级为「规划时决策」，可能是多智能体系统最划算的一次工程化。