HyperAgent: openJiuwen’s Reflections and Practices on Future Agent Architectures

Agents are moving from “answering a question” to “taking on a job.” Recently, the open-source AI Agent community openJiuwen provided an in-depth analysis of the HyperAgent architecture, systematically laying out its vision for the next generation of Agents—the eight characteristics HyperAgent should have, and the layered open-source AgentOS design that supports this form.

In September this year, the openJiuwen community had already publicly released the HyperAgent architecture, with its architecture diagram simultaneously published on the official website (openjiuwen.com). Last week, openJiuwen also disclosed the progress of implementing its swarm collaboration in WorkSwarm: Persistent Agents can connect to multiple IM platforms for cross-channel collaboration, while people, digital employees, and expert teams can divide responsibilities and collaborate in native group chats.

Recently, many industry vendors and research institutions have also begun exploring similar architectural directions. This analysis, by contrast, providesa complete explanation of the entire architecture: from the basic definition of an Agent and the eight characteristics of HyperAgent to AgentOS’s layered architecture and the design concepts behind each module, along with the corresponding open-source implementations.

The “Dual Attributes” of an Agent

openJiuwen’s understanding of Agents begins with one judgment:Unlike traditional applications, an Agent possesses two attributes simultaneously.

On the one hand, an Agent is a software program. To perform tasks, it needs a runtime environment, data, and tools: writing code requires a code repository, a terminal, and a testing environment; handling enterprise business requires connections to private-domain data, complex workflows, and legacy systems; and performing physical tasks requires sensing and execution devices. As software, it must also satisfy engineering requirements such as reliability, security, observability, and traceability.

On the other hand, an Agent is also an intelligent entity. It possesses general-purpose capabilities such as coding and office work, demonstrating autonomy, personality, growth, and collaboration, while its capabilities and behavior continuously evolve as it accumulates experience. openJiuwen uses the term “digital intelligent being” to describe this form that combines application capabilities with entity-like characteristics.

HyperAgent: Reflections on the Future Form of Agents

From openJiuwen’s perspective, there are two core drivers propelling the development of Agents. First, the boundaries of application continue to expand, creating higher demands on runtime environments and engineering capabilities such as DFx. Second, Agents are increasingly taking over work previously performed by humans, creating higher demands on the Agents’ own capabilities and degree of autonomy.

Along these two threads,openJiuwen argues that the Agent architecture should evolve from DeepAgent to HyperAgent. By its definition, DeepAgent focuses on the deep execution of complex tasks, whereas HyperAgent places further emphasis on continuous work, self-evolution, multi-agent collaboration, and reliable operation in real-world environments.

Figure 1: The Dual Attributes and Eight Characteristics of HyperAgent

The eight characteristics are as follows:

Proactiveness: Moving from passive response to proactive execution driven by goals and events

. An Agent no longer merely waits for instructions; it proactively works in response to business changes, device status, scheduled triggers, and execution feedback. It needs to combine long-term goals with the current environment to determine when to make progress, when to adjust the plan, and when to involve a human.

1. Persistence: Moving from Sessionful to Sessionless. Traditional Agents work in units of “sessions”; when a session ends, its context is interrupted as well. HyperAgent aims to let users interact continuously with Agents around their work, while the system organizes sessions in the background, distributes tasks, and finds relevant context. Identity, responsibilities, memory, and results can persist across sessions, with work continuity maintained through persistent state.

5. Growth: From SI to RSI, and Then CoRSI. SI (Self-Improvement, or self-improvement) refers to an Agent improving its capabilities through feedback; RSI (Recursive Self-Improvement, or recursive self-improvement) refers to an improved Agent continuing to participate in improving itself; CoRSI is openJiuwen’s proposed “Collaborative Recursive Improvement,” which enables work artifacts (Artifact), execution frameworks (Harness), and models (Model) to reinforce one another. openJiuwen also points out that it expects more Harness capabilities to be gradually absorbed by Agents and models in the future, with general capabilities such as coding and office work becoming built in, reducing the burden on users to organize prompts, context, and skills.

6. Collaboration: From a Single Agent to Heterogeneous Collaboration. Agents are moving from independent execution toward multi-Agent collaboration, expanding from homogeneous teams to “heterogeneous teams” that use different models, tools, and Harnesses. They need to discover one another’s capabilities, establish clear divisions of labor, exchange results, and resolve conflicts, forming ongoing working relationships around shared goals.

7. Determinism: From Executing Individual Tasks to Reliable, Verifiable Task Execution in Complex Environments. As Agents move from a single machine to clusters and enter mission-critical operations, state transitions, operational boundaries, exception recovery, and execution records all require clearly defined semantics, while execution latency requires corresponding monitoring and timeout policies. Determinism is implemented through these execution constraints, while model-generated results are validated through business rules and acceptance mechanisms.

8. Scalability: From “Developer-Friendly” to “RSI-Friendly”. Scalability is evolving from integrating components such as Skill, Connect, and Plugin, toward composing Agents, Agent Teams, and Agent Apps, and further toward an RSI-friendly architecture. RSI-friendly means that the Harness has clear module boundaries, explicit configuration, and replaceable interfaces, making it easier for RSI to understand and modify prompts, skills, tools, Rails, and execution strategies. Together with evaluation and version management, this enables changes to be verified, compared, and continuously iterated.

9. Openness: From Connecting to the Digital World to Controlling Physical Environments and Interconnecting Agents. Through tools, APIs, MCP, CUA, and device adapters, Agents operate digital systems and physical devices, continuing to act based on observations and feedback. Openness also includes Agent interconnection: through open interfaces for identity, capability descriptions, communication, and task interaction, Agents across different frameworks, platforms, and organizations can discover one another, exchange information, delegate tasks, and hand off results, forming an interoperable Agent network.

10. Cost Efficiency: From Optimizing Individual Calls to Optimizing Total Task Cost. Cost efficiency encompasses not only token consumption but also tool calls, multi-Agent communication, repeated execution, deployment and operations, and human intervention. The optimization objective is to improve effective output per unit of resources while satisfying requirements for effectiveness, latency, and concurrency.

openJiuwen believes that these eight characteristics require a common infrastructure to support them. What openJiuwen AgentOS aims to solve is how to connect development, runtime, collaboration, and evolution so that HyperAgent can continuously take on real-world work.

Overall Architecture of openJiuwen AgentOS

openJiuwen positions itself as an AgentOS, rather than merely a Harness framework. According to openJiuwen, a conventional Harness framework is primarily responsible for model invocation, context management, tool orchestration, and the execution loop; AgentOS covers the entire Agent lifecycle, from development and deployment to operation, observability, and continuous evolution. Beyond the framework layer, it also provides system-level capabilities such as a distributed runtime, system services, and AgentOps.Meanwhile, openJiuwen takes the future-oriented HyperAgent form as its design starting point and builds its architecture around its intelligent-agent and application attributes, supporting proactive execution, continuous operation, ongoing growth, and multi-Agent collaboration. It meets the requirements of real-world businesses for reliability, scalability, openness, and cost efficiency, while supporting a variety of deployment scenarios ranging from individual desktops to enterprise clusters.

Figure 2: AgentOS logical layered architecture diagram published on the openJiuwen official website

The overall architecture is divided into six layers from top to bottom:

In addition, two capabilities span all layers:Asset MarketUses Agent Hub, Skill Hub, MCP Hub, and Plugin Hub to accumulate, distribute, and reuse capability assets;AgentOps provides runtime observability, effectiveness evaluation, identity and permission management, and version governance, connecting development and debugging with runtime diagnostics and continuous improvement.

What HyperAgent Looks Like in openJiuwen: A “Meta Agent-App”

In openJiuwen’s design, HyperAgent is modeled as a “Meta Agent-App”: it can either take on work directly as an application or organize different types of Agents internally, combining general-purpose and specialized capabilities to accommodate different tasks and business scenarios.

Figure 3: Composition of the HyperAgent Meta Agent-App

Specifically, this structure consists of four parts:

1. HyperAgent provides complete frontend (multiple clients and multiple Channels) and backend functionality, while incorporating built-in general-purpose capabilities such as Coding and office productivity, allowing it to work directly as an Agent application.

2. Through extension mechanisms such as Skill, plugins, and UI, HyperAgent can easily be formed into an AgentApp tailored to specific scenarios and tasks.

3. HyperAgent is a collaborative multi-Agent system that includes both Sessionful Agents, which organize tasks around sessions, and Sessionless Agents, which organize work around stable identities and ongoing responsibilities—that is, Persistent Agents. A Sessionless Agent contains multiple Workers internally, with Agentg identifying task intent and dispatching the Task to the appropriate Worker for execution. Agents within HyperAgent can collaborate through SwarmEngine.

4. HyperAgent’s memory engine and RSI engine provide Agents with memory and evolutionary support. Memory is used to accumulate work facts, user preferences, and task experience, and, together with role settings, behavioral conventions, and capability configurations, supports personalized behavior. RSI organizes evaluation, improvement, and validation around the Agent’s task trajectory and feedback, applying validated updates to the Agent’s skills and execution strategies so that it can continue to evolve through ongoing work.

From a deployment perspective, a HyperAgent consists of a frontend and an Agent Serving. The frontend provides the user interaction entry point and typically runs on the user’s device; an Agent Serving corresponds one-to-one with a HyperAgent backend instance and hosts backend capabilities such as the Gateway, Agents and their Workers, the memory engine, and RSI.

Figure 4: Correspondence between HyperAgent and Agent Serving

Agent Serving is the service-based hosting unit for a single HyperAgent backend instance.

Gateway, Agents, Workers, the memory engine, RSI, and other components together form the backend instance, while the storage, sandbox, and inference resources it requires are provided by system services. The memory engine handles memory processing and retrieval, and MemoryStore provides the persistence foundation for memory data.

openJiuwen uses the Distributed Executor to support the distributed scheduling and operation of multiple Agent Servings, thereby enabling the deployment of multiple HyperAgents. Agent Protocol connects execution units, system services and infrastructure provide shared resources, and AgentOps provides end-to-end observability and governance.

For “Intelligent Agents”: Enabling Agents to Work Continuously, Collaborate, and Grow

For intelligent agents, AgentOS needs to support agents in continuously taking on responsibilities, maintaining context while working, collaborating with people and other agents, and improving themselves through feedback. With a focus onproactivity, continuity, growth,andcollaboration,openJiuwen organizes its architecture design around the following four aspects.

1. Proactivity: EDA Architecture and Full-Duplex Interaction

When an Agent moves from completing a single instruction to taking on ongoing responsibilities, the signals that trigger its work expand to include messages, scheduled tasks, and changes in business state. During execution, supplemental information, goal adjustments, and human interventions also arise continuously. Agents need to be able to initiate actions proactively and continue interacting with people and the environment throughout the course of their work.

Figure 5: Event-Driven and Full-Duplex Interaction Architecture

openJiuwen uses EDA (Event-Driven Architecture) to organize inputs. The continuous interaction path sits above the Gateway and handles voice, visual, and text inputs from the frontend; messages, Cron triggers, and scenario-adapted business events are also uniformly ingested by the Gateway. The Agent determines when to act based on its responsibilities, goals, and context, and advances tasks within its authorized scope.

Full duplex advances foreground interaction, background task execution, and progress output independently. While an Agent is executing a long-running task or waiting for a tool, users can still add requirements or adjust direction, and progress and results are continuously returned to the original conversation through the Gateway. video-duplex has demonstrated a mechanism for decoupling foreground media interaction from Core Agent tasks.

The Agent execution path further organizes the asynchronous execution of tools. For tools that support asynchronous execution or background delegated tasks, the Agent submits the invocation after authorization and records the task identifier and status; the execution side advances the work in the background and returns progress, completion, or failure results through status queries or event pushes. TaskLoop converges these results and continues execution once the task dependencies have been met. Public mechanisms such as sessions_spawn and sessions_list provide background subtask delegation and state management, while the generic asynchronous toolchain is adapted by individual tools and execution backends.

Supplemental instructions, steering, and aborts during execution are handled by TaskLoop’s control semantics, such as FOLLOWUP, STEER, and ABORT, and take effect within their corresponding control boundaries. Asynchronous waiting is decoupled from foreground interaction, while task progression continues to follow tool dependencies, permissions, and business constraints; the ability to cancel tool tasks is determined by the execution backend.

2. Continuity: Using Persistent Agents to Support Ongoing Work

Real-world work often spans multiple interaction rounds, multiple tasks, and substantial periods of time. Users want to collaborate with the same Agent over the long term, having it remember the background, track progress, and proactively locate relevant context. Work continuity must be maintained jointly by the Agent and the platform, reducing the burden on users to manage sessions and transfer background context.

Figure 6: Internal Mechanisms of a Persistent Agent

A Persistent Agent uses a stable identity to associate itself with responsibilities, behavioral conventions, its own memory, task state, and a workspace, and it inherits built-in general-purpose capabilities such as Coding and office productivity.After receiving input, it first identifies the intent, determines whether it is a new task or a continuation of existing work, associates the relevant context, and then dispatches the Task to multiple internal Workers for execution.

Workers advance the task, producing progress updates and work products; the Agent saves task status, artifact references, and handoff summaries so that subsequent work can continue from where it left off. The platform is responsible for Session allocation, concurrency coordination, and context resource management, enabling users to interact continuously with the Agent in pursuit of their objectives.

Here, Sessionless means that users do not need to organize Sessions themselves; the Agent finds and associates the relevant context. Managed Sessions are still retained internally. The foundation of continuity is the persistent storage of identity, memory, and work status. Real persistent backends and host-side links are integration-verified in accordance with the deployment.

3. Growth: Driving Collaborative Recursive Evolution with CoRSI

As business environments, tools, and task objectives continually change, the Agent’s execution strategies must also improve accordingly. Memory can accumulate experience, but growth also requires converting experience into verifiable changes in capability. As optimization progresses, the mutual influence among work products, execution mechanisms, and model capabilities also necessitates a shared feedback and evaluation mechanism.

Figure 7: CoRSI Target Architecture

openJiuwen summarizes this path as moving from SI to RSI and then to CoRSI: from self-improvement, to improved Agents continuing to participate in the next round of improvement, and then to the collaborative recursive evolution of Artifact, Harness, and Model.

Here, Artifact optimizes work products such as programs and papers; Harness optimizes Prompt, Skill, Tool, Rails, and execution strategies; and the Model side improves data and model capabilities through task feedback. These three paths collaborate around shared task objectives and evaluation criteria to assess the impact of improvements on overall performance.

The architecture takes execution traces, artifacts, and user feedback as inputs, generates candidate solutions through evaluation and diagnosis, validates their quality and cost in an isolated environment, and then performs versioned releases of results that pass validation. The improved Agent continues to participate in diagnosis, solution generation, and validation, forming a recursive closed loop. At present, openJiuwen has made its Artifact optimization interface and AutoHarness mechanism public, while collaborative evolution on the Model side is indicated by dashed lines in the diagram as the architectural direction.

TAG207@@4. Collaboration: Organizing Heterogeneous Agent Collaboration with a Swarm Architecture

TAG210@@Complex work typically spans research, development, analysis, and validation, and requires the participation of different specialized capabilities. Agents already deployed within enterprises may also use different models, Harnesses, and tools. As the scope of work expands, Agents need to understand task division, hand off artifacts, coordinate progress, and work with humans and other Agents to achieve shared objectives.TAG213@@Figure 8: Heterogeneous Swarm Collaboration ArchitectureTAG215@@openJiuwen uses the Swarm engine to organize collaboration: a shared swarm context carries objectives, history, and work products; the coordinator assigns work based on roles, task dependencies, and acceptance criteria, and wakes members according to message routing. Specialized Agents or expert teams execute their respective tasks, then consolidate the results, conduct validation, and bring feedback back into the collaboration space. Humans can also participate as members in decision-making and acceptance.TAG217@@Heterogeneous collaboration is realized through member adaptation and collaboration contracts. Different models, Harnesses, executors, and specialized tools can be integrated through supported external CLIs, team MCPs, and other mechanisms, with messages, task status, and artifacts handed off according to agreed conventions. The scope of integration is determined by the specific adapters and permission configurations.TAG219@@Within this architecture, Workers inside an Agent execute subtasks belonging to that Agent, while the swarm organizes collaboration among independent Agents and Agent Teams.Together, these two mechanisms enable HyperAgent to leverage single-agent general-purpose capabilities while also organizing specialized division of labor around complex objectives.

Focused on “Application Attributes”: Enabling Agents to Enter Real-World Business Environments

To enable HyperAgent to enter real-world business operations, it needs to adapt to complex systems, continuously expand its capabilities, and run reliably in clusters and diverse computing environments. To meet these application requirements, openJiuwen builds the corresponding runtime infrastructure and system services around determinism, extensibility, openness, and cost efficiency.

1. Determinism: A Distributed Runtime for Reliable Execution

Enterprise tasks often span multiple systems and run for extended periods, requiring the ability to handle concurrent requests, resource fluctuations, waits, and failures. Businesses care not only about whether a task can be completed, but also about execution latency, fault recovery, and process traceability. Here, determinism is reflected in reliable execution, controllable behavior, verifiable state, and observable runtime processes.

Figure 9: Logical Architecture of the Distributed Runtime

openJiuwen adopts an approach that separates computation from persistent state: compute instances are scheduled on demand, while working files, business records, and checkpoints (Checkpoint, runtime state snapshots that can be used for recovery) are stored. Application-layer work continues based on task state, artifacts, and history, while execution environments are restored based on checkpoints; the two types of state are managed separately.

The elastic sandbox allocates execution resources based on task requirements, concurrency limits, and node capabilities, and adjusts capacity through prewarming, on-demand creation, and reclamation of idle resources. Session affinity and concurrency control govern execution order, while metrics, logs, and call chains help pinpoint congestion and failures and verify execution and recovery results. Critical business actions must also be checked against actual business state, forming a manageable closed loop of execution.

245@@2. Extensibility: A Controllable Plugin Mechanism and “RSI-Friendly” Extension Points

248@@Enterprise agents need to integrate new skills, systems, and collaboration units, and also improve their own Harness based on execution feedback. The extension mechanism therefore needs to serve both developers and RSI: making capabilities easy to integrate, compose, and manage, while making the Harness easy to understand, modify, and validate, and continuously distilling effective improvements into reusable versions.

Figure 10: Controllable Plugin Mechanism and RSI-Friendly Extension Points

The controllable plugin mechanism supports the integration and composition of Skill, Connect, Plugin, Agent, Agent Team, and Agent App according to their respective contracts, and enables on-demand assembly through declaration, registration, versioning, and lifecycle management. Rails and permission policies constrain specific calls at runtime, while execution backends provide corresponding execution boundaries, keeping extension capabilities manageable.

The design of RSI-friendly extension points focuses on making it easy for RSI to modify the Harness. Prompt, context processing, Skill, Tool, Rails, and execution policies are organized into modules with clear boundaries, explicit configuration, and local replaceability, and provide pinpointable execution traces and evaluation entry points. On this basis, RSI can identify problems, choose where to make changes, and adjust configurations or component implementations, reducing the cost of understanding and modifying the Harness.

Changes are made in an isolated workspace and turned into candidate versions through comparative evaluation and regression validation, before entering a controlled release process as extension packages or code PRs. Evaluation results, version differences, and runtime feedback support subsequent iterations, allowing extension points to serve both human development and the continuous evolution of RSI.

260@@3. Openness: Enhancing the Ability to Control the Digital and Physical Worlds

263@@As Agents take on more real-world work, they need to access business systems, operate software interfaces, perceive device status, and drive devices to perform actions. The core of openness is to continuously expand the range of control Agents have over the digital and physical worlds, enabling tasks to be completed in real-world environments.

Figure 11: Open Architecture

In the digital world, Agents connect to data sources and business systems through Connect, tools, APIs, MCP, and other methods, and operate browsers and desktop application interfaces through CUA. Business services such as account and payment services can also be integrated as needed. Structured calls and interface operations jointly expand Agents’ software control capabilities.

In the physical world, device access and execution channels link Agents to specific devices, convert Agents’ action requests into device commands, and feed device status and execution results back to the Agents. Through adapters, the architecture continuously expands to support device types such as endpoints and peripherals, while specific execution capabilities are determined by device interfaces and backends.

AopenJiuwen also proposed ADF (Agent Device Foundation), a device-focused infrastructure initiative that provides unified abstractions for capability descriptions, device access, action invocation, and status feedback. CUA, tool and system connectivity, device control, and other capabilities together form an “observe–act–feedback” closed loop for environment interaction, enabling Agents to continue tasks based on actual execution results.

4. Cost Efficiency: Optimizing Task Costs through Compute Affinity and Model Routing

An Agent’s costs are distributed across inference, tool execution, environment preparation, data access, and other stages. In multi-step tasks, KV reuse, sandbox preparation, and general-purpose computing scheduling interact with one another, while different tasks require different model capabilities. Cost efficiency therefore requires optimizing both resource coordination and model selection, balancing effectiveness, latency, and total cost across the entire task.

First, compute affinity: coordinating intelligent computing, storage, and general-purpose computing

, that is, using the stage of an Agent task as a guide to coordinate and organize intelligent computing, storage, and general-purpose computing resources, reducing overhead caused by repeated computation, environment preparation, and data movement.

Figure 12: Three Types of Compute-Affinity Coordination

• Intelligent Computing Coordination: centered on proactive KV management for inference, it combines the Agent’s inference, tool execution, and waiting stages to plan logical KV capacity and context growth. Request admission, suspension, and resumption increase opportunities for KV reuse and reduce repeated prefill. The inference engine is responsible for model execution and the allocation and reclamation of physical KV blocks.

• Storage Coordination: focused on sandbox scheduling, it incorporates the storage locations of environment snapshots, recoverable nodes, and cache reuse conditions into environment allocation. Sandbox restoration and node selection are organized according to snapshot type and backend capabilities, while connecting them with workspace and persistent data access to reduce environment rebuilding and data movement. Further optimizing sandbox placement in conjunction with cross-data access costs is an extension of this coordination mechanism.

• General-Purpose Computing Coordination: focused on scheduling tasks and general-purpose computing resources, it arranges execution according to concurrency requirements and resource conditions such as CPU and memory capacity. By incorporating node constraints, session affinity, instance prewarming, and idle resource reclamation, it improves resource utilization across Agent backends, tool execution, and sandbox environments.

Second, model routing: matching tasks with model capabilities, that is, selecting the appropriate model for each invocation step. Strategies can be designed around task capability requirements, latency, budget, and model availability, matching invocation targets among local, private, and cloud models while being assembled and evolved for different business scenarios.

Figure 13: Model Selection and Feedback Loop

Model Router receives requests through route, reads state snapshots provided by StateProvider, and then has AlgorithmProvider generate the model selection results. Algorithms and state are integrated through their respective interfaces, making it easier to replace strategies according to task and deployment conditions.

Actual model invocations are performed by the host.After the host receives a response, it uses report to provide feedback on the invocation result, latency, and available cost statistics, providing a basis for subsequent selection; model invocation, retries, and task progression remain orchestrated by the host. Policy performance is evaluated based on full-task success rate, resource consumption, and end-to-end latency.

Typical Deployment Options for openJiuwen

Based on the same HyperAgent model and AgentOS layered architecture, openJiuwen can organize personal desktop and enterprise distributed deployments according to different scenarios. The two forms adopt different approaches to resource organization while sharing the modeling relationship that “a HyperAgent consists of a frontend and one Agent Serving.”

(1) Personal Desktop: For Day-to-Day Coding and Office Work

Personal desktop deployments are intended for scenarios such as coding, office work, and personal knowledge processing. The frontend and Agent Serving can run on the same device, with the Serving hosting backend capabilities such as the Gateway, Agents and their internal Workers, memory, and RSI. Users interact continuously with the HyperAgent through a client.

Figure 14: Reference Architecture for Personal Desktop Deployment

(2) Enterprise Distributed Deployment: For Multiple Applications and Large-Scale Operation

Enterprise deployments are intended for multi-user collaboration, multiple business applications, and continuously running tasks. Users connect through a frontend or Channel, while the HyperAgent backend runs in an enterprise cluster. Each Agent Serving hosts one HyperAgent backend instance, and the Distributed Executor provides distributed runtime support for multiple Servings.

Figure 15: Reference Architecture for Enterprise Distributed Deployment

The cluster separates computation from persistent state: compute nodes handle computation, while storage services retain working materials, task records, and memory data, managed according to application namespaces and access boundaries. Sandboxes and execution environments allocate resources according to task requirements, with capacity management, concurrency control, and resource reclamation mechanisms supporting large-scale execution.

Model inference services and their corresponding hardware resource pools are deployed independently and accessed through model interfaces. Model routing and compute affinity are configured according to the actual hosts and compatible inference backends. AgentOps provides centralized runtime observability and diagnostics, helping analyze task outcomes, resource consumption, and execution latency. Business capabilities, Agent runtime capacity, and inference resources can scale according to their respective workloads.

Flexible Combinations of Deployment Locations and Resources

Deployment locations for Agent backends, model services, tools, and device-side execution endpoints can be selected independently. A HyperAgent on a desktop can invoke remote models, while a HyperAgent in a cluster can access external systems or devices through adapted connections. Native CUA adaptation and interface operations must be configured in the target desktop environment and meet the relevant connectivity, session, and permission requirements.

Conclusion

From the September architecture release, through recent progress on implementing swarm collaboration, to this comprehensive analysis, it is clear that openJiuwen is conceived as treating an Agent as a “digital entity” that must operate over the long term and continue to evolve, rather than merely as a program invoked once. Building on this premise, it brings together the requirements of “intelligent entities,” such as proactive execution, cross-session continuity, self-improvement, and heterogeneous collaboration, and those of “engineering applications,” such as reliable execution, controllable scaling, environment control, and cost optimization, within a unified AgentOS layered architecture.

The analysis also clearly distinguishes between the open-source implementations and the target architecture. For example, model-side collaboration in CoRSI remains an area of ongoing evolution, and the end-to-end integration of some components still needs to be validated for individual deployment scenarios. As Agents gradually enter critical enterprise operations, the open-source exploration of openJiuwen AgentOS and its implementation in real-world scenarios warrant continued attention.

Relevant links

• openJiuwen official website (including HyperAgent architecture diagram): https://openjiuwen.com

• WorkSwarm official website and download: https://openjiuwen.com/workswarm

• GitHub open-source code repository: https://github.com/openJiuwen-ai

• AtomGit open-source code repository: https://atomgit.com/openJiuwen