HarmonyOS PC Gets an Open-Source AI Swarm

JiuwenSwarm recently released a HarmonyOS PC version and open-sourced its entire codebase. Jointly launched by the openJiuwen community and teams including Huawei’s tablet and PC product lines and software division, the project combines its previously separate productivity and Code modes into a unified workspace covering document creation, HarmonyOS application development, human-AI interaction, and other scenarios.

The project describes itself as the first open-source unified AI workspace for HarmonyOS PC. More noteworthy than that label, however, is that JiuwenSwarm is no longer content with simply having multiple agents run workflows automatically in the background. Instead, it proposes the HITS (Human in the Swarm) paradigm: people do not merely assign tasks from outside the swarm; they can enter the collaboration pipeline directly, revise plans, add roles, reject results, and work alongside multiple agents to complete deliverables.

This may sound like a conceptual upgrade, but it addresses the most practical issue facing today’s multi-agent systems: whether agents can discuss tasks among themselves is not the key question. What matters is whether people can intervene promptly when those discussions go off track, and whether this form of collaboration can be integrated into real desktop workflows.

From “Supervisor” to Team Member

Over the past two years, the typical design of multi-agent frameworks has been to define roles first, then use directed graphs, state machines, or message queues to arrange the execution order. For example, one research agent searches for information, a writing agent produces the main text, and another review agent checks facts and formatting. Users are generally responsible only for entering the objective, after which they wait outside the workflow for the result.

openJiuwen summarizes this model as HOTS (Human on the Swarm): the human sits above the swarm as its manager and scheduler. JiuwenSwarm’s newly proposed HITS model stands for Human in the Swarm—the human also becomes one of the swarm’s nodes.

The difference between the two is not merely a matter of adding a few more buttons to the interface.

In the HOTS model, the human is more like a developer submitting a CI job: configure the workflow, click Run, and then check whether the build succeeds or fails. In the HITS model, the human is more like a participant in an ongoing code review, able to change requirements midway, @mention a particular agent to redo a module, or temporarily bring in a new “expert.”

Take the creation of presentation materials as an example. JiuwenSwarm can split the task among multiple agents responsible for research, structural design, drafting, and visual integration, allowing them to work in parallel. During the process, the user can revise the outline, request additional specialized analysis, or add a design-enhancement agent if the slides do not look satisfactory—all without terminating and restarting the entire task.

This is closer to how real teams work than traditional one-question, one-answer interaction. In actual work, requirements can rarely be explained clearly in a single pass, and many judgments cannot be encoded into a workflow in advance. Allowing people to join midway effectively transforms the previously closed agent black box into a collaborative system that continuously exposes its intermediate state.

“Coordination Engineering” Is Not Just Opening More Chat Windows

JiuwenSwarm is an engineering implementation of the Coordination Engineering approach proposed by openJiuwen. The concept clearly overlaps with the recently popular Graph Engineering approach, but the two emphasize different things.

Graph Engineering primarily answers questions such as:

• Which nodes should a task be broken down into?
• How should state be passed between nodes?
• Which steps should run in parallel, and which should run sequentially?
• From which point should the process retry after a failure?
• Under what conditions should the entire workflow terminate?

Coordination Engineering goes a step further by asking how teams should be assembled on the fly, how conflicts between roles should be negotiated, at which nodes humans should intervene, and whether a successful collaboration can be preserved as a reusable asset for future tasks.

For developers, the former can be understood as constructing the agent’s “control flow,” while the latter attempts to provide the missing organizational layer. A production-ready multi-agent system is more than an elaborate DAG. It must also handle context isolation, permission boundaries, task preemption, result merging, cost control, and observability.

In particular, when multiple agents work in parallel, the number of model calls can quickly balloon. Breaking a task into more granular pieces does not necessarily make it faster or cheaper. If three agents use the same materials and similar prompts and ultimately produce three highly overlapping outputs, the so-called “swarm” has merely turned one inference job into three bills.

JiuwenSwarm’s value, therefore, cannot be judged solely by how many agents it can launch simultaneously. It should instead be measured against three more rigorous criteria:

1. Does task decomposition produce genuine parallelization benefits, rather than duplicated inference?
2. Is the intermediate process transparent enough for users to identify which node caused an error?
3. Can the results of collaboration be preserved and reused, avoiding the need to assemble teams and write prompts from scratch every time?

Judging from public demonstrations, JiuwenSwarm has already placed “team formation—execution—human adjustment—merged delivery” within a unified interface. However, the stability of long-running tasks, failure recovery, and the cost of large-scale concurrency will require validation through more real-world projects.

Assign Tasks via Feishu, and Let the HarmonyOS PC Get to Work at the Office

Another major focus of the HarmonyOS PC version is its integration with access points such as Feishu and Xiaoyi. Users do not need to remain at their computers; they can send instructions from their phones and remotely wake the agent team on the PC to continue processing tasks.

A typical scenario demonstrated by the project is as follows: a user receives an urgent request for presentation materials while traveling on a high-speed train and assigns the task to JiuwenSwarm through Feishu. The HarmonyOS PC in the office immediately begins producing the materials. Research, outlining, writing, and formatting can proceed in parallel, while the user monitors the process and adjusts requirements from a mobile device.

This is not simply a matter of moving a web chat box onto a phone. Instead, it allows task state to follow the user across devices. The phone serves as the interface for issuing instructions and approvals, while the PC handles file access, tool execution, code compilation, and relatively long-running background tasks.

This division of labor is well suited to desktop agents. Phones are not suitable for continuously running complex development environments, while PCs lack an always-accessible interface. HarmonyOS’s cross-device capabilities can bridge the two. If future versions can also address recovery from network outages, credential synchronization, and device permission confirmation, the system could align more closely with the real office environments of Chinese enterprises than a purely cloud-based agent.

Of course, remote wake-up also entails higher security requirements. An agent capable of reading local documents, operating productivity software, executing code, and sending results externally essentially gains privileges comparable to those of an employee account. At a minimum, enterprise deployments must clearly define:

• How mobile instructions are authenticated, and whether secondary confirmation is supported;
• Which directories, applications, and accounts each agent can access;
• Whether complete audit logs are retained for tool calls and outbound file transfers;
• Whether prompt injection can bypass existing permission boundaries;
• Whether code is executed in a sandbox, and how the environment is cleaned up after failures.

The smoother the cross-device experience becomes, the more important it is not to leave permission design until the end.

200 Presentation Slides in 20 Minutes—Speed Is Not the Only Metric

Among the use cases published by JiuwenSwarm, the most eye-catching is “completing a 200-slide presentation in under 20 minutes.” After the user enters the topic, target audience, and style requirements, multiple agents separately handle research, structure, content, and layout before combining their work into a complete deck.

From the perspective of parallel computing, this acceleration is reasonable. Traditional generation methods often proceed sequentially—“search first, then create an outline, then write each slide”—whereas a multi-agent system can divide independent sections and work on them simultaneously.

However, “200 slides” is primarily a demonstration of throughput. It does not mean that all 200 slides can be used directly in a formal presentation. The bottleneck in creating presentations is generally not text generation, but judgment: which data is credible, which slides are redundant, what management actually needs to see, and whether the arguments across different sections are consistent.

Multi-agent systems are especially prone to producing work that is locally correct but globally disjointed. Each agent may complete its own section, yet the final merged result may contain repeated concepts, conflicting definitions, or inconsistent data time ranges. This is precisely where the value of placing a human inside the swarm becomes apparent: not to fill in missing words for the AI, but to continuously make prioritization decisions and drive quality convergence.

In other words, what deserves recognition about JiuwenSwarm is not that it can make presentations longer, but that it attempts to keep bulk generation open to intervention. If it merely produces large volumes of slides more quickly, only for humans to rework them afterward, it remains nothing more than an automated content factory.

Code Mode Joins the Workspace, with Ambitions Beyond Coding Through Chat

This upgrade also merges Code mode with productivity mode. Within the same workspace, users can submit application requirements, and the system can assemble agents for design, front-end development, back-end development, testing, and coordination. They develop in parallel branches before merging their work.

Publicly demonstrated use cases include recreating the classic game Battle City and generating a calorie-tracking tool. The latter can write, compile, and package ArkTS code, ultimately producing an installable native HarmonyOS application. During development, users can continue adding requirements and direct a particular agent to modify specific features.

What distinguishes this from an ordinary code-completion tool is that JiuwenSwarm attempts to take over project-level tasks rather than merely generating a few dozen lines of code near the cursor. It must handle requirements decomposition, file modification, builds, testing, and merging, positioning it more like a desktop-based engineering team orchestrator.

However, multi-agent programming does not automatically solve software engineering problems. When several agents modify code simultaneously, they can easily encounter inconsistent interpretations of interfaces, dependency version conflicts, insufficient test coverage, and branch merge failures. The experience will ultimately be determined by the underlying engineering capabilities:

• Whether the workspace and context of each agent are isolated;
• Whether automatic rollbacks can be triggered based on test results;
• Which role adjudicates merge conflicts;
• Whether every file change and tool call is recorded;
• Whether agents can understand the latest project state after manual modifications;
• Whether failed tasks can resume from checkpoints instead of restarting entirely.

Only if these issues are handled well can JiuwenSwarm move from a demo-oriented agent into everyday development. Otherwise, it will simply have split one unreliable coding agent into multiple unreliable coding agents.

It Competes at a Different Layer from Existing Agent Tools

Today’s agent products can broadly be divided into three categories: those that provide models and coding capabilities, those that provide workflow orchestration frameworks, and those that directly occupy the browser, IDE, or desktop entry point.

JiuwenSwarm is closer to the third category while also extending into the second. Its goal is not to train a more powerful foundation model, but to control desktop task entry points, cross-device state, and multi-agent collaboration processes. Compared with development frameworks that emphasize graph orchestration, it is closer to end users. Compared with a single coding agent, it also brings office documents, application development, and entertainment interactions into the same collaborative interface.

This is also the most practical strategic value of the HarmonyOS PC version. While AI desktop entry points on Windows and macOS are already highly crowded, HarmonyOS PC still has an opportunity to redefine the agent workspace at the level of the operating system, device collaboration, and local permissions. Open sourcing also helps lower the barrier for developers building agent applications for the new platform.

However, a unified workspace also carries a common risk: it can do everything, but nothing deeply enough. Office users need reliable document formatting and enterprise knowledge permissions; developers need dependable terminals, version control, and testing environments; entertainment scenarios emphasize real-time performance. Putting all three into one interface is easy. Building a consistent and reliable execution foundation is much harder.

The Real Test Is “Doing Long-Term Work”

JiuwenSwarm’s open-source release shows that competition among China’s desktop agents is shifting from “who can answer questions” to “who can organize work.” HITS also reflects a reasonable assessment: full autonomy may not be the optimal solution at present. Allowing people to join at critical points may make it easier to bring multi-agent systems into production environments.

The direction is right, and it is more useful than merely demonstrating several agents talking to one another.

However, moving from demonstration to production still requires overcoming four major hurdles: stability, permissions, cost, and evaluation. A system’s ability to generate 200 presentation slides in 20 minutes does not mean it can maintain the same project continuously for several weeks. Likewise, compiling a sample application does not mean it can safely modify an enterprise codebase.

For developers, the more important question going forward is not how many additional agent roles JiuwenSwarm introduces, but whether it can disclose more comprehensive operational metrics: task success rates, the number of human interventions, model-call costs, failure recovery rates, and changes in quality after multiple rounds of collaboration.

The potential of swarms is enormous, but desktop productivity is ultimately measured not by the number of agents, but by the deliverables.

References

• ITHome: JiuwenSwarm Open-Source Unified AI Workspace for HarmonyOS PC Released—Introduces the project’s release background, the HITS collaboration paradigm, and use cases involving office productivity, programming, and cross-device collaboration.