8 月 19 日，Swarms 团队发布 GraphWorkflow 论文：把预先定义好的多 Agent 任务图编译一次、反复执行，降低运行时编排开销；在 10/50/200 节点的静态图上，相较 LangGraph 1.0.4 最高提速 62.5%，稳态几何均值约 7 倍。
但要注意：这个 benchmark 是单机、同步、静态 DAG，节点甚至可以是 no-op；它不测模型质量、不测真实 token 吞吐。真实系统里一次模型调用动辄几百毫秒到几秒，几毫秒的调度优化不可能让端到端快 7 倍。所以那个数字的意义不在于“框架争霸”，而在于——当 Agent 节点膨胀到几十、上百个，编排本身已经是一笔独立且可观的算力开支。
一、“蜂群”这个词，先别浪漫化
工程上常见的多 Agent，往往不是鸟群、蚁群那种完全去中心化系统，而是一个临时项目组：
• 主 Agent 拆解、收束
• Worker 分头检索 / 调用工具 / 写代码
• Verifier 验收、回退
• 很多路径在运行前就已画成 A→(B∥C)→D→E
可以按复杂度粗略分五层：
形态 特点 典型场景
单 Agent 上下文连贯、线性 短任务、单工具链
Supervisor/Worker 当前最成熟 研究、检索、复杂工程
Graph Workflow 流程稳定、可预期 合规审查、批量处理、测试流水线
动态蜂群 运行中决定是否再拆 Kimi Agent Swarm、WebSwarm
完全去中心化蜂群 局部信息、集体行为 研究/模拟，离生产尚远
所以，蜂群的本质不是一个“新物种”，而是一个组织问题：多个有一定自主性的 Agent，如何分工、通信、共享状态、相互验证。
二、为什么要组织起来：把“一条路想到底”拆开
单 Agent 变强不假，但面对工作面过宽的任务仍会瓶颈：
• 多源事实相互印证
• 十几条安全线索并行验证
• 跨模块、持续数小时的软件工程
• 同一答案的多路径搜索
单上下文越挖越深，容易路径锁定。多 Agent 的价值是让不同节点走彼此独立的路径：有人查公开资料、有人看原始文档、有人反证、有人压缩成可交接结论。
Anthropic 公开过一组内部数据（Opus 4 统筹、Sonnet 4 做子 Agent）：
• 复杂研究评测比单 Opus 4 高 90.2%
• 3–5 个子 Agent 并行，研究时间可压缩约 90%
• 代价：普通 Agent 约 4 倍 token，多 Agent 约 15 倍
这组“收益 vs 账单”比 90.2% 更关键：蜂群不是让一切变强，而是用更多计算与复杂度，换更宽的搜索面和更多独立尝试。
国内产品更激进：Kimi Agent Swarm 宣称可动态协调 300 个子 Agent、超 4000 次工具调用，大规模搜索相对单 Agent 约快 4.5 倍、BrowseComp 15.9→33.3（均为厂商披露，证据等级别混）。
三、2026 的转折：多 Agent 不再天然加分
2026 的系统研究显示，260 种配置、6 个 benchmark、5 种架构、3 个模型家族下：
• 多 Agent 相对单 Agent：最好 +80.8%，最差 −70%
• 结构化、可并行的金融推理受益
• 强顺序依赖的规划任务，越协作越乱
软件工程 benchmark 上还有一个经验边界：单 Agent 基线超过约 45% 时，多 Agent 正收益概率明显下降（不是跨领域定律，只是该任务集的规则）。
这和人类团队一致：一个熟练工程师 2 小时能干完的活，拉 8 个人不会变成 15 分钟——同步背景、确认接口、合并结果、处理分歧，协调本身吃掉时间。AI 团队更硬：每次委派要写清边界，每次交接要压缩上下文，每次汇总要裁决冲突，每个 Worker 都额外烧 token、工具和运行时。
真正决定扩展效果的，是“独立且有用的探索通道”；Agent 数量只是表面指标。
一组相同 prompt、相同工具、相同资料的 Agent，往往只是复制同一种偏见——这就是 diversity 问题。预印本研究发现：两个真正异质的 Agent，有时可等于或超过十几个同质 Agent。方向很清楚：难点从“扩编”转到“制造有效分歧”。
四、GraphWorkflow 的启示：组织层开始自己吃算力
GraphWorkflow 没换模型，只解决一件事：工作已是一张多节点图时，图怎么跑。
它的取舍是：
• 针对预先确定的静态 DAG
• 先做依赖分析、编译，再执行
• 换来更低编排开销
• 但不能等价替代支持循环、条件边、持久状态、复杂运行时控制的通用框架
价值在于“分层意识”出现了：
上层：模型 + 工具
下层：任务图、调度器、状态合并、检查点、资源分配、失败恢复
10 节点时调度慢点没人介意；200 节点时就会出现“人类组织也会遇到的问题”：谁在等前置、谁可并行、谁失败要重试、谁的结果覆盖谁、预算快烧完砍哪些分支。调度从附属功能，变成系统稳定性的一部分。
五、委派、记忆、验证：蜂群的三块硬骨头
1. 委派
该不该拆、拆几份、谁来做、何时直接自己做——SearchSwarm 一类研究开始把“是否委派、向谁委派”训练成能力，子 Agent 只回传压缩证据，避免把完整搜索轨迹塞回主上下文。
2. 记忆
蜂群要的不是“用户喜欢什么”的聊天记忆，而是一张可更新的证据图与任务图：
• 结论来自哪些来源
• 哪条假设已被推翻
• 谁负责什么、花了多少钱
• 哪些工作尚未验收
全量转发长对话只会淹没系统；现实做法是只传递支撑下一步的最小状态，且必须可追溯、可被推翻。
3. 验证
“多讨论就更可靠”是错觉——相近资料 + 相近 prompt + 相近奖励，会让 Agent 互相强化错误。研究观察到：
• 无中央协调者时，LLM 群体会形成共同约定与集体偏见
• 多 Agent 任务效用可能更高，但对齐表现比单 Agent 更差
一项错误传播实验（仅该设置下）：
• 独立 Agent 架构错误放大最高约 17.2 倍
• 带中央验证架构约 4.4 倍
结论实用：成熟蜂群里最稀缺的角色，未必是再多一个 Worker，而是能独立验收、打回重做、在高风险动作前暂停的 Verifier。
六、风险层面：从 prompt 注入，升级为“网络传播”
单 Agent 被 prompt injection 已够麻烦，蜂群把它放大：
1. 被污染的 Worker 把恶意指令写进共享记忆
2. Planner 把记忆当可信状态
3. 有权限的 Agent 据此执行动作
这就是 Agent Worm / 间接 prompt injection 的研究方向：污染不一定直攻高权限 Agent，而是先落入普通工作节点，再沿消息、记忆、任务图逐跳放大。因此企业部署必须改成“网络安全思维”：
• Worker 最小权限（“只是检索”也不该默认读生产库）
• 共享记忆标记来源与传播范围，默认可疑
• 高风险动作独立验证 + 人工审批
• 日志不只记最终答案，而要记录：哪个 Agent → 哪份材料 → 哪次工具调用 → 哪条结论
100 个 Agent 运行时，必须能回答：谁可以做什么、花了多少、为什么做、出错谁负责、如何停下。
七、未来的蜂群，未必像一家公司
CEO / 市场 / 产品 / 工程一排头像，直观但容易误导——不是把人类部门结构复制一遍。
更合理的形态是短命、工具化的临时拓扑：
• 进入任务先判断风险、预算、依赖、可并行度
• 可独立展开处临时生成不同类型 Agent
• 强顺序部分留给主 Agent / 图工作流
• 关键结论交验证器
• 任务结束组织解散，下次任务再长新的
WebSwarm 一类递归研究就在探索：Agent 途中决定“自己解决 or 再生成子 Agent”，拓扑从一棵预先画好的树，变成运行中长出的计算图。
但也不是越动态越好——预算失控、无限拆分、权限绕行、错误回溯难。生产系统大概率走中间路线：上层保留规划、权限、验收，下层允许局部探索与动态重组。主流蜂群可能更接近“有边界的临时小队”，而非无中心蜂群。
八、对创业者的变化：从“换更强模型”到“组织能力”
长任务、多步骤、多人协作、高风险场景里，拉开差距的往往是模型之外的东西：
• 如何拆解
• 怎样授权
• 状态怎么留存
• 错误如何恢复
• 结果如何验收
• 成本如何控制
所以这一轮同时出现 MCP、A2A、工作流引擎、Agent Harness、可观测性、评测，并不偶然：
• MCP：接入工具与能力
• A2A：Agent 间通信
• 工作流/Harness：组织与执行
• 记忆层：可传递状态
• 评测/可观测：判断对不对、为什么对
缺任何一环，蜂群都容易退化成“一堆同时输出文字的窗口”。
最该避免的也许是 “Agent 数量焦虑”：不必先问“能不能调度 100 个”，先问“用户的问题有没有 100 条值得独立探索的路径”。没有，就用单 Agent + 好工具 + 清晰状态 + 验收机制，通常更便宜更可靠。
只有当任务确实可分解、每条分支有独立信息增益、结果又能交叉验证时，蜂群才产生复利。
回到标题
GraphWorkflow 的新闻没有证明“谁取代谁”，也没有证明“Agent 越多越好”。它只是把一件事摆到台面：
多 Agent 已经多到需要有人专门优化“它们怎么一起工作”。
模型竞赛还会继续；下一轮 agentic 系统的差距，很可能不只在于谁有更强的大脑，而在于谁能把有限的大脑，组织成一支不浪费、不失控、能交付的队伍。
