Featured image of post HarmonyOS 7 Reframes App Development Around AI Agents

HarmonyOS 7 Reframes App Development Around AI Agents

Coding tools meet system agents.

The main shift: apps become callable capabilities

The main shift: apps become callable capabilities

Two months after the HarmonyOS 7 Developer Beta appeared at HDC 2026, the bigger story is not a single new feature, but Huawei’s attempt to reorganize the operating system around AI agents.

In an InfoQ interview, full-stack engineer and HarmonyOS ecosystem advocate Liu Guangzhi argued that the traditional app model asks users to choose an app first and then complete a task inside it. HarmonyOS 7 tries to invert that flow: users express an intent, and the system decides which capabilities should be invoked. An agent here means software that can understand a goal, break it into steps, and call tools or services to finish the job.

The central layer is HMAF 2.0, the upgraded HarmonyOS intelligent agent framework. According to Liu, the stack can be viewed in six layers: Xiaoyi as the system assistant and user entry point; HMAF 2.0 for task decomposition and multi-agent coordination; the AI foundation including openPangu 2.0 and an on-device 30B model; system support such as Ark Engine, Star Shield security and interconnection capabilities; developer tools including DevEco Code and DevEco CLI; and scenario layers such as spatial computing.

For developers, the practical change is that an app should not only wait to be opened. It can expose its functions as a recognizable and schedulable agent, with intent, parameters and callbacks available to the system.

Models, performance and security signals

openPangu 2.0 is one of the important underlying pieces. Its Pro version has 505 billion parameters, while the Flash version has 92 billion parameters. Both support a 512K long context window. Huawei also highlights its Ascend-native design, saying single-card throughput can reach twice that of mainstream open-source models.

HarmonyOS 7 also introduces what Liu described as a “performance large model” at the scheduling layer. Key figures mentioned in the interview include:

  • 24% faster launch speed for system apps;
  • 34% faster launch speed for ecosystem apps;
  • 40% improvement in game frame-rate stability;
  • annual load growth kept within 10%.

On the security side, the Star Shield architecture uses on-device AI to detect fraud patterns. It has reportedly helped users identify 3.47 million potential scams, and mainstream apps including Alipay and Douyin have already integrated with it.

DevEco’s two-track tool strategy

DevEco’s two-track tool strategy

Huawei’s developer tooling follows what Liu called a two-track route. DevEco Code is the more autonomous option: developers describe a requirement, and the tool can plan, generate code, compile, debug and attempt fixes when errors occur. DevEco CLI, by contrast, does not try to be the brain. It exposes HarmonyOS capabilities such as project management, build checks, running and debugging as command-line functions that can be called by Claude, Cursor or a company’s own agent system.

DevEco Code combines Huawei’s self-developed Bifang engine with the open-source OpenCode framework. Bifang is responsible for agent reasoning, planning and tool use, while OpenCode supplies terminal interaction, configuration and ecosystem interfaces such as MCP, Skill and Plugin. The logic is clear: the proprietary layer deepens integration with the HarmonyOS toolchain, while the open layer keeps third-party compatibility.

Inside DevEco Code, a Plan Agent interprets requirements and turns them into steps, while a Build Agent executes coding, compilation and debugging. In multi-device scenarios, this means the tool can factor in adaptation requirements during planning rather than leaving developers to patch UI logic later.

The hard part: adaptation and developer productivity

The most difficult issue for many small and mid-sized teams remains device adaptation. HarmonyOS spans phones, tablets, car systems, wearables and other form factors. Differences in screen size, chips, memory and system API versions can lead to failed installation, crashes, broken layouts or performance problems. Teams with only a few test devices may not discover these issues until after release.

Huawei has tools aimed at this problem, including EasyGo for wider-screen experiences on foldables and tablets, and multi-device UX automatic detection for issues such as oversized images, truncated UI and overlapping content. But Liu also pointed out several gaps: DevEco Code does not support Linux; it still depends heavily on DevEco Studio, so the pure command-line experience is limited; and general large models still have relatively little ArkTS training data. As a result, around 15% to 20% of generated ArkTS code may need manual correction.

The community is also trying to fill the gap. One example is the open-source harmonyos-ai-skill project, which condenses HarmonyOS development knowledge into a Markdown file. After configuration, tools such as Claude, Cursor and Copilot can use it to supplement their HarmonyOS knowledge and partly offset the lack of training data.

Outlook: the real test is a closed loop

Compared with Apple and Google, Huawei is presenting development-time AI tools and runtime system agents as one connected architecture. Apple keeps Xcode and Apple Intelligence as more separate narratives, while Google presented AI tools, models, Android Studio and related topics in separate I/O sessions. Huawei is trying to connect DevEco Code, DevEco CLI, Xiaoyi and HMAF 2.0 into one operating-system-level agent strategy.

The opportunity is significant: if app capabilities can be safely registered, understood and scheduled by the system, user interaction may shift from tapping icons to expressing intent. The challenge is equally concrete. Tool maturity, ArkTS data, multi-device adaptation and native app development will determine whether the agent architecture becomes a daily development reality. In the near term, the value of HarmonyOS AI is less about replacing programmers and more about automating high-friction work such as adaptation, build debugging and capability exposure. The long-term test is whether development-time agents and runtime agents can truly form a closed loop.