人工智能技术应用已走向深水区，AI 智能体面对的任务复杂度正呈指数级上升。如何保障多个 Agent 在高压场景下稳定分工、高效协同并精准执行？这已成为多智能体系统落地生产环境的核心瓶颈。

为了攻克这一难题，openJiuwen 持续深耕Coordination Engineering（协同工程）领域。在我们的理念中，Agent 不再是孤立无援的个体，而是拥有清晰组织架构、明确执行边界与紧密协作关系的数字群体。

基于这一发展方向，openJiuwen 正式推出全新智能体协作产品形态——JiuwenSwarm。

作为该产品的核心特性，Agent Swarm 架构赋予了多智能体如同真实团队般的组织能力：由 Leader 统一进行任务编排与调度，各成员紧密围绕终极目标展开协同，共同攻克复杂课题。

早期的 Agent Swarm 多部署于单机、单进程或本地环境，团队虽逻辑分工明确，却更像“在同一个房间内紧密配合”。这种模式简单可控，但在任务规模、模型复杂度、工具链长度显著增长时，容易遇到物理边界。近日，JiuwenSwarm 迎来重大技术演进——正式支持分布式 Agent Swarm。

现在，一个 Swarm 团队的成员不再需要“同挤一台机器”。Leader 与集群成员可以自由部署在不同的进程、节点甚至跨云服务器上，通过注册中心、远程接入、高效消息传输及共享工作空间无缝协作。

这不仅仅是把集中式的进程生硬拆开，而是推动 Agent Swarm 从“本地协同”真正跨入“跨节点组织协作”的新时代。它将协同工程（Coordination Engineering）的触角从逻辑编排层延伸到了物理部署层，让 AI 团队拥有了适配工业级生产环境的组织韧性。

当前主流Agent Swarm系统仍然以单机模式为主，背后的原因很自然：单机架构简单，状态容易管理，文件路径一致，调试成本低。但随着Agent应用进入更复杂的任务场景，单机架构会遇到几个典型问题。

计算资源遭遇瓶颈： 一个全能型 Swarm 往往集成了规划、检索、代码生成、浏览器自动化、测试及报告编译等多种角色。如果模型推理、工具调用和 I/O 读写全部压在一台服务器上，CPU、内存和网络连接极易过载，导致长任务排队、卡顿甚至系统崩溃。

运行环境难以隔离： 不同的 Agent 术业有专攻。写代码的需要完备的开发工具链，跑浏览器的依赖 Playwright 等图形环境，对接企业内网的需要特定服务器权限，而做模型推理的则离不开 GPU 算力。单机模式强行把所有依赖混在一起，环境臃肿且极易引发冲突。

协作边界缺乏弹性： 真实企业中没人会挤在一台电脑前办公。高效的团队应当是各成员拥有独立的执行节奏与环境，Leader 负责分发与汇总。分布式 Agent Swarm 正是顺应了这一规律，将团队成员转化为可被动态发现、预约和调度的远程执行单元。

因此，分布式Agent Swarm的目标很明确：让智能体团队突破单机限制，把团队成员变成可以被发现、预约、引导和调度的远程执行单元。

这次分布式Agent Swarm的实现，没有另起一套割裂的运行时，而是在 openjiuwen 现有的 AgentServer 与 TeamManager 体系之上进行的分布式能力平滑扩展。业务入口仍然保持统一，并通过配置切换运行模式。

整体上，我们采用“控制面”和“数据面”分层的路线：

控制面（成员发现与连结）：

集群成员启动后，会主动将其网络地址注册至 A2X 注册中心，以空闲状态静候调度。Leader 在构建团队时无需硬编码成员 IP，而是向注册中心动态“预约”空闲节点。预约成功后，Leader 通过 direct ZMQ 发送远程接入指令，将团队身份及路由信息下发给成员，成员响应后即正式归队。

数据面（业务协同与共享）：

任务流转、消息传递和状态同步仍沿用 JiuwenSwarm 的原生链路。为了打破多节点间的信息孤岛，系统引入了共享工作空间机制。在推荐方案中，Leader 侧通过 NFS 导出 Swarm 工作目录，成员侧挂载同一目录。如此一来，跨节点协作不仅能“通电话”（消息互通），还能“共用一个工作空间”（文件、上下文和产物实时共享沉淀）。

在传输层与运行配置上，系统通过 pyzmq 承载跨节点通信，利用 runtime.role 区分 Leader 与普通成员，并通过 runtime.mode=distributed 开启分布式模式。

leader不再依赖静态集群成员配置，而是通过注册中心动态获得可用成员。这为后续弹性调度、多成员扩展和资源池化管理打下了基础。

从使用者视角看，创建分布式跨节点Swarm可以概括为三步。

第一步，准备分角色配置。leader和集群成员分别使用对应的分布式配置模板。双方需要指向同一个A2X注册中心数据集。集群成员需要发布自己的远程接入地址，leader只需要知道注册中心地址，不必静态维护集群成员地址列表。

第二步，启动基础服务并准备共享工作空间。推荐顺序是：先停止旧的Swarm进程；随后启动注册中心；再准备共享工作空间。当前我们提供了scripts/nfs/目录下的脚本，支持leader启动NFS Server，集群成员作为NFS Client挂载同一份Swarm工作目录。挂载完成后，可以通过双向写入文件验证共享是否生效。

第三步，启动集群成员和leader并完成组队。共享工作空间准备完成后，启动集群成员的app_agentserver，让它注册为空闲节点；最后启动leader后端和前端。这样，leader在构建Swarm时，就可以从注册中心预约到真实可用的远程集群成员，并完成远程成员接入，形成完整的分布式Swarm。

完成组队后，跨节点成员就可以围绕统一工作空间协同处理任务上下文、共享中间结果，并沉淀团队产物。

为了更直观地展示分布式Agent Swarm的使用方式，我们准备了一个轻量级Demo：一个leader和两个集群成员分别运行在三台不同机器上，共同完成一次跨节点代码文件接力开发任务。

在这个Demo中，leader负责任务发起、成员调度和执行过程组织；teammate-1和teammate-2分别作为远程集群成员运行在不同节点上。三个节点通过注册中心完成成员发现和组队，并通过共享工作空间访问同一份任务文件。

用户只需要向leader提交任务目标，例如：让teammate-1在共享工作空间中创建一个czz.py文件，并在文件中生成加法和减法函数；随后让teammate-2读取该文件，在原有代码基础上继续补充乘法和除法函数。

从用户视角看，这个过程并不需要手动登录每台机器，也不需要逐个分发文件或复制中间结果。用户面对的仍然是一个统一的Swarm入口：任务提交给leader后，leader会根据当前团队结构调度远程成员完成协作。teammate-1在自己的节点上生成文件后，文件会沉淀到共享工作空间；teammate-2随后可以在另一台机器上读取同一个文件，并继续完成后续修改。

这个例子本身很简单，但它展示了分布式Agent Swarm最核心的使用价值：跨节点成员可以围绕同一个任务目标、同一份共享上下文和同一个团队工作空间进行连续协作。

对于真实业务场景，这种模式可以自然扩展到更复杂的任务。例如，在代码研发场景中，一个成员可以负责生成代码，另一个成员负责补充测试用例，第三个成员负责执行测试并修复问题；在报告生成场景中，一个成员可以负责资料检索，一个成员负责数据分析，另一个成员负责撰写和汇总。不同成员可以运行在不同机器上，各自使用最适合自己的工具链和运行环境，但最终仍然通过leader组织成一个统一的智能体团队。

通过这个Demo可以看到，分布式Agent Swarm带来的变化不只是“把Agent放到不同机器上运行”，而是让用户能够把多台机器、多种环境、多类工具能力组织成一个可协同的智能体团队。leader负责统一调度，远程成员负责分工执行，共享工作空间负责承载上下文和产物沉淀，从而形成更接近真实生产环境的多智能体协作方式。

从上面的Demo可以看到，分布式Agent Swarm并不是简单地把本地进程拆分到多台机器上，而是让leader、远程集群成员和共享工作空间形成一个完整的协作闭环。它带来的收益主要体现在以下几个方面：

异构资源精细调度： 告别单机资源争抢。浏览器、重计算、内网访问等不同属性的成员可定向部署在最合适的节点，Swarm 算力不再受限于 Leader 单机硬件瓶颈。

工程隔离与易运维： 成员升级为独立进程，拥有专属端口、配置与依赖。即便个别成员因执行高危工具或长耗时任务崩溃，也不会波及 Leader 进程。同时，支持从注册、接入到空间挂载进行分层排查。

动态成员发现调度更加灵活： 引入资源池模式，拒绝硬编码地址。成员启动后作为空闲节点向注册中心报到，Leader 根据任务需要动态预约并完成组队，调度极其灵活。

真正意义上的团队上下文： 依托共享工作空间，打破了跨节点“文件与状态不一致”的痛点。Leader 写入上下文、成员认领任务、汇总中间结果都在统一空间内完成，告别了简单的远程 RPC 调用。

直面生产环境的就绪状态： 打通了内网、云主机、GPU 节点与既有基础设施的屏障，为后续对接容器平台、资源调度系统以及实现复杂的权限隔离提供了底座支撑。