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

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

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

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

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

引言

过去四十年，整个软件世界有一个默认共识：

Process
=
运行对象

Thread
=
执行对象

无论：

• Windows
• Linux
• Android
• macOS

系统真正调度的始终是：

Thread

于是整个软件架构形成了经典模型：

Application
      ↓

Process
      ↓

Thread
      ↓

CPU

几十年来，这套模型几乎没有变化。

因为过去的软件核心非常简单：

用户打开 App
↓
执行功能
↓
退出 App

Thread 足够描述整个运行过程，但 AI Native 软件时代，一切开始发生变化。

今天的软件越来越多地出现：

• Agent
• Workflow
• Long Task
• Tool Calling
• Workspace
• Context

这时候，一个新的问题出现了：

Thread 真的是用户感知的运行对象吗？

答案可能是否定的。因为用户真正关心的，从来不是：

Thread-1

Thread-2

Thread-3

而是：

完成任务

于是，一个新的执行模型开始出现。

一、Thread 本质解决的是资源执行

传统线程：

while(true){

    execute();

}

系统调度：

Thread
↓
CPU Scheduler
↓
CPU

Thread 的职责非常明确：使用 CPU ➡️ 执行代码 ➡️ 切换上下文 ➡️ 消耗资源

因此：

Thread
=
Execution Unit

线程解决的是：

如何运行

而不是：

为什么运行

这也是 Thread 最大的局限。

二、用户真正运行的，其实是 Task

假设当前正在开发一个审批流系统。Workspace 中同时存在：

• DevEco Studio
• 接口文档
• 数据库工具
• 企业微信
• 测试计划
• AI Assistant

操作系统看到：

300+ Threads

但是用户真正只有一个目标：

完成审批流测试方案

整个过程包含：

读取需求
↓
分析接口
↓
生成测试用例
↓
生成报告
↓
发送邮件

用户感知的是：

Task

而不是：

Thread

这意味着：

Task Boundary
>
Process Boundary

任务边界已经开始超过应用边界。

三、Thread 无法描述复杂依赖关系

线程之间：

Thread A

Thread B

Thread C

彼此独立，但 AI Workflow 更像：

Task1
读取需求
      ↓

Task2
分析接口
      ↓

Task3
生成测试用例
      ↓

Task4
输出报告

形成：

Task Graph

例如：

interface Task {

    id:string

    priority:number

    dependencies:string[]

}

真正重要的是：

Dependency

而不是：

Time Slice

因为：

Task3 必须等待 Task2

Task2 必须等待 Task1

这已经不是 Thread Scheduler 能够描述的问题。

四、Task 开始成为新的执行对象

未来系统可能变成：

Goal
 ↓

Planner
 ↓

Task Graph
 ↓

Task Runtime
 ↓

Thread Pool
 ↓

CPU

注意，Thread 并没有消失，只是位置发生变化。

过去：

Thread
=
执行对象

未来：

Thread
=
资源载体

真正持续存在的是：

Task

例如：

interface RuntimeTask {

    id:string

    goal:string

    context:any

    state:string

}

Task 可以：

1、暂停

Suspend

2、恢复

Resume

3、跨设备迁移

Transfer

4、持续数小时

Long Running

这些能力，Thread 很难天然支持。

五、HarmonyOS PC 为什么需要 Task Runtime

过去：

状态属于页面

例如：

@Component
struct ChatPage {

    @State messages = []

}

页面关闭：

State 消失

但未来，任务可能持续：

• 数小时
• 多窗口
• 多应用
• 多设备

例如，当前 Workspace：

AMS工程

需求文档

设计稿

数据库

用户关闭 DevEco Studio 重新打开。

任务不应该消失：

生成测试方案

因此，真正持续存在的应该是：

Task

而不是：

Page

于是：

Workspace Runtime
↓
Task Runtime
↓
Thread Pool

开始出现。

六、Agent Runtime 正在成为新的执行层

传统执行：

Thread
↓
CPU

未来：

Goal
↓

Planner
↓

Task Graph
↓

Agent Scheduler
↓

Tool Runtime
↓

Thread Pool
↓

CPU

真正执行的是：

1、File Tool

2、Search Tool

3、LLM Tool

4、Notification Tool

Thread 只是底层资源，高层执行权开始上移：

Agent Runtime

这越来越像：

Task Kernel

而不是：

Chat Assistant

七、未来可能存在双执行系统

未来系统会有两层执行对象。

第一层，Kernel：

Process

Thread

CPU

负责：

Resource Runtime

第二层，Agent Runtime：

Goal

Task

Context

Tool

负责：

Goal Runtime

形成：

Goal
 ↓

Task
 ↓

Thread
 ↓

CPU

因此：

Task
>
Thread

不是因为 Thread 消失。而是，Thread 开始退化成资源层。

八、HarmonyOS PC 真正想重写的，也许是执行模型

很多人认为，HarmonyOS PC 在挑战：

• Windows
• macOS

其实更深层的竞争是：

Execution Model

过去：

Thread
=
执行对象

未来：

Task
=
执行对象

过去优化：

CPU 利用率

未来优化：

Goal Completion

过去：

Kernel Scheduler
决定执行

未来：

Planner
+
Agent Scheduler
决定执行

于是，软件系统开始从：

Resource OS

进入：

Goal OS

时代。

总结

过去四十年：

Thread
=
Execution Unit

未来十年，真正持续存在的对象可能变成：

Task

过去：

线程驱动程序

未来：

任务驱动程序

过去：

资源决定行为

未来：

目标决定行为

所以，Task 会取代 Thread 吗？答案是：

不会。

但 Thread 会越来越退居到底层资源层。

而 Task，正在成为 AI Native Runtime 世界新的执行对象。

这或许才是 HarmonyOS PC 新执行模型背后最值得关注的变化。

因为未来软件真正运行的，可能不再是线程。而是：

Task。