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

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

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

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

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

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

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

引言

过去几年，鸿蒙 App 的主流架构基本都围绕以下展开：

Page
Store
Service

典型结构：

UI
 ↓
Store
 ↓
Repository
 ↓
Network

这种架构在传统业务场景下没有问题，例如：

• 电商
• 教育
• 社交
• OA

因为用户行为通常是：

打开页面
 ↓
点击按钮
 ↓
执行功能

整个系统本质上属于，Page First 架构。但 AI 开始进入 App 后，系统开始出现新的挑战。

例如：

帮我整理今天会议

帮我完成报销

帮我生成周报

这些需求已经不是：

单页面功能

而是：

跨模块任务

此时传统 Page First 架构开始失效。

一、Page First架构的问题

传统鸿蒙项目：

Page
 ↓
Store
 ↓
System

例如：

Button("提交")
  .onClick(() => {
      orderStore.submit()
  })

执行链路：

页面
 ↓
Store
 ↓
System
 ↓
Repository

这种结构有一个前提：

页面是业务入口。

但是AI时代：

用户输入一句话

可能触发：

订单模块
消息模块
日历模块
设备模块

多个领域协同，例如：

帮我完成出差申请

可能涉及：

审批
 ↓
机票
 ↓
酒店
 ↓
日历
 ↓
消息通知

这时候：

页面已经无法承担入口职责

二、Agent First的核心思想

Agent First并不是：

增加一个聊天页面

而是：

引入统一任务入口

结构变成：

User
 ↓
Intent
 ↓
Task
 ↓
Runtime
 ↓
Domain

这里，Intent负责：

理解用户需求

Task负责：

业务流程编排

Runtime负责：

资源调度

Domain负责：

具体能力实现

三、Intent Center设计

Intent 是 Agent Runtime 的入口。例如，用户输入：

帮我整理今天会议

系统不会直接调用模型，而是先进入：

Intent Center

示例：

export interface Intent {

  name: string

  confidence: number

}

识别器：

class IntentClassifier {

  async classify(
    query: string
  ): Promise<Intent> {

  }

}

输出：

{
  name: "MeetingSummaryIntent",
  confidence: 0.95
}

这样：

模型能力
与
业务能力
开始解耦

四、Task成为业务核心

这是很多团队最容易忽略的部分。传统：

页面驱动业务

未来：

Task驱动业务

例如：

export interface Task {

  execute(): Promise<void>

}

会议总结：

class MeetingSummaryTask
  implements Task {

}

报销申请：

class ExpenseTask
  implements Task {

}

Agent Runtime只负责：

调度Task

不负责：

实现业务

这样：

系统扩展能力极强

五、Runtime层设计

真正的Agent First项目一定会出现：

Runtime

这一层，推荐结构：

runtime/
 ├── intent/
 ├── planner/
 ├── scheduler/
 ├── task/
 ├── memory/
 ├── tool/
 └── agent/

各模块职责，ntent/ 负责：

意图识别

planner/ 负责：

任务规划

例如：

出差申请
 ↓
审批任务
 ↓
订票任务
 ↓
同步任务

拆分为多个Task。scheduler/ 负责：

任务调度

例如：

串行
并行
优先级
重试

memory/ 负责：

长期上下文

例如：

用户偏好
历史任务
设备信息

tool/ 负责：

工具调用

例如：

Calendar
Message
Map
Payment

六、鸿蒙为什么适合Agent Runtime

因为鸿蒙天然具备：

跨设备能力

例如：

Phone
Pad
PC
Watch

Agent执行任务时：

Task
 ↓
Runtime
 ↓
DeviceManager

可以自动选择：

最合适设备

例如：

文档编辑
→ PC

运动提醒
→ Watch

导航
→ Phone

这实际上已经接近，分布式 Agent 模型。

七、推荐项目结构

未来Agent First鸿蒙项目推荐：

app/
 ├── ui/
 ├── state/
 ├── intent/
 ├── runtime/
 ├── task/
 ├── domain/
 ├── distributed/
 └── infrastructure/

相比传统：

page/
service/
util/

结构，更加适合 AI Native 应用。

总结

如果用一句话总结 Agent First：

Agent First 不是交互升级，而是架构升级。

传统鸿蒙 App：

Page
 ↓
Function

未来鸿蒙 AI App：

Intent
 ↓
Task
 ↓
Runtime
 ↓
Domain

真正的变化不是：

增加一个聊天框

而是：

引入一个新的系统核心

这个核心就是：

Agent Runtime

未来鸿蒙 AI Native App 的竞争力，很可能不再来自：

• 页面数量
• 功能数量
• 组件数量

而来自：

• Intent能力
• Task编排能力
• Runtime调度能力
• 多设备Agent协同能力

这才是 Agent First 架构真正值得关注的技术价值。