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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

过去十几年，无论是：

• Android
• iOS
• Web
• HarmonyOS

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

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

本质上：

UI 驱动业务

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

Page ↓ ViewModel ↓ Service ↓ Data

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

很多时候：

用户并不想操作页面

用户真正想做的是：

完成目标

例如：

帮我生成报销申请 帮我整理会议纪要 帮我完成审批配置 帮我分析异常日志

此时用户关心的是：

Goal

而不是：

Page

这意味着：

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

而这正是 AI Native App 的本质。

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

看一个典型鸿蒙 App：

UI Layer ↓ ViewModel ↓ Repository ↓ Network

例如：

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

用户点击：

提交

系统执行：

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

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

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

问题来了，系统应该：

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

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

页面知道业务 但业务不知道目标

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

二、AI Native App 的本质变化

过去：

User ↓ UI ↓ Business

未来：

User ↓ Goal ↓ AI Runtime ↓ Business ↓ UI

最大的区别在于：

AI Runtime

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

帮我提交上周的差旅报销

AI Runtime 会自动：

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

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

三、AI Native App 四层架构

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

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

这就是典型：

AI Native 四层架构

四、第一层：Presentation Layer

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

负责业务逻辑

未来：

负责状态投影

例如：

@Componentstruct ExpensePage{@ObjectLinkstore:ExpenseStorebuild(){Column(){Text(store.currentStatus)}}}

这里页面只负责：

展示 Runtime 状态

而不是：

控制业务

五、第二层：AI Runtime

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

• Intent Parsing
• Task Planning
• Tool Calling
• Memory Management
• Context Building

例如：

exportclassAIRuntime{asyncexecute(goal:string){}}

执行过程：

Goal ↓ Intent ↓ Plan ↓ Task ↓ Tool

例如：

生成周报

AI Runtime 会自动拆解：

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

六、第三层：Domain Runtime

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

正确做法应该是：

AI ↓ Domain Runtime ↓ API

例如：

exportclassExpenseRuntime{asyncsubmitExpense(id:string){}}

AI 只能调用：

ExpenseRuntime

而不能直接：

POST /expense/submit

这样能够保证：

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

七、第四层：System Runtime

System Runtime 负责：

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

统一抽象：

exportinterfaceTool{name:stringexecute(params:object):Promise<any>}

例如：

exportclassFileToolimplementsTool{asyncexecute(params){}}

统一注册：

toolRegistry.register(newFileTool())

形成标准 Tool Ecosystem。

八、鸿蒙 AI Native Runtime 实战

首先定义全局 Runtime。

@ObservedexportclassAppRuntime{currentTask:string=""currentGoal:string=""currentState:string="idle"}

全局实例：

exportconstruntime=newAppRuntime()

创建 Agent 执行器：

exportclassAgentExecutor{asyncexecute(goal:string){runtime.currentGoal=goal runtime.currentState="running"constresult=awaitllm.invoke(goal)runtime.currentState="finished"returnresult}}

页面绑定：

Text(runtime.currentState)

此时：

AI Runtime ↓ Store ↓ UI

形成统一状态流。

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

过去：

View ↓ ViewModel ↓ Model

本质解决的是：

状态同步

而未来：

View ↓ Runtime ↓ Agent ↓ Domain

解决的是：

目标执行

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

ViewModel

变成：

Agent Runtime

十、未来 App 的终极形态

过去的软件：

用户操作系统

未来的软件：

用户描述目标 AI 操作系统

例如：

整理本周项目进展 生成测试方案 完成报销申请 分析线上异常

用户只提供：

Goal

系统自动完成：

Plan ↓ Execute ↓ Feedback

这才是真正意义上的：

AI Native Application

总结

如果一句话总结：

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

答案是：

从页面驱动 变成目标驱动

过去：

Page ↓ Event ↓ Action

未来：

Goal ↓ Agent ↓ Runtime ↓ Action

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

而鸿蒙的：

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

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

AI Runtime

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