HyperAgent：openJiuwen对未来Agent架构的思考和实践

Agent 正在从「回答一个问题」走向「承担一份工作」。近日，开源 AI Agent 社区 openJiuwen 针对 HyperAgent 架构详细解读，系统阐述了它对下一代 Agent 形态的判断 ——HyperAgent 应具备的八项特征，以及支撑这一形态的开源 AgentOS 分层设计。

今年 9 月，openJiuwen 社区就已对外发布 HyperAgent 架构，架构图同步在官网公开（openjiuwen.com）。上周，openJiuwen 又公开了其蜂群协作在 WorkSwarm 中的落地进展：永续智能体（Persistent Agent）可以接入多个 IM 跨渠道协同，人、数字员工和专家团可以在原生群聊中分工协作。

近期，业内不少厂商和研究机构也开始探索相近的架构方向。这次的解读则是对整套架构的完整说明：从 Agent 的基本定义、HyperAgent 的八项特征，到 AgentOS 的分层架构和各模块的设计思路，并给出了对应的开源实现。

Agent 的「二元属性」

openJiuwen 对 Agent 的理解，起点是一个判断：Agent 和传统应用不同，它同时具有两种属性。

一方面，Agent 是一个软件程序。它要完成任务，就需要运行环境、数据和工具：写代码需要代码仓库、终端和测试环境；处理企业业务需要连接私域数据、复杂工作流和遗留系统；执行物理任务则需要感知和执行设备。作为软件，它还必须满足可靠性、安全性、可观测性和可追溯性等工程要求。

另一方面，Agent 又是一个智能主体。它具备编码、办公等通用能力，表现出自主性、个性、成长性和协作性，能力和行为会随着经验积累不断变化。openJiuwen 用 "数字智能生物" 来概括这种兼具应用能力与主体特征的形态。

HyperAgent：Agent 未来形态的思考

在 openJiuwen 看来，推动 Agent 发展的核心动力有两条：一是应用边界不断扩展，这对运行环境和 DFx 等工程能力提出更高要求；二是 Agent 替代人完成工作的程度不断加深，这对 Agent 自身的能力和自主程度提出更高要求。

沿着这两条主线，openJiuwen 提出 Agent 架构应从 DeepAgent 演进到 HyperAgent。按其定义，DeepAgent 侧重复杂任务的深度执行；HyperAgent 则进一步强调持续工作、自我演进、多主体协作，以及在真实环境中的可靠运行。

图 1：HyperAgent 的二元属性与八项特征

这八项特征分别是：

1. 主动性：从被动响应走向目标驱动和事件驱动的主动执行。Agent 不再只是等待指令，而是根据业务变化、设备状态、定时触发和执行反馈主动工作，它需要结合长期目标与当前环境，判断何时推进、何时调整计划、何时请人介入。
2. 永续性：从 Sessionful 走向 Sessionless。传统 Agent 以「会话」（Session）为单位工作，会话结束，上下文也随之中断。HyperAgent 希望用户只需围绕工作与 Agent 持续交互，由系统在后台组织会话、分发任务、寻找相关上下文，身份、职责、记忆与成果能够跨会话延续，工作的连续性由持久状态维持。
3. 成长性：从 SI 到 RSI，再到 CoRSI。SI（Self-Improvement，自我改进）指 Agent 从反馈中改善能力；RSI（Recursive Self-Improvement，递归自我改进）指改进后的 Agent 继续参与对自身的改进；CoRSI 则是 openJiuwen 提出的「协同递归改进」，让工作产物（Artifact）、执行框架（Harness）与模型（Model）三者相互促进。同时 openJiuwen 也指出，未来期待更多 Harness 能力逐步被 Agent 与模型吸收，Coding、办公等通用能力成为内置能力，降低用户组织 Prompt、上下文和 Skill 的负担。
4. 协作性：从单 Agent 走向异构协作。Agent 从独立执行走向多 Agent 协作，并从同构团队扩展到使用不同模型、工具和 Harness 的「异构团队」。它们需要发现彼此能力、明确分工、交换成果和处理冲突，围绕共享目标形成持续的工作关系。
5. 确定性：从个人任务的执行走向复杂环境下可靠、可验证的任务执行。当 Agent 从单机走向集群、进入关键业务，状态转换、操作边界、异常恢复和执行记录都需要有明确语义，执行时延需要相应的监测与超时策略。确定性落实在这些执行约束上，模型生成的结果则通过业务规则和验收机制验证。
6. 扩展性：从「开发者友好」走向「RSI 友好」。扩展性从 Skill、Connect、Plugin 等组件的接入，走向 Agent、Agent Team 与 Agent App 的组合，进一步走向 RSI 友好的架构。RSI 友好是指 Harness 具有清晰的模块边界、显式配置和可替换接口，便于 RSI 理解并修改 Prompt、Skill、Tool、Rails 及执行策略；配合评测与版本管理，让修改能够被验证、比较和持续迭代。
7. 开放性：从数字世界接入走向物理环境操控与 Agent 互联。Agent 通过工具、API、MCP、CUA 与设备适配操作数字系统和物理设备，并依据观察与反馈继续行动。开放性还包括 Agent 互联：通过开放的身份、能力描述、通信与任务交互接口，支持不同框架、平台和组织中的 Agent 相互发现、交换信息、委派任务与交接成果，形成可互操作的 Agent 网络。
8. 经济性：从单次调用优化走向任务总成本优化。经济性既包括 Token 消耗，也包括工具调用、多 Agent 通信、重复执行、部署运维和人工介入。优化目标是在满足效果、时延与并发要求的前提下，提高单位资源的有效产出。

openJiuwen 认为，这八项特征需要一套共同的基础设施支撑，openJiuwen AgentOS 所要解决的，就是如何将开发、运行、协作与演进连接起来，让 HyperAgent 能够持续承担真实工作。

openJiuwen AgentOS 整体架构

openJiuwen 将自身定位为 AgentOS，而不只是一个 Harness 框架。按其解释，一般的 Harness 框架主要负责模型调用、上下文管理、工具编排和执行循环；AgentOS 则覆盖 Agent 从开发、部署到运行、观测和持续演进的完整生命周期，在框架层之外，还提供分布式运行时、系统服务和 AgentOps 等系统级能力。同时，openJiuwen 以面向未来的 HyperAgent 形态为设计出发点，围绕其智能主体属性与应用属性构建架构，支撑主动执行、永续工作、持续成长和多 Agent 协作，并满足真实业务对可靠性、扩展性、开放性与经济性的要求，支持从个人桌面到企业集群的多种部署场景。

图 2：openJiuwen 官网发布的 AgentOS 逻辑分层架构图

整体架构从上到下分为六层：

此外，有两项能力贯穿各层：资产市场通过 Agent Hub、Skill Hub、MCP Hub 和 Plugin Hub 沉淀、分发和复用能力资产；AgentOps 提供运行观测、效果评测、身份权限和版本治理，将开发调试、运行诊断与持续改进连接起来。

HyperAgent 在 openJiuwen 中的样子：一个「元 Agent-App」

在 openJiuwen 的设计中，HyperAgent 被建模为一个「元 Agent-App」：它既可以作为应用直接承担工作，也可以在内部组织不同类型的 Agent，组合通用能力与专业能力，适应不同的任务和业务场景。

图 3：HyperAgent 元 Agent-App 的组成

具体来看，这个结构包含四部分：

1. HyperAgent 含前端（多客户端多 Channel）/ 后端完整的功能，同时内置 Coding、办公等通用能力，可以作为 Agent 应用直接工作。
2. HyperAgent 通过 Skill、插件、UI 等扩展机制，很方便形成面向具体场景和任务的 AgentApp。
3. HyperAgent 是一个支持协作的多 Agent 系统，既包含以会话为中心组织任务的 Sessionful Agent，也包含以稳定身份和持续职责组织工作的 Sessionless Agent，即 Persistent Agent。Sessionless Agent 内部包含多个 Worker，由 Agentg 识别任务意图，将 Task 分发给相应 Worker 执行。HyperAgent 内部的 Agent 可以通过 SwarmEngine 进行协作。
4. HyperAgent 的记忆引擎与 RSI 引擎为 Agent 提供记忆与演进支持。记忆用于积累工作事实、用户偏好与任务经验，并与角色设定、行为约定和能力配置共同支撑个性化行为。RSI 围绕 Agent 的任务轨迹与反馈，组织评估、改进和验证，将经验证的更新应用于 Agent 的技能与执行策略，使其能够在持续工作中不断演进。

从部署角度看，一个 HyperAgent 由前端和一个 Agent Serving 组成。前端提供用户交互入口，通常运行在用户端；一个 Agent Serving 与一个 HyperAgent 后端实例一一对应，承载 Gateway、Agents 及其 Workers、记忆引擎和 RSI 等后端能力。

图 4：HyperAgent 与 Agent Serving 的对应关系

Agent Serving 是单个 HyperAgent 后端实例的服务化承载单元。Gateway、Agents、Workers、记忆引擎和 RSI 等共同构成该后端实例，其所需的存储、沙箱和推理资源由系统服务提供。其中，记忆引擎负责记忆加工与检索，MemoryStore 提供记忆数据的持久化基础。

openJiuwen 通过 Distributed Executor 支撑多个 Agent Serving 的分布式调度与运行，从而支撑多个 HyperAgent 的部署。Agent Protocol 连接运行单元，系统服务和基础设施提供公共资源，AgentOps 贯通观测与治理。

面向「智能主体」：让 Agent 持续工作、协作和成长

面向智能主体，AgentOS 需要支撑 Agent 持续承担职责，在工作中保持上下文、与人和其他 Agent 协作，并通过反馈改进自身。openJiuwen 围绕主动性、永续性、成长性和协作性，从以下四个方面展开架构设计。

1. 主动性：EDA 架构与全双工交互

当 Agent 从完成一次指令走向承担持续职责，触发工作的信号会扩展到消息、定时任务和业务状态变化。执行过程中，也会不断出现补充信息、目标调整和人工干预。Agent 需要能够主动发起行动，并在工作过程中持续与人和环境交互。

图 5：事件驱动与全双工交互架构

openJiuwen 的做法是用 EDA（Event-Driven Architecture，事件驱动架构）组织输入：持续交互通路位于 Gateway 上方，承接前端的语音、画面与文字输入；消息、Cron 定时触发和经场景适配的业务事件也由 Gateway 统一接入。Agent 结合职责、目标与上下文判断何时行动，并在授权范围内推进任务。

全双工将前台交互、后台任务执行和进度输出分开推进。Agent 执行长任务或等待工具时，用户仍可补充要求、调整方向，进度与结果经 Gateway 持续返回原对话。video-duplex 已展示了前台媒体交互与 Core Agent 任务解耦的机制。

Agent 执行通路进一步组织工具的异步执行：对支持异步的工具或后台委派任务，Agent 在授权后提交调用，记录任务标识与状态；执行端在后台推进工作，通过状态查询或事件推送返回进度、完成或失败结果。TaskLoop 汇合这些结果，并在任务依赖满足后继续执行。公开的 sessions_spawn、sessions_list 等机制提供了后台子任务委派与状态管理能力，通用异步工具链路由具体工具和执行后端适配。

执行中的补充、引导与中止由 TaskLoop 的 FOLLOWUP、STEER 和 ABORT 等控制语义处理，并在相应控制边界生效。异步等待与前台交互解耦，任务推进仍遵循工具依赖、权限和业务约束；取消工具任务的能力由执行后端决定。

2. 永续性：用 Persistent Agent 承载持续工作

真实工作往往跨越多轮交互、多个任务和较长时间。用户希望与同一个 Agent 长期合作，让它记得背景、掌握进度，并主动找到相关上下文。工作连续性需要由 Agent 和平台共同维护，减少用户管理会话、搬运背景的负担。

图 6：Persistent Agent 内部机制

Persistent Agent 以稳定身份关联职责、行为约定、自有记忆、任务状态与工作区，并继承 Coding、办公等内置通用能力。收到输入后，它先识别意图，判断是新任务还是既有工作的延续，关联相关上下文，再将 Task 分发给内部多个 Worker 执行。

Worker 推进任务，产生进度与工作成果；Agent 保存任务状态、产物引用和交接摘要，供后续工作接续。平台负责 Session 分配、并发协调和上下文资源管理，让用户围绕 Agent 与目标持续交互。

这里的 Sessionless 指用户无需自行组织 Session，相关上下文由 Agent 寻找和关联；内部仍保留受管理的 Session。永续性的基础是身份、记忆与工作状态的持续保存，真实持久后端与宿主链路按部署完成集成验证。

3. 成长性：以 CoRSI 推动协同递归演进

业务环境、工具和任务目标持续变化，Agent 的执行策略也需要随之改进。记忆能积累经验，成长还需要将经验转为可验证的能力变化。随着优化深入，工作产物、执行机制与模型能力之间的相互影响，也要求一套共同的反馈与评测机制。

图 7：CoRSI 目标架构

openJiuwen 将这一路径概括为从 SI 走向 RSI，再走向 CoRSI：从自我改进，发展到改进后的 Agent 继续参与下一轮改进，再发展到 Artifact、Harness 与 Model 的协同递归演进。

其中，Artifact 优化程序、论文等工作产物；Harness 优化 Prompt、Skill、Tool、Rails 及执行策略；Model 侧通过任务反馈改善数据与模型能力。三条路径围绕共同的任务目标和评测依据协同，评估改进对整体效果的影响。

架构以执行轨迹、产物与用户反馈为输入，经评测和诊断生成候选方案，在隔离环境中验证质量与成本，再对通过验证的结果进行版本化发布。改进后的 Agent 继续参与诊断、方案生成与验证，形成递归闭环。目前，openJiuwen 已公开 Artifact 优化接口和 AutoHarness 机制，模型侧协同演进在图中以虚线表示架构方向。

4. 协作性：以蜂群架构组织异构 Agent 协作

复杂工作通常跨越调研、开发、分析与验证，需要不同专业能力共同参与。企业中已有的 Agent 也可能采用不同模型、Harness 和工具。随着工作范围扩大，Agent 需要能够理解分工、交接产物、协商推进，并与人及其他 Agent 共同完成目标。

图 8：异构蜂群协作架构

openJiuwen 以 Swarm 引擎组织协作：共享群上下文承载目标、历史与工作产物，协调者根据角色、任务依赖和验收条件进行分工，按消息指向唤醒成员。专业 Agent 或专家团分别执行任务，再汇合成果、进行验证，并把反馈带回协作空间。人也可以作为成员参与决策与验收。

异构协作通过成员适配与协作契约实现。不同模型、Harness、执行器和专业工具，可通过已支持的外部 CLI、团队 MCP 等方式接入，并按约定交接消息、任务状态和产物。接入范围由具体适配器及权限配置确定。

在这一架构中，Agent 内部的 Worker 执行所属 Agent 的子任务；蜂群则组织独立 Agent 和 Agent Team 之间的协作。两层机制结合，让 HyperAgent 既能发挥单体通用能力，也能围绕复杂目标组织专业分工。

面向「应用属性」：让 Agent 进入真实业务环境

要让 HyperAgent 进入真实业务，需要适配复杂系统、持续扩展能力，并在集群和多种算力环境中稳定运行。面向这些应用要求，openJiuwen 围绕确定性、扩展性、开放性和经济性，构建相应的运行基础与系统服务。

1. 确定性：分布式运行时支撑可靠执行

企业任务往往跨越多个系统并持续较长时间，需要应对并发请求、资源波动、等待和失败。业务既关心任务能否完成，也关心执行时延、故障恢复和过程追溯。这里的确定性，体现为执行可靠、行为可控、状态可核对，以及运行过程可观测。

图 9：分布式运行时逻辑架构

openJiuwen 采用计算与持久状态分离的思路：计算实例按需调度，工作文件、业务记录和检查点（Checkpoint，可用于恢复的运行状态快照）由存储保存。应用层工作依据任务状态、产物与历史记录接续，运行环境则依据检查点恢复，两类状态分开管理。

弹性沙箱结合任务需求、并发限制与节点能力分配执行资源，通过预热、按需创建和空闲回收调节容量。会话亲和与并发控制管理执行秩序，指标、日志和调用链帮助定位拥塞与失败，核验运行和恢复结果。关键业务动作还需结合真实业务状态核对，形成可管理的执行闭环。

2. 扩展性：可控插件机制与「RSI 友好」的扩展点

企业 Agent 既需要接入新的技能、系统和协作单元，也需要根据执行反馈改进自身 Harness。扩展机制因此需要同时面向开发者与 RSI：让能力便于接入、组合与管理，也让 Harness 便于被理解、修改和验证，将有效改进持续沉淀为可复用版本。

图 10：可控插件机制与 RSI 友好扩展点

可控插件机制支持 Skill、Connect、Plugin、Agent、Agent Team 和 Agent App 按各自契约接入与组合，通过声明、注册、版本和生命周期管理实现按需装配。Rails 与权限策略约束运行中的具体调用，执行后端提供相应的运行边界，使扩展能力保持可管理。

RSI 友好的扩展点设计，重点是方便 RSI 修改 Harness。Prompt、上下文处理、Skill、Tool、Rails 及执行策略被组织为边界清晰、配置显式、可局部替换的模块，并提供可定位的执行轨迹与评测入口。RSI 据此识别问题、选择修改位置，调整配置或组件实现，降低理解和修改 Harness 的成本。

修改在独立工作区中完成，经对比评测与回归验证形成候选版本，再以扩展包或代码 PR 进入受控的发布流程。评测结果、版本差异与运行反馈支撑后续迭代，让扩展点同时服务于人工开发和 RSI 持续演进。

3. 开放性：增强对数字世界和物理世界的操控能力

随着 Agent 承担更多实际工作，它需要能够访问业务系统、操作软件界面，也需要感知设备状态并驱动设备执行动作。开放性的核心，是持续拓展 Agent 对数字世界和物理世界的操控范围，让任务能够在真实环境中完成。

图 11：开放性架构

在数字世界，Agent 通过 Connect、工具、API 与 MCP 等方式连接数据源和业务系统，通过 CUA 操作浏览器与桌面应用界面；账号、支付等业务服务也可按场景接入。结构化调用与界面操作共同扩展 Agent 的软件操控能力。

在物理世界，设备接入与执行通道负责关联具体设备，将 Agent 的动作请求转换为设备命令，并把设备状态和执行结果反馈给 Agent。架构通过适配器持续扩展终端、外设等设备类型，具体执行能力由设备接口与后端决定。

AopenJiuwen 还提出了 ADF（Agent Device Foundation）这一面向设备的基础设施方向，为能力描述、设备接入、动作调用与状态反馈提供统一抽象。CUA、工具与系统连接、设备操控等能力共同形成「观察 — 行动 — 反馈」的环境交互闭环，支撑 Agent 根据实际执行结果继续推进任务。

4. 经济性：以算力亲和与模型路由优化任务成本

Agent 的成本分布在推理、工具执行、环境准备和数据访问等多个环节。多轮任务中的 KV 复用、沙箱准备与通用计算调度会相互影响，不同任务又需要不同的模型能力。因此，经济性需要同时优化资源协同与模型选择，围绕完整任务平衡效果、时延与总成本。

一是算力亲和：智算、存储与通算协同，即以 Agent 任务所处的阶段为线索，协同组织智算、存储与通算资源，减少重复计算、环境准备和数据搬运带来的开销。

图 12：算力亲和的三类协同

• 智算协同：以推理的主动 KV 管理为核心，结合 Agent 的推理、工具执行和等待阶段，规划逻辑 KV 容量与上下文增长，通过请求准入、暂停和恢复提高 KV 复用机会，减少重复预填充。模型执行与物理 KV 块的分配、回收由推理引擎负责。
• 存储协同：以沙箱调度为重点，将环境快照的存储位置、可恢复节点与缓存复用条件纳入环境分配。依据快照类型和后端能力组织沙箱恢复及节点选择，并与工作区和持久资料访问衔接，减少环境重建与数据搬运。进一步结合跨资料的访问代价优化沙箱选址，是这一协同机制的扩展方向。
• 通算协同：聚焦任务与通用计算资源的调度，根据并发需求和 CPU、内存等资源条件安排执行，结合节点约束、会话亲和、实例预热与空闲回收，提升 Agent 后端、工具执行和沙箱环境的资源利用率。

二是模型路由：匹配任务与模型能力，即为每一步调用选择合适的模型。策略可围绕任务能力需求、时延、预算与模型可用性设计，在本地、私有和云端模型中匹配调用目标，并按业务场景装配和演进。

图 13：模型路由的选择与反馈闭环

Model Router 通过 route 接收请求，读取 StateProvider 提供的状态快照，再由 AlgorithmProvider 生成模型选择结果。算法与状态通过各自的接口接入，便于按任务和部署条件替换策略。

实际模型调用由宿主执行。宿主获得响应后，通过 report 反馈调用结果、时延及可获取的成本统计，为后续选择提供依据；模型调用、重试和任务推进仍由宿主组织。策略效果以完整任务的成功率、资源消耗与端到端时延评估。

openJiuwen 的典型部署方式

基于同一套 HyperAgent 建模和 AgentOS 分层，openJiuwen 可以按场景组织个人桌面和企业分布式部署。两种形态采用不同的资源组织方式，共同遵循「一个 HyperAgent 由前端和一个 Agent Serving 组成」的建模关系。

（1）个人桌面：面向日常编码与办公

个人桌面部署面向编码、办公和个人知识处理等场景。前端与 Agent Serving 可以运行在同一台设备上，Serving 承载 Gateway、Agents 及其内部 Worker、记忆与 RSI 等后端能力，用户通过客户端与 HyperAgent 持续交互。

图 14：个人桌面部署参考

（2）企业分布式：面向多应用与规模化运行

企业部署面向多人协作、多业务应用和持续运行的任务。用户通过前端或 Channel 接入，HyperAgent 后端运行在企业集群中。每个 Agent Serving 承载一个 HyperAgent 后端实例，Distributed Executor 为多个 Serving 提供分布式运行支撑。

图 15：企业分布式部署参考

集群将计算与持久化状态分开组织：运行节点承担计算，存储服务保存工作资料、任务记录和记忆数据，并按应用命名空间与访问边界管理。沙箱和执行环境按任务需求分配资源，通过容量管理、并发控制与回收机制支撑规模化执行。

模型推理服务和相应硬件资源池独立部署，通过模型接口接入，并按实际宿主和兼容推理后端配置模型路由与算力亲和。AgentOps 集中提供运行观测与诊断，帮助分析任务效果、资源消耗和执行时延。业务能力、Agent 运行容量与推理资源可以按各自负载扩展。

部署位置与资源选择可以灵活组合

Agent 后端、模型服务、工具与设备执行端可以分别选择部署位置。桌面上的 HyperAgent 可以调用远程模型，集群中的 HyperAgent 也可以通过已适配的连接访问外部系统或设备。CUA 的原生适配和界面操作需要在目标桌面环境中配置，并满足相应连接、会话与权限条件。

结语

从 9 月发布架构，到近期蜂群协作的落地进展，再到这次的完整解读，可以看出 openJiuwen 的出发点是把 Agent 当作一个需要长期运行、持续成长的「数字主体」，而不只是一次性调用的程序。围绕这一判断，它把主动执行、跨会话延续、自我改进、异构协作这些 "智能主体" 需求，与可靠执行、可控扩展、环境操控、成本优化这些 "工程应用" 需求，放进同一套 AgentOS 分层架构中统一考虑。

解读中也明确区分了已开源实现与目标架构：例如 CoRSI 的模型侧协同仍属演进方向，部分组件的端到端集成也有待按部署场景验证。随着 Agent 逐步进入企业关键业务，openJiuwen AgentOS 的开源探索，以及它在真实场景中的落地情况，值得持续关注。

相关链接

• openJiuwen 官网（含 HyperAgent 架构图）：https://openjiuwen.com
• WorkSwarm 官网与下载：https://openjiuwen.com/workswarm
• GitHub 开源代码仓：https://github.com/openJiuwen-ai
• AtomGit 开源代码仓：https://atomgit.com/openJiuwen
  

文章来自于"机器之心"，作者 "机器之心"。