先别问能不能更强，先问值不值
多智能体流水线的讨论，过去几年大多停在能力层面：拆开之后能不能解决单个模型解决不了的问题。arXiv 2610.37700 把问题换了个问法——这笔拆解划不划算。
论文由 Andreas Zettl 与 Diego Gosmar 两位作者完成，16 页，给了一个闭式模型：一边是协调税，等于拆解开销加上每次交接的协议成本；另一边是异构红利，等于把一部分活路由到更便宜的模型省下的钱。模型给出盈亏门槛，也给出一个可行性边界。
每一项都做了实测。以 Open Floor Protocol 为被测协议，在 135 道 HumanEval 与 ClassEval 任务上跑了 2430 次运行，覆盖六种架构，用的是 Claude Opus 5.5 与 Haiku 5.5。
贵的是拆解，不是握手
先说那个反直觉的数字。协议每次交接增加 7.2 毫秒，占整条流水线墙钟时间的 0.11%。也就是说，互操作协议带来的那点开销几乎可以忽略——如果多智能体流水线贵，原因不在协议。
原因在拆解本身。一个规划—编码—复查的流水线，成本是单次强模型调用的 3.22 倍，用时 3.24 倍，而解对的题并没有变多。这三条合起来的意思很清楚：在这批任务上，拆解是纯支出。
换便宜模型这条路，实测走不通
异构红利通常被理解成「给不同角色配不同模型」。这篇论文的实测否掉了这个方向。
把规划者与复查者挪到便宜模型上，流水线成本确实降到单次强模型调用的 0.39 倍。但 pass 值掉了 6.7 个百分点，整体仍然比单次调用更贵、更慢、更不准。更值得注意的是：盈亏预测偏了 19%，原因是便宜角色会写出更多词元。
这个偏差比数字本身更有信息量。模型换了，它写多少也跟着变；按角色配模型做成本估算时，把「行为不变」当默认前提，账就会系统性算少。任何一份给管理层看的多智能体成本测算，都得把这一项显式写进去。
省钱的地方在按题选模型
论文给出的出路是换位：不按角色拆，而按题目选。在两次单次调用之间做预言机式选择，能解决 94.3% 的运行，而每解对一题的成本只有强模型单次调用的一半。
但要读清楚这是上界，不是方案。预言机假定事先知道哪道题该用哪个模型；真实系统得先造出一个路由器，而路由器自己的判断成本要算进去。论文的价值在于指出省钱的来源在哪一处，而不是给出一个可以照搬的架构。
冷水与适用边界
规模要摆在明面上。135 道题、两个以函数级与类级为主的基准、六套架构、两款模型，结论首先属于编码类短任务。长程任务、工具密集任务、需要外部状态的任务里，拆解可能带来别的好处——比如上下文隔离本身的价值——这些没有被这篇论文测量。
协议那一侧也要留有余地：0.11% 的开销是在 Open Floor Protocol 上测的，换成别的协议、或者交接频率高出一个量级，这个比例未必守得住。论文用的是 Haiku 5.5 作为便宜模型，换成别的档位，便宜角色多写词元这件事的方向可能变。
对工程的含义：先量单调用基线
本站此前记录过多智能体工作流的另一批研究：有的在搜索拓扑，有的把同步轮流发言换成异步共享缓冲，有的把消息放进共享库按内容检索。那批工作回答的是「怎么组织更好」，这篇回答的是「组织起来值不值」——两件事不该混着谈。
落到可执行的动作上，顺序其实是反过来的：先把单次强模型调用的成本、用时与准确率量出来当基线，再考虑要不要拆。拆完之后如果只有逐条通过率变好而整单完成率没变，那多半不是拆解奏效，而是评估口径松了。至于按题路由，值得投入，但要先把路由器的判断成本当成一等公民——否则省下的钱会以另一种形式花掉。