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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

过去二十年，桌面软件一直遵循一个固定模式：

用户操作
    ↓
应用响应
    ↓
界面更新

无论是：

• Office
• IDE
• 浏览器
• 企业管理系统

本质都属于：

Application Driven

即：

应用驱动用户完成任务。

但随着大模型与 Agent 技术的发展，软件架构正在发生新的变化：

User
   ↓
AI
   ↓
Application

越来越多情况下，用户不再直接操作应用。

而是：

告诉 AI 目标

由 AI 负责：

• 理解任务
• 调度能力
• 组织流程
• 执行操作

这意味着：

软件交互入口正在从 App 转向 Agent。

而鸿蒙 PC 的 Workspace 架构，恰好为这种演进提供了天然基础。

一、为什么 Agent 必须理解 Workspace

先看一个真实场景，用户正在鸿蒙 PC 上同时进行：

• 编写需求文档
• 查看 AMS 系统设计稿
• 阅读接口文档
• 回复企业微信消息
• 调试审批流代码

这时候用户说：

帮我整理当前审批流需求

问题来了，AI 如何知道：

• 当前需求文档是哪一个？
• 哪个窗口正在工作？
• 哪个项目是当前项目？
• 哪份设计稿与当前任务相关？

如果没有 Workspace 概念，AI 实际看到的只有：

帮我整理当前审批流需求

这几乎没有任何上下文，因此：

传统 Chat AI
=
无状态 AI

而真正可用的 Agent 必须拥有：

Workspace Awareness

即：

工作区感知能力。

二、Workspace Runtime 才是真正的上下文来源

很多团队设计 AI 时，首先想到的是：

聊天记录

实际上真正有价值的是：

运行时状态

例如：

interface WorkspaceState {

  currentProject: string

  currentTask: string

  activeWindow: string

  openedFiles: string[]

  selectedContent: string

}

AI Runtime 实际读取的应该是：

Workspace State

而不是：

Chat History

因为聊天记录描述的是：

用户说过什么

Workspace 描述的是：

用户正在做什么

后者价值远远更高。

三、Agent Runtime 核心架构设计

真正的鸿蒙 PC Agent 通常会拆成四个核心模块：

Workspace Runtime
        ↓
Context Engine
        ↓
Agent Scheduler
        ↓
Tool Runtime

分别承担不同职责。

Workspace Runtime

负责：

• 维护工作区状态
• 维护窗口关系
• 管理任务生命周期
• 管理跨设备状态

例如：

class WorkspaceRuntime {

  currentWorkspaceId: string = ""

  activeTaskId: string = ""

  activeWindowId: string = ""

}

这里保存的是：

系统状态

而不是：

页面状态

Context Engine

负责上下文构建。例如：

class ContextEngine {

  async buildContext() {

    return {
      task: runtime.activeTaskId,
      file: runtime.activeFile,
      summary: await memory.summarize()
    }

  }

}

这里最重要的是：

上下文裁剪

否则，随着工作时间增长：

Token
无限增长

最终推理成本失控。

Agent Scheduler

调度器是整个 Agent 的核心。例如，用户输入：

生成 AMS 项目测试计划

Scheduler 会执行：

理解目标
     ↓
拆解任务
     ↓
调用工具
     ↓
生成结果

任务结构：

interface AgentTask {

  id: string

  goal: string

  status: string

  dependencies: string[]

}

未来复杂场景甚至可能变成：

Agent Network

多个 Agent 协同完成任务。

Tool Runtime

负责管理工具能力。例如：

文件读取
数据库查询
搜索服务
系统通知
代码生成

统一抽象：

interface Tool {

  name: string

  execute(input: any): Promise<any>

}

所有工具注册到 Runtime：

toolManager.register(new FileTool())
toolManager.register(new SearchTool())
toolManager.register(new NotifyTool())

这样 Agent 就具备：

行动能力

而不只是：

生成文本

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

很多 Agent 产品目前仍然运行在浏览器中。但浏览器存在天然限制：

无法感知系统状态
无法获取窗口关系
无法控制应用能力

而鸿蒙 PC 不同。其核心能力包括：

• 分布式软总线
• Workspace 管理
• 多窗口体系
• 系统级服务
• 应用间协同

这些能力天然适合作为：

Agent Runtime 底座

因此未来的鸿蒙 PC 更可能形成：

Workspace
      ↓
Agent Runtime
      ↓
System Capability

的系统级架构。

五、一个企业级 Agent 实战案例

假设用户正在开发 AMS 系统。当前 Workspace 包含：

需求文档
接口文档
设计稿
源码工程
测试计划

用户输入：

帮我生成审批流测试方案

Agent Runtime 执行：

读取需求文档
      ↓
读取接口定义
      ↓
分析业务流程
      ↓
生成测试用例
      ↓
输出测试方案

整个过程中：用户无需打开多个页面。Agent 直接从 Workspace 获取全部上下文。

这才是真正意义上的：

Workspace Native Agent

六、未来演进方向

未来鸿蒙 PC Agent 很可能经历：

Chat Assistant
        ↓
Tool Assistant
        ↓
Workspace Assistant
        ↓
Agent Runtime
        ↓
System AI

最终，AI 不再是一个应用。而会成为：

系统级运行时

持续理解：

• 用户目标
• 工作区状态
• 任务上下文
• 跨设备环境

并主动帮助用户完成任务。

总结

过去的软件时代：

用户操作应用

未来的软件时代：

用户描述目标
AI 操作系统

而鸿蒙 PC Workspace 架构的价值就在于：它让 AI 不再停留在聊天窗口中。

而是真正进入：

Workspace Runtime

成为系统的一部分，从这个角度看：未来鸿蒙 PC 最大的变化，可能不是新的 UI。

而是：

Agent 开始成为新的操作入口。