搭建 Multi-Agent 架构其实到现在也没有一个可以就是作为一个核心统一的那种扩展性强，泛化好的核心。 很多的研究集中在这个多 agent 架构的各个… · @snwiki238337 · TwKit

@snwiki238337

搭建 Multi-Agent 架构其实到现在也没有一个可以就是作为一个核心统一的那种扩展性强，泛化好的核心。 很多的研究集中在这个多 agent 架构的各个 agent 之间的博弈上。但是忽略了其他的比如共享状态、上下文上。 这篇论文 Mining the Design Space of Multi-Agent Workflows，总结了一下目前多 Agent 发展的这个忽视的地方和接下来的 agent 的开发原则、规范。 简单来说的话，过去像 AFlow 这类用 MCTS自动化寻找最优 Agent 工作流的方法，最终只会保留单条最优路径，成千上万次探索生成的中间代码与执行轨迹都被直接丢弃了。 作者基于 6 种可组合算子和 26 个强逻辑验证任务，完整保留了 MCTS 全量探索痕迹，构建了包含 28,568 个可执行 Multi-Agent 工作流的庞大数据集。 随后引入沙盒化 AutoResearch 挖掘循环，在稀疏化惩罚的目标函数下进行特征回归与跨任务泛化检验，最后呢是得到了几个结论： 很多工程架构习惯一上来就让多个 Agent 独立思考后做单步汇总聚合，但在高复杂度逻辑任务中，这不仅不会带来增益，反而引入了严重的早期噪声干扰。 第二个就是关于共享状态管理的，目前很多开源框架推崇多智能体互相之间的博弈容易发展为不是我们预期的事件。 但实验证明维护一份持久化的集中式共享文档/黑板记忆，比互相通信辩论的效果高出足足 13.5%。对长链推理来说，同步确定性的上下文状态远比一个博弈论要高效。 最后就是图结构，大家往往热衷于把调用图画得花里胡哨，但深入挖掘发现，算子内部的 prompt specificity 以及精准的占位符上下文路由，带来的收益提升高达 11.8%，影响力完全不亚于重写整套 Agent 拓扑。 其实这篇文章给日常做 Agent 开发、研究都有一些意义，其实你说这个论文对于 agent 发展的论点其实不大，甚至是心知肚明。 但是我们很好写出来做实验证明出来，我们在做编排、设计的时候往往都过于注重博弈、图结构的设计。但是忽视了上下文和状态管理。 arxiv：https://arxiv.org/abs/2610.31709

曝光 127 · 评论 1 · 点赞 1 · 书签 2