网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括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 的终极形态总结引言过去十几年无论是AndroidiOSWebHarmonyOS应用开发的核心逻辑始终没有变用户点击 ↓ 触发事件 ↓ 更新状态 ↓ 刷新页面本质上UI 驱动业务整个系统围绕页面运转。例如Page ↓ ViewModel ↓ Service ↓ Data用户永远是系统唯一的驱动者。但是随着大模型、Agent、Workspace Runtime 的出现一个新的问题开始出现。很多时候用户并不想操作页面用户真正想做的是完成目标例如帮我生成报销申请 帮我整理会议纪要 帮我完成审批配置 帮我分析异常日志此时用户关心的是Goal而不是Page这意味着App 的架构中心开始从页面转向智能体。而这正是 AI Native App 的本质。一、传统 App 架构为什么开始遇到瓶颈看一个典型鸿蒙 AppUI 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 ParsingTask PlanningTool CallingMemory ManagementContext 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 RuntimeSystem Runtime 负责文件 数据库 通知 搜索 设备能力 系统服务统一抽象exportinterfaceTool{name:stringexecute(params:object):Promiseany}例如exportclassFileToolimplementsTool{asyncexecute(params){}}统一注册toolRegistry.register(newFileTool())形成标准 Tool Ecosystem。八、鸿蒙 AI Native Runtime 实战首先定义全局 Runtime。ObservedexportclassAppRuntime{currentTask:stringcurrentGoal:stringcurrentState:stringidle}全局实例exportconstruntimenewAppRuntime()创建 Agent 执行器exportclassAgentExecutor{asyncexecute(goal:string){runtime.currentGoalgoal runtime.currentStaterunningconstresultawaitllm.invoke(goal)runtime.currentStatefinishedreturnresult}}页面绑定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因为最终用户需要的从来不是按钮而是结果。