SwarmFlow来了！openJiuwen开创蜂群可控协同新范式

AI Agent 正在从 "单兵作战" 走向 "团队协作"—— 让多个 Agent 分工配合，去完成单个 Agent 难以独立扛下来的复杂任务，也是近期最受关注的方向之一。

沿着这条路，华为支持的openJiuwen 社区一直在围绕 Coordination Engineering（协同工程）推进多智能体协同：Agent Swarm 让多个智能体自主分工、协同执行；Swarm Skills 把一次成功的团队协作沉淀成可复用的 "团队技能"；SwarmSkill Creator 进一步让用户用一句自然语言就能生成多角色团队。

能 "组起队" 之后，下一步要解决的，就是 "团队怎么稳定地把活干完"。

这一次，openJiuwen 给这条技术栈补上了新的一块 —— 开源 SwarmFlow，一种面向多智能体团队的可控工作流编排。

它想回答的，是多智能体走进复杂任务后绕不开的一个问题：

团队会协作了，但这套协作流程，能不能被稳定、可控、可复用地执行？

会协作之后：复杂任务带来的三个考验

要理解 SwarmFlow，得先理解它针对的痛点。

在主流的多 Agent 协作模式里，通常有一个 Leader Agent 充当大脑：它一边理解需求，一边拆任务、建成员、分配工作、等结果，再根据回传决定下一步。任务简单时，这种 "临场调度" 非常灵活。

但任务一旦变长、变大，出现多步骤、多分支，需要并行、需要验证和重试，把整条流程都压在 Leader 的临场判断上，会遇到三个绕不开的问题：

• Leader 变成瓶颈。 每一份中间结果都要回到 Leader，它的上下文很快被过程信息淹没，大量精力消耗在 "流程管理" 上，反而做不好真正需要它判断的事。
• 过程不稳定。 同一个任务跑两次，可能走出两条不同路径 —— 因为每一步都取决于 Leader 当场怎么决定。
• 执行不可靠。 谁先做、谁并行、什么时候汇总、失败怎么处理，这些要求即便提前写清楚，到底有没有被照做，仍然依赖 Leader 临场发挥。

而很多复杂任务的协作关系，其实是清晰、可以提前确定的。金融研判要让宏观、行业、风险、投资几个角色并行研判再统一汇总；论文分享要先读论文、再生成总结、最后撰写邮件发送 —— 每一步的输入输出都很明确。

openJiuwen 的判断是：这类任务真正关键的不是 "多叫几个 Agent"，而是把这套确定的协作关系稳定地执行下来，而不是每次重新临场判断一遍。

核心思路：编排归系统，智能归 Agent

SwarmFlow 的解法，可以用一句话概括：把 "编排" 和 "智能" 分开。

谁先做、谁并行、谁把结果交给谁、什么时候汇总、失败如何处理 —— 这些协作关系（编排），交给系统按程序稳定执行；而每个子任务具体怎么理解、怎么推理（智能），才交给 Agent。

常见的多 Agent 协作流程是：Leader 既要做编排、又要做判断，两件事混在一起，全靠一轮轮临场推进。

SwarmFlow 做的，是把编排逻辑从 Leader 的 "临场理解" 里抽出来，变成一段系统可以自动执行的工作流：Leader 不再每一轮手动调度，只需要启动这条工作流，后续协作由 SwarmFlow 自动推进，Agent 只在需要推理的节点被调用。

由此，"团队怎么配合" 不再靠 Leader 临场判断，而是被系统稳定执行、自动追踪、可被复用。用 openJiuwen 自己的话说：SwarmFlow 增加的不是 Agent 数量，而是协作的确定性。

这背后是一个并不激进的判断：不是 "越自主越好"，而是为任务匹配合适的形态。确定的编排更可预测、更易复盘，自主推理更灵活、更能应对开放问题。

那它和大家已经熟悉的 Swarm Skill 是什么关系？

一句话：Swarm Skill 是团队协作的能力包，SwarmFlow 是其中负责 "可执行编排" 的那部分能力。

Swarm Skill 定义了一支团队 —— 有哪些角色、各自负责什么、如何协作、遇到问题怎么处理。过去它更像一份 "团队协作说明书"，把该怎么配合写清楚了，但真正执行时仍要靠 Leader 一边读、一边临场照做，流程一长，照样会回到上面那三个问题。

SwarmFlow 补上的正是 "执行" 这一环：当一支团队的协作流程可以提前确定时，就把这套编排写进 Swarm Skill 的 scripts/workflow.py，让它从 "靠 Agent 临场照做" 变成 "被系统直接执行"。

所以 SwarmFlow 不是另起炉灶的新概念，而是让 Swarm Skill 从一份 "协作说明书"，长出一条 "可执行的工作流"。

该不该写成脚本：就看编排能不能提前确定

SwarmFlow 比较有意思的地方，在于它没有走 "把一切都脚本化" 的极端。openJiuwen 给出的判断标准只有一个 ——编排能不能提前确定。 

同一个 Swarm Skill 由此分成两种形态。

第一种，不带 workflow.py 脚本。 适合编排本身就动态的场景，比如多专家圆桌研讨、方案评审、战略讨论。这类任务里，角色和阶段是确定的 —— 会有哪些人参与、大致经历 "独立思考、相互讨论、观点汇总" 几个阶段；但谁回应谁、谁质疑谁、谁补充谁，需要根据上下文临场决定。它更像一场真实会议：议程是确定的，但观点如何流动、信息如何交锋，得在协作过程中自然发生。强行写成脚本，反而会束缚协作。所以这类 Swarm Skill 只沉淀角色、规则、边界和协作方式，把 "谁交给谁" 留给临场判断。

第二种，带 workflow.py 脚本。 适合编排可以提前确定的任务，比如论文分析与办公自动化：论文解析的结果交给总结，总结交给文档生成，文档再交给邮件撰写 —— 谁接谁、下一步做什么，都能提前定好。于是脚本里用 SwarmFlow 把这套编排固化下来，交给系统稳定执行。

一句话：编排是动态的，用不带脚本的 Swarm Skill 保留开放协作；编排能提前确定，用带脚本的 Swarm Skill 承接可执行编排。

这正是 SwarmFlow 的设计亮点 —— 确定性与开放性可以在同一套体系里各得其所，十分灵活。

SwarmFlow 长什么样：用积木搭出团队工作流

openJiuwen 提供了一组算子当积木，用于搭建 SwarmFlow—— 每个算子只管一件事，拼起来就能描述出复杂的团队协作。

这套积木大致覆盖四类需求：派生智能体去执行子任务、让多个智能体以不同方式并发与流转、把长流程切分成可观察的阶段并支持子流程复用、以及在关键环节插入人机交互。

落到具体能力上，有几处设计值得一提。

并发不止一种：一种是并行 parallel，几个智能体一起跑、全部完成后统一汇总；另一种是流水线 pipeline，多个条目各自独立逐级流过、互不等待 —— 前者适合多视角研判后合并，后者适合批量逐条处理。有状态的智能体 agents_session 能在多轮协作中保留记忆，甚至 "分身" 出一个副本去做假设推演而不污染主线。需要人拍板的地方，可以插入一个人机节点 human，在执行中向人类要一条输入或一次审批。此外还有专门约束资源与额度消耗的算子 budget，把 "会不会跑超" 也纳入了可控范围。

通过这些算子：一个动作一块积木，复杂协作由简单积木拼出来，无需从零设计编排逻辑。

同时，SwarmFlow 不是黑盒，在 JiuwenSwarm TUI 中，用户还可以通过 /swarmflows 打开内置可视化视图，用一张实时交互式树状图查看当前会话里的所有 Swarm Workflow：上方展示阶段进度，下方联动展示选中阶段里的 Agent 状态；需要进一步排查时，也可以下钻到单个 Agent，查看提示词、输出结果或错误日志。

对想把多智能体用进生产的团队来说，可观测、可续跑、可控额度，往往比 "算子多不多" 更要紧。

怎么用：从一句话生成，到 Team 模式自动调用

形态分成两种，门槛却没有变高，因为生成和调用都被 openJiuwen 包了起来。

生成端，交给内置的 SwarmSkill Creator。 它是 JiuwenSwarm 内置的能力，用户无需额外安装，会根据自然语言需求自动判断该生成哪种形态：默认生成不带脚本的 Swarm Skill（角色、协作规则、流程说明和约束），适合开放协作；当它判断用户要的是一条工作流 —— 比如 "帮我写一条工作流，逐篇分析这批论文、汇总成报告再发邮件"—— 就生成仅含脚本的版本，只保留一个最小的 Skill.md 入口和一个 workflow.py，让用户快速拿到能跑、可复用的工作流；两者都要时，也支持生成兼具完整协作规范和脚本的版本。用户不必先理解文件结构，也不必手写编排脚本，只要把目标说清楚。

调用端，在 Team 模式下一句需求自动进入。 用户不用分辨任务属于哪种形态，也不用手动编排每个 Agent 的执行顺序，只要用自然语言描述，系统会判断其中是否包含工作流意图。

例如 "用工作流帮我分析这家公司是否值得投资"，或 "用 swarmflow 组织几个专家阅读这篇论文、生成总结文档并起草一封邮件"。识别到工作流意图后，系统会进一步判断任务形态：适合固定编排就进入 SwarmFlow，更适合开放协作就用不带脚本的 Swarm Skill，单个 Agent 够用就不额外启动多 Agent。

这也是 openJiuwen 想定义的可控协同工程新范式 —— 让复杂协作在系统内部变得可控，让用户侧保持自然和简单。

三个实战场景

看完了设计，再看看实战效果。

参考 JiuwenSwarm 快速上手，先安装与启动 JiuwenSwarm：https://openjiuwen.com/jiuwenswarm#quick-start

场景一：从一张流程图，生成一套金融分析的 SwarmFlow。用户上传了一个流程图，JiuwenSwarm 基于该流程图，使用内置的 swarmskill-creator 即可直接生成该流程图对应的 SwarmFlow 团队技能，包含对应的工作流执行脚本 —— 整条 SwarmFlow 不用手动编排，由一张图直接生成。

用户提出分析目标，这条工作流就会自动启动：先进行数据采集、清洗，然后从财务、行情等五个维度并行分析，最后交叉验证、综合置信度，输出完整的分析报告和总结建议。整个过程中，用户看到的不只是最终答案，还能看到团队在各阶段如何推进。

场景二：给定选题，自动进行技术调研、素材整理并发送邮件。这个案例是一个更接近日常办公和科研协作的技术分享工作流。用户只需要给出技术分享主题和目标读者，SwarmFlow 就会自动组织多个阶段依次推进：先搜索相关论文和资料，再整理素材、提取可用图片并保存到本地目录；随后分析核心问题、技术趋势、关键观点、可讨论议题等；最后生成结构清晰、适合组内阅读的技术分享邮件，并发送给指定收件人。

技术分享是一类会反复发生的团队工作：主题会变，但 “搜资料、提素材、做分析、写邮件、发出去” 的动作和标准相对稳定。SwarmFlow 可以把这套流程固化下来，避免每次临场指挥导致步骤遗漏、口径变化和交付不一致。

场景三：在已有团队技能上补充工作流，200 页 PPT 稳定产出。这个案例基于已有的团队技能，生成了一条专门生产 PPT 的工作流 —— 设计三阶段流程，阶段一首先规划章节主题和分工，阶段二里 10 个章节并行生成 PPT，最后合并阶段把所有章节统一汇总，整理成一份 200 页的完整 PPT。

做大型 PPT 正是那种 "步骤固定、但量大易乱" 的任务：两百页内容若全靠 Leader 一页页临场调度，每次跑出来的结构、风格、详略都可能不一样；而固化成工作流之后，每次都按相同的步骤和标准执行，既靠并行明显加速，又能稳定产出一份结构统一、风格一致的 200 页 PPT。

几点观察与思考

把这次开源放回 openJiuwen 的 Coordination Engineering 这条线上看，SwarmFlow 几个设计上的选择值得关注。

一是它把 "编排" 和 "智能" 显式切开，又和 Swarm Skill 这套能力包统一了起来 ——"可执行编排" 成了团队能力的一部分，而不是另起一套独立的编排系统。

二是它用自然语言生成（SwarmSkill Creator）加 Team 模式自动路由，"该用哪种形态" 不需要用户操心。

三是人机节点、可观测、断点续跑、额度约束这层工程能力，保证了 "可控" 真正落地。

值得一提的是，华为云 AgentArts 也已经将 openJiuwen 引入到商业化平台能力中，开箱即用，感兴趣的用户可以直接去华为云官网体验。

多智能体的故事，正在从 "能不能协作"，走向 "能不能稳定地把复杂工作干完"—— 而后者更难、也更关键。SwarmFlow 给出的答案是把 "编排" 交给系统、"智能" 留给 Agent：它增加的不是 Agent 数量，而是协作的确定性。作为国产全开源的 AI Agent 平台，openJiuwen 也已将 SwarmFlow 完整放在社区上，值得开发者上手试试，也值得我们持续关注。

文章来自于"机器之心"，作者 "机器之心"。