一句话：多智能体协作，也该「按任务现场画图」
arXiv:2609.05774 提出 ReActNet，它想解决的是多智能体编排里一个被习以为常的尴尬：今天我们大多给一组智能体定好一张固定的通信拓扑——谁和谁连、信息怎么流，任务一来就照这张图跑。ReActNet 的提议是反过来：先看清这次查询要什么，再为它现场编译出一张只服务于这个任务的通信图。它来自 Katherine Tieu、Dongqi Fu 等研究者组成的团队，是一个无需训练、不依赖强化学习的框架。
为什么值得看：固定拓扑把「结构」和「任务」焊死了
多智能体系统近两年的主流做法是预设拓扑：有的全连接，有的按角色分层，少数会学一个拓扑但只在训练时定一次。问题在这张图和具体任务脱钩——同一个图既要应对数学推理，又要应对代码生成，还要应对需要调工具的助手任务，但不同任务真正需要的「谁告诉谁什么」差别很大。固定拓扑要么为覆盖所有情况而过度连接、徒增上下文开销，要么连接不足、关键消息传不过去。ReActNet 的角度是：结构不该是常数，而该是查询的函数。
机制拆解：把「编译」和「执行」拆开
ReActNet 的做法可以一句话概括——把一条查询和一组角色专长的智能体，编译成一串有向通信图，每个图快照对应一个推理阶段，每条边带一句自然语言指令，说明源智能体该把什么消息传给目标智能体。关键在于它把图编译和图执行分成了两步：编译阶段由控制器根据任务生成一系列逐步细化的图，执行阶段才让智能体按图做结构化消息传递——各自用历史状态加上邻居发来的消息更新自己的推理状态，最后由一个聚合器把各路状态综合成答案。编译和执行解耦之后，协作过程变得显式、可检查，也不再需要为拓扑去跑强化学习或梯度优化。
图里到底装了什么：让「何时、为何、如何传信息」可被设计
这套框架有意思的地方，是它把多智能体协作里常被忽略的三个问题——信息该在什么时候传、为什么传、怎么传——变成了图上的显式对象。每条边不是简单连一条线，而是带一句指令，规定源智能体要向目标智能体提供的具体内容；每个图快照是一个推理阶段，阶段之间靠控制器重新指派邻居关系来推进。协作不再是一个黑箱里的涌现，而是一张可以摊开来看、可以针对任务改的蓝图。在知识推理、数学解题、代码生成和类 GAIA 助手任务上，ReActNet 相比固定拓扑与学习拓扑基线都有稳定提升，同时推理成本保持在有竞争力的区间。
优势与局限：方向清楚，但仍是早期
它的长处是问题定义扎实——把「协作结构」从「模型能力」里独立出来，给出了可解释的、按任务生成的编排方式，且无需训练就拿到优于固定拓扑的结果。局限也同样明显：其一，编译阶段依赖控制器对任务的理解，复杂任务下生成的图质量直接决定上限；其二，目前仍在相对标准的基准上验证，真实企业工作流里的动态工具、长程依赖与失败恢复还没充分覆盖；其三，关于图快照数量与每阶段邻居规模有没有系统性的成本拐点，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。它真正的价值，是给「多智能体该怎么连」递了一把可以现场绘图的笔。
结语
ReActNet 提醒我们：多智能体的瓶颈未必在单个智能体够不够强，而在它们之间的信息流是不是被精心设计过。当协作结构能随任务现场生成、能被人摊开检查，多智能体系统才真正从「连上线」走向「连得对」。它未必是终局方案，但确实把编排这件事，从玄学往工程推了一步。