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

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

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

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

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

引言

过去几十年，操作系统解决的核心问题一直都是：

如何调度 CPU？

Windows 有 Scheduler、Linux 有 CFS（Completely Fair Scheduler）、macOS 也有自己的线程调度器。它们共同完成一件事情：

Thread
      ↓
CPU

哪个线程先运行？哪个线程暂停？哪个线程抢占 CPU？整个系统都围绕 Thread 展开，所以过去的软件架构通常都是：

Application
      ↓
Process
      ↓
Thread
      ↓
CPU Scheduler

这种模型在传统软件时代几乎没有问题，因为那个时代：

一个 Thread
≈
一项工作

但是 AI Native 软件时代发生了一个根本变化，AI 已经不是执行一段代码。而是在完成一个目标，例如：

生成审批流模块

它背后可能包含几十个甚至上百个子任务，这时候真正需要调度的对象已经不是 Thread，而是：

Task

这也是为什么，未来 HarmonyOS PC 更需要的是 Task Scheduler，而不是更复杂的 CPU Scheduler。

一、Thread Scheduler 为什么已经不够用了？

来看一个传统线程模型，例如：

下载文件

系统可能创建：

Main Thread
        ↓
Network Thread
        ↓
IO Thread

操作系统负责：

CPU 时间片

线程切换

抢占

同步

所有事情都围绕 Thread 进行。但是 AI Agent 的执行过程完全不同。

例如用户输入：

帮我完成审批流开发

系统真正执行的是：

需求分析
↓

数据库设计
↓

接口生成
↓

权限设计
↓

代码实现
↓

单元测试
↓

生成文档

这里没有任何一个步骤对应某一个 Thread，真正需要管理的是：

任务之间的关系

因此：

Thread Scheduler

已经无法表达 AI 的执行过程。

二、AI Native Runtime 真正调度的是 Task

过去：

CPU Scheduler

负责回答：

哪个线程先执行？

未来：

Task Scheduler

负责回答：

哪个任务先完成？

例如：

Goal

↓

Task A
数据库设计

↓

Task B
接口生成

↓

Task C
测试生成

这里 Task B 必须等待：

Task A

完成。

Task C 又依赖：

Task B

这已经不是线程依赖。

而是：

业务依赖

因此 Runtime 开始维护：

interface Task {

    id: string

    goalId: string

    priority: number

    dependencies: string[]

    status: TaskStatus

}

真正调度的是：

Task Graph

而不是 Thread Queue。

三、为什么 Task 一定会形成 Graph？

很多人第一次设计 Agent 时，会把任务拆成一棵树：

Goal

├── Task A

├── Task B

└── Task C

但是现实开发并不是这样，例如：

生成接口

需要：

数据库设计

权限模型

而：

生成测试

又需要：

接口设计

业务流程

需求文档

多个任务之间，存在大量共享节点。最终形成：

        Goal

      /  |   \

 TaskA TaskB TaskC

    \     |    /

      Context

          |

        Tool

真正的数据结构变成：

Task Graph

而不是：

Task Tree

四、Task Graph 如何驱动整个 Runtime？

未来 HarmonyOS PC 的执行流程，更接近下面这种架构：

Goal
      │
      ▼
Goal Planner
      │
      ▼
Task Graph
      │
      ▼
Task Scheduler
      │
      ▼
Tool Runtime
      │
      ▼
Execution Engine

每新增一个 Goal，Planner 都会生成对应的 Task Graph。Scheduler 并不是简单地按顺序执行。

而是实时分析：

• 哪些 Task 已完成？
• 哪些 Task 被阻塞？
• 哪些 Task 可以并行？
• 哪些 Task 需要重新规划？

整个过程类似传统操作系统的调度器，只不过调度对象已经从 Thread 升级为 Task。

五、Task Scheduler 与 CPU Scheduler 有什么不同？

两者解决的是完全不同的问题。

CPU Scheduler	Task Scheduler
调度 Thread	调度 Task
管理 CPU 时间片	管理任务生命周期
关注资源利用率	关注目标完成率
毫秒级切换	秒级甚至分钟级执行
Kernel 调度	Agent Runtime 调度

CPU Scheduler 关注：

资源是否充分利用？

Task Scheduler 更关注：

目标是否能够完成？

这意味着未来 Runtime 不只是资源调度系统，更是：

目标执行系统

六、Task Graph 为什么必须支持动态重规划？

传统程序代码写好以后，执行路径几乎固定。但是 AI 不一样。

例如：

生成接口代码

过程中，发现：

数据库字段发生变化。

那么整个执行流程必须重新规划，例如：

Task Graph

↓

Dependency Update

↓

Planner

↓

重新生成 Task

↓

Scheduler

↓

继续执行

Task Graph 并不是静态图，而是一张持续变化的动态图。

这也是 AI Runtime 与传统 Runtime 最大的区别。

七、HarmonyOS PC 为什么特别需要 Task Graph？

HarmonyOS PC 正在构建：

• Workspace Runtime
• Context Engine
• Goal Planner
• Agent Scheduler
• Tool Runtime

这些模块之间需要一个统一的执行中心，Task Graph 正好承担这一角色。

例如：

Workspace
      │
      ▼
Context Engine
      │
      ▼
Goal Planner
      │
      ▼
Task Graph
      │
      ▼
Task Scheduler
      │
      ▼
Tool Runtime
      │
      ▼
Execution Engine

Task Graph 保存的不只是任务，还保存：

• Task Dependencies（依赖关系）
• Execution State（执行状态）
• Retry Policy（重试策略）
• Priority（优先级）
• Workspace Binding（工作区绑定）
• Context Binding（上下文绑定）

因此，它更像 Runtime 中的"任务控制中心"。

八、Task Graph 只是开始，未来还会出现 Runtime Graph

Task Graph 并不是终点，随着 Agent 能力不断增强，Runtime 还需要维护更多对象：

Goal
Task
Context
Memory
Tool
Workspace
Device

未来这些对象之间会形成一张更大的运行图：

Runtime Graph

其中：

• Goal Graph 描述目标之间的关系。
• Task Graph 描述执行过程。
• Context Graph 描述上下文关联。
• Tool Graph 描述能力调用。
• Memory Graph 描述长期记忆。

Task Graph 是连接这些图的执行层，也是 Agent Runtime 的核心组成部分。

总结

过去四十年，操作系统最重要的调度器一直都是：

CPU Scheduler

它解决的是：

Thread 如何运行？

AI Native 时代，真正需要解决的问题已经变成：

Task 如何完成？

因此，未来的 Runtime 不会只维护 Thread Queue，而会维护一张持续演化的 Task Graph。

过去：

Scheduler
调度 Thread。

未来：

Scheduler
调度 Task。

从 Thread Scheduler 到 Task Scheduler，看似只是调度对象发生了变化，实际上意味着操作系统开始从资源调度（Resource Scheduling）迈向目标调度（Goal Scheduling）。

而这，也正是 HarmonyOS PC 在 AI Native 时代重新定义任务运行模型的重要一步。