多 agent 系统中子 agent ，绝大部分都有问题，第一个是他的 token 消耗高。第二个延迟高。 斯坦福大学 Azalia Mirhoseini … · @snwiki238337 · TwKit

@snwiki238337

多 agent 系统中子 agent ，绝大部分都有问题，第一个是他的 token 消耗高。第二个延迟高。 斯坦福大学 Azalia Mirhoseini 团队的这篇 Decentralized Multi-Agent Systems with Shared Context 用分布式系统里流水线并行的概念，把当前多智能体协作的低效根源总结为气泡，意思就是说即 Agent 在等其他 agent，或者重复 agent 已经踩过的坑上的耗时。 在 Terminal-Bench 4.0 的长程任务上，Claude Code 开启原生中心化 Subagent 后，主 Agent 有 73% 的时间在等子任务返回。 整个系统 44% 的 Agent 算力时间都费在等待气泡上，而在 DeepSWE v1.1 的复杂仓库调试中，开启 Claude Code 原生 Subagent 甚至让准确率从单智能体的 71.67% 跌到了 50.00%，耗时和成本却分别涨了 15.9% 和 65.1%。 为了彻底去掉这些气泡，团队提出了 DeLM 框架，在 Codex 和 Claude Code 等现有底座上彻底砍掉中心化的 Main Agent，改用状态化共享上下文+ 异步任务队列让所有 Agent 平权自治协作。 所有 Agent 共享一个只追加的状态日志，一旦某个 Agent 跑出了可用的中间结论、确认了某条死胡同或完成了子模块，无需等整个任务结束就立即发布精简摘要。 代码文件则通过引用挂载，队友平时只读取最新摘要，需要细节时才查看 Diff 或合并到本地工作区。 在 720 条真实长程轨迹中，Agent 之间跨工作区导入共享文件达 5,237 次，且 80.3% 的轨迹会主动拉取其他 agent 后续迭代的修正版，而读取共享上下文的开销仅占总任务成本的 1.7% 到 3.7%。 任务队列采用先抢先得的机制，每个任务的归属人以及每个 Agent 的实时会话状态对全员透明。 论文展示了一个例子，在优化光学器件参数的任务中，Agent 1 和 Agent 3 一开始调同一组端口参数，Agent 1 读取共享上下文发现 Agent 3 刚刚认领了完全相同的 5 个参数，杀掉自己的冗余搜索进程，去优化材料图案全程没有任何中心节点干预，自己就完成了去重与负载均衡。 在中心化架构里，下游模块必须等上游子 Agent 全部跑完、再经主 Agent 总结转发才能开工。而在 DeLM 中，上游 Agent 刚写出初版脚本就立刻发布到共享区，下游 Agent 马上就能拿真实中间数据。 在 Claude Opus 5.5 底座下，双智能体 DeLM 在 Terminal-Bench 上拿下 93.33% 准确率，耗时 64.77 分钟。 四智能体下提速2.49 倍，等待气泡从 44% 降至 2%。在 DeepSWE 上，DeLM 准确率达 90.83%，比最强中心化基线 AOrchestra 高 7.5 个百分点。在 GPT-6-Astra 底座下是 98.33% 的近乎满分。 在 DeepSWE 长程任务上，仅用轻量级 DeepSeek-V4.1-Flash 跑双智能体 DeLM，就能把准确率从 76.67% 升到 88.33%。 搭配 Gemini 3 Flash 在 SWE-bench Verified 上取得 66.08%*解决率。在给定 120 分钟预算从零重写的 ProgramBench 上，四智能体 DeLM 用 60 分钟追平 Claude Code 跑满两小时的测试通过率，终局通过率更是 18.96 和 19.91 个百分点。 文中也做了消融实验。单独去掉中间结果早发布、agent 的状态可见或持久化共享上下文中的任何一个机制，双 Agent 的速度立刻从 1.54x–2.02x 变回了0.82x–1.09x。 这说明没有高效共享底座的并发，纯粹是在烧钱制造等待气泡。更赞的是作者直接开源了可插入 Codex 和 Claude Code 的插件，平时重度使用 Coding Agent 的开发者非常值得一试。 arxiv：https://arxiv.org/abs/2606.10662

曝光 92 · 评论 1 · 点赞 0 · 书签 0