AI Native 鸿蒙 App：从页面驱动到智能驱动的架构革命

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- [一、传统 App 架构为什么开始遇到瓶颈](#一、传统 App 架构为什么开始遇到瓶颈)
- [二、AI Native App 的本质变化](#二、AI Native App 的本质变化)
- [三、AI Native App 四层架构](#三、AI Native App 四层架构)
- [四、第一层：Presentation Layer](#四、第一层：Presentation Layer)
- [五、第二层：AI Runtime](#五、第二层：AI Runtime)
- [六、第三层：Domain Runtime](#六、第三层：Domain Runtime)
- [七、第四层：System Runtime](#七、第四层：System Runtime)
- [八、鸿蒙 AI Native Runtime 实战](#八、鸿蒙 AI Native Runtime 实战)
- [九、为什么 MVVM 正在演化为 AI Runtime](#九、为什么 MVVM 正在演化为 AI Runtime)
- [十、未来 App 的终极形态](#十、未来 App 的终极形态)
- 总结

引言

过去十几年，无论是：

Android
iOS
Web
HarmonyOS

应用开发的核心逻辑始终没有变：

text 复制代码

用户点击
    ↓
触发事件
    ↓
更新状态
    ↓
刷新页面

本质上：

text 复制代码

UI 驱动业务

整个系统围绕页面运转。例如：

text 复制代码

Page
 ↓
ViewModel
 ↓
Service
 ↓
Data

用户永远是系统唯一的驱动者。但是随着大模型、Agent、Workspace Runtime 的出现，一个新的问题开始出现。

很多时候：

text 复制代码

用户并不想操作页面

用户真正想做的是：

text 复制代码

完成目标

例如：

text 复制代码

帮我生成报销申请

帮我整理会议纪要

帮我完成审批配置

帮我分析异常日志

此时用户关心的是：

text 复制代码

Goal

而不是：

text 复制代码

Page

这意味着：

App 的架构中心开始从页面转向智能体。

而这正是 AI Native App 的本质。

一、传统 App 架构为什么开始遇到瓶颈

看一个典型鸿蒙 App：

text 复制代码

UI Layer
    ↓
ViewModel
    ↓
Repository
    ↓
Network

例如：

ts 复制代码

Button("提交")
  .onClick(() => {
      submit()
  })

用户点击：

text 复制代码

提交

系统执行：

text 复制代码

接口调用
↓
状态更新
↓
页面刷新

完全没有问题，但是如果未来用户这样说：

text 复制代码

帮我提交昨天未完成的报销单

问题来了，系统应该：

text 复制代码

打开哪个页面？
点击哪个按钮？
选择哪个数据？

传统架构根本无法回答，因为：

text 复制代码

页面知道业务

但业务不知道目标

这就是传统 App 最大的限制。

二、AI Native App 的本质变化

过去：

text 复制代码

User
 ↓
UI
 ↓
Business

未来：

text 复制代码

User
 ↓
Goal
 ↓
AI Runtime
 ↓
Business
 ↓
UI

最大的区别在于：

text 复制代码

AI Runtime

开始成为新的中间层。例如，用户输入：

text 复制代码

帮我提交上周的差旅报销

AI Runtime 会自动：

text 复制代码

识别意图
      ↓
查询报销记录
      ↓
补全缺失字段
      ↓
执行提交
      ↓
反馈结果

整个过程中，用户甚至不需要打开页面。

三、AI Native App 四层架构

经过大量 Agent 项目实践后，我们发现最稳定的架构通常是：

text 复制代码

┌─────────────────┐
│ Presentation    │
└────────┬────────┘
         ↓
┌─────────────────┐
│ AI Runtime      │
└────────┬────────┘
         ↓
┌─────────────────┐
│ Domain Runtime  │
└────────┬────────┘
         ↓
┌─────────────────┐
│ System Runtime  │
└─────────────────┘

这就是典型：

text 复制代码

AI Native 四层架构

四、第一层：Presentation Layer

这一层仍然存在，但职责发生变化。过去：

text 复制代码

负责业务逻辑

未来：

text 复制代码

负责状态投影

例如：

ts 复制代码

@Component
struct ExpensePage {

  @ObjectLink store: ExpenseStore

  build() {

    Column() {

      Text(store.currentStatus)

    }

  }

}

这里页面只负责：

text 复制代码

展示 Runtime 状态

而不是：

text 复制代码

控制业务

五、第二层：AI Runtime

这是整个 AI Native App 的核心，负责：

Intent Parsing
Task Planning
Tool Calling
Memory Management
Context Building

例如：

ts 复制代码

export class AIRuntime {

  async execute(goal: string) {

  }

}

执行过程：

text 复制代码

Goal
 ↓
Intent
 ↓
Plan
 ↓
Task
 ↓
Tool

例如：

text 复制代码

生成周报

AI Runtime 会自动拆解：

text 复制代码

读取任务
↓
读取工时
↓
整理内容
↓
生成周报

六、第三层：Domain Runtime

很多团队喜欢让 AI 直接调用接口，这是危险的。

正确做法应该是：

text 复制代码

AI
 ↓
Domain Runtime
 ↓
API

例如：

ts 复制代码

export class ExpenseRuntime {

  async submitExpense(id: string) {

  }

}

AI 只能调用：

text 复制代码

ExpenseRuntime

而不能直接：

text 复制代码

POST /expense/submit

这样能够保证：

权限控制
审计追踪
业务一致性

七、第四层：System Runtime

System Runtime 负责：

text 复制代码

文件
数据库
通知
搜索
设备能力
系统服务

统一抽象：

ts 复制代码

export interface Tool {

  name: string

  execute(params: object): Promise<any>

}

例如：

ts 复制代码

export class FileTool implements Tool {

  async execute(params) {

  }

}

统一注册：

ts 复制代码

toolRegistry.register(new FileTool())

形成标准 Tool Ecosystem。

八、鸿蒙 AI Native Runtime 实战

首先定义全局 Runtime。

ts 复制代码

@Observed
export class AppRuntime {

  currentTask: string = ""

  currentGoal: string = ""

  currentState: string = "idle"

}

全局实例：

ts 复制代码

export const runtime = new AppRuntime()

创建 Agent 执行器：

ts 复制代码

export class AgentExecutor {

  async execute(goal: string) {

    runtime.currentGoal = goal

    runtime.currentState = "running"

    const result = await llm.invoke(goal)

    runtime.currentState = "finished"

    return result

  }

}

页面绑定：

ts 复制代码

Text(runtime.currentState)

此时：

text 复制代码

AI Runtime
    ↓
Store
    ↓
UI

形成统一状态流。

九、为什么 MVVM 正在演化为 AI Runtime

过去：

text 复制代码

View
 ↓
ViewModel
 ↓
Model

本质解决的是：

text 复制代码

状态同步

而未来：

text 复制代码

View
 ↓
Runtime
 ↓
Agent
 ↓
Domain

解决的是：

text 复制代码

目标执行

这两者不是一个层级的问题，因此未来大型鸿蒙 App 的核心模块，很可能从：

text 复制代码

ViewModel

变成：

text 复制代码

Agent Runtime

十、未来 App 的终极形态

过去的软件：

text 复制代码

用户操作系统

未来的软件：

text 复制代码

用户描述目标
AI 操作系统

例如：

text 复制代码

整理本周项目进展

生成测试方案

完成报销申请

分析线上异常

用户只提供：

text 复制代码

Goal

系统自动完成：

text 复制代码

Plan
 ↓
Execute
 ↓
Feedback

这才是真正意义上的：

text 复制代码

AI Native Application

总结

如果一句话总结：

AI Native 鸿蒙 App 到底改变了什么？

答案是：

text 复制代码

从页面驱动
变成目标驱动

过去：

text 复制代码

Page
 ↓
Event
 ↓
Action

未来：

text 复制代码

Goal
 ↓
Agent
 ↓
Runtime
 ↓
Action

页面不再是系统中心，AI Runtime 才是。

而鸿蒙的：

状态管理
多设备协同
Workspace
系统服务
分布式能力

恰好为这种架构提供了天然土壤，未来真正有竞争力的鸿蒙 App，不一定拥有最多页面，但一定拥有最强的：

text 复制代码

AI Runtime

因为最终用户需要的，从来不是按钮，而是结果。