Tool Graph：HarmonyOS PC 如何统一所有系统能力？

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- [一、为什么 Application 已经不是能力边界？](#一、为什么 Application 已经不是能力边界？)
- [二、Tool 为什么会成为 Runtime 的一等公民？](#二、Tool 为什么会成为 Runtime 的一等公民？)
- [三、为什么 Tool 最终一定会形成 Graph？](#三、为什么 Tool 最终一定会形成 Graph？)
- [四、Tool Graph 如何组织整个能力网络？](#四、Tool Graph 如何组织整个能力网络？)
- [五、Tool Runtime 如何驱动 Execution Graph？](#五、Tool Runtime 如何驱动 Execution Graph？)
- [六、为什么 Tool Graph 必须支持动态发现？](#六、为什么 Tool Graph 必须支持动态发现？)
- [七、HarmonyOS PC 为什么特别适合 Tool Graph？](#七、HarmonyOS PC 为什么特别适合 Tool Graph？)
- [八、Tool Graph 的终点不是 Tool，而是 Capability Graph](#八、Tool Graph 的终点不是 Tool，而是 Capability Graph)
- 总结

引言

过去二十多年，桌面操作系统一直遵循着同一种能力组织方式：

text 复制代码

Application
      ↓
Function
      ↓
System API

每一个应用，都拥有自己的功能。例如：

文件管理器负责文件操作
浏览器负责网页访问
IDE 负责代码编辑
企业微信负责消息通信

能力被封装在不同 App 中，如果需要完成一项复杂任务，用户只能不断切换应用：

text 复制代码

打开浏览器
      ↓
复制内容
      ↓
打开 Word
      ↓
编辑文档
      ↓
打开企业微信
      ↓
发送消息

整个桌面的核心是：

text 复制代码

Application Driven

应用决定用户能够完成什么。但 AI Native 时代，这种模式开始暴露出明显的问题。

用户越来越少关心：

text 复制代码

打开哪个 App？

而更多是在表达：

text 复制代码

我要完成什么？

例如：

text 复制代码

帮我整理今天的会议纪要，并发送给项目成员。

对于 AI 来说，这个目标涉及：

读取录音
调用语音识别
总结内容
生成文档
查询联系人
发送消息

整个过程需要跨越多个应用和系统服务。

这意味着，AI 真正需要调用的不是 App，而是能力。

因此，一个新的 Runtime 层开始出现：

text 复制代码

Tool Graph

它试图统一管理整个系统的能力，让 AI 从"调用应用"转向"调度能力"。

一、为什么 Application 已经不是能力边界？

过去，一个应用就是一个能力集合。例如：

text 复制代码

浏览器

提供：

HTTP 请求
下载
文件上传

IDE 提供：

编辑代码
编译
调试

这种模式没有问题，因为所有操作都由用户主动完成。

但 AI Native 场景不同。例如：

text 复制代码

帮我生成审批流测试方案，并提交到项目系统。

AI 需要：

text 复制代码

读取需求文档
        ↓
解析接口定义
        ↓
生成测试用例
        ↓
保存文档
        ↓
调用企业系统 API

这些能力来自多个 App，对于 AI 来说：

text 复制代码

Application
≠
Execution Unit

真正需要组织的是：

text 复制代码

Capability

因此，能力边界开始超过应用边界。

二、Tool 为什么会成为 Runtime 的一等公民？

很多开发者理解 Tool，只是一个函数调用。例如：

ts 复制代码

searchTool.execute()

实际上，在 AI Runtime 中，一个 Tool 更像一个可调度的系统能力。例如：

ts 复制代码

interface Tool {

    id: string

    name: string

    description: string

    permissions: Permission[]

    inputSchema: object

    outputSchema: object

    execute(input: any): Promise<any>

}

这里不仅包含执行逻辑，还包含：

能力描述
输入输出规范
权限控制
生命周期
可观测信息

这意味着 Tool 已经从普通 API，升级为 Runtime 的基础对象。

未来 Runtime 管理的不只是：

text 复制代码

Process
Thread
Memory

还包括：

text 复制代码

Tool

三、为什么 Tool 最终一定会形成 Graph？

如果只有几个 Tool，顺序调用即可：

text 复制代码

Read File
      ↓
LLM
      ↓
Save File

但真实企业场景远比这复杂。例如：

text 复制代码

生成周报

需要：

text 复制代码

读取 Git 提交记录
          │
读取 Jira 数据
          │
读取日志平台
          │
读取企业 IM 消息
          │
调用大模型总结
          │
生成 Word
          │
发送邮件

每个 Tool 都存在依赖关系。例如：

text 复制代码

生成 Word

必须等待：

text 复制代码

LLM 总结完成

发送邮件，必须等待：

text 复制代码

Word 导出完成

因此，Tool 之间天然形成：

text 复制代码

Tool Graph

而不是简单的调用链。

四、Tool Graph 如何组织整个能力网络？

Tool Graph 的核心思想是：

能力之间建立依赖关系，而不是应用之间建立调用关系。

例如：

text 复制代码

                Goal
                  │
             Planner
                  │
            Task Graph
                  │
        ┌─────────┼─────────┐
        │         │         │
 ReadFile   SearchAPI   Database
        │         │         │
        └─────────┼─────────┘
                  │
                 LLM
                  │
        ┌─────────┼─────────┐
        │         │         │
 SaveFile Notify ExportPDF

Planner 不再思考：

text 复制代码

启动哪个 App？

而是：

text 复制代码

下一步需要哪个 Tool？

Tool Graph 成为了整个 Runtime 的能力网络。

五、Tool Runtime 如何驱动 Execution Graph？

Execution Graph 中的每一个节点，本质上都对应一个 Tool。

例如：

text 复制代码

Task A
      │
      ▼
Read File Tool

Task B
      │
      ▼
Search Tool

Task C
      │
      ▼
Generate Tool

Task D
      │
      ▼
Notify Tool

Execution Graph 负责维护执行状态。Tool Graph 则负责维护能力关系。

二者共同组成：

text 复制代码

Task
        ↓
Execution Graph
        ↓
Tool Graph
        ↓
Execution Engine

Execution Graph 决定"什么时候执行"，Tool Graph 决定"调用什么能力"。

六、为什么 Tool Graph 必须支持动态发现？

传统软件所有 API 在编译时已经确定，但是 AI Runtime 不一样。未来系统能力会不断变化。

例如，今天安装：

text 复制代码

Git Tool

明天新增：

text 复制代码

Jira Tool

后天新增：

text 复制代码

企业 OA Tool

Planner 不需要修改代码，只需要重新扫描：

text 复制代码

Tool Registry

Runtime 即可自动更新：

text 复制代码

Tool Graph

因此，一个新的能力注册中心开始出现：

ts 复制代码

class ToolRegistry {

    register(tool: Tool)

    unregister(id: string)

    discover(): Tool[]

}

Tool Graph 由 Registry 动态构建，而不是写死在程序中。

这也是 AI Native Runtime 与传统插件系统最大的区别。

七、HarmonyOS PC 为什么特别适合 Tool Graph？

HarmonyOS PC 天然具备统一系统能力的优势，例如：

文件系统
分布式设备
多窗口管理
剪贴板
通知中心
系统搜索
跨设备流转

如果这些能力全部抽象为 Tool：

text 复制代码

Clipboard Tool
Camera Tool
Search Tool
Notification Tool
Distributed Device Tool

那么 Agent 就可以直接编排它们，而无需关心具体应用实现。

未来 HarmonyOS PC 更可能形成：

text 复制代码

Workspace Runtime
        │
Context Engine
        │
Goal Planner
        │
Task Graph
        │
Execution Graph
        │
Tool Graph
        │
System Capability

系统能力第一次真正成为 AI Runtime 的组成部分，而不是 App 私有能力。

八、Tool Graph 的终点不是 Tool，而是 Capability Graph

从架构演进来看，第一阶段：

text 复制代码

API

第二阶段：

text 复制代码

Service

第三阶段：

text 复制代码

Tool

未来很可能进入：

text 复制代码

Capability Graph

此时，Runtime 维护的不再只是工具，而是完整的能力网络：

text 复制代码

Goal
      │
Task
      │
Execution
      │
Capability
      │
Device
      │
Context

AI 调度的不再是某个 Tool，而是一组可以动态组合、动态替换、动态优化的能力集合。

Tool Graph 将逐渐演进为整个 AI Native Runtime 的能力底座。

总结

传统操作系统组织的是：

text 复制代码

Application

应用决定能力边界，而 AI Native 操作系统组织的是：

text 复制代码

Tool

能力成为新的运行对象。

Tool Graph 的意义，不是简单管理一组工具，而是在 Runtime 内建立统一的能力调度模型，使 Goal、Task、Execution 与 System Capability 建立直接联系。

从这个角度来看，HarmonyOS PC 真正想统一的，并不是应用，而是整个系统的能力网络。

未来，AI 不再需要知道"哪个 App 能完成任务"，它只需要理解"当前有哪些能力可用"，然后通过 Tool Graph 自动编排执行。

而当 Goal Graph、Task Graph、Execution Graph、Tool Graph 全部连接在一起时，一个真正的 AI Native Runtime 才算真正建立起来。