鸿蒙 PC 正在诞生“第二操作系统”：Agent Runtime 架构揭秘

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

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

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

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

引言

过去四十年，PC 软件一直遵循一个非常稳定的架构：

用户 ↓ 操作系统 ↓ 应用程序 ↓ 完成任务

无论是：

• Windows
• macOS
• Linux

本质上都属于：

OS First

操作系统负责：

• 进程管理
• 内存管理
• 文件管理
• 设备管理

而应用负责：

• 文档编辑
• 浏览器访问
• 视频播放
• 企业业务

这套模式运行了几十年，直到 AI 出现。越来越多开发者开始发现：

用户真正想要的，从来不是打开 App。

而是：

完成任务

例如：

帮我写周报 帮我整理会议纪要 帮我分析日志 帮我完成审批流配置

用户描述的是：

Goal

而不是：

Application

这意味着：整个软件架构正在发生一次巨大的迁移。

一、传统操作系统正在遇到一个新问题

过去，用户知道：

任务在哪个软件里完成

例如：

写文档 → Word 做表格 → Excel 发邮件 → Outlook 写代码 → IDE

所以：

用户 ↓ 应用 ↓ 任务

逻辑完全成立，但 AI 时代开始不同。用户越来越习惯：

直接说目标

例如：

整理本周项目进展 生成测试方案 统计审批通过率 分析线上异常

这时候用户已经不关心：

打开哪个 App

而关心：

结果什么时候出来

这意味着：

App

正在失去入口地位。

二、为什么 Agent Runtime 会成为新的入口

先看传统架构：

Application ↓ Business ↓ Data

每个 App：

• 自己维护状态
• 自己管理任务
• 自己管理数据

结果就是：

任务被困在应用里

例如，用户正在：

• 微信聊天
• 浏览需求
• 查看设计稿
• 编辑代码

实际上这是一个完整工作流：

需求 ↓ 设计 ↓ 开发 ↓ 测试

但系统无法理解，因为：

状态被切碎

分散在不同 App 里面。而 Agent Runtime 出现以后：

Workspace ↓ Agent Runtime ↓ Applications

Agent 开始站在 App 之上。

三、什么是“第二操作系统”

很多人第一次听到 Agent Runtime 时会觉得：

不就是 AI SDK 吗？

实际上完全不是。真正的 Agent Runtime 更像：

系统级运行时

例如，传统操作系统管理：

CPU Memory File Network

而 Agent Runtime 管理：

Task Context Memory Tool Workspace

你会发现，二者职责已经非常接近。例如：

OS 调度

Process Scheduler

负责：

哪个进程先执行

Agent Runtime 调度

Task Scheduler

负责：

哪个任务先执行

例如：

生成需求文档 ↓ 生成接口设计 ↓ 生成测试方案 ↓ 生成发布计划

整个流程自动调度。

四、鸿蒙 PC 为什么特别适合 Agent Runtime

这里是最关键的一点，很多 Agent 产品现在运行在：

Browser

或者：

Electron

内部。存在天然问题：

拿不到系统状态 无法理解窗口关系 无法理解工作区 无法跨设备同步

而鸿蒙 PC 本身拥有，Workspace 概念。例如，当前工作区：

AMS项目 需求文档 接口文档 测试计划 开发代码

这些状态天然存在于系统之中。这意味着，Agent Runtime 可以直接感知。用户正在做什么，而不是猜测。

五、Agent Runtime 的核心架构

完整 Runtime 通常包含：

┌──────────────────┐ │ Workspace Layer │ └────────┬─────────┘ ↓ ┌──────────────────┐ │ Context Engine │ └────────┬─────────┘ ↓ ┌──────────────────┐ │ Agent Scheduler │ └────────┬─────────┘ ↓ ┌──────────────────┐ │ Tool Runtime │ └────────┬─────────┘ ↓ ┌──────────────────┐ │ System Runtime │ └──────────────────┘

每层职责完全不同。

六、Workspace Layer

负责维护：

interfaceWorkspace{workspaceId:stringcurrentTask:stringactiveWindow:stringopenedFiles:string[]}

这里保存的是：

当前工作状态

例如：

正在开发 AMS 当前查看审批流代码 当前打开测试方案

这才是真正的上下文。

七、Context Engine

很多团队做 AI 时，把所有内容直接塞给模型。结果：

Token 暴涨

成本爆炸，所以需要：

Context Engine

例如：

classContextEngine{asyncbuildContext(){constworkspace=workspaceStore.snapshot()constmemory=awaitmemoryStore.recall()returnmerge(workspace,memory)}}

最终送给模型的是：

最有价值的上下文

而不是：

全部历史数据

八、Agent Scheduler 实现

Scheduler 是整个 Runtime 的核心。例如，用户输入：

生成 AMS 测试方案

Runtime 会自动拆解：

读取需求 ↓ 分析接口 ↓ 生成测试点 ↓ 生成测试用例 ↓ 输出方案

代码结构：

interfaceAgentTask{id:stringgoal:stringstatus:string}

调度器：

classScheduler{asyncexecute(task:AgentTask){}}

未来甚至可能变成：

Multi-Agent Runtime

多个 Agent 协同工作。

九、Tool Runtime 实战

Agent 最大区别在于：

不仅能思考 还能行动

因此必须具备 Tool Runtime，例如：

interfaceTool{name:stringexecute(params:object):Promise<any>}

文件工具：

classFileToolimplementsTool{asyncexecute(params){}}

数据库工具：

classDatabaseToolimplementsTool{asyncexecute(params){}}

注册：

toolRegistry.register(newFileTool())toolRegistry.register(newDatabaseTool())

Agent 获得：

执行能力

十、鸿蒙 Agent Runtime Demo

创建全局 Runtime：

@ObservedexportclassAgentRuntime{currentGoal:string=""currentTask:string=""state:string="idle"}

实例：

exportconstruntime=newAgentRuntime()

执行器：

exportclassAgentExecutor{asyncrun(goal:string){runtime.currentGoal=goal runtime.state="running"constresult=awaitllm.invoke(goal)runtime.state="finished"returnresult}}

ArkUI 页面：

@Componentstruct AgentPanel{build(){Column(){Text(runtime.state)Text(runtime.currentGoal)}}}

这里 UI 不管理业务，只负责：

投影 Runtime 状态

十一、未来会发生什么

未来几年可能出现一个非常有趣的架构演进：

OS ↓ Application

逐渐变成：

OS ↓ Agent Runtime ↓ Application

甚至进一步演化成：

User ↓ Goal ↓ Agent Runtime ↓ System ↓ Application

此时，App 不再是入口，Agent Runtime 才是入口。

十二、总结

如果一句话总结：

为什么说鸿蒙 PC 正在诞生“第二操作系统”？

因为未来真正重要的管理对象已经发生变化。

过去操作系统管理：

进程 文件 设备 网络

未来 Agent Runtime 管理：

任务 上下文 记忆 工具 工作区

过去：

用户操作 App

未来：

用户描述目标 Agent 调度 App

而鸿蒙 PC 的 Workspace、多设备协同、分布式能力和系统级 Runtime 天然具备构建 Agent Runtime 的土壤。

最终你会发现：未来鸿蒙 PC 最重要的创新，可能不是新的窗口系统。也不是新的 UI 框架。

而是：

Agent Runtime

这个运行在操作系统之上的“第二操作系统”。