在这里插入图片描述

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

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

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

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

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


文章目录

引言

过去几十年，整个操作系统领域有一个默认共识：

Scheduler
=
CPU Scheduler

无论是：

  • Linux CFS
  • Windows Scheduler
  • macOS XNU
  • Android

本质上解决的问题都只有一个：

哪个线程运行？
运行多久？
运行在哪个 CPU Core？

于是整个软件世界形成了一套经典模型：

Application
      ↓

Process
      ↓

Thread
      ↓

Scheduler
      ↓

CPU

几十年来，这套模型几乎没有变化。因为过去的软件核心对象始终是：

Process

CPU Scheduler 调度线程 ➡️ 线程驱动程序 ➡️ 程序完成任务。

这一切看起来天经地义，但 AI Native 时代，一个新的问题开始出现：

用户真正运行的，真的是 Thread 吗？

答案可能是否定的，因为今天的软件世界正在出现越来越多新的对象：

Goal

Task

Workspace

Context

Tool

Agent

这些对象既不属于 Process，也不属于 Thread。但却越来越决定整个软件系统如何运行。

于是，一个新的调度层开始出现。而 HarmonyOS PC，很可能正在提前演示这种变化。

一、过去四十年，Scheduler 调度的是资源

传统系统：

Process
      ↓

Thread
      ↓

CPU Scheduler
      ↓

CPU

Scheduler 的职责非常明确：

时间片分配

Time Slice

优先级调度

Priority

上下文切换

Context Switch

多核负载均衡

Load Balance

例如 Linux CFS，内部维护：

struct sched_entity {

    u64 vruntime;

};

核心目标只有一个：

公平使用 CPU

Windows Scheduler 同样如此，整个 Scheduler 本质上属于：

Resource Scheduler

即：

资源调度器

它关心的是：

Thread

而不是：

用户目标

二、用户真正运行的，从来不是 Thread

假设当前正在开发一个审批流系统，桌面同时打开：

  • DevEco Studio
  • 浏览器
  • 企业微信
  • 数据库客户端
  • API 文档
  • AI 助手

操作系统看到：

400+ Threads

CPU Scheduler 正在不停调度：

Thread-21

Thread-78

Thread-135

但用户感知到的只有：

开发审批流模块

用户不会说：

暂停 Thread-21

用户说的是：

帮我生成测试计划

对于用户来说，真正持续存在的对象是：

Goal

而不是：

Thread

于是，出现了一种天然的不匹配：

Kernel
看到：

Thread

用户看到：

Task

这也是传统调度模型越来越难描述 AI Native 软件的原因。

三、Thread Scheduler 无法描述复杂任务

传统线程之间：

Thread A

Thread B

Thread C

彼此独立，但一个 AI 工作流可能是：

读取需求文档
      ↓

分析接口定义
      ↓

生成测试用例
      ↓

生成报告
      ↓

发送通知

形成：

Task DAG

例如：

interface Task {

    id: string

    priority: number

    dependencies: string[]

}

真正重要的已经不是：

CPU Time Slice

而是：

Dependency

因为：

Task2 必须等待 Task1

Task4 必须等待 Task3

CPU Scheduler 根本无法理解：

Task Graph

它只知道：

Thread Ready Queue

这意味着：

Thread Scheduler
<
Task Scheduler

新的调度层开始出现。

四、AI Native 软件真正需要的是 Goal Scheduler

假设用户输入：

生成审批流测试方案

内部实际上发生：

Goal
 ↓

Planner
 ↓

Task Graph
 ↓

Tool Runtime
 ↓

Execution

例如：

Task1

读取需求文档

↓

Task2

分析接口

↓

Task3

生成测试用例

↓

Task4

输出 Markdown

↓

Task5

发送通知

这里真正需要调度的是：

1、任务优先级 Priority

2、依赖关系 Dependency

3、错误恢复 Retry

4、Context Memory

5、Tool：File Tool、Search Tool、LLM Tool

这些东西，Thread Scheduler 完全不知道。

于是，一种新的调度器开始出现：

Agent Scheduler

五、Agent Scheduler 正在诞生

传统：

Scheduler
 ↓

Thread
 ↓

CPU

未来：

Goal
 ↓

Planner
 ↓

Task Graph
 ↓

Agent Scheduler
 ↓

Tool Runtime
 ↓

Kernel Scheduler
 ↓

CPU

这里有两个 Scheduler：

Kernel Scheduler

负责：

CPU

Memory

IO

调度对象：

Thread

属于：

Resource Runtime

Agent Scheduler

负责：

Goal

Task

Context

Tool

调度对象：

Task Graph

属于：

Goal Runtime

这意味着，CPU Scheduler 不再是整个系统唯一的大脑。

六、Workspace Runtime 正在成为调度基础

但 Agent Scheduler 并不是孤立存在，它依赖：

Workspace Runtime

维护：

interface WorkspaceState {

    currentProject:string

    currentTask:string

    activeFiles:string[]

    activeWindows:string[]

}

例如当前 Workspace：

AMS 工程

设计稿

需求文档

测试计划

用户输入：

生成测试方案

Scheduler 首先读取：

Workspace Context

自动获得：

当前项目

当前文件

当前任务

然后：

Planner
 ↓

Task Graph
 ↓

Agent Scheduler
 ↓

Tool Runtime

整个执行过程不再依赖：

Chat History

而依赖：

Workspace State

因此，真正的上下文来源开始从：

Conversation

变成：

Runtime

七、HarmonyOS PC 为什么特别适合这种架构

很多 Agent 产品运行在浏览器里，但浏览器最大的问题是：

无法理解系统状态

而 HarmonyOS PC 拥有：

1、Workspace 维护状态。

2、多窗口系统 维护上下文。

3、分布式软总线 维护设备关系。

4、System Service 提供统一能力。

5、ArkUI Runtime 维护组件树。

6、Agent Runtime 组织 Goal。

最终形成：

Workspace Runtime
        ↓

Context Engine
        ↓

Planner
        ↓

Agent Scheduler
        ↓

Tool Runtime
        ↓

Kernel Scheduler
        ↓

CPU

整个系统开始从：

Resource OS

进入：

Goal OS

时代。

八、未来可能存在“双调度系统”

这是最值得关注的一点，未来操作系统可能存在两层 Scheduler。

第一层，Kernel Scheduler：

CPU

Memory

Thread

第二层，Agent Scheduler：

Goal

Task

Tool

Action

形成：

Goal
 ↓

Agent Scheduler
 ↓

Task
 ↓

Kernel Scheduler
 ↓

Thread
 ↓

CPU

CPU Scheduler 并没有消失，但它正在逐渐退居到底层。

真正决定系统行为的开始变成：

Goal Scheduler

这和四十年来：

CPU Scheduler
=
系统大脑

的时代完全不同。

九、HarmonyOS PC 真正想重写的，也许是 Scheduler

很多人认为 HarmonyOS PC 想挑战的是：

Windows

macOS

但桌面 UI 并不难复制，真正难复制的是：

Runtime

而 Runtime 的核心，恰恰是：

Scheduler

过去调度：

Thread

未来调度：

Task

过去优化：

CPU 利用率

未来优化：

Goal Completion

过去：

Kernel 决定执行

未来：

Planner + Agent Scheduler
决定执行

总结

过去四十年：

Scheduler
=
CPU Scheduler

未来十年，系统可能出现：

Kernel Scheduler

+

Agent Scheduler

过去：

Thread
=
执行对象

未来：

Task
=
执行对象

过去：

资源决定行为

未来：

目标决定行为

所以，线程调度还够吗？答案是：

对资源调度来说，够。

但对于 AI Native 软件来说，仅有 Thread Scheduler 已经不够。因为未来真正需要调度的，可能不再是线程。而是：

Goal

Task

Tool

Context

而这，也许才是 HarmonyOS PC Runtime 演进过程中最值得关注的一次系统级变化。

因为下一代操作系统竞争的核心，可能不再是谁拥有更强的 CPU Scheduler。

而是谁能够构建：

Agent Scheduler
+
Workspace Runtime
+
Goal Runtime

这或许才是 AI Native OS 真正的开始。

# harmonyos # 华为
Logo
HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

鸿蒙7亲密圈怎么用？家人状态一眼就知道

微信群是“对话式”的，你不说话就不知道对方在干嘛。亲密圈是“状态式”的，不需要说话就能感知对方的状态。想说话的时候说话，不想说话的时候看一眼状态就够了。不是刻意聊天，而是一种“我在想着你”的轻社交表达，特别适合家庭成员之间的日常互动。亲密圈的状态共享基于鸿蒙安全体系，所有状态信息在端侧处理，不会泄露给第三方。比如你可以让父母看到你的出行状态，但只让伴侣看到心情状态。不用打开微信问“你在干嘛”，抬手

avatar HarmonyOS开发者社区

鸿蒙闪控球功能评测：盯盘抢单搜题记账等一步直达

闪控球把路径缩短成一步——点击悬浮球，直接抵达。同花顺、东方财富等接入闪控球后，点击悬浮球即可直接查看自选股行情和涨跌信息，不用打开App再切换到自选页面。淘宝、京东等购物应用接入闪控球，限时秒杀时点击悬浮球直接进入活动页面，比打开App再找入口快好几秒。作业帮等学习应用接入闪控球，点击悬浮球直接启动拍照搜题，不用退出当前App再打开搜题应用，搜完题继续做笔记，学习流程不被打断。记账应用接入闪控球

avatar HarmonyOS开发者社区

鸿蒙开发 Column 垂直布局详解

在 HarmonyOS ArkTS 开发中，Column 是最基础、使用频率最高的垂直布局容器，所有子组件会按照从上到下的顺序垂直排列，页面绝大多数表单、长列表、登录页、详情页都会以 Column 作为根布局。给子组件设置layoutWeight(1)，代表自动瓜分父容器剩余垂直高度；layoutWeight 不生效：父布局未设置固定宽高，或子组件同时写了固定高度；注意：使用权重时，父 Colum

avatar HarmonyOS开发者社区