GraphWorkflow 提速62.5% 后，Agent 蜂群真正要解决什么？

本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《GraphWorkflow 提速 62.5% 后，Agent 蜂群真正要解决什么？》

8月19日，Swarms团队发布了一篇关于GraphWorkflow的论文。把预先定义好的多Agent任务图编译一次，再反复执行，以减少运行时的编排开销。

论文拿它和LangGraph 1.0.4比较，在10、50、200个节点的静态图上，报告了最高62.5%的加速，稳态几何平均约为7倍。

又有一个Agent框架跑得更快了。

但把论文的方法和限制一起读完，会发现更值得看的东西不在那个数字里。它测的是单机、同步、静态DAG的编排开销，节点甚至可以是no-op。它不测模型质量，不测真实token吞吐，也不意味着一个真实Agent系统会整体快7倍。真实的模型调用要几百毫秒甚至几秒，几毫秒的调度优化不会神奇地把一切压缩到十分之一。

可也正因如此，GraphWorkflow反而把一个新问题照得很清楚：当一个任务里开始有几十、上百个Agent节点时，模型可能还在思考，系统已经先忙着安排谁该等谁、谁把结果交给谁、失败从哪里续跑、共享状态怎么合并。

过去大家主要盯着模型这颗脑袋够不够聪明。现在，脑袋一多，问题开始变成：怎样让一群已经足够聪明的脑袋不互相浪费。

这就是Agent蜂群真正开始进入工程阶段的信号。

一、“蜂群”不是同时开十个聊天窗口

先把一个最容易被营销话术弄乱的词说清楚。

今天只要多个Agent同时跑，很多产品都会把它叫作Swarm。严格来说，这个词原本指向更强的东西：没有固定中央控制者，个体只根据局部信息行动，整体却形成某种集体行为。蚂蚁找路、鸟群转向，是这种意义上的蜂群。

而眼下工程上有效的多Agent系统，大多没有这么浪漫。

它们通常有一个负责拆解和收束的主Agent；有一批各自查资料、调用工具、写代码或执行局部任务的Worker；有时还会再放一个Verifier，专门检查结果能不能交付。很多流程在运行前就已经画成图：A完成后交给B，B和C并行，D汇总，E验收。

从工程结构看，它更像一个临时项目组。完全去中心化的蜂群，仍主要停留在研究和模拟里。

为了避免把不同东西混为一谈，可以把现在的形态粗略分成五种。

-单Agent最适合线性、短小、上下文高度连贯的任务。它自己规划、调用工具、修正错误，像一个独自干活的熟练员工。

-Supervisor/Worker是目前最成熟的多Agent形态。一个人把大问题拆开，几个人分别去查、去做，再由负责人合并。Anthropic的Research系统就接近这一类。

-Graph Workflow则把协作关系预先写成状态机或任务图。它适合流程稳定、路径可预期的工作，例如固定的合规审查、批量处理、测试流水线。GraphWorkflow和LangGraph都属于这一条线。

-再往前一步，才是动态蜂群：任务跑到一半，Agent自己判断要不要再拆、该找哪一类同伴、谁接手下一段。Kimi Agent Swarm、WebSwarm等产品和研究正在试这种形态。

至于真正完全去中心化的蜂群，目前更多还是社会模拟和学术实验。它有趣，也可能孕育新能力，但离多数企业真正愿意交付的生产系统还很远。

所以，今天讨论蜂群，最好别把它想成一个全新的“AI物种”。它本质上是一个组织问题：多个有一定自主性的Agent，怎样通过任务分解、通信、共享状态和验证，完成单个Agent不好完成的事。

二、为什么突然需要把Agent组织起来

单个模型这些年一直在变强。更大的上下文、更好的工具调用、更长的推理时间，都在延长一个Agent能独自处理的任务长度。

但有些任务并不只是“多给一点时间”就能解决。

比如要在大量网页、报告和数据库里找出一组相互印证的事实；要同时验证十几条安全线索；要维护一个横跨多个模块、持续数小时的软件工程任务；要在有限时间里从几条不同路径搜索同一个答案。问题不在于某一步有多难，而在于工作面太宽。

这时，继续把所有信息塞进一个上下文窗口，常常会发生两件事：它越想越慢，也越容易被已经走过的路径绑住。一个Agent找到一个看似合理的方向之后，会顺着它继续挖，未必还会回头看另一条路。

多Agent的价值首先是把这条单线思考拆开。有人专门查公开资料，有人查原始文档，有人反证，有人负责把零散证据压缩成可以交接的结论。它们不一定比单个Agent更“聪明”，但可以在同一段时间里走更多条彼此独立的路。

Anthropic去年公开多Agent Research系统时，给过一个很直白的内部数据：以Claude Opus 4负责统筹、Sonnet 4做子Agent的架构，在其内部研究评测中，比单独使用Opus 4高出90.2%。对需要从多个独立方向检索的复杂问题，3到5个子Agent并行调用工具，有时能把研究时间压缩约90%。

这个结果听上去很猛，但Anthropic自己也同时给出了账单：普通Agent大约消耗聊天任务4倍的token，多Agent系统约为15倍。

它并不适合每一个问题。对于上下文必须高度共享、环环相扣的任务，多开几个Agent反倒会带来交接损耗。Anthropic还特别提到，大量编程任务的可并行部分没有研究任务那么多，Agent之间也还不擅长实时协调和委派。

这段提醒比90.2%更值得记住。蜂群不会自动让每个任务变强。它是在用更多计算和系统复杂度，换取更宽的搜索面与更多独立尝试。

国内产品在把这件事推向更激进的规模。

Kimi Agent Swarm公开宣称，系统可以动态协调最高300个子Agent、完成超过4000次工具调用；在其官方测试中，大规模搜索任务相对单Agent顺序执行可快约4.5倍，BrowseComp的数据从15.9提升到33.3。这些是厂商披露，不是独立benchmark，不能和论文结论放在同一证据等级上看。不过它至少说明，动态决定“要不要继续拆、要拆到多大”已经开始从论文问题变成产品能力。

过去十年AI的主线是Scale Up：把一颗脑袋做得更大。蜂群代表的则是另一件事，Scale Out：把有限的认知能力布置成一个能并行工作的网络。

三、2026年的转折：多Agent不再天然加分

蜂群最早被讨论时，很容易落到一个朴素想象里：一个Agent不够，就上十个；十个不够，就上几百个。

现在这个想象正在被一批反例修正。

一项发表于2026年的系统研究比较了260种配置、6个benchmark、5种多Agent架构和3个模型家族。结果并不整齐。多Agent相对于单Agent的表现，有的任务能提高80.8%，有的反而下降70%。结构化、可并行的金融推理能受益；强顺序依赖的规划任务，很可能越协作越乱。

另一个针对软件工程benchmark的研究给出过一个颇刺眼的经验边界：当单Agent在某类任务上的基线表现超过约45%时，多Agent带来正收益的概率会明显下降。这个45%不能当作任何领域的定律，它只是在特定任务集上总结出的经验规则。但它戳中了一个朴素事实：单个Agent已经足够能干时，更多人围着讨论，可能只是在制造更多噪声和等待。

这和人类团队没有本质区别。

如果一个问题本来只需一位熟练工程师连续两小时完成，拉进八个人，项目通常不会变成十五分钟。大家需要同步背景、确认接口、合并代码、处理彼此不同的理解。那套协调本身会吃掉时间。

AI团队同样有这笔账，而且更硬。每一次委派都要写清任务边界；每一次交接都要压缩上下文；每一次汇总都要决定谁说得对；每一个Worker都会额外消耗token、工具调用次数和运行时资源。

决定蜂群扩展效果的是独立且有用的探索通道，Agent数量只是表面指标。

一组Agent如果拿着相同提示词、相同工具、从相同资料里找答案，最后往往只是复制同一种偏见。研究者把这叫作diversity。它可以来自不同角色，也可以来自不同检索路径、不同模型、不同数据源和不同的验证方式。收益取决于后来加入的那个Agent，能不能从一个不同入口带回新信息。

围绕Agent scaling的一项预印本研究甚至发现，两个真正异质的Agent，有时可以达到或超过十几个同质Agent的效果。这个结论还需要更多复现，但方向已经很清楚：多Agent的难点正在从扩编，转到如何制造有效分歧。

四、GraphWorkflow提醒我们：组织层开始自己吃算力

回到GraphWorkflow。

这篇论文没有更换模型。它盯住了一个更基础、也更容易被忽略的问题：当工作已经被拆成一张多节点图时，图怎么跑。

过去不少Agent框架更强调灵活性。节点可以条件跳转，可以循环，可以在运行中改路径，也可以保存复杂的长期状态。这些能力很重要，代价是每一轮执行都要经过一层较重的调度和状态处理。

GraphWorkflow选择了另一端。对于预先确定的静态DAG，它先做依赖分析和编译，再把执行计划跑起来。论文里的测试因此测到更低的编排开销。它目前不能等价替代支持循环、条件边、持久状态和复杂运行时控制的通用框架，论文也明确承认这一点。

但这个取舍本身很有意思。

它说明多Agent基础设施开始像传统系统软件一样分层：上面是模型和工具，下面是任务图、调度器、状态合并、检查点、资源分配和失败恢复。你可以把它理解为一个临时组织的运行时。

一个十节点的流程，调度慢一点没人太在意。一旦扩到两百个节点，系统里就会出现很多“人类组织也会遇到”的东西：谁在等前置任务，谁可以并行，谁失败后需要重试，谁的结果覆盖谁，预算快花完时该砍掉哪些分支。到这个规模，调度不是附属功能，它开始决定系统能不能稳定跑下去。

这也是为什么最近的多Agent讨论里，Graph、Workflow、Harness、Memory、Verifier这些原本很“工程”的词越来越靠前。模型能力仍然重要，但它已经不够解释一个蜂群为什么能工作。

五、委派、记忆和验证，才是蜂群的三块硬骨头

把一项工作拆给多Agent，看起来像管理学，实际是一个很难的技术问题。

第一块硬骨头是委派。

什么问题应该拆？该拆成几份？谁做更合适？什么时候别再拆，直接自己做？这些决定如果全靠固定规则，系统很快会变笨。SearchSwarm这类研究开始尝试把“是否委派、向谁委派”本身训练成能力。它的主Agent不需要把所有搜索亲自做完，子Agent只回传压缩后的证据和摘要，避免把完整搜索轨迹重新塞回主上下文。

第二块是记忆。

很多人谈Agent memory时，想到的是“记住用户喜欢什么”。蜂群需要的不是这种聊天记忆。它更接近一张持续更新的证据图和任务图：现在的结论来自哪些来源，哪条假设已被推翻，谁负责什么，哪些工具有权限，花了多少钱，还有哪些工作没有验收。

如果所有Agent都把长篇对话原样互相转发，系统会很快被上下文和噪声淹没。更现实的做法是只传递能支撑下一步的状态。这个状态必须可追溯，也必须能被推翻。

第三块是验证。

蜂群最常见的误会，是觉得多找几个人讨论，自然会更可靠。可一组Agent也可能把同一个错误讲得越来越像真理。

研究已经观察到，LLM群体在没有中央协调者的情况下，会通过局部互动形成共同约定，也会形成单个Agent身上看不到的集体偏见。另一项关于AI组织的研究则发现，多Agent组织的任务效用可能更高，但在对齐上表现得比单Agent更差。

这不难理解。只要几个Worker使用相近的资料、相近的prompt和相近的奖励目标，它们就可能彼此强化，而不是彼此纠错。

一项关于错误传播的实验给出了更直观的数字：在其设置里，独立Agent架构的错误放大最高约为17.2倍；带中央验证的架构约为4.4倍。数字只属于那组实验，不能拿来当作行业平均水平，但结论足够实用：推理的组织结构重要，验证的组织结构同样重要。

未来成熟的蜂群里，最稀缺的角色未必是再多一个Worker，而是能独立验收、能打回重做、能在高风险动作前按下暂停键的Verifier。

六、蜂群的风险，开始接近网络安全和组织失控

单个Agent被prompt injection诱导，已经够麻烦。蜂群把问题升级了。

一个被污染的Worker可能把恶意指令写进共享记忆；后续的Planner把它当作可信状态；另一个有工具权限的Agent又据此执行动作。原本是一个节点的安全问题，会沿着消息、记忆和任务图传播。

2026年关于Agent Worm和间接prompt injection的研究已经在模拟或生产风格框架中展示过这种传播路径：一份带污染指令的内容，不一定直接攻击拥有高权限的Agent，而是先进入一个看似普通的工作节点，再通过交接逐步放大影响。部分研究仍是预印本，具体成功率也高度依赖实验环境，但它至少把问题说清了：多Agent安全不再只是一道输入过滤题，而是一道网络传播题。

这会直接改变企业部署蜂群的方式。

Worker应该拿到最小权限，不能因为它“只是帮忙检索”就顺手读生产数据库。共享记忆不能默认可信，需要标记来源和传播范围。高风险动作要有独立验证和人工审批。日志也不能只记录最终答案，而要记录一项结论从哪个Agent、哪份材料、哪次工具调用传过来的。

当一个任务有一百个Agent在跑时，系统必须回答几件很具体的事：谁可以做什么，花了多少钱，为什么做了这一步，出错后谁负责把它停下来。

七、未来的蜂群，未必长得像一家公司

提到多Agent，很多演示喜欢把它排成CEO、市场、产品、工程、财务的一排小头像。它直观，但也容易误导人，以为AI组织的未来就是把人类公司的部门结构复刻一遍。

更合理的形态可能更短命，也更工具化。

一个复杂任务进入系统后，先判断它的风险、预算、依赖关系和可并行程度。能独立展开的部分，临时创建几个不同类型的Agent；需要顺序推进的部分，留给主Agent或图工作流；关键结论交给验证器；任务结束，组织就解散。下一次任务再来，可能需要的是另一种拓扑。

WebSwarm这类递归式研究已经在探索这个方向。一个Agent不是固定做某个岗位，它可以在任务途中决定自己解决，或再生成子Agent。组织结构不再是一棵提前画好的树，而是一张在运行中长出来的计算图。

当然，这不等于“越动态越好”。

动态拓扑带来的自由，正好也是最难治理的地方。预算可能失控，任务可能无限拆分，权限边界可能被绕开，错误也更难回溯。真正的生产系统大概率会在两端之间取平衡：上层保留清晰的规划、权限和验收，下层允许局部探索和动态重组。

换句话说，未来主流的蜂群，未必是无中心的蜜蜂王国。更像一支有边界的临时小队：中心负责目标、预算和责任；局部节点负责探索；验证器负责刹车。

八、对创业者来说，问题也变了

过去做Agent产品，最容易的路径是选一个更强的模型，再给它接几个工具。现在这条路径仍然能做出很漂亮的Demo，但一旦进入长任务、多步骤、多人协作或高风险场景，真正拉开体验差距的往往是模型之外的东西。

任务如何拆解，工具怎样授权，状态怎样留存，错误如何恢复，结果如何被验收，成本如何被控制。它们听上去不那么性感，却决定一个系统能不能从“看起来会做”变成“可以持续交付”。

这也解释了为什么MCP、A2A、工作流引擎、Agent Harness、可观测性和评测，会同时出现在这一轮产品演进里。MCP解决Agent如何接入工具与能力；A2A试图处理Agent之间的通信；工作流和Harness管理组织与执行；记忆层保留可传递的状态；评测和可观测性负责判断系统到底有没有把事情做对。

这些层各自处理不同的问题，也不会自动拼成一台机器。但当多Agent开始成为常用执行方式，它们会自然靠近。缺了其中任何一环，蜂群都很容易退化成一堆同时输出文字的窗口。

对创业团队而言，最值得避免的也许是“Agent数量焦虑”。不必先问能不能调度100个Agent，先问用户的问题有没有100条值得独立探索的路径。没有的话，单Agent加上好的工具、清晰的状态和一套验收机制，通常更便宜，也更可靠。

只有当任务确实能分解、每个分支有独立的信息增益、结果又能被交叉验证时，蜂群才会带来它承诺的复利。

GraphWorkflow的这条性能新闻，恰好落在这个节点上。它并没有证明某个框架会取代谁，也没有证明Agent越多越好。它提示的是另一件更朴素的事：多Agent已经多到需要有人专门优化“它们怎么一起工作”。

模型竞赛还会继续。但下一轮agentic系统的差距，很可能不只在谁有更强的大脑，也在谁更会把有限的大脑组织成一支不浪费、不失控、能交付的队伍。

-

资料说明

文中GraphWorkflow的性能数据来自Swarms团队2026年8月发布的论文和可复现实验，范围是静态多Agent图的编排开销，不应外推为真实端到端Agent任务的整体加速。

Anthropic的90.2%、并行研究时长和token成本数据，来自其公开的多Agent Research系统说明，属于其内部评测和生产经验。

SearchSwarm、WebSwarm、Agent scaling via diversity、Agent Worm等一部分工作仍处于预印本或快速迭代阶段；文中将其用作观察方向，而非已经定论的工业标准。