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

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

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

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

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

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

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

引言

过去十几年，前端框架几乎都在解决同一个问题：

如何组织页面？

1、React 引入 Component
2、Vue 引入 SFC
3、Flutter 引入 Widget
4、SwiftUI 引入 View。
5、ArkUI 引入声明式 Component。

虽然实现方式不同，但它们都有一个共同假设：

Component 是整个软件系统最重要的运行单元。

整个 Runtime 围绕 Component 构建：

Component
      ↓
State
      ↓
Render

因此过去十几年，我们讨论最多的是：

• Component 如何拆分？
• Component 如何通信？
• Component 如何复用？
• Component 如何管理 State？

几乎所有 UI 框架，都在不断优化 Component。

但是 AI Native 软件出现以后，一个新的问题开始暴露：

真正持续运行的对象，已经不是 Component。

这也是为什么，未来 HarmonyOS PC 很可能不仅要升级 ArkUI，而是重新定义整个 Component Runtime。

一、传统 Component 模型，本质上解决的是页面问题

先看 React，一个典型组件：

function UserCard() {
    return <Card />
}

Flutter：

class UserCard extends StatelessWidget {}

ArkUI：

@Component
struct UserCard {}

虽然语法不同，但是 Runtime 做的事情完全一致：

创建 Component
        ↓
建立 Component Tree
        ↓
维护 Component State
        ↓
Diff
        ↓
Render

整个生命周期始终围绕 Component 展开。

因此传统 UI Runtime 可以抽象成：

Component Runtime

它最大的职责只有两个：

管理状态

管理渲染

这也是过去二十年 UI 框架不断演进的方向。

二、AI Native 软件第一次打破了 Component 的生命周期

真正的问题来了，例如用户说：

帮我开发审批流模块

Agent 开始：

分析需求

↓

设计数据库

↓

生成接口

↓

生成代码

↓

生成测试

↓

提交 Git

整个过程可能持续：

2 小时

8 小时

2 天

期间，页面可能：

关闭

窗口可能：

切换

甚至，设备可能：

改变

但是任务不能结束，也就是说：

Goal 生命周期
>>
Component 生命周期

第一次整个软件真正持续存在的对象，已经不是：

Component

而是：

Goal

传统 Component Runtime 开始失效。

三、真正的问题不是组件，而是 State 放错了位置

很多开发者认为，未来 Component 最大的问题是：

渲染性能

实际上不是，真正的问题是：

State Ownership

过去：

@Component
struct ChatPage {

    @State
    messages: Message[]

}

State 属于：

Page

页面关闭：

State 消失

但是 AI Runtime 中，真正需要保存的是：

Goal

Task

Context

Execution

这些对象根本不应该属于页面，更合理的关系应该是：

Workspace Runtime

↓

State Runtime

↓

Component

Component 只是：

Projection

也就是 Runtime 的一个投影，State 真正属于 Runtime。

四、为什么 Component Tree 已经不够用了？

所有现代 UI 都有：

Component Tree

例如：

Page

├── Header

├── List

└── Footer

但是 AI Runtime 真正维护的是：

Goal Graph

Task Graph

Context Graph

Execution Graph

这些对象之间，全部都是：

Graph

而不是：

Tree

例如一个 Task，可能同时依赖：

多个 Goal

多个 Context

多个 Tool

Tree 根本无法表达这种关系。

因此未来真正组织系统的，已经不是：

Component Tree

而是：

Runtime Graph

Component Tree 只是，Runtime Graph 的一个渲染结果。

五、未来 Component 更像 Runtime 的观察者

传统：

State

↓

Component

↓

Render

未来：

Runtime

↓

Execution Graph

↓

Component

↓

Render

Component 不再拥有：

State

而是：

Subscribe Runtime

例如：

@Component
struct TaskPanel {

    @Observed
    executionGraph

}

真正更新的是：

Execution Graph

Component 只是：

Observer

这意味着，未来 Component Runtime 更接近：

Reactive Runtime

而不是：

Page Runtime

六、未来 HarmonyOS PC 为什么需要 Runtime Component？

未来的组件可能不再描述：

Button

List

Text

而开始描述：

Goal Panel

Task Timeline

Execution Monitor

Context Viewer

Agent Console

组件绑定的对象已经从：

State

升级为：

Runtime Object

例如：

Goal Runtime

Task Runtime

Execution Runtime

Context Runtime

真正运行的是 Runtime，Component 只是 Runtime 的可视化终端。

总结

过去二十年，整个 UI 世界都建立在一个默认前提之上：

Component 是运行时的中心。

因此，所有框架都在不断优化：

• Component Tree
• State
• Diff
• Render

但是 AI Native 软件第一次打破了这一假设，真正持续运行的对象已经变成：

Goal

Task

Context

Execution

而这些对象都拥有远远长于页面的生命周期，也具有复杂的图结构关系。

因此，未来 HarmonyOS PC 真正需要重写的，并不是 @Component 这个语法，也不是声明式 UI，而是 Component 与 Runtime 的关系。

新的架构更可能演进为：

Workspace Runtime
        ↓
Goal Graph
        ↓
Task Graph
        ↓
Execution Graph
        ↓
State Runtime
        ↓
Component Runtime
        ↓
Render Engine

在这套模型中，Component 不再是系统的中心，而是 Runtime 的观察者（Observer）和投影（Projection）。系统真正的核心，从页面树（Component Tree）转向运行图（Runtime Graph）。

这不仅是 UI 框架的一次升级，更意味着 HarmonyOS PC 正在从页面驱动架构（Page-Driven Architecture）迈向运行时驱动架构（Runtime-Driven Architecture）。

这也是 AI Native 操作系统与传统桌面系统最本质的架构差异。