鸿蒙 App 接入 AI 后，架构为什么会被改写

这类代码放在页面里很顺手，拿出来就不对了。AI 没法复用，测试也不好拆。

最后只能重构：把业务逻辑从页面里抽出去，让页面只负责展示和交互。

四、把能力服务化，才算真正开始复用

我先拆的是订单这类能力。

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

拆完之后，UI 和 AI 都可以直接调用同一个能力：

await orderService.getOrders(userId)

这时候结构就清楚多了。App 不再是'几个页面拼起来'，而是'几个能力拼起来'。页面只是其中一个消费方。

五、再往上一层，加 Tool 才能让 AI 真正调用能力

很快又遇到一个现实问题：AI 并不知道该调用哪个 Service，也不知道参数该怎么组。于是中间多了一层 Tool。

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

AI 只需要面向 Tool，不必关心底层是接口、数据库还是缓存。这样一来，架构变成了 AI → Tool → Service。

这层抽象不算优雅，但很实用。尤其是当后面能力越来越多的时候，AI 直接碰 Service 往往会很乱。

六、复杂任务把 Agent 推了出来

当用户开始说'帮我查订单，再推荐相关商品'，事情就不再是一个接口能解决的了。这里需要先理解意图，再拆成多个步骤，最后把几个能力串起来。

于是 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 展示。

很多场景下，UI 甚至不参与流程本身，只负责最后那一下呈现。它还重要，但不再是入口。

八、数据流也变了

传统数据流通常是 UI → Service → Data → UI。

接入 AI 之后，更像是：用户输入 → AI → Service → Data → UI。

差别看起来只是箭头顺序变了，实际影响很大。数据流不再由页面触发，而是由意图触发。页面从'发起者'变成了'接收者'。

九、真正变化的是思维方式

做完这一轮重构后，我最深的感受不是代码量变了，而是思考问题的方式变了。

以前会先想：这个页面怎么排版？按钮放哪里？流程怎么走最顺？

现在先想的是：用户会怎么说？系统怎么识别意图？哪些能力能复用？任务要怎么拆？

这不是小修小补，而是从'页面中心'转到'能力中心'。

十、我最后得到的结论

如果只用一句话概括，这次改动不是给鸿蒙 App 加了一个 AI 功能，而是把它从页面应用推向了能力系统。

这个变化不是概念上的包装，是真会落到代码结构里的。你会开始重构 Service，补 Tool，考虑 Agent 的编排方式，最后连 UI 都要重新找位置。

结语

一开始只是想给鸿蒙 App 加一个 AI 功能，最后却把整个架构都改了。我的经验是，别把 AI 当成一个挂在页面上的按钮，它更像新的系统入口。早点按这个思路设计，后面少很多返工；如果继续沿用老的页面中心模型，代码很快就会散掉，扩展也会越来越别扭。