背景：多智能体框架的入口错位
过去两年的多智能体框架有一个共同的隐含假设：用户愿意为了用上多智能体，先切换到一个新的工作场景。无论是对话式的工作流画布、还是独立的控制台，都要求使用者注册一个新账号、打开一个新页面、把既有流程搬进去。这个假设在企业环境里反复落空——真正的阻力往往不是模型能力，而是入口摩擦。
JiuwenSwarm 的选择是反过来的。它把多智能体能力投递到用户每天已经开着的窗口里：国内的飞书、钉钉、企业微信、个人微信、小艺，海外的 Telegram、Discord、Slack、WhatsApp，再叠加 Web、TUI 终端、JetBrains 与 VS Code 插件、浏览器扩展。这个产品取向在同类框架里并不常见，也是理解它全部技术取舍的起点——因为入口一旦是 IM，消息协议的异构性、会话的持久化、以及人在回路的介入点，就从「附加功能」变成了架构的地基。
项目在开源社区的爬升速度值得记录：不同时间点的公开快照分别显示约 1.8k、约 6k 与约 6.5k 星（对应约 1.1k fork），PyPI 包名为 jiuwenswarm，要求 Python 3.11 及以上，覆盖 Windows、macOS、Linux 与 HarmonyOS，并提供桌面安装包、Docker 部署、GitCode 镜像与完整中英文文档。需要说明的是，星数快照差异较大，反映的是抓取时间不同而非数据矛盾，引用时应注明观测时点。
JiuwenSwarm 不内置任何模型，是一个纯粹的 Harness。模型侧开放对接华为云 MaaS、OpenAI 兼容 API、DeepSeek、DashScope、SiliconFlow、OpenRouter 以及本地部署模型。这意味着它的所有能力叙事都建立在「编排与工程」而非「模型智商」之上——评估时也应当按运行时标准而非模型标准来衡量。
四层拆解：入口、协议、执行、编排
JiuwenSwarm 的架构可以拆成四个层次。理解这四层的分工，比记住任何单项功能都更有用。
| 层级 | 核心组件 | 主要职责 | 关键设计决策 |
|---|---|---|---|
| 入口层 | IM 适配器 + Web/TUI/IDE 插件 | 把用户意图接进系统，把结果送回原渠道 | 不要求切换工作场景，覆盖十余个国内外渠道 |
| 协议层 | Gateway + E2A 信封 | 外部协议归一化 | E2AEnvelope 请求结构 + 三层 E2AResponse 响应结构 |
| 执行层 | Leader / Teammate + A2X 注册中心 | 任务分解、专家分工、分布式协作 | 单机多进程与分布式模式双形态，ZMQ 直连 + 共享 PostgreSQL |
| 编排层 | SwarmFlow | 确定性多阶段工作流 | Python 脚本描述，pipeline / parallel / human 等算子 |
这四层并非彼此独立的模块，而是一次明确的责任切分：入口层负责「在哪里用」，协议层负责「怎么进来」，执行层负责「谁来做」，编排层负责「按什么顺序做」。多智能体框架常见的失败模式是把这四件事揉进一个抽象里，结果任何一维的改动都会牵动全局。
在 openJiuwen 的整体生态里，JiuwenSwarm 处于最上层。底层 agent-core 提供 Python SDK，内置 ReAct 与工作流两种预置智能体、异步并行图执行与断点恢复；中间层 Agent Runtime 负责把智能体从开发态带到生产态；JiuwenSwarm 则是面向终端用户的完整应用。社区口径称整个 openJiuwen 平台由华为 2012 实验室与华为云 AgentArts 团队联合构建，但仓库页面本身未直接署名，这一归属宜以官方渠道说明为准。
E2A 统一信封：把协议差异挡在门外
工程设计上最值得注意的部分是协议层。所有外部协议——ACP、A2A，以及各个 IM 渠道各自的私有消息格式——都不直接进入系统内部，而是在 Gateway 统一转换为规范化的 E2AEnvelope 请求结构，并返回三层结构的 E2AResponse：信封、判别载荷、协议投影。
这个三层响应结构值得单独解释。信封层承载与渠道无关的元信息；判别载荷层是与具体协议无关的业务内容；协议投影层则负责在出口时按目标渠道的要求重新渲染。换言之，同一份内部结果可以同时投影到飞书的卡片、Slack 的 Block Kit 与终端的纯文本，而内部系统不需要知道任何一方的方言。
这个设计带来的直接结果是：新增一个渠道只需写一个适配器，内部系统与外部协议彻底解耦。对一个把「覆盖多少入口」当作核心卖点的框架来说，这是决定性的工程选择——渠道数量可以线性扩张，而内部复杂度保持恒定。
同时，它兼容 MCP 工具生态，并对外实现 A2A 智能体间通信协议。这使得 JiuwenSwarm 既能消费外部工具，也能作为 A2A 网络中的一个节点被其他系统调用——在协议层面它不是孤岛。实测相关的集成中还包括 playwright-mcp，用于浏览器子代理场景。
Leader/Teammate 与分布式蜂群
多智能体协作采用 Leader/Teammate 模式：Leader 负责理解目标、分解任务、组建专家团队并汇总结果，Teammate 是具体执行专家。典型的分工包括调研、编码、规划与汇总四类角色，但角色划分由 Leader 动态协商而非硬编码。
执行层提供两种形态，切换由配置项 team.runtime.mode 控制：
| 维度 | 单机模式 | 分布式模式 |
|---|---|---|
| 部署形态 | 同一机器上多进程运行 | 控制面与数据面分离，Leader 与 Teammate 可跨机器 |
| 节点发现 | 进程内直接调度 | Teammate 向独立的 A2X 注册中心注册为空闲节点 |
| 建连方式 | 本地进程通信 | Leader 组队时预约，通过 ZMQ 直连 bootstrap |
| 状态共享 | 本地文件系统与内存 | 任务数据走共享 PostgreSQL |
| 适用场景 | 开发调试、中小规模任务 | 规模化协同、需要弹性伸缩的蜂群 |
分布式模式的意义在于把「蜂群」从比喻变成可部署的拓扑。控制面与数据面分离之后，Teammate 的增减不再需要重启 Leader，注册中心成为集中式的协调点。公开资料也把「在 100 轮对话后仍保持团队对齐」作为项目的目标之一——这直指多智能体系统的经典失效模式：随着轮次增加，各子智能体对任务目标的理解逐渐发散。
SwarmFlow：给不确定性留一个显式开关
面对需要可控执行的任务，纯自主的多智能体协商可能不稳定。SwarmFlow 用 Python 脚本描述确定性编排，提供 agent、pipeline、parallel、human 等算子。其中 pipeline 无 barrier，被官方列为默认首选；parallel 提供 fork-join；human 算子用于人工介入点。
它还支持结构化输出、Git worktree 隔离、Leader 级共享 token 预算，并在 TUI 中以三层运行树（工作流 → 阶段 → 节点）实时监控。需要强调的是，SwarmFlow 依附于 Team 模式，本质是在「自由协商」和「确定性流水线」之间给用户一个显式选择，而不是要用工作流取代自主协商。
自我进化：Skill 自演进、AutoHarness 与 Symphony
这是 JiuwenSwarm 最具辨识度的部分，也是它自称「自主进化」的落点。三项机制分别作用于不同的层次。
Skill 自演进：证据门槛加人工审批
技能不再是静态文档。系统按每 5 轮任务自检（团队模式则在任务验收后），基于任务证据判断是否存在可复用的改进。触发后由 evolution_reviewer 子智能体用只读工具审查证据、生成结构化提案，默认走人工审批；通过的经验存入 evolutions.json 并在后续调用时自动加载，可用 /evolve_rebuild 永久合入 SKILL.md。
让一个智能体去改写自己的指令文件，是风险相当高的动作——一旦被注入内容污染，改写的是行为准则本身。JiuwenSwarm 的处理是三重约束：只读工具审查、证据门槛、人工审批默认开启。这个组合体现出对自动化改写指令风险的克制，在同类自进化设计里属于偏保守的一档。
AutoHarness：给 Harness 做后训练
AutoHarness 的思路是不改模型权重，让智能体为自己生成评测、定位短板、修改提示词/工具/护栏/技能，再验证。它分为两层：Meta 层改动通用底座，需要改源码提 PR 且必须人工审查；Expert 层生成领域扩展包，热加载即插即用，无需重启。全程 Git worktree 隔离加 CI 自动修复循环。
把「改底座」与「加扩展」分成两条权限不同的路径，是这里的关键决策。前者影响所有任务、必须走代码评审；后者作用域受限、可以快速迭代。这与软件工程里「框架升级」和「业务插件」的区分逻辑一致。
Symphony：技能检索与编排
当技能装到上百个时，全部注入上下文会撑爆注意力预算。Symphony 的方案是「检索用树，编排用图」：离线构建技能树索引，供智能体像查目录般逐层浏览；再基于技能图谱（节点为技能，边代表输出可衔接输入）生成可确认的技能执行链。它不替代 Leader 的任务派发，只做辅助。
Skill 自演进改的是单个技能的内容，AutoHarness 改的是 Harness 的配置与护栏，Symphony 解决的是技能规模变大后的检索与组合。三者作用于不同层次，互不替代——这也是判断一个「自进化」叙事是否成立的实用检查点：如果所有进化都发生在同一层，通常意味着机制设计还没有想清楚。
记忆系统：文件即数据源
JiuwenSwarm 的记忆设计采取「文件即数据源」的取向，用一组可读可编辑的 Markdown 文件承载不同层次的记忆：
- USER.md：用户档案，长期稳定的个人偏好与背景
- MEMORY.md：长期记忆，跨会话积累的结论
- 每日会话日志：按天归档的过程记录
- TEAM_MEMORY.md：Leader 在每一轮自动提炼的团队经验
检索采用 BM25 全文检索与向量语义检索的混合方式，默认权重为 0.7 / 0.3，底层基于 SQLite 加 FTS5 与 vec0 实现，并由 watchdog 监控文件变动异步更新索引。同时支持外接 Mem0、OpenViking 等第三方记忆服务。
此外还有一个可选的 Dreaming 机制：空闲时用大模型周期性整理历史会话、提取长期信息，带忙碌退避与增量扫描。把它设计成可选而非默认，同样是对算力与不可预期行为的克制。
把记忆落在纯文本上，代价是检索质量受制于混合检索的效果；收益是用户可以直接查看、编辑、版本化甚至手工删除某一条记忆。在权限审计严格的场景里，这个收益往往比几个百分点的检索准确率更重要。
与同类技术路线对比
| 维度 | JiuwenSwarm | AgentScope Java | docker-agent | OpenClaw |
|---|---|---|---|---|
| 语言与运行时 | Python 3.11+，含 HarmonyOS 桌面端 | Java，JDK 17+ | Go，容器化分发 | 本地优先的个人智能体 |
| 协作范式 | Leader/Teammate 蜂群，可跨机器 | ReAct 循环上的能力叠加 | YAML 声明式多智能体自动委派 | 单智能体为主，工具扩展 |
| 入口策略 | 十余个 IM 渠道 + IDE + TUI | 应用内嵌 SDK | CLI 与 Docker Desktop | 本地客户端 |
| 确定性编排 | SwarmFlow（Python 脚本算子） | 图工作流 | YAML 声明 | 对话驱动 |
| 自我进化 | Skill 自演进 + AutoHarness + Symphony | 无同类机制披露 | 无同类机制披露 | 无同类机制披露 |
| 协议归一 | E2A 统一信封 | 协议适配由应用层处理 | MCP 工具集 | MCP 为主 |
| 开源协议 | Apache 2.0 | Apache 2.0 | Apache 2.0 | 依发行版本而定 |
横向看，JiuwenSwarm 的差异化集中在三点：入口覆盖广度、协议归一化设计、以及成套的自我进化机制。这三点都指向同一个目标——降低多智能体进入既有工作流的摩擦。它的相对弱势也很清楚：作为一个面向终端用户的完整应用而非轻量库，它的抽象层次更高、可裁剪性更弱，想要只用其中某一层的团队需要付出额外的拆解成本。
局限与冷静判断
- 缺少公开基准成绩：未检索到 JiuwenSwarm 在任何第三方榜单上的评测数据，其能力叙事目前全部基于架构主张与功能描述，选型前应在非核心链路自行验证
- 归属口径需谨慎：社区资料称其由华为 2012 实验室与华为云 AgentArts 团队联合构建，但仓库页面未直接署名，正式引用时应以官方说明为准
- 星数快照差异大：不同来源分别记录约 1.8k、6k、6.5k 星，差异来自抓取时点而非数据错误，但说明项目处于高速增长期，生态成熟度仍在变化
- 自进化的长尾风险：Skill 自演进虽设人工审批默认开启，但一旦团队为效率关闭该开关，指令改写就完全依赖 evolution_reviewer 的只读审查，缺少独立的第二道防线
- 分布式运维成本：A2X 注册中心、ZMQ 直连与共享 PostgreSQL 构成一套需要单独运维的控制面，中小团队为分布式模式付出的固定成本可能高于收益
- IM 入口的双刃性：把智能体放进聊天窗口降低了使用门槛，也让权限边界与群聊场景下的数据暴露面更难界定，企业部署前需要单独评估渠道侧的合规要求
- 迭代速度带来的稳定性疑问：近期版本仍在快速迭代，公开记录涉及冷启动延迟优化、Code 工作区代码差异视图、多模态对话与浏览器子代理隔离等方向，接口稳定性尚需观察
总体而言，JiuwenSwarm 提供的是一套完整的、有明确工程主张的多智能体运行时，而不是一个可以随意拼装的工具箱。它的价值在于把入口、协议、协作、编排与进化这几件事做成了相互咬合的整体；它的代价则是使用者需要接受这一整套主张。对于已经确定要把多智能体推进到业务一线、且渠道碎片化是主要障碍的团队，这套整体性是优势；对于只想解决其中某一环的团队，它可能显得过重。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。