HarmonyOS App 接入大模型后，架构为什么必须重构？

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

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

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

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

引言

过去一年，很多 HarmonyOS App 团队都在做同一件事：

给 App 接入大模型

实现方式通常也非常直接：

原有业务 ↓ 增加 AI 页面 ↓ 调用 LLM API

例如：

asyncaskAI(prompt:string){returnawaitllm.chat(prompt)}

功能很快就能跑起来，甚至一周内就能上线一个 AI 版本。很多团队会觉得：

AI 化已经完成了。

但项目运行三个月以后，问题开始集中爆发。例如：

AI 无法理解当前业务 上下文越来越混乱 会话历史越来越长 多页面状态无法共享 多设备体验完全割裂 Agent 能力无法扩展

于是团队开始不断打补丁：

增加 Prompt 增加缓存 增加数据库 增加记忆系统

结果：

系统越来越复杂

最后发现一个根本问题：

我们的问题不是模型不够聪明。

而是：

App 架构仍然停留在移动互联网时代。

一、传统 HarmonyOS App 架构是如何设计的

绝大多数项目都遵循类似结构：

UI Layer ↓ ViewModel ↓ Service ↓ Repository

例如：

HomePage ↓ HomeViewModel ↓ UserService ↓ ApiClient

用户操作：

点击按钮 ↓ 发起请求 ↓ 返回数据 ↓ 刷新页面

核心特点：

页面驱动

即 Page First 架构，在这种模式下：

@StatemessageList:Message[]=[]

状态天然属于页面，因为：

页面就是业务边界

过去完全成立。

二、大模型接入后，业务边界消失了

看一个真实案例，用户在教育 App 中，上午：

查看课程

下午：

练习题目

晚上：

让 AI 制定学习计划

对于传统架构来说，这是三个页面：

CoursePage PracticePage ChatPage

但对于 AI 来说，这是一个连续任务。因为 AI 需要知道：

学过什么 错过什么 当前进度 最近行为

这些信息：

分散在多个页面

于是出现第一个问题：

页面边界 ≠ 业务边界

这是 AI Native App 与传统 App 最大的区别。

三、为什么 State Management 开始失效

很多项目都有类似代码：

@Statemessages:Message[]=[]

或者：

@StatecurrentUser:User

这种设计在普通业务里没问题，因为：

状态生命周期 = 页面生命周期

但 AI 出现以后，情况变了。例如，用户问：

帮我总结最近学习情况

AI 需要访问：

课程记录 答题记录 考试记录 收藏记录 笔记记录

这些状态可能来自：

5个页面 10个组件 20个接口

因此：

State

已经不足以表达业务，真正重要的是：

Context

例如：

interfaceLearningContext{currentCourse:Course recentExercises:Exercise[]notes:Note[]mistakes:Question[]}

这里保存的已经不是：

页面状态

而是：

工作上下文

四、Agent 出现以后，系统开始进入 Runtime 时代

这是最关键的一步，过去：

用户点击 ↓ 系统执行

未来：

用户描述目标 ↓ Agent 执行

例如：

帮我生成本周学习计划

系统可能执行：

分析课程 ↓ 分析成绩 ↓ 分析学习时间 ↓ 生成计划

这已经不是：

一次请求

而是：

任务流

因此系统必须拥有：

Task Runtime

例如：

interfaceTask{id:stringgoal:stringstatus:stringcontext:Context}

Agent 不再处理：

页面事件

而是在处理：

任务生命周期

五、为什么 Workspace 会成为新的系统核心

很多团队把聊天记录当作上下文，实际上真正重要的是：

Workspace

例如，当前用户正在：

阅读课程 查看笔记 分析错题 生成计划

这些行为共同组成：

interfaceWorkspace{activeTask:Task currentCourse:Course currentContext:Context}

AI 真正需要读取的是：

Workspace Runtime

而不是：

Chat History

因为：

聊天记录描述的是： 用户说过什么 Workspace 描述的是： 用户正在做什么

后者价值远远更高。

六、HarmonyOS 为什么特别适合 AI Native App

传统移动 App：

App = 孤岛

但 HarmonyOS 天然拥有：

分布式能力 跨设备协同 统一账号体系 设备感知能力

例如，手机：

查看需求

PC：

编写代码

平板：

查看原型

AI 可以持续维护：

统一 Workspace

因此未来同步的不是：

页面

而是：

Context

甚至：

Agent Runtime

七、AI Native App 的四层 Runtime 架构

未来更合理的架构：

Workspace Runtime ↓ Context Runtime ↓ Agent Runtime ↓ Capability Runtime

Workspace Runtime

负责：

任务空间管理

维护：

目标 任务 工作区

Context Runtime

负责：

上下文聚合

统一收集：

用户行为 文件 业务数据 历史记录

Agent Runtime

负责：

任务拆解 计划生成 工具调度

例如：

Goal ↓ Plan ↓ Execute

Capability Runtime

统一封装：

文件系统 数据库 搜索 通知 系统服务

提供给 Agent 调用。

总结

很多团队认为：

AI 化 = 接入大模型

实际上：

接入模型 只是开始

真正的挑战是：

App 架构重构

从技术演进角度看，过去：

Page First

关注：

页面 状态 接口

未来：

Runtime First

关注：

Workspace Context Task Agent

当大模型开始理解上下文、当 Agent 开始执行任务、当 Workspace 开始承载工作流。HarmonyOS App 的核心将不再是页面，而是：

Runtime。