子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

随着大模型能力逐渐进入应用开发领域，越来越多开发者开始尝试把 AI 引入 App。但很多项目在实践中都会遇到一个问题：

AI 功能加进来了，但整个架构却越来越混乱。

常见的情况是：

• 在某个页面加一个 AI 聊天入口
• 在搜索页接入大模型
• 在客服模块接入智能问答

短期看，这些做法都能跑通功能。但随着业务增加，代码很快就会变得难以维护。

原因很简单：

AI 不是一个功能模块，而是一种新的应用架构。

如果仍然使用传统的 页面驱动架构，AI 的能力就无法真正发挥出来。

因此，如果希望构建真正的 AI Native（AI 原生）应用，架构设计需要从一开始就考虑 AI 的位置。

一、AI Native 应用架构的核心思想

在传统应用中，系统入口通常是 页面（Page）：

用户点击页面
     ↓
触发业务逻辑
     ↓
请求数据
     ↓
展示结果

而 AI Native 应用的入口则是 用户意图（Intent）：

用户输入
     ↓
AI 理解意图
     ↓
规划任务
     ↓
调用系统能力
     ↓
返回结果

也就是说：

传统应用 = UI 驱动
AI Native 应用 = AI 驱动

因此在架构设计上，需要引入一个新的核心模块：

Agent

二、AI Native 鸿蒙应用的整体架构

一个比较清晰的 AI Native 架构通常包含以下几个层级：

UI Layer
Agent Layer
Tool Layer
Service Layer
Data Layer

整体流程：

用户输入
   ↓
Agent（意图识别）
   ↓
Tool（能力接口）
   ↓
Service（业务逻辑）
   ↓
Repository / Data
   ↓
返回结果

这种架构的关键是：

AI 不再只是调用接口，而是成为整个系统的调度中心。

三、Agent 层：系统调度中心

Agent 层负责整个系统的核心逻辑：

• 意图识别
• 任务拆解
• 工具调用
• 结果整合

可以把 Agent 理解为：

系统的大脑

简单示例：

export class Agent {

  async run(input: string) {
    const intent = await this.parseIntent(input)

    if (intent === "searchFlight") {
      return await flightTool.execute()
    }

    if (intent === "checkWeather") {
      return await weatherTool.execute()
    }
  }

}

Agent 的作用是根据用户输入，决定调用哪个能力。

四、Tool 层：让 AI 可以调用系统能力

AI 本身无法直接操作业务逻辑，因此需要一个 Tool 层。

Tool 的作用是：

把应用能力暴露给 AI

例如：

查询订单
搜索航班
获取天气
推荐商品

每个能力都可以封装成一个 Tool，示例：

export class WeatherTool {

  async execute(city: string) {
    return await weatherService.getWeather(city)
  }

}

这样 AI 就可以通过 Tool 调用系统能力。

五、Service 层：业务能力模块

Service 层负责真正的业务逻辑，例如：

订单服务
搜索服务
推荐服务
用户服务

示例：

export class OrderService {

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

}

需要注意的一点是：

Service 不应该依赖 UI。

这样才能让 AI、Web、App 等不同入口复用这些能力。

六、数据层设计

数据层主要负责：

网络请求
缓存管理
数据库访问

例如：

export class OrderRepository {

  async fetchOrders() {
    return await http.get("/orders")
  }

}

Repository 的作用是：

统一数据来源

避免不同模块重复请求数据。

七、UI 层：从“功能入口”变成“交互界面”

在 AI Native 架构中，UI 的角色会发生变化。传统应用：

UI = 功能入口

AI Native 应用：

UI = 交互界面

用户可能通过：

• 聊天界面
• 语音输入
• 搜索框

触发 AI，示例：

@Entry
@Component
struct ChatPage {

  @State message: string = ""
  @State reply: string = ""

  agent: Agent = new Agent()

  async send() {
    this.reply = await this.agent.run(this.message)
  }

}

UI 只负责输入和展示结果。

八、工程目录设计示例

一个 AI Native 鸿蒙应用的目录结构可以设计为：

entry
 ├─ pages
 │
 ├─ components
 │
 ├─ agent
 │   ├─ agent_service
 │   ├─ intent_parser
 │   └─ task_planner
 │
 ├─ tools
 │   ├─ weather_tool
 │   ├─ order_tool
 │   └─ search_tool
 │
 ├─ services
 │
 ├─ repository
 │
 ├─ models
 │
 └─ utils

这种结构有几个优点：

• AI 能力集中管理
• 业务服务清晰
• 模块之间解耦

九、设计 AI Native 架构的关键原则

在设计 AI Native 应用时，有几个重要原则。

1 能力模块化

系统能力必须拆成独立模块：

SearchService
OrderService
PaymentService

这样 AI 才能灵活组合。

2 UI 与业务解耦

不要把业务逻辑写在页面里：

Page → Service

而应该：

Page → Agent → Service

3 工具化系统能力

每个系统能力都应该有对应 Tool：

WeatherTool
OrderTool
SearchTool

4 引入任务规划机制

复杂任务需要：

任务拆解
步骤执行
结果整合

例如：

订机票

AI 可能执行：

查询航班
推荐时间
确认信息
提交订单

总结

AI Native 应用与传统应用最大的区别在于：

AI 不再只是一个功能，而是应用架构的核心。

传统应用架构：

UI → Service → Data

AI Native 架构：

User Input
   ↓
Agent
   ↓
Tool
   ↓
Service
   ↓
Data

这种架构能够让应用具备：

• 更灵活的任务执行能力
• 更强的能力组合能力
• 更好的扩展性

随着 AI 技术的发展，未来很多应用很可能都会从：

Page Driven

逐渐转向：

Agent Driven

这也意味着：

AI Native 架构，很可能会成为下一代鸿蒙应用的重要设计模式。