网罗开发 （小红书、快手、视频号同名）

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

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

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

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

引言

过去几年，大模型接入 App 的方式其实非常简单：

输入问题
 ↓
调用 API
 ↓
返回答案

很多鸿蒙项目也是这样做的：

const result = await llm.chat(prompt)

然后把结果展示到页面，看起来：

AI 已经接入成功

但很快你会发现：

只能聊天
不能做事

例如用户说：

帮我预约今天下午的课程

AI 返回：

您可以点击课程页面进行预约

用户会觉得：

那我为什么要问你？

真正的 AI 助手应该是：

用户说需求
 ↓
AI理解意图
 ↓
调用业务能力
 ↓
完成任务
 ↓
返回结果

而不是：

用户提问
 ↓
AI聊天
 ↓
结束

所以：

AI 助手不是一个聊天窗口，而是一套新的应用架构。

一、为什么普通 AI 聊天框没有价值

很多项目的第一版：

ArkUI
 ↓
LLM API
 ↓
Answer

例如：

Button("发送")
  .onClick(async () => {

    const result =
      await llm.chat(input)

    this.answer = result

  })

架构：

UI
 ↓
Model
 ↓
Text

问题，AI 永远只能：

说

不能：

做

所以：

无法和业务结合

最终变成：

一个套壳 ChatGPT

二、真正的 AI 助手架构

推荐结构：

UI
 ↓
Assistant
 ↓
Intent Engine
 ↓
Task Center
 ↓
Tool Center
 ↓
System
 ↓
Repository

这里：

Assistant

成为整个应用的新入口。

三、第一层：Assistant Runtime

Assistant 是整个 AI 助手的大脑，职责：

理解用户
管理上下文
调度任务

示例：

export class Assistant {

  async run(text: string) {

    const intent =
      await this.parseIntent(text)

    return await taskCenter.run(intent)

  }

}

调用：

await assistant.run(
  "帮我预约英语课程"
)

四、第二层：Intent Engine

Intent Engine 负责：

把自然语言
变成结构化命令

例如，用户输入：

帮我购买英语四级课程

转换：

{
  "intent": "buy_course",
  "course": "英语四级"
}

示例：

class IntentEngine {

  async parse(text: string) {

    return await llm.chat(`
      提取用户意图:
      ${text}
    `)

  }

}

整个 AI 应用最关键的一步：

不是生成答案，而是识别意图。

五、第三层：Task Center

很多开发者喜欢：

AI直接调用业务代码

这是错误的，正确方式：

AI
 ↓
Task
 ↓
业务能力

例如：

class BuyCourseTask {

  async run(params) {

    return await courseTool.buy(
      params.courseId
    )

  }

}

统一入口：

await taskCenter.run(
  "BuyCourseTask"
)

这样：

业务流程标准化

六、第四层：Tool Center

这是 AI Native 架构里最重要的一层，很多团队会这样写：

orderStore.orders = []

AI 直接修改数据，问题：

无法审计
无法控制权限

正确做法：

await orderTool.cancel(id)

示例：

export class OrderTool {

  async cancel(
    orderId: string
  ) {

    return await orderSystem
      .cancel(orderId)

  }

}

Tool 的本质：

AI 与业务之间的隔离层

七、鸿蒙 App 中如何设计 Tool

推荐目录：

tools/
 ├── user
 ├── order
 ├── payment
 ├── course
 └── message

例如：

tools/
 └── order/
      ├── CancelOrderTool
      ├── QueryOrderTool
      └── CreateOrderTool

示例：

export class QueryOrderTool {

  async execute(id: string) {

    return await repository.find(id)

  }

}

这样：

AI 能力标准化

八、鸿蒙 ArkUI 接入助手

页面层应该非常轻，例如：

@State question: string = ""
@State answer: string = ""

Column() {

  TextInput({
    text: this.question
  })

  Button("发送")
    .onClick(async () => {

      this.answer =
        await assistant.run(
          this.question
        )

    })

  Text(this.answer)

}

这里页面不知道：

任务怎么执行
工具怎么调用
模型怎么推理

只负责：

输入
输出

九、增加 Memory

如果没有记忆：

每次都是新对话

例如，用户：

帮我查订单

AI：

哪个订单？

用户：

昨天那个

AI：

无法理解

因为：

上下文丢失

Memory 架构

Assistant
 ↓
Memory
 ↓
LLM

示例：

class MemoryStore {

  history: string[] = []

  add(message: string) {
    this.history.push(message)
  }

}

调用：

await assistant.run(
  text,
  memoryStore.history
)

十、增加 State

AI Native App 必须管理状态，例如：

当前任务
当前订单
当前用户

推荐：

AssistantState

示例：

class AssistantState {

  currentTask?: string

  currentIntent?: string

  taskStatus?: string

}

这样：

任务执行过程可追踪

十一、一个完整课程助手实战

用户：

帮我推荐专升本课程

流程：

Assistant
      ↓
Intent Engine
      ↓
RecommendCourseTask
      ↓
CourseTool
      ↓
CourseRepository
      ↓
Result

代码：

const intent =
  await intentEngine.parse(text)

const result =
  await taskCenter.run(intent)

return result

整个系统：

完全任务化

十二、AI Native 鸿蒙 App 的推荐目录

src
├── assistant
│    ├── runtime
│    ├── intent
│    ├── memory
│    └── state
│
├── task
│    ├── order
│    ├── payment
│    └── course
│
├── tools
│    ├── order
│    ├── user
│    └── payment
│
├── system
│
├── repository
│
├── store
│
└── ui

这是比较适合的结构是：

AI Native 鸿蒙 App

十三、为什么未来会从页面驱动变成助手驱动

传统 App：

页面
 ↓
按钮
 ↓
功能

AI Native App：

意图
 ↓
Assistant
 ↓
Task
 ↓
结果

例如，过去：

打开订单页
点击取消
确认取消

未来：

帮我取消昨天的订单

AI 自动完成，这里最大的变化是：

页面不再是入口。

而是：

Assistant 成为入口。

十四、结合鸿蒙分布式能力

鸿蒙最大的优势：

多设备协同

例如，手机：

发起任务

平板：

查看执行过程

PC：

继续处理结果

因此：

AssistantState

应该支持：

分布式同步

结构：

Phone
   ↓
AssistantState
   ↓
Pad
   ↓
PC

未来：

AI 助手是跨设备存在的

而不是：

只存在某个页面

十五、总结

如果用一句话总结：

鸿蒙 App 集成 AI 助手，不是在页面里放一个聊天框，而是在应用内部增加一个新的 Runtime。

过去：

用户操作功能

未来：

用户表达意图

过去：

页面驱动业务

未来：

Assistant 驱动业务

过去：

App = UI + Service

未来：

App
 = UI
 + State
 + Task
 + Tool
 + Assistant Runtime

很多开发者接入 AI 后，看到模型能够回复内容，就觉得已经完成了 AI 化。

但真正的 AI Native 鸿蒙应用，目标从来不是：

让 AI 会聊天

而是：

让 AI 会做事

记住一句话：

聊天框只是入口，

Assistant Runtime 才是核心。

当你的鸿蒙 App 开始拥有：

• Intent Engine
• Memory Engine
• Task Center
• Tool Center
• Assistant State
• 分布式 Assistant Runtime

你会发现：

AI 不再是一个功能模块，

而开始成为整个鸿蒙 App 的新基础设施。