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

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

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

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

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

引言

过去四十多年，操作系统一直围绕一个核心对象运行：

Process

Windows、Linux、macOS 的底层模型几乎一致：

Application
      ↓
Process
      ↓
Thread
      ↓
CPU

整个 Runtime 管理的是：

• Process
• Thread
• Memory
• File
• Socket

所以过去的软件开发，本质上都是围绕 Application Runtime 展开的。

但是，大模型和 Agent 的出现，正在改变这一切。今天，越来越多用户不再告诉电脑：

打开 IDE
打开浏览器
打开数据库

而是直接说：

帮我开发审批流模块

帮我生成测试方案

帮我完成版本发布

用户关心的已经不是某一个 App，而是：

Goal

也就是说，AI Native 时代真正持续运行的对象，已经从 Process 变成了 Goal。

而 Goal Graph，正是 HarmonyOS PC 为此构建的新一代任务运行模型。

一、为什么 Process 已经无法描述 AI Native 软件？

过去，一个软件几乎等同于一个 Process。例如：

Chrome
    ↓
Process
    ↓
关闭浏览器
    ↓
Process 结束

整个生命周期非常简单。但是今天，一个开发任务往往会持续数小时甚至数天。

例如开发审批流，开发者会同时打开：

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

操作系统看到的是：

7 个 Process

但开发者真正正在完成的只有一个目标：

开发审批流

这个目标会跨越：

• 多个窗口
• 多个应用
• 多个 Workspace
• 多台设备

因此：

Task Boundary
>
Application Boundary

真正持续存在的已经不是 Process，而是 Goal。这也是传统 Runtime 开始遇到瓶颈的原因。

二、Goal 为什么会成为新的 Runtime Object？

很多人认为 Goal 只是：

一句 Prompt

实际上，一个 Goal 会经历完整生命周期。例如：

Goal
    ↓
Planner
    ↓
Task
    ↓
Tool
    ↓
Execution
    ↓
Feedback
    ↓
RePlanning

用户输入：

开发审批流模块

Planner 会自动拆解：

需求分析
      ↓
数据库设计
      ↓
接口设计
      ↓
代码生成
      ↓
测试验证
      ↓
部署上线

整个 Goal 会不断产生新的 Task。因此 Goal 不再是一段文本，而成为 Runtime 中持续存在的对象。

例如：

interface Goal {

    id: string

    priority: number

    status: GoalStatus

    workspaceId: string

    contextId: string

    dependencies: string[]

}

未来 Runtime 不仅需要管理 CPU 和 Thread，还需要管理：

Goal

Task

Context

Workspace

Tool

三、为什么 Goal 最终一定会变成 Graph？

很多 Agent Framework 最初都会把任务组织成一棵树：

Goal
  ├── Task A
  ├── Task B
  └── Task C

但真实的软件开发远比树复杂，例如：

生成接口

依赖：

需求文档
数据库设计

而：

生成测试

又依赖：

接口代码

数据库

权限模型

多个任务之间存在大量共享依赖，最终结构更像：

Goal
      │
 ┌────┼─────┐
 │    │     │
Task Task  Task
 │  ╲ │ ╱   │
 └────Context──┘
        │
      Tool

真正运行的已经不是 Tree，而是一张不断变化的：

Goal Graph

四、Goal Graph 才是真正的 Runtime 核心

未来 HarmonyOS PC 更合理的数据结构应该是：

interface GoalNode {

    id: string

    children: string[]

    dependencies: string[]

    contextId: string

    workspaceId: string

    taskIds: string[]

    status: GoalStatus

}

整个 Runtime 都围绕 Goal Graph 工作：

Goal Graph
        ↓
Planner
        ↓
Task Graph
        ↓
Scheduler
        ↓
Tool Runtime
        ↓
Execution

Goal Graph 不只是保存任务，它还维护：

• 当前 Goal
• 当前 Context
• 当前 Workspace
• 当前 Tool
• 当前执行状态
• Task 之间的依赖关系

因此，它更像整个 Runtime 的"执行地图"。

五、Planner 真正操作的是 Goal Graph

很多人认为 Planner 的工作就是：

Prompt
↓

LLM
↓

Answer

实际上并非如此，真正的 Planner 更像操作系统中的 Scheduler。

例如：

Goal
    ↓
Planner
    ↓
Goal Graph
    ↓
Task Graph
    ↓
Execution

Planner 每次都会：

• 判断哪些任务已经完成
• 哪些任务失败
• 哪些任务可以继续执行
• 是否需要重新规划

因此 Planner 操作的并不是 Prompt，而是整个 Goal Graph。

Prompt 只是入口，Goal Graph 才是真正的运行对象。

六、Goal Graph 如何连接整个 Runtime？

整个 Runtime 可以表示为：

Workspace Runtime
        ↓
Context Engine
        ↓
Context Cache
        ↓
Goal Graph
        ↓
Goal Planner
        ↓
Agent Scheduler
        ↓
Tool Runtime
        ↓
Execution Engine

其中 Context Engine 负责回答：

AI 当前看到了什么？

Context Cache 负责回答：

AI 当前记住了什么？

Planner 负责回答：

AI 下一步应该做什么？

而 Goal Graph 真正回答的是：

AI 当前正在完成什么？

它成为整个 Runtime 的唯一事实来源（Single Source of Truth）。

七、为什么 Goal Graph 必须 Event Driven？

传统应用通常采用：

用户点击
↓

更新 State

而 AI Native Runtime 不一样，Goal 会持续变化。

例如：

需求修改
↓

Goal 更新
↓

Planner 重新规划
↓

Scheduler 重新调度
↓

Tool 重新执行

整个 Runtime 都需要响应事件，因此 Goal Graph 必须采用：

Event
↓

Goal Graph Update
↓

Planner
↓

Scheduler
↓

Execution

这种事件驱动模型，才能支持长时间运行的 Agent。

八、HarmonyOS PC 为什么特别适合 Goal Graph？

浏览器中的 AI 最大的问题在于：

无法持续维护运行状态

而 HarmonyOS PC 拥有：

• Workspace
• 多窗口
• 分布式能力
• 系统级服务
• 持续运行的 Runtime

这些能力天然适合维护：

Goal Graph

未来，系统真正维护的不再是：

Window

而是：

Workspace
      ↓
Goal Graph
      ↓
Agent Runtime

Goal 可以跨应用、跨设备持续存在。这也是 AI Native 操作系统最大的不同。

总结

过去四十年，操作系统运行的核心对象一直是：

Process

因此 Runtime 关注的是：

Thread

Memory

CPU

AI Native 时代，真正持续运行的对象开始变成：

Goal

而一个 Goal 又会不断拆分、关联、恢复、演化，最终形成一张持续变化的：

Goal Graph

未来：

Scheduler
调度的不只是 Thread。

而是：

Goal。

过去：

Runtime
维护的是 Process。

未来：

Runtime
维护的是 Goal Graph。

从这个角度来看，HarmonyOS PC 真正想重写的，不只是桌面，不只是应用，也不只是 Agent。

它真正试图重构的，是整个软件世界运行了四十多年的任务运行模型（Task Runtime）。

而 Goal Graph，很可能就是 AI Native Runtime 最核心的数据结构，也是下一代操作系统从资源驱动（Resource Driven） 迈向 目标驱动（Goal Driven） 的关键一步。