OpenJiuwen开源多智能体平台综述
目录
1.研究背景
OpenJiuwen（九问）是华为 2012 实验室、华为云 AgentArts 团队联合推出的开源生产级 AI Agent 操作系统（AgentOS）底座，2025 年 12 月正式开源，核心提出协同工程（Coordination Engineering）范式，推动智能体从单一体执行向多智能体团队协同升级。
平台原生支持蜂群多智能体自动分工协作、分层独立记忆体系、智能体自演进三大核心能力；配套可视化低代码开发工作台、全链路可观测运维工具，模型中立兼容主流大模型，支持单机与集群部署。上层衍生 JiuwenSwarm 蜂群智能体、WorkSwarm 办公工作台、DeepSearch 深度检索等产品，适用于长周期科研调研、复杂多角色任务、企业级 Agent 系统搭建等场景。
2026 年 10 月，上层产品 WorkSwarm 进一步推出全双工多模态交互能力，实现实时对话与后台任务并行执行，将人机协同从“半双工回合制”升级为“全双工并行制”，覆盖实时办公协同、多模态任务等场景。
1.1Agent 发展痛点
随着大模型能力提升，Agent 开始承担更长周期、更复杂的任务，单智能体方案逐渐暴露四类核心痛点：
1. 任务复杂度瓶颈：单个 Agent 难以同时兼顾规划、调研、写作、校验等多角色工作，面对大型任务能力不足；
2. 长周期上下文爆炸：长任务中对话上下文无限膨胀，关键历史信息易丢失，Token 开销指数级上升；
3. 多 Agent 方案浅层化：多数多 Agent 框架仅实现简单消息转发，缺少自动任务拆解、结果冲突校验、团队能力复用机制；
4. 工程化能力缺失：大量原型框架缺少可视化开发、全链路调试观测、自动迭代优化能力，Agent 运行如同黑盒。
5. 交互体验痛点：传统 Agent 为“半双工”回合制对话，用户必须等 AI 回复完成才能继续提问；工具执行期间无法交互，等待感强；复杂后台任务与实时对话互相阻塞，无法实现“边聊边办事”的自然协同。
2.整体架构与核心模块
2.1六层架构
OpenJiuwen 采用严格的自上而下分层依赖设计，完整架构如下图所示：
自上而下分别为：DeepAgents 上层应用、SwarmSkillsHub 技能中心、AgentStudio 开发工作台、openjiuwen-Ops 运维观测、AgentFramework 运行内核、AgentSystemService 底层系统。其中 AgentFramework 是整个系统的执行核心，所有业务逻辑最终落地到 agent-core 仓库。
2.2全系统数据流总览
完整端到端数据流如下：
1. 用户通过前端 UI 提交任务；
2. 请求进入 Agent Gateway 接入网关，完成格式标准化与消息投递；
3. Agent Core 接收任务，调用 Agent Engine 进行调度；
4. 任务执行过程中，从 Swarm Skills Hub 加载技能，从 Agent Memory 召回历史记忆；
5. 蜂群场景下，Coordination Engine 拆解任务，多个 Agent 通过 A2A 协议通信协作；
6. Harness 容器启动 TaskLoop 循环，经过 Agent Shell 安全校验，由 Core 层原语执行工具调用，所有执行动作在 System Sandbox 中隔离运行；
7. 任务执行轨迹、指标数据全部上报 openjiuwen-Ops；
8. 任务结束后，异步触发记忆提取压缩、自演进优化；
9. 最终结果沿调用链路返回用户。
2.3核心模块一：AgentCore 运行内核
2.3.1核心引擎调度原理
AgentEngine 总调度：采用引擎组合模式，不同子引擎负责不同维度：ContextEngine 管上下文、HarnessEngine 管运行管控、CoordinationEngine 管多 Agent 协同、SelfEvolving 管自演进。各引擎可独立配置、可插拔替换。
2.3.2全双工双轨执行原理
全双工模式下，Agent Core 内部拆分为两条独立执行通路，是 WorkSwarm 全双工能力的底层技术支撑。
1. 实时交互通路：对接多模态输入，由轻量化实时模型负责语音转写、意图识别、即时播报；核心实现人声检测、BARGE-IN 打断机制——检测新人声立即停止播报、开启新回合，已生成文字保留；负责前台对话体验，支持随时打断、补充、追问。
2. 后台任务通路：接收实时通路移交的复杂任务，完整复用原有 TaskLoop、工具调用、蜂群协同、记忆系统全部能力；负责后台复杂任务处理，执行不阻塞前台对话。
3. AGENT HANDOFF 交接机制：实时通路自动判断任务复杂度，简单问题即时回复，复杂任务自动移交后台；任务状态、进度、结果异步回传原会话；支持多任务排队、顺序调整、置顶、取消；两条通路独立调度、独立运行，音视频关闭后已提交任务仍可继续执行。
2.4核心模块二：Agent Memory 分层记忆系统
OpenJiuwen 的记忆体系采用短时会话记忆 + 长时分层记忆的双层分离设计，其中短时记忆内置于 Agent Core 的上下文引擎，服务于单次任务的即时推理；长时记忆由独立的 agent-memory 组件实现，实现跨会话、跨任务的知识沉淀与复用。
2.4.1短时记忆（工作记忆）原理
短时记忆也叫会话上下文记忆，是单任务推理的直接“工作内存”，对应 Agent Core 内部的 Context Engine，是每次推理最先调用的记忆单元。
核心作用：为当前正在执行的任务提供即时上下文支撑，保持多轮对话的连贯性与推理连续性，解决单轮对话“失忆”问题。
存储内容：仅保存当前任务 / 会话范围内的信息，包括本次对话的历史消息、每一轮工具调用的输入与输出、中间推理状态、临时任务变量。
生命周期：随任务启动而初始化，随任务结束而销毁，不跨会话、不跨任务保留；关闭对话或任务终止后，短时记忆直接释放，不会持久化。
实现机制：采用滑动窗口 + 动态优先级裁剪模式：默认保留最近的 N 轮对话，维持信息新鲜度；当 Token 总量接近模型上下文上限时，自动按照优先级裁剪——优先保留最新对话、用户明确指令、工具执行结果，优先裁剪冗余的中间推理过程、重复表述，在保留关键信息的前提下控制上下文长度。
核心特点：访问速度极快，但容量受模型上下文窗口限制，属于临时存储，无需额外部署存储组件。
2.4.2长时记忆（持久记忆）原理
长时记忆是跨任务、跨会话的持久知识沉淀，由独立的 agent-memory 组件实现，是 OpenJiuwen 区别于多数单 Agent 框架的核心能力之一。
核心作用：沉淀历史任务中的知识、经验、用户偏好，跨任务复用，解决长周期任务“失忆”、重复提问、重复推理的问题，让智能体具备“经验积累”能力。
生命周期：任务结束后异步后台加工写入，持久化保存在向量数据库与 KV 存储中，跨会话、跨任务永久保留，可按需召回。
（1）L0-L3 四层分层存储结构
长时记忆内部按抽象粒度逐级分层，兼顾原始信息的可回溯性与检索效率：
L0 原始信息层：完整无损保存原始对话、时间戳、元数据，作为所有记忆提取的源头，支持完整回溯；容量大、访问频率低。
L1 摘要记忆层：对单次会话做压缩提炼，生成关键结论摘要，大幅降低 Token 开销；中等容量、按会话检索。
L2 结构化记忆层：拆分为情景记忆（事件、决策、活动）和语义记忆（背景知识、技能、领域）；支持语义检索、跨会话复用。
L3 用户画像层：最高层级抽象，存储用户核心特征、偏好、习惯、结构化属性；容量最小、访问频率最高、优先召回。
（2）四阶段处理流水线
记忆处理是完整的信息加工流水线，而非简单保存对话：
1. 信息提取精炼（Extraction & Refinement）：任务结束后异步触发，调用大模型从原始对话、工具返回中过滤噪声，提取结构化事实、结论、约束。
2. 记忆压缩构建（Compression & Construction）：对长文本做摘要压缩，生成 Embedding 向量，平衡记忆粒度与 Token 开销。
3. 混合检索（Hybrid Retrieval）：采用关键词精确匹配 + 向量语义检索双路召回，兼顾事实准确性与语义联想能力，召回结果注入推理上下文。
4. 记忆整合演进（Consolidation & Evolution）：后台异步常驻任务，合并重复记忆、清理过期信息、更新向量索引，持久化写入向量数据库。
（3）Dreaming 睡眠整合机制
类比人类睡眠时的记忆巩固过程，后台定时异步运行，分阶段完成记忆筛选、提炼、整合，全程无需人工干预，是长时记忆自动演进的核心机制：
浅睡阶段：增量扫描新产生的会话，筛选出有价值的会话，过滤无效短会话、无意义对话；
REM 阶段：批量完成信息提取、分类、分层，生成 L1 摘要记忆、L2 结构化记忆，并生成向量索引；
深睡阶段：深度整合跨会话知识，更新 L3 用户画像，去重冲突记忆，完成长期记忆巩固与升华。
2.4.3长短时记忆协同工作机制
二者在任务全生命周期中紧密配合、双向联动：
1. 任务推理阶段（读路径）
上下文引擎同时加载两部分信息，融合为完整的推理上下文：
短时记忆：提供本次会话已产生的对话历史、工具调用结果、中间状态；
长时记忆：根据当前任务的语义，召回相关的历史知识、过往经验、用户偏好。
2. 任务结束阶段（写路径）
短时记忆：随任务实例销毁，直接释放内存；
长时记忆：触发后台异步流程，将本次会话中有价值的信息进行提取、精炼、分层，写入长时记忆存储，完成知识沉淀。
2.4.4实现局限
记忆提取、摘要的质量高度依赖底座大模型的能力；
长时记忆依赖外部向量数据库（Chroma、Milvus 等），轻量场景部署偏重；
多源记忆的冲突消解策略相对基础，复杂长周期多任务场景下容易出现记忆不一致；
Dreaming 定时整合会产生后台 LLM 调用，是无用户交互时 Token 消耗的核心来源之一。
2.5核心模块三：多 Agent 蜂群协同机制
1. Leader Receives Task（Leader 接收任务）
Leader 作为总负责人，接收用户下发的目标任务（比如代码编写、论文方案设计）。
原理：Leader 先理解需求，规划整体执行方案，是整个蜂群任务的入口。
2. Budget Check 预算检查
执行 `budget()` 算子，核查剩余 token / 算力预算。
重点（汇报亮点，衔接你之前 token 优化内容）：OpenJiuwen 在这里就做前置管控，提前判断任务开销，预算不足时可以直接提前剪枝，避免无限制消耗 token，这就是它控制 token 的手段之一。
3. Determine N Workers 确定 Worker 数量
根据预算多少，决定并行启动多少个 Worker 子 Agent。预算充足就多开几个 Worker 并行生成方案；预算紧张就减少并行数量。
原理：协同引擎动态调控并行规模，算力和任务难度匹配。
4. Parallel Dispatch 并行分发 parallel()
调用 `parallel()` 算子，同时启动多个 Worker（Worker A/B/C…），每个 Worker 独立思考、独立生成候选方案。
屏障同步机制：所有分支全部执行完成，才会进入下一阶段。每个 Worker 拥有独立记忆，互不干扰，各自产出自己的候选方案。
5. Filter Empty Results 过滤空结果 compact()
`compact()` 算子，剔除执行失败、返回空内容的 Worker 分支，只保留有效的候选方案。
作用：淘汰无效分支，减少后续评审环节的 token 开销。
6. Streaming Review 流式评审 pipeline()
`pipeline()` 流式流水线评审。候选方案不需要等全部生成完再评审，一个候选方案评审完成，就立刻进入下一个候选的评审，串行依次完成所有候选的审查，提升执行效率。
7. Stateful Arbitration 有状态仲裁 agent_session()
`agent_session()` 有状态仲裁器，保存全部子任务会话状态，汇总所有候选方案 + 全部评审反馈，横向对比所有方案，挑选最优候选。
关键点：有状态，意味着仲裁过程中间结果会持久保存，任务中断后可以断点继续执行。
8. Confidence Check 置信度判断
仲裁器评估当前最优方案的可信度：
Yes：置信度达标，直接选定最优方案
No：置信度不足，触发 `human()` 人工兜底
9. Human Fallback 人在回路介入 human()
当 AI 自己拿不准方案好坏，就交给人工审核，由人来做最终决策，修正方案。这就是 OpenJiuwen 支持的人在回路（human-in-the-loop）。
10. Final Return 返回最终结果 return
把最终确定的方案作为整个 SwarmFlow 工作流的输出，交付给用户。
SwarmEngine 蜂群引擎
蜂群生命周期管理器：接收总任务→初始化蜂群环境→管理 Agent 实例创建、调度、销毁。
CoordinationEngine 协同引擎
任务拆解：将复杂任务自动拆分为并行 / 串行列子任务；
角色匹配：为子任务分配对应角色的 WorkerAgent；
结果合并：收集子 Agent 输出，做冲突检测、去重、汇总，而非简单文本拼接；
流转控制：支持串行、并行、条件分支等多种协作模式。
2.6核心模块四：RSI 递归自我改进框架
2.6.1双维度设计
将自我改进拆为两个互不耦合的优化轨道，避免梯度干扰：
Harness 维度：优化 Agent 的工作方法（Prompt、Skill、Tool、Rail），改过程；
Artifacts 维度：优化最终交付产物（论文、代码程序），改结果。
2.6.2四层架构与六阶段闭环
四层架构：任务层→迭代优化层→执行层→基础框架层。六阶段闭环：评测验证建立基线→分析定位问题→提案构建候选→采纳融合有效改进→RSI 经验沉淀→归档停止。
任务层定义优化目标。左边任务输入包含目标、初始版本、任务数据、证据、评测标准和训练材料；右边配置包含约束、模型角色、预算、并发和环境。没有清晰评测标准，自演进就无法判断变好还是变坏。
迭代优化层由 OptimizationController 统一调度。父版本选择决定从哪个版本继续搜索，Frontier 保存还值得探索的候选，PUCT 在利用高分版本和探索新方向之间平衡，预算分配限制总成本。
执行层有两条路径。ArtifactBuilder 用于生成或修改产物；AgentTaskRunner 用于运行 Agent 任务。ExecutionAdapter 选择 Docker、本地或沙箱，并负责超时、取消和异常恢复。两条路径都必须返回结果与证据包，里面包括原始输出、分数、轨迹、日志、费用和版本摘要。
基础框架提供 AgentLoop、模型与上下文、Tool Skill Rail、沙箱隔离、Checkpoint 和可观测性。上层优化器并不直接假设执行细节，而是通过统一结果和证据接口比较不同候选。
2.6.3实测效果与局限
Harness 优化在 SWE-benchLiteDev 上通过率 61.0%→87.0%；冻结后独立测试集 Evo-BenchGeneral 上 60.9%→71.9%；
核心局限：强依赖人工编写的评测集，冷启动成本高；训练集提升存在过拟合风险，泛化能力需单独验证；完整 RSI 产品化能力在 WorkSwarm 中，开源内核侧缺少完整独立的 RSI 框架实现。
2.7其他模块功能简述
AgentStudio：对应 agent-studio 仓库，Web 端低代码开发平台，提供拖拽式工作流画布、Agent 编辑器、资源管理，输出 DSL 配置交给内核执行。
openjiuwen-Ops：全链路埋点可观测，Trace 追踪所有 LLM 调用，支持定位异常 Token 消耗、回放任务轨迹。
AgentDistributedRuntime：对应 agent-runtime、agent-dx 仓库，负责分布式部署、实例管理、负载均衡，单机模式自动降级。
AgentSystemService：底层系统能力，包括系统沙箱、隔离文件系统、消息总线，散落在各内核仓库中。
-
3.实现局限与现存问题详细分析
3.1技术实现层面
多语言栈碎片化：协议层 C++、核心 SDK Python、行业方案 Java，多语言并存。agent-protocol 仅提供 C++ SDK，Python 开发者二次开发协议层门槛较高；不同语言版本功能迭代不同步。
部分组件文档缺失：model-router、agent-infer 等仓库无公开简介，docs 文档更新滞后于代码，高级特性（如分布式调度、算力亲和）缺少完整开发文档，学习曲线陡峭。
分布式能力门槛高：agent-dx、agent-runtime 的集群部署需要较强运维能力，普通研究者大多使用单机模式，分布式、多租户、弹性扩缩等能力基本无法体验。
算力亲和硬件绑定：KVCache 调度、算力亲和优化深度绑定昇腾 NPU / 鲲鹏 CPU 基础设施，通用 x86 + NVIDIA 硬件上优化效果大幅下降，无法复现官方实验数据。
记忆模块部署较重：agent-memory 依赖外部向量数据库，对于简单任务、轻量场景，记忆组件显得过重。
3.2产品与生态层面
RSI 开源程度有限：完整 RSI 实验框架、可视化实验页面主要集成在 WorkSwarm 桌面产品中，开源仓库没有独立完整的 RSI 实现，二次开发自定义 RSI 难度大。
插件生态相对薄弱：相比 QwenPaw 丰富的桌面工具插件，OpenJiuwen 的 agent-plugin 生态体量较小，偏向服务端、行业场景，个人桌面工具较少。
桌面端产品开源度低：WorkSwarm 作为面向用户的桌面产品，未完全开源，开源侧主要是内核与组件，普通用户直接使用门槛高。
行业方案侧代码不透明：agent-solution 行业解决方案仓库仅公布通用组件，垂直场景具体实现未完全开源算法层面
搜索算法黑盒：RSI 的候选生成、父版本选择（Frontier / PUCT）等搜索算法的具体实现细节公开不足，无法判断是否存在局部最优问题。
记忆冲突消解能力弱：多源记忆冲突、矛盾信息识别的策略较为基础，复杂长周期任务容易出现记忆不一致。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)