往期回顾

当单个Agent已经足够强，工程的下一个增量藏在哪里？JiuwenSwarm给出的答案是：不在「让一个Agent更强」，而在 「让多个Agent更好地协作」。这篇文章想把这件事讲清楚 —— 协同，凭什么值得被当作一种独立的工程范式。

过去一年，把单个Agent「调教」得能干、可控、可靠，几乎成了行业标配。但真实世界里那些真正棘手的任务，诸如跨领域深度调研、大型软件交付、多角色联合决策、复杂业务流程编排等，从来都不是「一个人」能搞定的。软件要产品、研发、测试、SRE；会诊要分诊师加多个科室专家；一份两百页的技术报告，需要十个方向的人并行铺开再汇总成稿。

这些场景缺的不是「一个更强的Agent」，而是「一支配合默契的团队」。这就是协同工程（Coordination Engineering）要回答的问题。

一、先看清它在演进史上的位置

要理解JiuwenSwarm为什么把「协同」单拎出来作为一种范式，得先把时间线拉长一点。

从Prompt Engineering到Harness Engineering，工程的重心一直在往上走。这三者不是互相替代，而是层层叠加：提示词工程解决「沟通」，让模型听懂你；Harness工程解决「单体能力」，—让一个Agent能干、可控、可靠；协同工程解决「群体协作」，让一群Agent分工、流转、汇总。

Agent Team 的核心不是『更强的 Agent』，而是『更好的协作』。

这句话的潜台词是：当你已经有了一个足够强的单Agent，继续往上堆单体能力，边际收益是递减的。真正的下一个数量级，藏在多个Agent如何分工、如何建立协作机制、如何流转任务并汇总结果里。协同工程，就是冲着这块增量去的。

值得强调的是，协同工程不是对Harness工程的否定，而是它的自然延伸。每个Teammate内部仍然是一个完整的Harness SDK Agent，拥有全部的单体能力；协同工程只是在此之上叠了一层协调层，让多个优秀的个体，组成一个高效的团队。

二、为什么传统的多Agent编排不够用

抽象的话讲到这里就够了，换个具体场景。

12345政务热线收到一条投诉：「某工地夜间施工噪音扰民且扬尘污染」。听上去简单，实则横跨城管（噪音执法）、环保（扬尘监管）、住建（工地资质核查）三个部门的职责。理想的处理方式是：自动解析出三个诉求点，动态组建包含三类专家的处置团队，让他们并行制定各自方案，最后汇总成一份完整的联合处置方案。

拿传统的多Agent方案来套这个场景，有三个绕不过去的硬伤：

第一，编排是硬编码的。 谁先调研、谁再分析、谁最后汇总，这些依赖关系得写死在代码里。任务一变，代码就得改。可12345热线每天有成千上万种诉求，你不可能为每一种都手写一套编排脚本。

第二，信息是有瓶颈的。 多个Agent之间靠消息传递通信，但消息格式、传递顺序、异常处理全要预先定义。城管做的噪音监测结果，环保怎么及时知道？两个部门结论矛盾了，谁来仲裁？

第三，异常是无解的。 一个成员卡住了，比如要跨部门敏感数据却没权限，那么，整个流程是等，还是跳？跳了之后下游依赖怎么办？人工编排不可能穷举所有异常分支。

协同工程要做的，就是把多Agent协同从「写脚本串联」升级成一套可设计、可优化、可复用的工程化体系。下面四节，正是这套体系的四块拼图。

三、AgentTeam：协作是怎么跑起来的

JiuwenSwarm把协同工程落地为AgentTeam（智能体团队），它的设计理念很直接：模拟真实团队的协作方式。

一条完整的闭环是这样跑的：用户提出目标，Leader分析需求、组建团队、拆解任务；Teammate认领任务、独立执行、汇报产物；最后Leader汇总，输出交付物。这条链路里藏着三个关键的设计决策。

（1）分级自主协同，而非中央集权或彻底放养。 Leader像项目经理，负责目标理解、团队组建、任务规划、关键决策、整体推进、结果汇总；Teammate则认领专长任务、独立执行、必要时向上求助、汇报并提交产物。Leader不替Teammate干活，Teammate也不脱离Leader的统筹。职责边界清晰，是多Agent系统不陷入混乱的前提。

（2）任务依赖与并行推进。 任务之间支持前置、后续、并行关系。这意味着AgentTeam不是「一个干完下一个」的串行队列，而是能让多个无依赖的任务同时推进。在政务场景里，城管关心的噪音分贝标准，和环保关心的扬尘监测标准完全独立，两者在各自工作区并行推进，互不阻塞。多Agent相对单Agent的效率，主要就来自这里。

（3）事件驱动，而非一次性分工。 这一点容易被忽视，却很关键。任务状态变化会自动触发后续任务，成员间通过消息协同，异常能自动恢复。Teammate A完成调研，触发任务完成事件，事件总线通知Leader，Leader判断后续任务的前置条件已满足，自动启动Teammate B；B超时了，触发异常事件，Leader决定是重试还是换人。整个过程不需要轮询，没有「每隔五秒检查谁完成了」的浪费。现实任务总会变，事件驱动让团队能动态响应进展与异常，而不是按一张僵化的计划表走到黑。

还有一层刚性约束不能省：关键决策权始终在Leader手里。环保Teammate建议罚款，这属于敏感操作，自动提交Leader审批；Leader调用法规Teammate复核处罚依据后，才批准。城管想查封施工设备，Leader先核查是否有「情节显著轻微可整改」的替代方案。住建要调用跨部门敏感数据，请求经Leader审批并记入审计日志。Agent可以自主建议，但收尾的决策不放手——这是「自由发挥后收拾烂摊子」的防线。

四、共享工作区与双层记忆：协作的「物理基础」

多个Agent要协作，就必须有共享的「桌面」和共享的「记忆」。AgentTeam用一套清晰的文件层级和记忆架构解决了这件事。

桌面这一层，靠双层级的工作区。团队共享区（team-workspace/）放团队共同的产物和技能，各成员的独立区（workspaces/）放自己的工作空间。调研Agent把行业数据写进共享区，分析Agent直接读，不需要手动传文件，也不需要互相发消息「你去看某某路径」，直接读写，天然共享。同时共享区提供文件级锁定，A在写report.md时B只能读，避免并发冲突。这样既能协作，又互不干扰。

记忆这一层，是双层记忆架构。个人记忆每个成员独立读写；团队共享记忆TEAM_MEMORY.md则所有成员只读，由Leader在每个Round（一轮完整协作周期）结束后，通过一个专门的提取Agent统一写入。提取的内容会用标签分类：decision（决策）、lesson（经验教训）、member（成员特长）、context（项目背景）；记忆还分 temporary（临时，只读不留痕）和 persistent（持久，跨Round累积）两种生命周期。

这套设计真正的巧思在于：团队记忆采用「只读 + Leader 统一写入」，绕开了多个成员并发写同一份记忆带来的冲突和污染，同时又让每个成员都能读到团队级的共识。这和人类团队把「经验手册」和「操作规程」分开管理是一个道理——规程是基础，经验是补充，各自迭代，互不打架。

五、模式系统：协同的「运行时档位」

如果说AgentTeam定义了协作的「组织结构」，那么 模式系统（Modes） 就是决定「用什么档位去跑」的运行时开关。

这里有个容易误解的点：模式不只是UI上的一个名字，它直接决定AgentServer选哪个运行时profile、挂载哪些Rail、如何注入记忆与协作能力。说到底，模式切换就是Rail组合的切换。

最能说明问题的，是对比agent.plan和agent.fast。两者用的是同一个Deep Agent底座，区别只在Rail的挂载与卸载：前者挂上TaskPlanningRail、SubagentRail、技能演进等「重编排」Rail，适合复杂长程任务，用编排能力换深度；后者主动卸载这些Rail，换取低延迟的快速响应，用编排能力换速度。同一个底座，靠Rail的增减，就切出了两种性格迥异的运行形态，这正是把协同能力做成「可挂载组件」的好处。

在前端，这些模式被表述为更直观的三种：规划模式、性能模式、集群模式，其中集群模式对应的就是Team/AgentTeam。切换方式也很轻，/mode team、/switch，或者为每个通道设默认模式。

六、SwarmFlow：协同工程的「执行引擎」

有了组织结构（AgentTeam）和运行档位（模式系统），还差最后一块拼图：Leader拆解出来的任务，怎么被结构化地编排、监控和追踪？这就是SwarmFlow的职责。

要理解它，得先看清一个痛点。在常见的多Agent模式里，Leader既要做编排，又要做判断，两件事混在一起，全靠一轮轮临场推进。任务简单时这很灵活，可一旦任务变长、变大，问题就来了：

• • Leader变成瓶颈，每份中间结果都要回到它，上下文很快被流程信息淹没；
• • 过程不稳定，同一个任务跑两次可能走出两条路径；
• • 执行不可靠，谁先谁后、何时汇总、失败怎么处理，到底有没有被照做，全看临场发挥。

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

SwarmFlow的解法可以一句话概括：把「编排」和「智能」分开。谁先做、谁并行、谁把结果交给谁、何时汇总、失败如何处理，这些编排逻辑，交给系统按程序稳定执行；而每个子任务具体怎么理解、怎么推理，这些智能，才交给Agent。Leader不再每一轮手动调度，只需启动这条工作流，后续协作由系统自动推进。

落到机制上，SwarmFlow有三层核心概念：

• • Workflow：是一次完整的运行实例，启动时生成唯一的Run ID；
• • Phase（阶段）把任务切成有序的阶段（比如「调研 → 分析 → 撰写」），阶段内的Agent可并行也可串行；
• • 生命周期事件流：由专门的Monitor实时聚合进度、推送增量更新。整个状态机覆盖running / completed / failed / stopped等状态，过程可观测、可续跑。

用openJiuwen自己的话说：SwarmFlow增加的不是Agent数量，而是协作的确定性。它也没走「把一切都脚本化」的极端，判断标准只有一条：编排能不能提前确定。能确定的（论文分析、办公自动化），就固化成工作流稳定执行；不能确定的（圆桌研讨、方案评审），就保留开放协作。确定性与开放性，在同一套体系里各得其所。

把三者的分工说透：AgentTeam回答「谁来协作」，模式系统回答「用什么档位协作」，SwarmFlow回答「协作过程如何被结构化执行与监控」。协同工程从一句理念，变成一套可运行的系统，靠的就是这最后一步。

七、小结：协作本身，就是一种工程

把整篇串起来，JiuwenSwarm做的其实是同一件事的五个侧面：

• • 范式上，它把工程重心从「单体能力」推进到「群体协作」，提出协同工程；
• • 组织上，用AgentTeam的分级自主协同、事件驱动、任务依赖，定义协作如何流转；
• • 基础上，用共享工作区加双层记忆，给多Agent协作提供物理与记忆的底座；
• • 运行时上，用模式系统切换Rail组合，决定以什么档位协作；
• • 执行上，用SwarmFlow把任务计划编排成可监控的阶段化工作流。

一句话收尾：在JiuwenSwarm里，「协作」不是模型自发涌现的副产品，而是被当作一等公民来工程化的对象。

AI Agent的星辰大海，注定不是一个无所不能的「超级个体」，而是一群各有所长、彼此协同、不断进化的「群体智能」。当行业刚把视线从「更强的单Agent」转向「更强的Agent团队」，把这条路完整铺出来的，目前还没有几家。

更多JiuwenSwarm信息，请参见官网：

• 官网地址：https://www.openjiuwen.com/

• AtomGit: https://atomgit.com/openJiuwen

PS：

更多Agentic AI技术前沿分享，欢迎扫描下方二维码进入技术交流群（或者添加群助手ID：qstarsky 邀请您进群交流）

Agentic AI

立即扫码

参考资料

1. 1. 官网地址：https://www.openjiuwen.com/
2. 2. AtomGit: https://atomgit.com/openJiuwen
3. 3. openJiuwen官方文档：https://openjiuwen.com/docs-page?path=%E4%BA%A7%E5%93%81%E7%AE%80%E4%BB%8B
4. 4. 告别单体架构：JiuwenSwarm蜂群协同内核, https://cn.chinadaily.com.cn/a/202605/20/WS6a0d664fa310942cc49ad47f.html
5. 5. https://mp.weixin.qq.com/s/QIIvpMPNSXuLmoob7QSKWg
6. 6. https://mp.weixin.qq.com/s/zcYq4IfcI6o33Lo4D1GW4Q