HarmonyOS 7 Opens Up Skills, Lowering the Cost of Agent Integration

HarmonyOS 7 is turning Skills and Agents from capabilities confined within the system into standardized capabilities that developers can package, publish, and invoke.

At Huawei Developer Conference 2026, held in June this year, Huawei unveiled a new toolchain for agent development centered on products including HarmonyOS 7, HMAF 2.0—the HarmonyOS Agent Framework, the Ark Agent Framework, and DevEco CLI. Over the past few months, these capabilities have begun entering the stage of real-world developer integration and application validation.

The value of this development does not lie in the fact that “HarmonyOS now has an AI assistant too.” It is not difficult for a smartphone manufacturer to build an assistant that can chat. The difficult part is enabling an Agent to truly understand the system, invoke application services, operate devices, and complete a closed loop across permissions, security, state management, and multi-device collaboration.

HarmonyOS 7 is attempting to address precisely the engineering costs involved in this process. Developers no longer need to build separate systems for intent recognition, tool invocation, permission verification, and task orchestration for every application. Application capabilities can be packaged as Skills, while Agents can also be encapsulated as reusable components and then centrally scheduled by the system or other Agents.

From “Integrating a Model” to “Integrating a Set of Capabilities”

In the past, when developers said they were “adding AI to an application,” they generally meant calling a large-model API: turning a user’s question into a prompt, sending it to a cloud-based model, and displaying the returned text in the interface.

This approach works well for question answering, summarization, and content generation, but it has difficulty directly completing real-world tasks. If a user says, “Help me organize the seaside photos I took last week into a travel journal,” the model can only produce a piece of text. To actually complete the task, it would also need to access the photo album, identify where the photos were taken, retrieve historical information, generate a page, and possibly invoke sharing, calendar, or map services.

Developers therefore have had to build a complex pipeline themselves:

1. Define user intents and parameter structures;
2. Convert application functions into tools that models can understand;
3. Write prompts and tool-invocation protocols;
4. Handle multi-turn conversations, context, and task state;
5. Add permission checks and exception handling to every invocation;
6. Adapt to the output formats of different models;
7. Convert task results into interactive interfaces suitable for mobile devices.

This work has little to do with the underlying business itself, yet it is the part of agent projects most prone to repeated reinvention. The cost of integrating one application may still be acceptable. But if dozens of applications each need to be integrated separately, system capabilities become a bottleneck to ecosystem expansion.

HarmonyOS 7’s approach is to abstract functions that can be invoked by Agents into Skills. A Skill is not simply a piece of prompt text, nor is it an interface that only returns text. It is closer to an invocable service with capability descriptions, input and output structures, execution logic, permission boundaries, and lifecycle management.

For example, a travel application could package “search photos by location,” “generate a route,” and “create a travel retrospective” as separate Skills. The system Agent Xiaoyi would be responsible for understanding the user’s goal, breaking down the task, and selecting the appropriate capabilities. The application would only need to expose its services according to HarmonyOS specifications, rather than repeatedly implementing an entire Agent orchestration system.

What Changes When Both Skills and Agents Can Be Packaged and Invoked

This opening-up initiative has two main aspects.

First, application and system capabilities can be packaged as Skills for invocation by on-device or cloud-based Agents. Huawei has stated publicly that HarmonyOS 7 adds on-device Skills and cloud Skills that can be distributed and listed together with applications. In other words, Skills are no longer limited to being preinstalled by the system team. Application developers can also incorporate their own business capabilities into HarmonyOS’s intelligent service chain.

Second, the Agents themselves can also be packaged and invoked. A complex task does not need to be planned from scratch by a large model every time. It can first be consolidated into a specialized Agent and then invoked on demand by an upper-level Agent.

This is similar to the evolution in software engineering from “directly calling low-level functions” to “calling services and components.”

• A Skill is more like an atomic capability: querying an order, identifying an image, controlling a device, or generating a report;
• An Agent is more like a business module with a task objective and execution strategy: a customer-service Agent, travel-planning Agent, or home-device-management Agent;
• The system Agent serves as a unified entry point for task understanding, capability discovery, process orchestration, and result presentation.

For developers, the biggest change is that capabilities can be reused in layers. An application can invoke system Skills and expose its own Skills to the system. An Agent can invoke multiple Skills and can itself be invoked by an Agent at a higher level. Agent development is therefore no longer merely about “writing prompts for a model”; it is beginning to resemble modularized and service-oriented development in traditional software engineering.

HMAF 2.0: HarmonyOS Begins to Complete the Agent Engineering Chain

HMAF 2.0, the second generation of the HarmonyOS Agent Framework, is a key foundation for HarmonyOS 7’s intelligent capabilities. According to publicly available information, the framework encompasses Agents, Skills, atomic services, an intent framework, and MCP, providing developers with an end-to-end path from capability definition to task execution.

Several of these concepts need to be considered separately.

Intent Framework: Turning Natural Language into Executable Goals

Users may say, “Help me arrange tomorrow’s itinerary,” while the application needs structured information: the date, locations, departure time, mode of transportation, participants, and whether a calendar event needs to be created.

The role of the intent framework is to convert a natural-language goal into a task description that both applications and the system can understand. It is not about whether the model can speak, but whether, after the model has spoken, the system can accurately determine what needs to happen next.

Skill: Turning Application Functions into Tools

Without standardized Skills, a model can only see a collection of interfaces and pages that differ from one another. Through unified capability descriptions, an Agent can determine what a Skill can do, what parameters it requires, whether user confirmation is needed, and how failures should be handled.

This is particularly important for cross-application invocation. A complete task often requires the participation of multiple applications—for example, obtaining a route from a map service, checking available time from a calendar, and then completing a booking through a transportation application. Skills provide a more stable invocation path than “simulating clicks” on an interface.

Agent: Encapsulating Complex Processes

When a task involves planning, decision-making, and multiple execution steps, exposing individual Skills is not enough. Developers can package an entire workflow as an Agent. For example, a “meeting preparation Agent” could automatically read the meeting topic, check the schedules of attendees, generate meeting materials, and create a calendar event.

The upper-level Xiaoyi or a third-party Agent would not need to understand every internal step. It would only need to pass in the objective and the necessary parameters. This would significantly lower the barrier to integrating complex business processes and make it easier for teams to divide Agents by business domain.

MCP: Connecting External Tools and Services

MCP can be understood as a general-purpose connection method between Agents and external tools. Its significance is not that it replaces HarmonyOS-native capabilities, but that it makes it easier for existing enterprise systems, cloud services, and development tools to enter an Agent’s invocation chain.

For enterprises with ERP, CRM, content-management, or data-analysis platforms, this means that Agents on HarmonyOS devices do not have to be limited to local smartphone services. They can also access enterprise business systems, provided that permissions remain under control.

Where Exactly Does Development Cost Decrease?

“Lowering integration costs” is not merely a vague efficiency slogan. It is reflected in at least four areas.

1. Less Reimplementation of the Tool-Invocation Layer

In the past, each application had to define its own model-callable functions and handle parameter validation, invocation failures, and result delivery. Skill specifications move this general-purpose work into the platform layer, allowing application teams to focus more on their business logic.

This is particularly important for small and medium-sized teams. They often have mature application functionality but no dedicated AI infrastructure team. As long as they can package their existing capabilities according to the specifications, they have an opportunity to integrate with system-level intelligent entry points.

2. Less Need to Build Separate Context and Task-Orchestration Systems

Complex tasks cannot be completed with a single invocation. An Agent needs to remember the user’s objective, the steps that have already been executed, the current device state, and whether the user has granted authorization.

If all this state has to be managed entirely by the application, the development team must handle numerous edge cases: Should the task be retried after a network interruption? Should it continue if the user switches devices? How should execution be paused when a particular step requires payment or privacy authorization?

A system-level Agent framework can centrally handle part of this orchestration. Applications only need to specify what they can do, when they can do it, and what conditions they require. The framework can manage how tasks flow across Skills.

3. No Need to Design the On-Device/Cloud Division of Labor from Scratch

HarmonyOS 7 emphasizes both on-device Skills and cloud Skills. On-device execution is better suited to privacy-sensitive or latency-sensitive tasks, as well as tasks requiring direct device operation. Cloud execution is better suited to complex reasoning, long-form text processing, and tasks that require access to remote business systems.

Developers do not need to force every capability onto the device, nor do they need to upload all data to the cloud. Instead, they can divide tasks according to their characteristics. For example, photo filtering and device control can be performed primarily on the device, while travel-guide generation and cross-city route planning can be delegated to cloud-based Agents.

On-device/cloud collaboration is not a new concept. However, once the system layer provides a unified entry point, developers no longer need to repeatedly design orchestration logic for every device and network condition.

4. Multi-Device Adaptation Evolves from “UI Adaptation” to “Task Adaptation”

The challenge of the HarmonyOS ecosystem has never been limited to adapting to smartphone screens. It also involves ensuring a seamless experience across tablets, foldable phones, in-vehicle systems, smart displays, wearable devices, and other terminals.

When application capabilities are abstracted as Skills, an Agent can select an appropriate execution method according to the capabilities of each device: displaying a complete page on a phone, providing key reminders on a watch, enabling voice interaction in a vehicle, or generating visual results on a large screen.

This is closer to “one task, multiple presentations” than simply stretching a mobile interface onto a larger screen. Developers’ focus shifts from maintaining duplicate interfaces for each device to maintaining capability descriptions, data structures, and presentation strategies for different terminals.

The Significance of DevEco CLI: Enabling External Coding Agents to Truly Build HarmonyOS Applications

The latest opening-up initiative in HarmonyOS 7 is not limited to runtime Agents; it also covers the development phase.

Huawei’s DevEco CLI consolidates project creation, syntax checking, compilation and builds, device management, emulator control, application execution, and log collection into a command-line interface. For teams already using coding Agents such as Claude Code, Codex, OpenCode, and Trae, this step is highly significant.

AI coding tools struggle most when they encounter a platform that can only be operated through an IDE. A model may be able to generate ArkTS code, but it cannot create a project, launch an emulator, install an application, read build errors, or verify the interface on a physical device. The result is that “the code has been generated, but the project still does not run.”

Once DevEco CLI turns these steps into stable command-line entry points, external Agents have an opportunity to complete the full loop:

Requirements analysis
  -> Create a HarmonyOS project
  -> Generate or modify ArkTS code
  -> Perform syntax checking and build
  -> Launch an emulator or connect a physical device
  -> Install, run, and collect logs
  -> Fix issues based on error messages
  -> Build and verify again

Huawei has also released Skills for scenarios including multi-device adaptation, ArkTS syntax, application quality, and performance optimization. It has organized a large amount of official HarmonyOS documentation into knowledge resources that Agents can retrieve and invoke. For developers, this is more valuable than simply adding another code-completion model: the model must not only know how to write code, but also understand HarmonyOS engineering constraints, device differences, and release specifications.

However, the actual effectiveness of these capabilities will still depend on the quality of the documentation, the stability of the command-line interfaces, and the execution capabilities of the Agents. Moving IDE features to the CLI does not automatically mean that AI can complete development. UI layouts, animations, system permissions, and compatibility with physical devices in particular still require human confirmation.

This Is Not a “万能小艺”—the Omnipotent Version of Xiaoyi—for HarmonyOS

It is important to clarify that opening up Skills does not mean every application can be invoked unconditionally by Xiaoyi. Nor does it mean developers can obtain a stable flow of natural-language traffic simply by uploading a Skill.

First, permissions and privacy are hard constraints. For capabilities involving photo albums, location, contacts, payments, and device control, the system must distinguish between read, modify, and execute permissions. Many operations will still require explicit user confirmation. Otherwise, the “smarter” the Agent becomes, the greater the risks.

Second, the quality of a Skill’s description will directly affect its invocation success rate. If its capability boundaries are vague, its parameter definitions incomplete, or its exception states insufficiently covered, the model may invoke it incorrectly even if it understands the user’s intent. A Skill is essentially a product interface for Agents and cannot be treated casually using the standards of ordinary developer documentation.

Third, combining Agents will introduce new debugging challenges. Traditional application call chains are generally relatively fixed, whereas Agents dynamically select tools based on context. When a task fails, the cause may be incorrect model planning, invalid Skill parameters, missing permissions, a network timeout, or an unsatisfied device state. Developers will need new observability tools to record each task’s decisions, invocations, authorizations, and results.

Finally, model capabilities remain a variable. Metrics such as the complex-task success rates publicly disclosed for HMAF generally correspond to specific test sets, task types, and system configurations. They cannot be directly equated with success rates across all real-world businesses. Scenarios such as shopping, transportation, finance, and office work demand far greater stability and explainability than a demonstration.

HarmonyOS’s Differentiated Competition with Apple and the Android Ecosystem

From an industry-competition perspective, HarmonyOS 7 is shifting the operating-system battleground from “who has more applications” toward “who can organize application capabilities more effectively.”

Apple, through Apple Intelligence and its system-level Siri efforts, is also attempting to enable models to understand and invoke actions within applications. The Android camp has broader device and application coverage, but system capabilities, permission mechanisms, and Agent frameworks are not fully unified across manufacturers.

HarmonyOS’s advantage is that its devices, operating system, application framework, and distributed capabilities can be designed as part of a single platform. If the ecosystem reaches sufficient scale, the system Agent could connect phones, tablets, in-vehicle systems, and home devices into a task-execution network rather than leaving them as a collection of isolated apps.

Its weaknesses, however, are also clear: the richness of its Skills will ultimately depend on the size of the ecosystem and the participation of third-party applications. Without enough high-quality Skills, the system Agent will only be able to invoke a limited number of official capabilities, and users will ultimately return to traditional application entry points. For HarmonyOS, open specifications are only the first step. Its true competitiveness will depend on whether developers are willing to integrate, and whether they can gain traffic and commercial returns after doing so.

What Developers Should Focus on Now

If a team is developing a native HarmonyOS application or already has its own Agent product, HarmonyOS 7 creates at least three categories of opportunities worth evaluating:

• Turn high-frequency business actions into Skills: Prioritize capabilities such as querying, generating, organizing, and controlling that have clear boundaries and can be invoked repeatedly, rather than trying to build an all-purpose Agent from the outset.
• Consolidate complex processes into domain-specific Agents: Package multi-step processes such as customer service, office work, travel, and content production into stable inputs and outputs, reducing repeated planning.
• Design the on-device/cloud collaboration and permission models in advance: Determine during the Skill-design phase which data should remain on the device, which tasks require the cloud, and which operations require secondary confirmation.
• Integrate the CLI into existing development pipelines: Connect project creation, builds, testing, and log analysis to existing CI/CD systems and coding Agents, and verify whether AI can genuinely improve delivery efficiency rather than merely generate code.
• Establish task-level observability metrics: In addition to model accuracy, monitor Skill invocation success rates, task completion rates, user confirmation rates, the number of failed retries, and the latency of on-device/cloud switching.

Assessment: HarmonyOS Is Moving from “Supporting AI” to “Becoming an Operating System for Agents”

Opening up Skill and Agent packaging and invocation in HarmonyOS 7 is the right direction, and it offers greater long-term value than simply releasing a system assistant.

It addresses a frequently underestimated problem in platform ecosystems: the capabilities already exist, but Agents do not know how to use them safely and reliably. Through Skills, Agents, the intent framework, and multi-device capabilities, HarmonyOS is attempting to connect system services, application services, and model inference into a standardized invocation system.

In the short term, developers gain lower integration costs and more system-level entry points. In the medium term, the focus of application competition may shift from “whether an application has AI features” to “whether it has capabilities that Agents can invoke with high quality.” In the long term, the operating system itself may become a task-orchestration platform, with users no longer concerned about which app to open, but only whether the task can be completed.

Whether this path succeeds, however, will ultimately not be determined by the names of the frameworks announced at a developer conference. It will be determined by three metrics: whether Skills are sufficiently rich, whether Agent invocation is sufficiently stable, and whether developers can obtain tangible benefits from the ecosystem.

As of August 4, 2026, HarmonyOS 7 has placed the interfaces and toolchain for Agent development in front of developers. What is truly worth watching next is not how many more questions Xiaoyi can answer, but how many third-party applications are willing to make their core capabilities available for system invocation—and whether those capabilities can form high-frequency, reliable task-completion loops in real-world scenarios.