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