网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、为什么 Process 已经无法描述 AI Native 软件二、Goal 为什么会成为新的 Runtime Object三、为什么 Goal 最终一定会变成 Graph四、Goal Graph 才是真正的 Runtime 核心五、Planner 真正操作的是 Goal Graph六、Goal Graph 如何连接整个 Runtime七、为什么 Goal Graph 必须 Event Driven八、HarmonyOS PC 为什么特别适合 Goal Graph总结引言过去四十多年操作系统一直围绕一个核心对象运行ProcessWindows、Linux、macOS 的底层模型几乎一致Application ↓ Process ↓ Thread ↓ CPU整个 Runtime 管理的是ProcessThreadMemoryFileSocket所以过去的软件开发本质上都是围绕Application Runtime展开的。但是大模型和 Agent 的出现正在改变这一切。今天越来越多用户不再告诉电脑打开 IDE 打开浏览器 打开数据库而是直接说帮我开发审批流模块 帮我生成测试方案 帮我完成版本发布用户关心的已经不是某一个 App而是Goal也就是说AI Native 时代真正持续运行的对象已经从 Process 变成了 Goal。而 Goal Graph正是 HarmonyOS PC 为此构建的新一代任务运行模型。一、为什么 Process 已经无法描述 AI Native 软件过去一个软件几乎等同于一个 Process。例如Chrome ↓ Process ↓ 关闭浏览器 ↓ Process 结束整个生命周期非常简单。但是今天一个开发任务往往会持续数小时甚至数天。例如开发审批流开发者会同时打开DevEco Studio浏览器企业微信API 文档数据库GitAI 助手操作系统看到的是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 中持续存在的对象。例如interfaceGoal{id:stringpriority:numberstatus:GoalStatus workspaceId:stringcontextId:stringdependencies: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 更合理的数据结构应该是interfaceGoalNode{id:stringchildren:string[]dependencies:string[]contextId:stringworkspaceId:stringtaskIds:string[]status:GoalStatus}整个 Runtime 都围绕 Goal Graph 工作Goal Graph ↓ Planner ↓ Task Graph ↓ Scheduler ↓ Tool Runtime ↓ ExecutionGoal Graph 不只是保存任务它还维护当前 Goal当前 Context当前 Workspace当前 Tool当前执行状态Task 之间的依赖关系因此它更像整个 Runtime 的执行地图。五、Planner 真正操作的是 Goal Graph很多人认为 Planner 的工作就是Prompt ↓ LLM ↓ Answer实际上并非如此真正的 Planner 更像操作系统中的 Scheduler。例如Goal ↓ Planner ↓ Goal Graph ↓ Task Graph ↓ ExecutionPlanner 每次都会判断哪些任务已经完成哪些任务失败哪些任务可以继续执行是否需要重新规划因此 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 RuntimeGoal 可以跨应用、跨设备持续存在。这也是 AI Native 操作系统最大的不同。总结过去四十年操作系统运行的核心对象一直是Process因此 Runtime 关注的是Thread Memory CPUAI 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的关键一步。