【JiuwenSwarm技术解析】鸿蒙PC开源AI统一工作台与HITS人机蜂群协作

文章目录JiuwenSwarm技术解析鸿蒙PC开源AI统一工作台与HITS人机蜂群协作一、引言二、从JiuwenClaw到鸿蒙PC统一工作台是怎样长出来的2.1 从单Agent驾驭转向多Agent协同2.2 开源的是什么三、架构拆解一句话如何变成一支Agent团队3.1 六层协作链路3.2 Agent Team不是“同时问几个模型”3.3 Skill自演进不是训练模型四、HITS人不在流程外而在蜂群之中4.1 HITS与HOTS的区别4.2 从产品范式到当前代码入口五、工程实践从本地启动到鸿蒙部署5.1 通用版本快速启动5.2 鸿蒙分支的技术含量与当前边界5.3 权限治理决定它能否进入生产六、横向对比JiuwenSwarm与主流多Agent框架的生态位七、总结JiuwenSwarm技术解析鸿蒙PC开源AI统一工作台与HITS人机蜂群协作一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com2026 年 7 月华为 2012 实验室、华为云、终端小艺以及华为终端平板与 PC 产品线、软件部等团队将 JiuwenSwarm 带到鸿蒙 PC。项目团队将其定位为首个面向鸿蒙 PC 的开源 AI 统一工作台用户不必分别打开聊天助手、编程工具和自动化平台而是用一句自然语言组建多智能体团队完成调研、写作、PPT、代码开发乃至多人游戏。发布演示中JiuwenSwarm 用约 20 分钟生成 200 页 PPT也展示了由多个 Agent 分工开发坦克大战、使用 ArkTS 构建热量记录应用等案例。不过这些数字应理解为特定环境中的产品演示而不是跨模型、跨硬件均可复现的标准 Benchmark。真实速度取决于模型服务、任务复杂度、检索质量、工具延迟、并行度和验收标准。更值得关注的是人机协同范式 HITSHuman in the Swarm人不再只站在工作流外点击批准而是以一个有身份、有任务、有消息通道的成员加入 Agent 团队。本文基于截至 2026 年 8 月 1 日的 JiuwenSwarm 官方仓库、产品文档和发布报道分析其演进路径、系统架构、HITS 实现、工程边界及横向定位。二、从JiuwenClaw到鸿蒙PC统一工作台是怎样长出来的2.1 从单Agent驾驭转向多Agent协同JiuwenSwarm 不是突然出现的新项目。官方 README 记录2026 年 5 月 18 日发布的 v0.2.0 将 JiuwenClaw 正式升级为 JiuwenSwarm产品重点从单 Agent 的 Harness Engineering转向多 Agent 的 Coordination Engineering。7 月 14 日发布的 v0.2.3 又补齐浏览器子 Agent 隔离、同 Session 联机、多窗口、多模态对话、Skill 经验闭环和权限治理。阶段关键变化技术含义JiuwenClaw以通用 Agent、工具和桌面交互为核心重点是让一个 Agent 能规划和执行v0.2.0JiuwenSwarm引入 Swarm、桌面端和自演进能力从单体能力转向 Leader 与 Teammate 的协同v0.2.3同 Session 联机、多窗口、浏览器隔离、多模态 Skill团队协作开始具备产品化的状态、权限和交互基础鸿蒙PC版本openharmony分支、HAP 构建链路、小艺与飞书联动将多智能体工作台放进鸿蒙桌面和跨设备入口这个演进顺序很重要。若没有共享任务、工作区、消息、记忆和权限多 Agent 只是多个聊天窗口只有这些底层状态被统一管理办公、编程和娱乐才可能共用一个工作台。2.2 开源的是什么JiuwenSwarm 官方仓库以 Python 为主采用 Apache-2.0 许可证当前项目版本为 0.2.3要求 Python 3.113.13。项目开源了 Web、TUI、桌面入口Agent Team、Channel、Skill、记忆、MCP、权限、沙箱及分布式部署等代码鸿蒙适配则维护在受保护的openharmony分支。需要明确的是JiuwenSwarm 不包含大模型权重它是流程编排与工作平台。用户仍需配置华为云 MaaS、OpenAI、DeepSeek、DashScope、SiliconFlow、OpenRouter 等兼容服务或接入本地模型。因此“全套开源”指工作台与 Agent 编排代码开放不等于推理模型和第三方服务免费。三、架构拆解一句话如何变成一支Agent团队3.1 六层协作链路┌──────────────────────────────────────────────────────────┐ │ 入口层鸿蒙PC / Web / TUI / 小艺 / 飞书 / 企业微信等 │ └──────────────────────────┬───────────────────────────────┘ v ┌──────────────────────────────────────────────────────────┐ │ Channel Gateway身份识别、消息归一、会话与路由 │ └──────────────────────────┬───────────────────────────────┘ v ┌──────────────────────────────────────────────────────────┐ │ 执行模式规划模式 / 性能模式 / 集群模式 │ └──────────────────────────┬───────────────────────────────┘ v ┌──────────────────────────────────────────────────────────┐ │ Agent TeamLeader 拆解任务、组队、分配、跟踪和汇总 │ │ Teammate 认领、并行执行、汇报与交付 │ └───────────────┬──────────────────────────────┬───────────┘ v v ┌─────────────────────────────┐ ┌─────────────────────────┐ │ Skill / MCP / 浏览器 / 代码 │ │ 个人记忆 / 团队记忆 │ │ 权限审批 / 沙箱 / 定时任务 │ │ 共享产物 / 独立工作区 │ └───────────────┬─────────────┘ └─────────────┬───────────┘ └───────────────┬───────────────┘ v 文档、PPT、代码、报告与应用Channel 是统一工作台能够跨设备存在的关键。飞书、小艺或 Web UI 收到消息后Gateway 将不同平台的身份和消息转成统一会话再交给 AgentServer。简单问题可以走性能模式需要逐步确认的任务进入规划模式长链路任务则进入集群模式由 Leader 自动决定角色、依赖和并行关系。3.2 Agent Team不是“同时问几个模型”官方文档给出的完整链路是用户提出目标Leader 分析需求并组建团队Teammate 认领和执行任务完成后汇报最后由 Leader 整合结果。团队成员不是彼此隔离的临时调用而是共享任务状态和中间产物。协作对象主要职责状态边界Leader目标理解、组队、任务规划、关键决策、结果汇总观察全队任务与交付物Teammate认领任务、专业执行、求助、汇报拥有独立工作空间和个人记忆team-workspace存储团队共享代码、文档、报告和 Skill所有团队成员共享TEAM_MEMORY.md沉淀持久团队的决策、教训、成员与上下文全员只读Leader 在轮次结束后组织写入临时团队适合一次性任务不保留团队记忆持久团队则可跨轮次积累经验。分布式模式还能把 Leader 和 Teammate 放到不同进程或机器通过注册中心发现空闲成员以 PostgreSQL 共享 TeamDB、以 pyzmq 传输消息。若多个节点要直接读取同一产物还需要显式配置共享工作区相同路径名称并不代表底层文件已经同步。3.3 Skill自演进不是训练模型JiuwenSwarm 会检测工具失败和用户纠错把改进建议写入 Skill 目录中的evolutions.json下次调用时加载相关经验也可再固化回SKILL.md。这属于 Harness 与指令资产的迭代并没有修改模型权重。这种路线的优势是更新快、可审阅、可回滚风险则是错误经验也可能被积累。因此生产环境应该为 Skill 演进设置评测、审批和版本控制不能把“自动演进”理解成无需治理的自动正确。四、HITS人不在流程外而在蜂群之中4.1 HITS与HOTS的区别发布口径把 HITS 展开为 Human in the Swarm并用 HOTSHuman on the Swarm描述传统范式。两者的差异不在于有没有审批按钮而在于人是否拥有团队成员身份。维度HOTS人在蜂群之上HITS人在蜂群之中身份外部发起者、监督者与 AI 并列的团队席位参与时机关键节点批准或驳回可持续接收任务、发言、私聊和广播协作关系人指挥 Agent人与 Agent 共同组队由 Leader 协调适合场景高风险审批、固定流程专家会诊、多人创作、互动游戏、动态加需求例如人在高铁上通过飞书唤醒鸿蒙 PC 上的汇报团队可以打回大纲、邀请技术专家 Agent、追加美化角色并持续验收最终稿。这里手机不是远程控制器那么简单而是同一个 Team Session 的消息入口。4.2 从产品范式到当前代码入口截至本文写作时发布报道使用HITS而官方仓库对应文档与配置仍称HITTHuman-in-the-Team配置开关为enable_hitt。两者表达的是同一方向但开发者查找代码和配置时应使用 HITT。HITT 的当前交互流程非常具体Web 端创建包含真人席位的团队系统生成加入指令参与者从飞书或小艺进入同一 Session。示例如下# 飞书群中需要先 机器人私聊和小艺可直接发送 /join sess_abc123 as 架构评审 # 以该席位向指定成员发消息 测试Agent 请先验证安装包再给出阻塞问题 # 退出团队席位 /exit在 Web 端$成员名 内容用来驱动真人成员对应的 Agent目标可以私信all可以广播。真人成员的任务不会自动完成必须由本人继续驱动Web 发起页面可观察全队而普通成员只接收发给自己的消息。这种权限差异让 HITS 不只是“多人共用聊天框”而是带身份路由的协作协议。五、工程实践从本地启动到鸿蒙部署5.1 通用版本快速启动官方通用版本可通过 PyPI 安装。建议使用隔离环境并在启动后再通过 Web 配置模型服务python3.11-mvenv .venvsource.venv/bin/activate pipinstalljiuwenswarm jiuwenswarm-init jiuwenswarm-start# 浏览器访问 http://localhost:5173前端可在规划、性能和集群三种模式间切换。团队开发还可以安装jiuwenswarm-tui通过/mode team进入 Team 模式鸿蒙 PC 版本则应使用官网安装包或官方openharmony分支而不是默认假设通用 PyPI 包就是完整 HAP 应用。5.2 鸿蒙分支的技术含量与当前边界openharmony分支不仅修改了界面标识还提供独立的 HarmonyOS 依赖集合与 HAP 构建脚本。公开脚本展示了五阶段链路资源编译、ETS/ArkTS 编译、C NAPI 交叉编译、HAP 打包与签名并将 Python Agent 服务封装进 HNP 资源。环节公开实现工程注意点前端ArkTS/ETS 编译为字节码依赖对应 OHOS SDK 和构建工具原生桥接C NAPI、ARM64 交叉编译需匹配鸿蒙设备架构与系统库Agent服务Python 代码与依赖打成 HNP部分含 C 扩展依赖在 HarmonyOS 下被裁剪分发HAP 打包与签名调试证书、正式签名和设备权限必须分开管理当前构建脚本包含明确的 SDK 路径和调试环境假设更适合作为官方构建链路参考而不是任意机器都能直接运行的一键脚本。团队二次开发前应先验证目标鸿蒙版本、SDK、签名、Python 依赖和模型网络连通性。5.3 权限治理决定它能否进入生产能够写文件、执行 Shell、调用浏览器和跨设备收发消息的 Agent也拥有更大的误操作面。JiuwenSwarm 提供allow / ask / deny三级工具策略、内置高危命令规则、文件路径防护和审批记录团队级执行还支持工作区隔离与浏览器子 Agent 隔离。生产上线前至少应验证四件事高危命令是否被拒绝工作区外路径是否需要审批飞书、小艺等不同 Channel 的审批语义是否一致真人加入和团队产物是否满足最小可见范围。安全文档明确指出部分权限检查与 Channel 类型有关因此不能只在 Web 端测试一次就假设所有消息入口行为相同。六、横向对比JiuwenSwarm与主流多Agent框架的生态位JiuwenSwarm 与 LangGraph、AutoGen、CrewAI 都能构建多 Agent 系统但它们处于技术栈的不同层级。维度JiuwenSwarmLangGraphAutoGenCrewAI核心定位开箱即用的 Agent 统一工作台低层、有状态 Agent 编排运行时AgentChat、Core、Studio 组成的分层框架Crews 与 Flows 结合的多 Agent 框架主要入口Web、TUI、桌面端及多种 IM ChannelPython/JS 图编排与配套平台Python 框架也提供 AutoGen StudioPython 流程与 Agent 团队协作抽象Leader、Teammate、共享工作区、团队记忆节点、边、状态与持久执行事件驱动 Core 与会话式 AgentFlow 管状态Crew 负责自主协作真人参与HITS/HITT 真人席位可从飞书、小艺加入Human-in-the-loop 检查和修改图状态由应用或 Agent 对话逻辑编排由 Flow 和业务应用设计参与节点突出优势鸿蒙 PC、多端唤醒、Skill 自演进和完整工作台可精确混合确定性步骤与 LLM 决策多 Agent 研究与分布式扩展层次清晰角色化团队和业务流程表达直接更适合谁想快速部署个人或团队 Agent 工作空间的用户需要完全控制状态机和恢复逻辑的工程团队需要自定义多 Agent 通信与运行时的开发者习惯以角色、任务和流程建模的团队如果目标是构建一套高度定制的业务后端LangGraph 的低层状态控制、AutoGen Core 的事件驱动能力或 CrewAI 的 Flow 可能更自然如果目标是先获得一个能安装、能跨设备对话、能组队和管理产物的工作台再在上面扩展 SkillJiuwenSwarm 的产品完成度更有吸引力。它的短板也同样明确多 Agent 会放大 Token、并发和错误传播成本鸿蒙分支仍带有特定构建环境假设HITS 与仓库 HITT 的命名和文档尚未完全统一发布演示也缺少统一评测集。开源团队接下来的关键不是继续堆案例而是给出可复现的任务成功率、总成本、端到端延迟、人工介入次数和故障恢复数据。七、总结维度核心结论产品定位JiuwenSwarm 是模型无关的 Agent 编排与统一工作台不是一个新的大模型协同机制Leader 拆解与汇总Teammate 并行执行共享任务、产物和团队记忆鸿蒙价值openharmony分支将工作台带到鸿蒙 PC并通过小艺、飞书延伸到跨设备会话HITS范式真人以团队席位加入蜂群代码侧当前对应 HITT 与enable_hitt配置能力沉淀Skill 自演进修改的是指令和经验资产不是模型权重需要评测、审批和回滚生产边界模型费用、权限隔离、Channel 差异、构建依赖和多 Agent 失败传播都需单独治理JiuwenSwarm 最有价值的地方不是“20 分钟做 200 页 PPT”这个醒目的数字而是把多智能体协作从开发框架推进到了普通用户能打开的桌面工作台。人可以从手机进入同一支 Agent 团队电脑继续执行工具Leader 维护任务状态成员共同修改交付物这是一种比单轮聊天更接近真实组织协作的产品形态。对准备试用的团队最合理的起点不是直接交付 200 页材料而是选择一个可验收的中型任务例如带来源的行业简报或包含测试的鸿蒙小工具。记录单 Agent 与集群模式的完成时间、Token 成本、人工纠错次数和最终通过率再决定哪些环节值得组建蜂群、哪些任务仍应保持单 Agent。只有协同收益大于协调成本HITS 才真正从发布概念变成生产力。参考资料首个鸿蒙PC开源AI统一工作台JiuwenSwarm办公编程一站式搞定 — 量子位2026-07-29JiuwenSwarm 产品页 — openJiuwenJiuwenSwarm 官方仓库 — openJiuwen GitHubJiuwenSwarm 中文 README — openJiuwenJiuwenSwarm 鸿蒙适配分支 — openJiuwenJiuwenSwarm v0.2.3 Release Note — openJiuwenAgent Team 使用指南 — JiuwenSwarmAgentTeam 人类成员联机协作HITT— JiuwenSwarmSkill 自演进 — JiuwenSwarm工具权限与安全防护 — JiuwenSwarmLangGraph Overview — LangChainAutoGen Documentation — MicrosoftCrewAI Introduction — CrewAI