华为支持的 openJiuwen（开放九问）在 2026 年 10 月 9 日开源了企业级 AgentOS，定位是"智能体时代的操作系统"。正好手上有一套自研的采购域企业 Agent 架构设计，索性把 openJiuwen 拆开核对了一遍：官方文档、四个代码仓（agent-core / jiuwenswarm / agentos-enterprise / docs）的源码、以及公开报道。本文回答三个问题——它到底怎么搭的、和自研方案比强在哪、什么时候该选它。

一、先给结论

1. openJiuwen 是"Agent 操作系统"，不是"Agent 开发框架"。它不试图覆盖 Agentic AI 全栈，只做中间那层：向下亲和模型与算力，向上使能各类智能体。这个定位在开源生态里很少见——多数开源项目止步于 SDK/编排层。
2. 它的真正门槛是多智能体协作的工程化，不是单 Agent 能力。团队状态机、任务看板、审批流、成员故障重启、跨进程消息总线、团队技能自动沉淀——这些"让一堆 Agent 别散架"的脏活，它做得很细。
3. 企业级能力有实打实的交付：分布式运行时（subprocess / Docker / K8s 三种部署策略）、多租户隔离、六层安全防护、VIP 判定的 ingress 主节点、etcd 全局状态、一键打包成 AgentOS-Client/Server 双 tgz。这是"能进机房"的形态。
4. 「本体」和「消费智能体」不是 openJiuwen 的概念。它的资产体系是五类：技能、插件、连接器、专家、专家团。搜遍官方仓与官网文档，这两个词在 openJiuwen 语境里都没有定义（「本体智能体」是用友的提法）。第四章把这件事讲清楚，并给出最接近的真实对应物。
5. 结论：两者不是替代关系，是分层关系。 openJiuwen 是"运行时 + 协作骨架 + 资产市场"，自研架构是"业务契约 + 权限语义 + 数据基座"。可以组合：用 openJiuwen 当运行时底座，把自研 Manifest 契约和 on-behalf-of 挂上去。

二、openJiuwen 是什么

它的核心主张是三条设计理念，这三句话基本定义了整个架构的走向：

• CLI as New POSIX——终端命令是 Agent 最通用的系统调用接口，不该每接一个能力就发明一套协议。
• Skill as New Library——技能就是新的库，能力靠资产化分发，而不是靠硬编码集成。
• Agent as New Service——智能体是新的服务单元，要有注册发现、独立部署、统一管控。

一句话理解这个定位：它不生产 Agent，它生产"跑 Agent 的操作系统"。

三、架构拆解：五层，24 个仓

3.1 官方五层

注意分层顺序：系统服务在最下，应用在最上，而"开发工具"和"运行时"是并列的中间层。这个排法很说明问题——它把"开发"和"运行"视为同等重要的两个面，而不是先开发后部署的线性流程。

3.2 代码仓的真实面貌

我把 org 下的仓库全列了一遍（24 个，含 Java 实现对偶仓）：

有一条值得单独说：agent-core 里藏着一个叫 Symphony 的模块，做的是"能力资产的发现、指纹、评估、检索、编排和经验沉淀"，核心结构一句话——"检索用树，编排用图"。它给每个能力资产抽取语义画像（能力指纹），建树索引供逐层探索，再把能力视图组织成关系图生成可解释的执行路线。这是整个体系里最接近"语义层/本体"的东西，第四章会再提。

3.3 分布式运行时：真正区分"玩具"和"生产"的地方

agent-runtime 的设计很朴素但很关键：

（1）三种部署策略，一个策略接口

（2）多租户隔离：向 Agent 注入租户上下文（user_id、space_id），按租户隔离资源与操作。

（3）统一服务面：管理面 REST（/api/v1/agents/deploy、/agents、/agents/{id}、DELETE），Agent 面统一端点（/query、/health、/reset_conversation）。任何 Agent 部署完都是同一套接口，调用方不需要知道里面是低代码还是高码。

（4）数据库可换：SQLite / MySQL / GaussDB / openGauss——国产数据库适配是认真的。

3.4 AgentOS 交付仓：怎么进机房的

agentos-enterprise 是个"集成交付仓"，自己不实现功能，只把四个组件固定版本、统一构建部署：

几个我觉得设计得很清醒的细节：

• 构建不编译源码，只聚合：从 OBS 拉各组件的预编译产物（wheel/rpm），打成 AgentOS-Client.tgz（给终端用户）和 AgentOS-Server-<arch>.tgz（给部署者）两个包。组件 CI 独立出包归档，总包只拉最新成功归档——消除了版本号和时间戳硬编码。
• 部署脚本零组件逻辑：agentos.sh 只做调度，模块在 MODULES 数组里声明，每个模块实现 up/down/install/uninstall/status 五个钩子。up 按声明顺序、down 自动逆序（后启动的依赖先启动的，逆序停才安全）。
• 生命周期分三层，对应三种变更频率：install/uninstall（whl 包，几乎不变）、init/deinit（etcd bootstrap，一次性，数据跨 up/down 存活）、up/down（应用服务，随版本反复起停）。所以 down 不动 etcd，init 保留已有数据实现平滑升级。
• 不引入选举组件，复用网络层 VIP：config.yaml 声明 ingress_virtual_ip，本机网卡持有该 VIP 就是 ingress master；gateway 用 systemd ExecStartPre 门控，未持 VIP 的节点启动直接失败（fail-closed）而不是静默跳过。

最后这条我特别欣赏："谁在提供服务"在网络层就能看出来，不需要查任何配置文件。这是运维友好的设计。

3.5 六层安全

3.6 自演进：让 Agent"每次使用都是一次有效训练"

两条机制：

• 文本梯度优化：对 bad case 做轨迹分析，用"文本梯度"机制对提示词做自动化、非随机、有梯度意义的持续优化（不是随机试错）。
• 经验沉淀：任务执行后反思轨迹、提炼结构化经验，不断进化经验库。

加上 2026-09 发布的双维度 RSI（递归自我改进）框架，支持可插拔的 Harness 与 Artifacts 两条优化路径，并靠算力亲和降低多轮优化的开销。这套东西落在 WorkSwarm 上。

还有一个偏学术但在工程上很实在的设计：双通道验证架构——把 LLM 的"快思考"概率推理与形式化方法的"慢验证"确定性校验结合，运行时把校验结果反馈给 Agent，引导它在受限搜索空间内重新规划。用"执行—验证—修复"闭环，在概率之上构建确定性。企业流程要的就是这个。

四、概念澄清：「本体」和「消费智能体」在 openJiuwen 里并不存在

这一章是本文最需要先讲结论的部分。

4.1 先辟谣

我在四个官方仓（agent-core、jiuwenswarm、agentos-enterprise、docs）+ 官网文档全文检索了这两个词：

openJiuwen 的能力资产是五类，没有「本体」也没有「消费智能体」这两个东西。

至于「本体」，中文语境里最近确实有个热门提法叫本体智能体（Ontology-Driven Agent）——那是一家 ERP 厂商（用友）的提法，核心是在大模型和企业业务数据之间搭一套"业务语义本体"：实体、属性、关系、业务逻辑、行动的结构化体系。跟 openJiuwen 不是一回事。

4.2 openJiuwen 真实的五类资产（Agentic Hub）

五类资源都有完整的生命周期：创建 → 安装 → 使用 → 发布 → 再次获取，并可在任务中叠加组合。相关资产已上线 Agentic Hub（我实测首页显示 256 个 Swarm Skills，分类覆盖开发编程、办公生产力、内容创作、多模态、数据科研、合规法律、生活健康、金融理财）。

4.3 如果一定要对号入座

所以在这套体系里，真正需要分清的不是"本体 vs 消费智能体"，而是"个体 Agent vs 专家 vs 专家团 vs 多 Agent 协作"——这才是下面要讲的。

4.4 个体、专家、专家团、多 Agent 协作：区别与功能

一句话记忆：

个体 Agent 是"一个人"，专家是"一个带职称的人"，专家团是"一个项目组"，多 Agent 协作是"让项目组别散架的那套管理制度"。

很多人把"专家团"和"多 Agent 协作"混着说，其实一个是组织形态、一个是机制。前者是名词，后者是动词的容器。

五、多 Agent 协作：openJiuwen 最硬的部分

这是我认为它真正超出一般开源框架的地方。拆开看有五个层次。

5.1 团队编排层（Agent Swarm / AgentTeam）

角色模型——三种角色，但不是三个类：

关键设计：三种角色是同一个 TeamAgent 实例通过 TeamRole 切换行为。这个选择很聪明——统一实现降低了复杂度，还保证了角色行为一致（同一个内核，不会出现 Leader 和 Teammate 行为风格打架）。

团队生命周期两种：临时团队（任务完成自动解散）、持久团队（可暂停/恢复、跨会话存在）。团队模式三种：Default（Leader 用 spawn_teammate 动态建人）、Predefined（成员固定）、Hybrid（预注册基础成员 + 保留动态创建）。未显式指定时系统自动推断。

协调机制是事件驱动的，而且有个我很认可的哲学：

协调层不做业务决策，只负责唤醒（wake-up）。所有业务行为由 Agent 自身通过工具调用驱动。

事件来源两类：传输层事件（跨进程通信）+ 内部轮询事件（定时器补偿——即使外部事件丢了，轮询仍能推动团队继续跑，避免停滞）。六个协调处理器各管一摊：AgentLifecycleHandler（生命周期与中途 steer）、MemberHandler（成员状态、卡住的任务）、MessageHandler（未读消息）、TaskBoardHandler（任务认领、唤醒空闲 Agent）、StaleTaskHandler（120 秒超时的停滞任务检测）、TeamCompletionHandler（判定全团完工）。

协调层与 Agent 之间用三类窄接口（只暴露必要方法的接口）解耦：AgentRoundController（单轮对话 / 取消 / 恢复）、TeamLifecycleController（关闭自身）、PollController（暂停恢复轮询）。

任务管理是完整的看板模型：PENDING → CLAIMED → PLAN_APPROVED → COMPLETED，带 BLOCKED（阻塞回退）和 CANCELLED，任务间可建依赖形成 DAG，内置环检测防死锁。还有两条审批流：Plan 模式（Teammate 认领后先出计划、Leader 批了才执行）和工具审批（高风险工具调用时 Rail 拦截、向 Leader 申请，批准才恢复）。

成员容错：严格状态机（UNSTARTED / READY / BUSY / PAUSED / STOPPED / SHUTDOWN / ERROR），幂等保证（重复转换直接跳过，不写库不发事件，避免事件风暴），SpawnManager 做心跳检测 + 崩溃后指数退避自动重启（默认最多 3 次，间隔 2^attempt 秒），RecoveryManager 做团队级状态对齐。

HITT（Human-in-the-Team）比"人机协同"这个口号具体得多——人可以用三种身份介入：# 消息（全局视角直达 Leader，指挥者）、$<名字> 消息（以注册的 HumanAgent 身份在团队内发言，团队成员）、@<成员名> 消息（以外部用户身份定向；@all/@* 广播）。HumanAgent 工具集被严格限制为"只看和完成"，分配给它的任务被认领后其他成员不能重分配或取消。

可观测性：TeamMonitor 提供查询 API + 事件流两种监控，内置 OpenTelemetry，把 Agent 行为与团队事件转成分布式追踪 Span，支持跨异步任务的 Span 传播。

5.2 团队技能层（Swarm Skill）

协作跑通了，怎么沉淀？ 这是 Swarm Skill 解决的问题。它的文件结构本身就是设计：

skills/<skill-name>/
├── SKILL.md          # 入口，frontmatter 必须 kind: swarm-skill
├── roles/
│   └── <role-id>.md  # 每个角色的详细定义
├── workflow.md       # 工作流：任务依赖、并行/串行关系
├── bind.md           # 约束：轮数上限、超时、质量门
└── evolutions.json   # 演进记录

自动创建机制：TeamSkillCreateRail 等团队任务完成后，检查本次是否 spawn 了足够多成员（默认 ≥2）、且没复用现有技能——满足就注入 follow-up，引导 Agent 判断这次的协作模式是否值得沉淀；值得的话必须用普通回复向用户确认，不许用弹窗式交互工具。这个约束挺务实：沉淀动作要留痕、可审计。

对应一整套组件：TeamSkillEvolutionRail（在线演进）、SkillExperienceOptimizer、evolution_reviewer（主动审核链路的专用 subagent）、ExperienceScorer（经验评分）、TrajectorySpanProcessor（把已结束的 observability span 投影为轨迹证据）。

双维度 RSI（2026-09 落地 WorkSwarm）：团队层（按执行轨迹自动增减角色、补充约束、优化协作流程）+ 成员层（把工具报错、接口超时、调用技巧沉淀下来，同一类问题不重复踩坑）。团队在进步，每个成员也在成长——这话在宣传稿里常见，但代码里确实有对应机制。

5.3 工作流编排层（SwarmFlow）

2026-06 开源的 SwarmFlow，核心主张是"编排与智能分离"：

• 系统负责稳定执行预定义的协作流程（算子搭建工作流、可视化、断点续跑）
• 智能体负责推理与子任务执行

它和 Swarm Skill 是一对：Swarm Skill 定义团队角色与协作规范，SwarmFlow 是它的可执行部分，把规范转化成能自动跑的工作流脚本。用户用自然语言描述，内置的 SwarmSkill Creator 就能生成带或不带工作流脚本的 Swarm Skill，Team 模式下系统自动判断该调哪个。

这个分层解决的是多智能体最现实的痛点：协作流程不稳定、不可控。把"谁先谁后"这种确定性的东西交给系统，把"怎么做"留给模型。

5.4 分布式运行时层

传输层是可插拔的：

成员启动也分进程内（asyncio.Task，共享事件循环）和子进程（独立进程 + ZMQ，隔离更强）。从 agent-core 的示例目录能看到它支持的协作拓扑：team_hybrid、runtime_p2p、runtime_pubsub、runtime_hybrid——点对点、发布订阅、混合，三种都在，另外还有 handoff（交接式）和 hierarchical_msgbus（层级消息总线 + supervisor）两种内置团队形态。

模型池支持按角色分配不同 LLM：RoundRobin（线性轮转）、ByModelName（按模型名分组）、Router（单一映射）。

5.5 安全与约束

Rail 体系是它的护栏实现方式，在 Agent 行为链路上插检查点：

Prompt 严格三层分工：Policy 层（角色身份）、Workflow 层（操作步骤）、Tool/Description 层（工具的用途、约束、成本）。各层不重叠——这是很多团队做不好的地方。

六、和自研企业 Agent 架构对比

对比对象是一套采购域的企业 Agent 架构设计（内部设计稿，下称"自研方案"）。它和 openJiuwen 出发点完全不同：自研方案从业务边界出发（采购业务长什么样、权限怎么落、写操作谁来保证合规），openJiuwen 从运行形态出发（Agent 怎么跑、怎么协同、怎么进化）。

6.1 自研方案速览（便于对照）

6.2 逐维度对比

6.3 自研方案相对 openJiuwen 的四个优势

1. 业务语义层是它的空白，而这正是企业落地的命门。 openJiuwen 管得住 Agent 怎么跑，管不住"上季度钛合金采购均价该查哪儿"。数据基座、口径统一、主数据权威、读写分离——这些必须在业务侧解决。
2. on-behalf-of 与幂等键是"能办事"的前提。 Agent 代替人做事，权限不得超过本人；写操作必须有业务键幂等。openJiuwen 的六层安全解决的是运行时安全，不是"以谁的身份在业务系统里做了什么事"。
3. 数据新鲜度这类业务风险，框架不会替你想到。 "用 T+1 基座数据做实时放行决策"是会真出事的坑。在 Manifest 里强制声明 freshness: realtime|batch，平台据此选数据源——这个设计框架层给不了。
4. 交互载体可以深到"出现在人正在工作的地方"。 openJiuwen 的接入是 IM/工作台形态（人去找 Agent 或 Agent 找人），自研方案的浏览器插件是结果回流（Agent 干完活，页面自己刷新出结果）——在 ERP 场景里这个体验差距很大。

6.4 openJiuwen 相对自研方案的四个优势

1. 多智能体协作它已经趟过一遍了。 团队状态机、六大协调处理器、Plan 审批、工具审批、卡住任务 120 秒检测、成员崩溃指数退避重启、幂等状态转换防事件风暴——这些是"跑了才有 bug"的脏活。自研从零做，等于重走一遍。
2. 分布式运行时 + 多租户 + 三部署策略是现成的。 自研要自己解决注册发现、跨节点通信、状态持久化与断点续跑、资源隔离。
3. 资产市场与自演进构成飞轮。 256 个 Swarm Skills + 双维度 RSI，越用越强；自研起步是零资产。
4. 算力亲和与推理优化是真金白银。 KV Cache 主动协同、统一调度与任务路由——多 Agent 场景下 token 成本是主要成本项，这块它做到了系统层。

6.5 我的判断：分层，不是二选一

┌──────────────────────────────────────────────┐
│  业务契约与语义层（自研，不可替代）           │
│  Manifest · on-behalf-of · freshness · 幂等键 │
│  业务本体（物料/供应商/科目）· 数据基座        │
├──────────────────────────────────────────────┤
│  运行时与协作底座（可复用 openJiuwen）        │
│  Agent Runtime · 团队协作 · 分布式状态         │
│  沙箱 · 多租户 · 资产分发 · 自演进             │
└──────────────────────────────────────────────┘

契约层和业务语义层是核心资产，必须自研；运行时、协作机制、部署形态是可以借的。 这两层之间用 HTTP + on-behalf-of 令牌对接即可——openJiuwen 的 Agent 统一端点（/query 等）当被调用方，自研的注册中心当调用方与治理方，冲突不大。

反过来说，如果你是从零开始、没有深度绑定某套 ERP、且团队规模能接受一个分布式底座，直接用 openJiuwen 比自己造轮子划算得多。

七、选型建议

适合用 openJiuwen 的情况：

• 需要 10 个以上 Agent 协同，且协作模式会持续变化（框架帮你扛住复杂度）
• 需要私有化部署且认同国产数据库/沙箱/信创栈（GaussDB/openGauss 支持是认真的）
• 团队不想自建分布式运行时，只想写 Agent 逻辑
• 想要资产复用——社区 256 个 Swarm Skills 可以直接拿来改
• 已有华为栈（鸿蒙/华为云/小艺），通道和分发天然打通

要谨慎或坚持自研的情况：

• 业务权限必须精确到"以谁的身份做了什么"——openJiuwen 没有 on-behalf-of，这块要自己补
• 业务深度绑在 SAP 或自研 ERP 上，业务语义与数据口径必须自控
• 需要在宿主系统内部干活（浏览器插件结果回流、Excel 加载项这类形态），IM/工作台形态不够
• 团队没有运维分布式底座的能力——用了 K8s 策略就得有人管 K8s
• 对供应链风险敏感（开源项目虽然 Apache 2.0，但集成商生态、长期演进节奏需要评估）

三条风险提醒：

1. 生态还在快速演进：SwarmFlow（6 月）、WorkSwarm 上架（8 月）、Agentic Hub（9 月）、AgentOS（10 月）——四个月四个大版本。跟随成本不低，别绑死某一版的内部实现。
2. Agent 复杂度本身在指数增长：官方引用的 Nature 观点是"Agent 应用复杂度每 7 个月翻一番"。这意味着任何框架的价值都会随复杂度增长被重新检验，架构上要留出替换缝（这也是自研方案"契约自研、协议传输可换"的价值）。
3. 社区数据要盯着看：官方口径 100+ 家企业落地，邮储、腾讯视频（鸿蒙端侧 A2A）是可查的公开案例。但具体到你的场景，建议先做 2-4 周 PoC，用真实业务流验证协作与权限，而不是看 benchmark 分数做决定。

结语

openJiuwen 最值得学的地方不是某个具体模块，而是它对"企业级"这件事的理解方式：

• 把不确定性关进确定性的笼子——双通道验证、编排与智能分离、事件驱动 + 轮询补偿、幂等状态转换。
• 把治理做成默认而不是插件——六层安全、角色化工具注册、按角色分层 Prompt。
• 把经验变成资产而不是日志——Swarm Skill 自动沉淀、双重 RSI。

而我们自研架构最值得坚持的地方，是业务语义和身份权限必须自己拿在手里。框架能给你一个跑得稳的运行时，给不了"上季度钛合金均价该查哪张表、以谁的身份放行这笔 PO"。

框架管奔跑，业务管方向。这两件事从来不在同一层，也从来不该由同一方决定。

参考来源：openJiuwen 官网与官方文档仓；GitHub openJiuwen-ai 组织源码（agent-core / jiuwenswarm / agentos-enterprise / agent-protocol / agent-runtime / agent-memory / skillhub / docs）；openJiuwen Agentic Hub（swarmskills.openjiuwen.com）；百度百科「openJiuwen」词条；机器之心《openJiuwen：打造高可靠、自演进、多智能体原生、算力亲和的 AgentOS》（新浪财经转载）；《openJiuwen 发布并开源企业级 AgentOS》报道（2026-10-09）；知乎专栏《从 Harness 走向 Coordination，openJiuwen 社区发布 JiuwenSwarm》与《openJiuwen 发布业界首个企业级智能体分布式蜂群架构》。本文的架构细节以官方仓库源码为准，未做本机实机部署验证。