多智能体并行这件事，直觉上该接近线性加速：多雇几个 agent 同时干，总比一个 agent 慢慢磨快。可现实里不少并行系统跑出来比单 agent 基线还慢，问题到底出在哪。10 月 6 日挂上 arXiv 的 SquidAgent（编号 2610.08647，作者 Yexiong Lin、Shanshan Ye、Yu Yao、Zhen Fang、Bo Han 与 Tongliang Liu 等）把这笔账算清楚了：并行省下的墙钟时间，常常被两笔隐性成本吃掉，而它用一套以 token 预算为核心的判据，把这件事重新摆平。
两笔被忽视的账：重探索与对齐
SquidAgent 的核心观察是，并行执行相对串行会凭空多出两类开销。其一叫重探索：并行 worker 各自从零重建上下文，而其中不少判断编排者其实早就有了——比如之前做过的决策、已经探明的约束，串行执行时会天然继承，并行时却被每个 worker 重新推导一遍。其二叫对齐：多个 agent 独立产出结果之后，还要把这些彼此不一致的输出 reconciling 成一份，这本身又是一笔不小的开销。论文指出，正是这两笔账，让许多本该更快的并行系统反而慢于单 agent。这个判断和社区里另一个常见直觉吻合：简单地把任务切开分给多个模型，往往得不到线性的加速比，瓶颈不在算力，而在协作的摩擦。
用 token 预算代替墙钟时间做决策
要决定某一层该不该并行，最自然的想法是比较墙钟时间，但 SquidAgent 偏要用预测输出 token 数。理由是模型对任务耗时的估计并不可靠，可对自己大概要吐多少 token，估计得稳得多。于是它在一次规划里就把所有 token 预算估出来，给出一条原则性的判据：只有当某一层的临界路径成本，加上重探索与对齐的开销，低于对应的串行成本时，才值得并行。这个判据虽然本意是墙钟，但落地时换成 token 来算，反而更可操作。
两招消掉摩擦：fork 与约定块
判据定好之后，剩下是工程实现。SquidAgent 的其一，是把每个 worker 直接从编排者的会话 fork 出来，而不是各起炉灶——这一下子抹掉了重探索成本，因为 worker 天然继承编排者已有的上下文。其二，是把事后才做的对齐，换成事先生成的一段共享约定块：大家开工前就约定好输出格式与口径，对齐从一处不可控的收尾，变成一笔有界的前置成本。最后由一个确定性调度器逐层套用那条判据。实测下来，较 Claude Code 吞吐提升 2.2 倍、墙钟提速 2.6 倍，较表现最佳的多智能体基线吞吐也提升 2.0 倍。
放到多智能体效率的图谱里看
把 SquidAgent 和近期的其他工作摆在一起，能看出两条不同的解题路线。一类如 DeOrch，做的是自动编排本身——把任务分解与工人选择解耦，让换队伍不用重训；另一类如 DeLM，动的是通信拓扑——用共享上下文和任务队列挤掉并行气泡。SquidAgent 则卡在它们中间偏工程的一侧：它不重新训练编排器，而是先回答「什么时候该并行」这个被长期忽略的前提问题。三者的共同指向是，多智能体系统的下一个增量不在更大的模型，而在更省摩擦的组织方式。不过要冷静看待，论文的基准集中在代码与软件工程类任务，跨域泛化与真实生产流量下的稳定性，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
一句话收尾：多智能体并行省下的时间，常常被重探索和反复对齐悄悄吃回去，真正难的是先算清该不该并行。