构建 AI 鸿蒙应用：架构逻辑的转变

AI 根本调不了。

2 有些逻辑和 UI 强绑定

this.loading = true
this.orders = await api.get()
this.loading = false

AI 也用不了，于是我不得不重构：

把所有业务逻辑从页面里'抽出来'。

四、我开始把能力'服务化'

我做的第一步是：

拆 Service 

例如：

export class OrderService {
  async getOrders(userId: string) {
    return await api.get("/orders")
  }
}

然后 UI 和 AI 都调用：

await orderService.getOrders(userId)

这一刻变化很明显：

App 不再是页面集合，而是能力集合。

五、我又加了一层：Tool

很快我发现一个新问题，AI 并不知道该调用哪个 Service。

于是我加了一层：

Tool 

例如：

export class OrderTool {
  async execute(params) {
    return await orderService.getOrders(params.userId)
  }
}

AI 只需要：

调用 Tool 

而不用关心底层实现，这时候架构变成：

AI → Tool → Service 

六、我不得不引入'Agent'

再往后，问题又来了。用户输入开始变复杂：

帮我查订单，并推荐相关商品

这已经不是一个 Service 能完成的任务，我需要：

多个步骤
多个能力
组合执行

于是我引入了：

Agent 

示例：

export class Agent {
  async run(input: string) {
    const intent = await this.parse(input)
    if (intent === "order_and_recommend") {
      const orders = await orderTool.execute()
      const goods = await recommendTool.execute()
      return { orders, goods }
    }
  }
}

这时候我才彻底意识到：

AI 不只是调用接口，而是在'编排系统能力'。

七、UI 的地位明显下降了

以前：

UI = 核心 

现在：

AI = 核心
UI = 展示 

很多操作变成：

用户一句话
↓
AI 完成
↓
UI 展示结果 

甚至很多时候：UI 根本不参与流程

八、数据流也变了

传统数据流：

UI → Service → Data → UI 

现在变成：

用户输入
↓
AI
↓
Service
↓
Data
↓
UI（展示） 

变化很关键：

数据流不再由 UI 触发，而是由 AI 触发。

九、最大的变化，其实是'思维方式'

做完这个项目后，我最大的感受不是代码变了，而是：

思维方式彻底变了。

以前我在想：

这个页面怎么设计？
这个按钮放哪？
这个流程怎么走？

现在我在想：

用户会说什么？
系统怎么理解？
能力怎么组合？
任务怎么完成？

十、本质总结

如果用一句话总结这次变化：

我不再是在做'页面应用'，而是在做'能力系统'。

对比一下：

结语

一开始我只是想：

给鸿蒙 App 加一个 AI 功能

但最后我得到的是：

一个完全不同的应用架构。

如果你现在也在做 AI 鸿蒙 App，我给你一个建议：

不要把 AI 当成功能，而要当成系统入口来设计。

否则你很快就会遇到：

• 架构混乱
• 代码失控
• AI 能力无法扩展