多智能体系统并行跑长任务时，常常出现一个反直觉的现象：明明在并行，速度却提不上来，甚至更慢。问题不在算力，而在通信拓扑——agent 的时间大量漏在等待同伴、或重做同伴已经做过的事上。10 月 4 日更新到 v3 的 arXiv 论文 DeLM（编号 2606.10662，作者 Yuzhen Mao、Jerry Gu、Azalia Mirhoseini 等）给出的解法很干脆：把中央主 agent 换成一块共享上下文加一个任务队列，把那些漏掉的时间挤回去。
三种拓扑，三种气泡
DeLM 先把多智能体并行里的浪费拆清楚。独立 agent 各干各的，彼此不共享，于是会把同伴已经找到的事实再发现一遍；对等式通信要等同步轮次，进度卡在回合边界，谁慢谁拖全队；集中式编排下，主 agent 阻塞在子 agent 上，所有进度都要经它中继。三种通信方式，都让 agent 的时间花在等待与返工，而不是真正推进任务。论文把这类空闲统称为气泡，并指出它们才是长程任务里并行加速比上不去的根因。这个观察和多智能体效率的其它近期工作相互呼应——SquidAgent 从「何时该并行」切入，DeOrch 从「自动编排」切入，而 DeLM 选的是通信架构这条线。
共享上下文加任务队列
DeLM 的做法，是用 Decentralized Language Models 这个框架取代中央编排：放一块共享上下文，再配一个任务队列。agent 异步地从队列里认领任务，一有发现就立刻发布，并可以基于或纠正同伴的进度，每个 peer 的状态对所有人可见。它不动底层模型，而是架在既有 agent harness 之上——这意味着不需要为它另起一套运行时，直接贴在现有系统外面就能用。关键改变是，agent 不再等一个主 agent 来分配与中继，而是自己看全局状态、自己领活、自己交活，气泡因此被持续压缩。
实测数字与定位
在 Terminal-Bench 4.0、DeepSWE v1.1 与 SWE-bench Verified 上，DeLM 比 Codex、Claude Code、原生子 agent 与 AOrchestra 都更准也更快，较表现最佳基线准度提升 17.5 分，较其所建基座快 2.49 倍；在 ProgramBench 上，120 分钟预算内测试通过率高出 19.9 分。这些数字说明，通信架构的改动带来的增益是实打实的，而非边际。它和 SquidAgent、DeOrch 构成互补的三条路线：一个管「该不该并行」，一个管「怎么自动编排」，一个管「怎么通信才不堵」。三者共同把多智能体系统的下一个增量，从更大的模型挪到了更省摩擦的组织方式。
边界与未定项
冷静看待，DeLM 的共享上下文虽然省了气泡，但也把「全局状态一致性」这道题摆到台前：当多个 peer 同时读写共享上下文，谁来保证不互相踩、不写脏，论文对此的取舍仍要看实现细节。另一个要分清的点是，它在软件工程类基准上表现突出，跨域任务与真实生产流量下的稳定性，目前官方及行业暂未披露更多细节。共享状态还带来新的攻击面——一旦上下文被投毒或篡改，影响会被所有 peer 放大。对想跟进的团队，更稳妥的起点是先在小范围、低权限的任务上试用异步任务队列，再逐步放开共享范围。后续将持续跟进迭代动态。
一句话收尾：多智能体并行慢下来，往往不是因为算得慢，而是因为等得久、重做得多，把主 agent 换成共享上下文与任务队列，气泡就被挤掉了。