网罗开发
（小红书、快手、视频号同名）
大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》 图书作者：《SwiftUI 入门，进阶与实战》 超级个体：COC上海社区主理人 特约讲师：大学讲师，谷歌亚马逊分享嘉宾 科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员 👋 大家好，我是展菲！ 📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。 每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
文章目录
-
- 引言
- 一、传统 App 架构为什么开始遇到瓶颈
- 二、AI Native App 的本质变化
- 三、AI Native App 四层架构
- 四、第一层：Presentation Layer
- 五、第二层：AI Runtime
- 六、第三层：Domain Runtime
- 七、第四层：System Runtime
- 八、鸿蒙 AI Native Runtime 实战
- 九、为什么 MVVM 正在演化为 AI Runtime
- 十、未来 App 的终极形态
- 总结
引言
过去十几年，无论是：
- 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
这一层仍然存在，但职责发生变化。过去：
负责业务逻辑
未来：
负责状态投影
例如：
@Component
struct ExpensePage {
@ObjectLink store: ExpenseStore
build() {
Column() {
Text(store.currentStatus)
}
}
}
这里页面只负责：
展示 Runtime 状态
而不是：
控制业务
五、第二层：AI Runtime
这是整个 AI Native App 的核心，负责：
- Intent Parsing
- Task Planning
- Tool Calling
- Memory Management
- Context Building
例如：
export class AIRuntime {
async execute(goal: string) {
}
}
执行过程：
Goal
↓
Intent
↓
Plan
↓
Task
↓
Tool
例如：
生成周报
AI Runtime 会自动拆解：
读取任务
↓
读取工时
↓
整理内容
↓
生成周报
六、第三层：Domain Runtime
很多团队喜欢让 AI 直接调用接口，这是危险的。
正确做法应该是：
AI
↓
Domain Runtime
↓
API
例如：
export class ExpenseRuntime {
async submitExpense(id: string) {
}
}
AI 只能调用：
ExpenseRuntime
而不能直接：
POST /expense/submit
这样能够保证：
- 权限控制
- 审计追踪
- 业务一致性
七、第四层：System Runtime
System Runtime 负责：
文件
数据库
通知
搜索
设备能力
系统服务
统一抽象：
export interface Tool {
name: string
execute(params: object): Promise<any>
}
例如：
export class FileTool implements Tool {
async execute(params) {
}
}
统一注册：
toolRegistry.register(new FileTool())
形成标准 Tool Ecosystem。
八、鸿蒙 AI Native Runtime 实战
首先定义全局 Runtime。
@Observed
export class AppRuntime {
currentTask: string = ""
currentGoal: string = ""
currentState: string = "idle"
}
全局实例：
export const runtime = new AppRuntime()
创建 Agent 执行器：
export class AgentExecutor {
async execute(goal: string) {
runtime.currentGoal = goal
runtime.currentState = "running"
const result = await llm.invoke(goal)
runtime.currentState = "finished"
return result
}
}
页面绑定：
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
因为最终用户需要的，从来不是按钮，而是结果。
