网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、Thread Scheduler 为什么已经不够用了二、AI Native Runtime 真正调度的是 Task三、为什么 Task 一定会形成 Graph四、Task Graph 如何驱动整个 Runtime五、Task Scheduler 与 CPU Scheduler 有什么不同六、Task Graph 为什么必须支持动态重规划七、HarmonyOS PC 为什么特别需要 Task Graph八、Task Graph 只是开始未来还会出现 Runtime Graph总结引言过去几十年操作系统解决的核心问题一直都是如何调度 CPUWindows 有 Scheduler、Linux 有 CFSCompletely 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 开始维护interfaceTask{id:stringgoalId:stringpriority:numberdependencies: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每新增一个 GoalPlanner 都会生成对应的 Task Graph。Scheduler 并不是简单地按顺序执行。而是实时分析哪些 Task 已完成哪些 Task 被阻塞哪些 Task 可以并行哪些 Task 需要重新规划整个过程类似传统操作系统的调度器只不过调度对象已经从 Thread 升级为 Task。五、Task Scheduler 与 CPU Scheduler 有什么不同两者解决的是完全不同的问题。CPU SchedulerTask 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 GraphHarmonyOS PC 正在构建Workspace RuntimeContext EngineGoal PlannerAgent SchedulerTool Runtime这些模块之间需要一个统一的执行中心Task Graph 正好承担这一角色。例如Workspace │ ▼ Context Engine │ ▼ Goal Planner │ ▼ Task Graph │ ▼ Task Scheduler │ ▼ Tool Runtime │ ▼ Execution EngineTask Graph 保存的不只是任务还保存Task Dependencies依赖关系Execution State执行状态Retry Policy重试策略Priority优先级Workspace Binding工作区绑定Context Binding上下文绑定因此它更像 Runtime 中的任务控制中心。八、Task Graph 只是开始未来还会出现 Runtime GraphTask 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 时代重新定义任务运行模型的重要一步。