HyperAgent Architecture: 8 Traits for Agents That Do Jobs, Not Just Answer Questions
openJiuwen's HyperAgent architecture defines eight key traits—proactivity, persistence, growth, collaboration, determinism, extensibility, openness, and economy—supported by a layered AgentOS with event-driven runtime, persistent agents, CoRSI recursive improvement, and swarm-based heterogeneous collaboration for real-world deployment.
Agent's Dual Nature: Software Program and Intelligent Entity
openJiuwen posits that an Agent differs from traditional applications by possessing two simultaneous attributes. As a software program , it requires runtime environments, data, tools (code repositories, terminals, test environments, private data, workflows, legacy systems, perception/execution devices) and must meet engineering requirements: reliability, security, observability, traceability. As an intelligent entity , it exhibits autonomy, personality, growth, and collaboration; its capabilities and behaviors evolve with accumulated experience. openJiuwen terms this fusion a "digital intelligent organism."
From DeepAgent to HyperAgent: Eight Defining Characteristics
Driven by expanding application boundaries (demanding stronger engineering) and deeper work substitution (demanding higher autonomy), openJiuwen proposes evolving from DeepAgent (focused on complex task execution) to HyperAgent (emphasizing continuous work, self-evolution, multi-entity collaboration, reliable operation in real environments). The eight characteristics are:
Proactivity : Shift from passive response to goal-driven and event-driven active execution. Agents combine long-term goals with current context to decide when to advance, adjust plans, or request human intervention.
Persistence : Move from sessionful to sessionless. Users interact continuously around work; the system organizes sessions, dispatches tasks, and retrieves relevant context in the background. Identity, responsibilities, memory, and outcomes persist across sessions.
Growth : Progress from SI (Self-Improvement) to RSI (Recursive Self-Improvement) to CoRSI (Collaborative Recursive Self-Improvement). CoRSI lets work artifacts, execution harnesses, and models mutually enhance each other. Future harness capabilities (coding, office skills) should become built-in, reducing user burden of organizing prompts, context, and skills.
Collaboration : From single agent to heterogeneous collaboration. Agents discover each other's capabilities, divide labor, exchange artifacts, handle conflicts, and form ongoing work relationships around shared goals.
Determinism : From personal task execution to reliable, verifiable execution in complex environments. State transitions, operation boundaries, exception recovery, and execution records need explicit semantics; latency requires monitoring and timeout strategies. Model outputs are validated via business rules and acceptance mechanisms.
Extensibility : From developer-friendly to RSI-friendly. Extensions evolve from Skill/Connect/Plugin components to Agent/Agent Team/Agent App composition. RSI-friendly means harnesses have clear module boundaries, explicit configuration, replaceable interfaces, enabling RSI to understand and modify prompts, skills, tools, rails, and execution strategies; coupled with evaluation and versioning for verified, comparable, continuous iteration.
Openness : From digital-world access to physical-environment control and agent interconnection. Agents operate digital systems and physical devices via tools, APIs, MCP, CUA, and device adapters, acting on observations and feedback. Agent interconnection uses open identity, capability description, communication, and task interaction interfaces for cross-framework, cross-platform, cross-organization discovery, information exchange, task delegation, and artifact handoff.
Economy : From single-call optimization to total task cost optimization. Costs include tokens, tool calls, multi-agent communication, re-execution, deployment/operations, and human intervention. Goal: maximize effective output per resource unit while meeting quality, latency, and concurrency requirements.
These eight traits require common infrastructure; openJiuwen AgentOS connects development, runtime, collaboration, and evolution so HyperAgents can continuously undertake real work.
openJiuwen AgentOS Overall Architecture
Positioned as an AgentOS rather than merely a harness framework, it covers the full lifecycle: development, deployment, runtime, observation, continuous evolution. Beyond harness duties (model invocation, context management, tool orchestration, execution loops), it provides distributed runtime, system services, and AgentOps. Designed around HyperAgent's dual attributes, it supports proactive execution, persistent work, continuous growth, multi-agent collaboration, and meets real-business demands for reliability, extensibility, openness, economy across desktop to enterprise clusters.
The logical layered architecture (top to bottom) comprises six layers, with two cross-cutting capabilities:
Asset Market : Agent Hub, Skill Hub, MCP Hub, Plugin Hub for asset precipitation, distribution, reuse.
AgentOps : Runtime observation, effectiveness evaluation, identity/permission, version governance; connects development debugging, runtime diagnosis, continuous improvement.
HyperAgent as a Meta Agent-App
In openJiuwen's design, HyperAgent is modeled as a "meta Agent-App": it can directly undertake work as an application, and internally organize different agent types, combining general and specialized capabilities for varied tasks and business scenarios. Its structure includes four parts:
Full frontend (multi-client multi-channel) / backend functionality with built-in general capabilities (coding, office) to work directly as an Agent application.
Extension mechanisms (Skill, plugin, UI) to easily form scenario-specific AgentApps.
Multi-agent collaborative system: contains Sessionful Agents (session-centered) and Sessionless Agents (Persistent Agents) with stable identity and continuous responsibilities. Persistent Agent internally includes multiple Workers; Agentg recognizes task intent and dispatches Tasks to Workers. Internal agents collaborate via SwarmEngine.
Memory Engine and RSI Engine provide memory and evolution support. Memory accumulates work facts, user preferences, task experience, and together with role settings, behavioral conventions, capability configurations supports personalized behavior. RSI organizes evaluation, improvement, verification around task trajectories and feedback, applying verified updates to skills and execution strategies for continuous evolution.
Deployment View: HyperAgent and Agent Serving
A HyperAgent consists of a frontend and one Agent Serving. Frontend provides user interaction entry (usually on user device). One Agent Serving corresponds one-to-one with a HyperAgent backend instance, hosting Gateway, Agents & Workers, Memory Engine, RSI, etc. Required storage, sandboxes, inference resources are provided by system services. Memory Engine handles memory processing/retrieval; MemoryStore provides persistence.
Distributed Executor supports distributed scheduling/running of multiple Agent Servings, enabling multiple HyperAgent deployments. Agent Protocol connects runtime units; system services and infrastructure provide shared resources; AgentOps spans observation and governance.
Facing the "Intelligent Entity": Continuous Work, Collaboration, Growth
AgentOS must support agents continuously assuming responsibilities, maintaining context, collaborating with humans and agents, and improving via feedback. Architecture addresses four dimensions:
1. Proactivity: EDA Architecture & Full-Duplex Interaction
Work triggers expand to messages, scheduled tasks, business state changes. Execution sees supplemental info, goal adjustments, human interventions. Agents must proactively act and continuously interact. openJiuwen uses EDA (Event-Driven Architecture) to organize inputs: continuous interaction channel at Gateway handles voice, video, text; messages, Cron triggers, scenario-adapted business events also enter via Gateway. Agents combine responsibilities, goals, context to decide when to act within authorization.
Full-duplex separates foreground interaction, background task execution, progress output. While Agent executes long tasks or waits for tools, users can supplement requirements, adjust direction; progress/results stream back via Gateway to original conversation. video-duplex demonstrates foreground media interaction decoupled from Core Agent tasks.
Execution path organizes asynchronous tool execution: for async-capable tools or background delegated tasks, Agent submits calls after authorization, records task IDs and status; execution backend advances work, returns progress/completion/failure via status query or event push. TaskLoop merges results and continues when dependencies satisfied. Public sessions_spawn, sessions_list mechanisms provide background subtask delegation and state management; generic async tool chain routed by specific tools and execution backends.
Supplements, guidance, aborts during execution handled by TaskLoop's FOLLOWUP, STEER, ABORT control semantics at respective control boundaries. Async waiting decoupled from foreground interaction; task progression still respects tool dependencies, permissions, business constraints; tool task cancellation capability determined by execution backend.
2. Persistence: Persistent Agent Carries Continuous Work
Real work spans multiple interactions, tasks, long periods. Users want long-term cooperation with the same agent, remembering context, tracking progress, proactively finding relevant context. Continuity maintained jointly by agent and platform, reducing user burden of managing sessions, transporting background.
Persistent Agent binds stable identity to responsibilities, behavioral conventions, own memory, task states, workspace, inheriting built-in general capabilities (coding, office). On input, it identifies intent, judges new task vs. continuation, associates relevant context, dispatches Task to internal Workers. Workers advance tasks, produce progress and artifacts; Agent saves task state, artifact references, handoff summaries for subsequent work. Platform handles session allocation, concurrency coordination, context resource management, letting users continuously interact around agent and goal.
Sessionless means users need not organize sessions; relevant context found and associated by agent; internally managed sessions still exist. Persistence foundation: continuous preservation of identity, memory, work state. Real persistent backend and host links integrated and verified per deployment.
3. Growth: CoRSI Drives Collaborative Recursive Evolution
Business environments, tools, task goals change continuously; execution strategies must improve. Memory accumulates experience; growth requires converting experience into verifiable capability changes. As optimization deepens, mutual influence among work artifacts, execution mechanisms, model capabilities demands shared feedback and evaluation mechanism.
openJiuwen summarizes path: SI → RSI → CoRSI: from self-improvement, to improved agent participating in next improvement round, to collaborative recursive evolution of Artifact, Harness, Model. Artifact optimizes programs, papers, work products; Harness optimizes prompts, skills, tools, rails, execution strategies; Model improves data and model capabilities via task feedback. Three paths collaborate around shared task goals and evaluation criteria, assessing impact of improvements on overall effect.
Architecture takes execution trajectories, artifacts, user feedback as input; evaluation and diagnosis generate candidate solutions; verified in isolated environments for quality and cost; passed results versioned and released. Improved agent continues participating in diagnosis, solution generation, verification, forming recursive loop. Currently openJiuwen has open-sourced Artifact optimization interfaces and AutoHarness mechanism; model-side collaborative evolution shown as dashed lines indicating architectural direction.
4. Collaboration: Swarm Architecture Organizes Heterogeneous Agent Collaboration
Complex work spans research, development, analysis, verification needing diverse professional capabilities. Existing enterprise agents may use different models, harnesses, tools. As scope expands, agents must understand division of labor, handoff artifacts, negotiate progress, complete goals with humans and other agents.
openJiuwen uses Swarm Engine to organize collaboration: shared group context carries goals, history, work products; coordinator assigns roles based on task dependencies and acceptance criteria, wakes members by message direction. Professional agents or expert teams execute tasks, merge results, verify, feed feedback back to collaboration space. Humans can participate as members in decisions and acceptance.
Heterogeneous collaboration achieved via member adapters and collaboration contracts. Different models, harnesses, executors, professional tools integrate via supported external CLI, team MCP, etc., exchanging messages, task states, artifacts per contract. Integration scope determined by specific adapters and permission configs.
In this architecture, Agent-internal Workers execute sub-tasks of their Agent; Swarm organizes collaboration between independent Agents and Agent Teams. Two-layer mechanism lets HyperAgent leverage single-agent general capabilities while organizing professional division of labor around complex goals.
Facing "Application Properties": Entering Real Business Environments
To let HyperAgent enter real business, need to adapt complex systems, continuously extend capabilities, run stably in clusters and diverse compute environments. Addressing determinism, extensibility, openness, economy, openJiuwen builds corresponding runtime foundations and system services.
1. Determinism: Distributed Runtime Supports Reliable Execution
Enterprise tasks span multiple systems, long durations, must handle concurrent requests, resource fluctuations, waits, failures. Business cares about completion, latency, fault recovery, process traceability. Determinism means execution reliable, behavior controllable, state verifiable, runtime observable.
openJiuwen separates compute from persistent state: compute instances scheduled on-demand; work files, business records, checkpoints (snapshots for recovery) stored. Application-layer work resumes based on task state, artifacts, history; runtime environment restores from checkpoints; two state types managed separately.
Elastic sandboxes allocate execution resources per task needs, concurrency limits, node capabilities; pre-warm, on-demand create, idle recycle adjust capacity. Session affinity and concurrency control manage execution order; metrics, logs, call chains help locate congestion and failures; verify run and recovery results. Critical business actions further verified against real business state, forming manageable execution loop.
2. Extensibility: Controlled Plugin Mechanism & RSI-Friendly Extension Points
Enterprise agents need to onboard new skills, systems, collaboration units, and improve own harness per execution feedback. Extension mechanism must serve both developers and RSI: easy to integrate, combine, manage; harness easy to understand, modify, verify; effective improvements continuously precipitated as reusable versions.
Controlled plugin mechanism supports Skill, Connect, Plugin, Agent, Agent Team, Agent App integration per respective contracts; declaration, registration, version, lifecycle management enable on-demand assembly. Rails and permission policies constrain runtime calls; execution backends provide runtime boundaries, keeping extensions manageable.
RSI-friendly extension points focus on easing Harness modification by RSI. Prompts, context handling, Skills, Tools, Rails, execution strategies organized as modules with clear boundaries, explicit configuration, locally replaceable; provide traceable execution traces and evaluation entry points. RSI identifies issues, selects modification points, adjusts config or component implementations, lowering cost of understanding and modifying Harness.
Modifications done in isolated workspaces; comparative evaluation and regression verification produce candidate versions; then enter controlled release via extension packages or code PRs. Evaluation results, version diffs, runtime feedback support subsequent iterations, letting extension points serve both manual development and RSI continuous evolution.
3. Openness: Enhanced Control Over Digital and Physical Worlds
As agents undertake more actual work, they must access business systems, operate software UIs, perceive device states, drive device actions. Openness core: continuously expand agent's control range over digital and physical worlds so tasks complete in real environments.
In digital world: Agents connect data sources and business systems via Connect, tools, APIs, MCP; operate browser and desktop app UIs via CUA; account, payment services integrated per scenario. Structured calls and UI operations jointly extend software control capability.
In physical world: Device access and execution channels link specific devices, translate agent action requests to device commands, feed device states and execution results back. Architecture continuously expands terminal, peripheral device types via adapters; specific execution capabilities determined by device interfaces and backends.
openJiuwen proposes ADF (Agent Device Foundation) as device-oriented infrastructure direction, providing unified abstraction for capability description, device access, action invocation, state feedback. CUA, tools & system connections, device control together form "observe—act—feedback" environment interaction loop, supporting agents to continue tasks based on actual execution results.
4. Economy: Compute Affinity & Model Routing Optimize Task Cost
Agent costs distributed across inference, tool execution, environment prep, data access. Multi-turn KV reuse, sandbox prep, general compute scheduling interact; different tasks need different model capabilities. Economy must optimize resource collaboration and model selection, balancing effect, latency, total cost per complete task.
Compute Affinity : Coordinate intelligent compute, storage, general compute per agent task phase to reduce redundant computation, environment prep, data movement overhead.
Intelligent Compute Collaboration : Core is proactive KV management for inference; combine agent's inference, tool execution, wait phases; plan logical KV capacity and context growth; increase KV reuse via request admission, pause, resume; reduce redundant prefill. Model execution and physical KV block allocation/recycling handled by inference engine.
Storage Collaboration : Focus on sandbox scheduling; incorporate environment snapshot storage location, recoverable nodes, cache reuse conditions into environment allocation. Organize sandbox recovery and node selection per snapshot type and backend capability; connect with workspace and persistent data access; reduce environment rebuild and data movement. Further optimize sandbox placement with cross-data access cost as extension.
General Compute Collaboration : Schedule task and general compute resources; arrange execution per concurrency needs and CPU/memory conditions; combine node constraints, session affinity, instance pre-warm, idle recycle; improve utilization of agent backend, tool execution, sandbox environment.
Model Routing : Match task with model capability per step. Strategies designed around task capability needs, latency, budget, model availability; select from local, private, cloud models; assemble and evolve per business scenario.
Model Router receives request via route, reads state snapshot from StateProvider, AlgorithmProvider generates model selection. Algorithms and states plug in via respective interfaces for easy strategy replacement per task and deployment conditions. Actual model calls executed by host; host reports results, latency, cost stats via report for subsequent selections; model calls, retries, task progression still organized by host. Strategy effectiveness evaluated by full-task success rate, resource consumption, end-to-end latency.
Typical Deployment Patterns
Based on same HyperAgent modeling and AgentOS layering, openJiuwen supports personal desktop and enterprise distributed deployments with different resource organization, both adhering to "one HyperAgent = frontend + one Agent Serving".
(1) Personal Desktop: Daily Coding & Office
Targets coding, office, personal knowledge processing. Frontend and Agent Serving can run on same device; Serving hosts Gateway, Agents & Workers, Memory, RSI. User interacts continuously with HyperAgent via client.
(2) Enterprise Distributed: Multi-App & Scaled Operation
Targets multi-user collaboration, multi-business apps, continuous tasks. Users access via frontend or channels; HyperAgent backend runs in enterprise cluster. Each Agent Serving hosts one HyperAgent backend instance; Distributed Executor provides distributed runtime for multiple Servings.
Cluster separates compute and persistent state: compute nodes handle execution; storage services save work data, task records, memory data, managed by application namespaces and access boundaries. Sandboxes and execution environments allocate resources per task needs; capacity management, concurrency control, recycle mechanisms support scaled execution.
Model inference services and hardware pools deployed independently, accessed via model interfaces; model routing and compute affinity configured per actual host and compatible inference backends. AgentOps centralizes runtime observation and diagnosis for task effectiveness, resource consumption, execution latency. Business capabilities, agent runtime capacity, inference resources scale independently per load.
Flexible Deployment Location & Resource Combination
Agent backend, model services, tool/device execution ends can independently choose deployment locations. Desktop HyperAgent can call remote models; cluster HyperAgent can access external systems/devices via adapted connections. CUA native adaptation and UI operation require configuration in target desktop environment with appropriate connection, session, permission conditions.
Conclusion
From September architecture release to recent swarm collaboration progress to this complete interpretation, openJiuwen treats Agent as a long-running, continuously growing "digital entity" not a one-off program. It unifies intelligent-entity demands (proactive execution, cross-session continuity, self-improvement, heterogeneous collaboration) with engineering-application demands (reliable execution, controlled extension, environment control, cost optimization) in a single AgentOS layered architecture.
The interpretation distinguishes open-sourced implementations from target architecture: e.g., CoRSI model-side collaboration remains evolutionary direction; some components' end-to-end integration awaits per-deployment validation. As agents enter enterprise critical business, openJiuwen AgentOS open-source exploration and real-world adoption merit continued attention.
References
openJiuwen official site (includes HyperAgent architecture diagram): https://openjiuwen.com
WorkSwarm official site & download: https://openjiuwen.com/workswarm
GitHub open-source repo: https://github.com/openJiuwen-ai
AtomGit open-source repo: https://atomgit.com/openJiuwen
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
