子玥酱
（掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案， 在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化 内容平台：掘金、知乎、CSDN、简书 创作特点：实战导向、源码拆解、少空谈多落地 文章状态：长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨ 👋 如果你正在做前端，或准备长期走前端这条路 📚 关注我，第一时间获取前端行业趋势与实践总结 🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构） 💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。 愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- 一、Page First架构的问题
- 二、Agent First的核心思想
- 三、Intent Center设计
- 四、Task成为业务核心
- 五、Runtime层设计
- 六、鸿蒙为什么适合Agent Runtime
- 七、推荐项目结构
- 总结
引言
过去几年，鸿蒙 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 架构真正值得关注的技术价值。
