企业官网建设流程全解析

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、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

示例：

exportinterfaceIntent{name:stringconfidence:number}

识别器：

classIntentClassifier{asyncclassify(query:string):Promise<Intent>{}}

输出：

{name:"MeetingSummaryIntent",confidence:0.95}

这样：

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

四、Task成为业务核心

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

页面驱动业务

未来：

Task驱动业务

例如：

exportinterfaceTask{execute():Promise<void>}

会议总结：

classMeetingSummaryTaskimplementsTask{}

报销申请：

classExpenseTaskimplementsTask{}

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 架构真正值得关注的技术价值。