从 WorkBuddy 到 DeepSeek Harness：开源构建跨桌面与移动端 AI 工作助手（排版优化版）

聊天机器人正在迅速变成“工作执行者”。过去，人们打开 AI 产品，输入问题，然后等待一段文字回答；现在，越来越多用户希望 AI 能够读取项目资料、整理文件、分析 Excel、生成 Word 和演示文稿、访问网页、运行脚本、调用企业系统，并在任务结束后交付一份能够直接使用的成果。

这也是 WorkBuddy 一类产品受到关注的原因。它们不再把大模型当作一个更聪明的搜索框，而是尝试把模型放进一个具备工具、权限、工作区、任务状态和成果交付能力的执行环境中。

如果准备开发类似产品，真正需要解决的并不只是“接入哪个模型”。开发者还要回答任务如何拆解、本地文件怎样授权、执行过程如何展示、Skills 与 MCP 怎样管理、手机和电脑如何协作，以及模型误删文件、泄露凭据或执行危险命令时应该如何防护。

本文围绕这些工程问题，拆解一款 WorkBuddy 类 AI 工作助手应有的产品结构，并讨论如何使用开源的 DeepSeek Harness、Electron、Capacitor 与 MCP/Skills 体系，搭建覆盖网页、桌面和移动端的技术方案。

说明： 本文基于截至 2026 年 9 月 28 日可获得的公开资料整理。DeepSeek Harness 仍处于开发者预览阶段，接口和实现可能继续变化，正式产品必须自行完成安全加固、测试和版本锁定。

一、WorkBuddy 类产品究竟是什么

根据 WorkBuddy 官方产品说明，这类产品的核心目标是让 AI 从“回答问题”升级为“完成工作”。表面上看，用户仍然是在对话框里输入需求，但后台发生的其实是一条由任务规划、文件读取、工具调用、权限审批和成果生成组成的执行链。

假设用户提出这样的需求：“请读取项目文件夹中的需求文档和会议纪要，整理本周进度，找出三项延期风险，并生成一份适合管理层汇报的 PPT。”普通聊天模型只能根据已放入上下文的内容生成文字；真正的工作助手则要把一句话转换成一组可执行、可观察和可恢复的步骤。

这条流程中，真正依赖模型推理的只是其中一部分。文件系统、格式解析、任务编排、状态持久化、错误恢复、审批和成果管理同样重要。缺少这些工程能力，产品就会退化成一个带有“正在思考”动画的聊天页面。

对话与任务入口。 用户需要用自然语言表达目标，也可能上传文件、粘贴链接、选择工作区和补充要求。对话负责沟通，任务系统则负责保存状态、执行步骤和最终产物，两者不能混为一谈。

Agent 运行时。 运行时维护会话上下文、调用模型、选择工具、接收工具结果、处理错误并判断任务是否完成。它相当于整个产品的执行内核。

工具与插件系统。 AI 必须通过受控工具访问文件、终端、浏览器、数据库、邮件、日历和企业 API。工具越多，能力越强，但攻击面和维护成本也越大。

工作区与成果系统。 用户需要知道 AI 被允许访问哪些目录、生成了哪些文件、旧版本在哪里，以及成果是否能够继续编辑。稳定的工作区和产物体系，是演示原型与长期产品之间的重要分界线。

权限、审批与审计。 读取文件、覆盖文件、删除目录、发送邮件和执行安装命令的风险完全不同。系统必须根据动作风险决定自动执行、请求确认或直接拒绝，并保存足够的审计记录。

跨端控制。 桌面端适合处理本地文件和复杂工具；手机端适合发起任务、查看状态、审批高风险动作和接收通知。两者共享任务，却不应该被设计成完全相同的运行环境。

二、有哪些可以二次开发的开源底座

“是否有开源框架”需要进一步拆分，因为完整产品、Agent 运行时、消息型个人助理和教学项目解决的是不同问题。

DeepSeek Harness。 它是 DeepSeek AI 开源的 Agent Harness，官方采用“一切皆插件”的设计并使用 MIT License。这里的 Harness 可以理解为让模型持续执行工作的运行环境：它把模型、会话、工具、插件、文件系统、沙箱、任务调度和界面组织在一起。开发者可以在此基础上接入模型提供商、长期会话、文件与终端工具、Skills、MCP 服务、子 Agent、后台任务、Web UI 和桌面壳。

MIT License 通常允许复制、修改、分发和商业使用，但仍需保留版权与许可声明。第三方依赖、模型 API、商业数据源和 SaaS 服务也有各自的费用与许可证，不能因为框架开源就默认全部免费。

WorkDSH。 这是基于 DeepSeek Harness 构建的社区工作平台，更接近可以直接运行和修改的产品形态。它适合用来验证项目工作区、Skill 管理、插件入口和页面布局，但早期社区项目变化较快，商用前仍要检查升级兼容、数据迁移、权限模型和依赖许可证。

OpenClaw。 它更强调本地个人助手、多消息渠道、Skills、自动化和跨设备体验。如果重点是从聊天软件下达任务、让助手长期在线或连接多个消息入口，它值得重点研究。企业办公工作台则还需要额外建设工作区隔离、组织权限、成果模板、审批流程和审计能力。

learn-workbuddy。 它以教程方式拆解 Agent Loop、工具调用、记忆、Sidecar、沙箱、审计和任务调度，非常适合理解系统内部机制。但教学项目与生产框架的目标不同，代码容易阅读并不代表安全性、性能和升级策略已经满足商业系统要求。

综合来看，想快速做出原型可以参考 WorkDSH；想建设长期执行底座应重点研究 DeepSeek Harness；想做跨消息渠道个人助理可以评估 OpenClaw；想从底层原理学习则可以阅读 learn-workbuddy。真正商业化时，无论选择哪个仓库，都必须自行补齐身份、权限、审计、沙箱、成本控制和运维体系。

三、DeepSeek Harness 的界面与运行方式

DeepSeek Harness 不只是后端 SDK，它自带 Web UI。根据官方中文 README，安装 Node.js 后可以直接通过 npx @deepseek-ai/dsh web 启动，默认地址为 http://127.0.0.1:3080。本机启动时会尝试打开默认浏览器；如果只想启动服务，可以使用 --no-open。

从源码运行时，需要克隆仓库、安装依赖并构建。下面把两种启动方式放在一起，便于复制执行：

npx @deepseek-ai/dsh web

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

四、Electron 为什么适合桌面 AI 工作台

Electron 是使用 Web 技术开发桌面应用的开源框架。开发者可以使用 HTML、CSS、JavaScript、TypeScript、React 或 Vue 构建界面，再打包成 Windows、macOS 和 Linux 应用。它可以简化为 Chromium 与 Node.js 的组合：Chromium 负责渲染界面，Node.js 负责访问操作系统能力。

DeepSeek Harness 官方仓库包含 Electron 桌面壳代码，可以把 Harness 运行时、Web UI 和外部插件整合进可安装的桌面程序。这意味着开发者不必从空白窗口开始设计，但仍需要根据自己的产品补充身份、权限、成果模板、审批流、多租户、计费、质量评估和升级迁移等能力。

Main Process。 主进程负责应用生命周期、创建窗口、系统菜单、托盘、自动更新和操作系统集成。它拥有较高权限，因此不能直接信任来自网页界面的任意输入。

Renderer Process。 渲染进程负责显示 React 或 Vue 页面，可以理解为运行在 Chromium 中的前端应用。为了安全，它不应该默认获得完整文件系统和命令执行权限。

Preload 与 IPC。 Preload 脚本向页面暴露经过筛选的能力，IPC 负责渲染进程与主进程通信。如果页面只需要“选择工作区”能力，就应暴露明确的 selectWorkspace() 接口，而不是把整个 Node.js 环境交给页面。

这种结构同时满足复杂 Web 界面与本地系统能力两类需求。开发者可以快速实现对话、文件树、任务列表、终端和预览页面，也能访问本地文件、启动 Sidecar 服务、发送系统通知或管理窗口。

Electron 的代价同样明显：安装包和内存占用通常高于纯原生应用；每个客户端需要携带 Chromium；如果主进程、渲染进程和 IPC 边界设计错误，还可能产生严重安全风险。因此应遵循 Electron 安全指南 中关于上下文隔离、导航限制、IPC 发送方验证和不安全远程内容的要求。

五、手机端不应该复制桌面执行环境

Electron 主要面向 Windows、macOS 和 Linux，不能直接打包成 iOS 或 Android 应用。即使把 Web 页面放进手机 WebView，移动操作系统的权限、后台运行、文件访问和进程模型也与桌面系统不同。

桌面应用可以在用户授权后访问项目目录、启动本地服务和子进程。iOS 应用运行在严格沙箱中，任意执行外部程序、长期驻留后台或读取其他应用数据都会受到限制；Android 相对开放，但仍存在应用沙箱、后台限制、权限申请和不同厂商策略。

因此，成熟的 WorkBuddy 类产品通常把手机设计成控制面，而不是让手机承担全部执行工作。根据 WorkBuddy 移动端说明，手机端既可以通过云端环境执行任务，也可以连接电脑端继续处理本地资源。

如果把全部能力强行放进手机，最终会遇到后台任务被系统终止、文件权限不完整、插件难以运行、调试困难和风险不可控等问题。

六、移动端框架如何选择

如果桌面端已经使用 React 构建 Web UI，移动端可以在 Capacitor、React Native、Flutter 和原生开发之间选择。关键不是哪个框架“最先进”，而是移动端在产品中承担多大职责。

Capacitor。 它可以把 Web 应用封装为 iOS 和 Android 应用，并通过插件调用相机、通知、文件和分享等能力。如果团队已经拥有 React/Vue 前端，第一版又以对话、任务列表、审批和成果查看为主，Capacitor 往往是最快的路线。共享组件并不意味着复制桌面布局，手机页面仍要针对触摸、小屏幕和单任务流程重新设计。

React Native。 它使用 React 思维构建原生界面，比 WebView 封装更适合复杂手势、原生导航、语音、相机、推送、后台上传和分享扩展。如果移动端将成为主要入口，React Native 更适合作为长期方案，但团队需要维护独立的移动组件体系。

Flutter 或原生开发。 Flutter 适合强调多端视觉一致性的团队；SwiftUI 和 Android 原生技术能够获得最深的系统集成，但开发成本更高。早期团队没有必要一开始就同时维护 Electron、SwiftUI 和 Android 原生三套完整客户端。

七、一套可落地的跨端总体架构

开发类似 WorkBuddy 的产品，可以把系统拆成六层。分层的价值在于明确权限边界，避免把界面、模型调用、文件操作和高风险命令全部塞进 Electron 主进程。

多端交互层。 Web 可以使用 React；桌面端使用 Electron + React；手机端优先使用 Capacitor + React，移动体验成为核心后再评估 React Native。交互层负责对话、任务管理、工作区选择、工具授权、执行时间线、成果预览和通知，但不应掌握模型密钥，也不应自行决定高风险命令是否执行。

客户端 Host 层。 桌面 Host 负责启动和停止本地 Harness、选择工作区、调用系统文件选择器、保存本机设置、建立 UI 与运行时之间的安全通信，并在应用退出时清理子进程。复杂执行最好放入独立 Sidecar 进程，使 UI 崩溃或受到恶意内容影响时仍无法直接获得无限制 Shell 权限。

Agent Runtime 层。 这一层可以由 DeepSeek Harness 承担，负责会话与上下文、模型调用、Agent Loop、工具选择、子 Agent 协作、任务中断恢复、超时、插件生命周期和运行事件流。业务层还应定义自己的模型能力接口，避免被单一供应商绑定。

Skills、MCP 与业务工具层。 Skill 描述某类任务应该怎样完成；MCP 用统一协议连接外部工具和数据源；Plugin 则向运行时安装代码、服务和界面扩展。例如，“生成周报”可以是 Skill，“读取 Jira 工单”可以通过 MCP，而公司项目治理模块可能是包含权限与专用 UI 的完整插件。

执行与隔离层。 所有高风险动作都应经过执行层，而不是让模型直接接触宿主机。执行层需要管理只读或读写工作区、临时目录、命令策略、网络域名、容器或虚拟机、资源限制、人工审批以及文件变更审计。

数据与成果层。 系统至少要区分用户组织、会话消息、任务状态、执行步骤、工具记录、授权工作区、文件版本、插件配置、凭据引用、模型用量和审计日志。本地单用户 MVP 可以使用 SQLite；企业版通常需要 PostgreSQL、对象存储、消息队列和独立审计存储。密钥应放在系统钥匙串或专用密钥管理服务中，数据库只保存引用或加密值。

八、完整任务应该如何流转

以“根据销售数据生成月度分析 PPT”为例，可靠系统不会把全部逻辑塞进一轮模型对话，而是让任务沿着清晰阶段推进。

创建阶段。 用户在手机端上传 Excel，选择“月度经营分析”专家，API 创建任务并返回任务 ID。调度器根据文件类型、数据敏感度和所需工具选择云端隔离环境或连接电脑端执行。

理解阶段。 Harness 加载对应 Skill 和表格工具，Agent 读取工作簿结构，识别日期、区域、产品和收入列，并生成一份可以展示给用户的执行计划。

执行阶段。 系统对只读分析自动放行，对外部发送、覆盖文件或其他高风险动作请求确认。Agent 生成数据摘要、趋势图和异常点，再调用 PPT 工具套用公司模板。

验证阶段。 质量检查工具验证页数、空白页面、字体、图表数据和引用来源。产物通过后写入对象存储或工作区，并生成受控下载入口。

迭代阶段。 手机收到完成通知，用户预览并提出修改。新的要求应成为同一任务的新迭代，而不是抛弃历史状态重新开始。

对话记录只是交流界面，任务还需要独立状态机。正常状态可以依次经历 created、planning、waiting_for_approval、running、validating 和 completed；异常状态则至少要表达 failed、cancelled、timed_out 与 partially_completed。没有独立状态，页面刷新、网络中断或模型超时后，用户就无法判断任务是否仍在运行。

九、MVP 应该分阶段建设

第一版同时开发模型市场、多 Agent、知识库、浏览器自动化、Office 全家桶、企业微信、手机 App 和插件市场，看起来功能丰富，实际上往往每个模块都不可靠。更合理的方法是先完成少量稳定闭环，再逐步扩展。

第一阶段：桌面闭环。 成功标准不是“能聊天”，而是用户能稳定完成整理资料、生成周报和分析表格等场景，并且每次都能找到最终文件。第一版不需要账号系统和手机端，但必须拥有清晰工作区、任务状态、高风险确认和执行日志。

第二阶段：插件与专家。 角色专家不能只是一段 System Prompt。一个可靠专家应该包含角色说明、输入要求、工具权限、工作流程、交付模板、质量检查和失败处理。插件还需要记录来源、版本和新增权限。

第三阶段：云端与手机。 手机第一版不需要完整文件管理器和终端。它应该优先把随时下达任务、查看进度、完成审批和接收通知做好，真正执行则放在云端或电脑端。

第四阶段：企业能力。 进入企业场景后，重点会从“Agent 有多聪明”转向身份、组织、数据治理、敏感信息、模型预算、审计导出、高可用、灾难恢复和许可证合规。这些功能不如演示动画醒目，却决定产品能否进入日常工作流。

十、安全设计不能依赖一个确认按钮

普通聊天应用的主要风险是模型生成错误内容。能够操作电脑的 Agent 还可能覆盖文件、发送错误邮件、提交错误代码、上传敏感资料或执行恶意脚本，因此需要多层防线。

最小工作区授权。 不要默认读取整个用户目录。用户应明确选择工作区，系统按任务授予只读或读写权限。下载目录、SSH 配置、浏览器资料和系统钥匙串不应自动暴露。

按风险分级审批。 读取已授权文件和创建临时文件可以归为低风险；修改工作区文件和访问指定网络服务属于中风险；删除文件、安装软件、发送外部消息或提交代码属于高风险；读取未授权密钥、关闭安全软件和绕过权限系统则应直接禁止。审批页面必须显示具体命令、文件范围、目标地址和可能影响。

沙箱与专用环境。 对不可信代码、网页内容和第三方插件，优先使用容器、一次性虚拟机或隔离账户，并限制网络、挂载目录、CPU、内存、磁盘和运行时间。高价值数据不应与实验性 Agent 运行在同一环境。

凭据隔离。 模型不应看到 API Key 明文。工具层可以使用凭据调用外部服务，但返回给 Agent 的内容必须经过过滤。桌面端使用系统钥匙串，服务端使用密钥管理服务，并支持轮换和撤销。

插件供应链治理。 插件本质上是代码。正式产品需要记录来源、版本、哈希、签名、权限和依赖。第三方插件自动更新时，不应未经审核直接获得新增权限。

文件恢复与审计。 任务执行前可以创建快照，重要文件修改要保留 diff 或历史版本。日志既不能泄露密钥和敏感正文，也必须保留足够信息用于调查，因此业务日志、执行审计和敏感数据应分开管理。

DeepSeek Harness 的官方安全说明明确指出，该项目仍是实验性的开发者预览软件，尚未完成安全审计；它可能执行模型生成的代码和命令、加载第三方插件，并访问被授权的文件、网络、进程和凭据。官方建议遵循最小权限，并优先在一次性虚拟机、容器或专用环境中运行。沙箱能降低风险，但不能被当作唯一安全控制。

十一、七个常见产品误区

误区一：模型越强，产品就越可靠。 任务可靠性还取决于工具定义、输入校验、重试、超时、幂等、格式处理和质量检查。强模型搭配混乱工具，仍然会产生不稳定结果。

误区二：工具越多越好。 工具数量增长会扩大决策空间与攻击面。第一版应围绕少数高价值场景设计最小工具集，而不是安装大量未知来源插件。

误区三：聊天记录就是任务系统。 聊天记录无法可靠表达审批、重试、部分完成和产物版本。任务必须拥有独立状态和持久化结构。

误区四：桌面 UI 可以直接缩成手机 UI。 桌面适合多栏、文件树、终端和并行面板；手机适合单任务、分步骤、语音输入和审批卡片。共享业务逻辑不等于复制布局。

误区五：有沙箱就绝对安全。 任何沙箱都有边界和配置问题。安全必须由最小权限、隔离、审批、审计、备份和运营流程共同构成。

误区六：开源等于零成本。 开源框架降低从零构建的成本，却不会消除模型费用、云资源、数据服务、Office 兼容、代码签名、应用商店、运维和安全审计成本。

误区七：展示过程比成果重要。 用户购买的是节省时间和可用成果，而不是漂亮的 Agent 思考动画。文件是否正确、格式是否专业、数据是否可追溯、修改是否方便，通常更加重要。

十二、如何形成自己的产品差异化

如果只是给 DeepSeek Harness 更换 Logo，再加入几个模型下拉框，很难形成长期竞争力。真正的差异化来自任务闭环、企业连接、成果质量、隐私和跨设备连续性。

行业任务闭环。 面向咨询、销售、法务、制造、研发或人力资源，建立稳定的输入规范、流程、工具和交付模板。例如法务合同审查不仅需要总结，还需要条款引用、风险等级、修改建议和审查记录。

企业连接器。 连接项目管理、CRM、ERP、知识库、邮件和审批系统。连接器的价值不只是读取数据，更重要的是权限映射、字段语义和业务动作控制。

成果质量体系。 为文档、表格、幻灯片和代码建立自动验证规则。PPT 不应出现文字溢出，财务表格公式应可复算，引用应能定位来源，代码修改必须通过测试。

本地优先与隐私。 对数据敏感客户，可以提供本地模型、本地向量库、离线工作区和私有部署，同时明确哪些能力仍需联网。

跨设备连续性。 用户在电脑端选择工作区并开始任务，离开后在手机查看进度、批准动作，回到电脑继续修改成果。这种连续体验比简单同步聊天记录更有价值。

可治理的专家和插件市场。 企业需要管理员可审核、可分组授权、可追踪版本的能力市场，而不是无限制安装插件。专家、Skill 和连接器都应拥有明确所有者、权限、版本和质量等级。

十三、推荐技术组合与实施顺序

小团队可以先使用 Electron + React + DeepSeek Harness + SQLite 完成桌面闭环；第二阶段增加云端 API、任务队列和对象存储；第三阶段用 Capacitor 发布手机控制端；业务验证完成后，再建设企业身份、审计、插件治理和高可用能力。

这套组合不是唯一答案，但它明确分开了界面、执行、数据与安全边界，避免所有逻辑挤进一个 Electron 主进程或一个后端接口中。每个阶段都应以真实任务成功率和成果质量为验收标准，而不是以功能入口数量为标准。

十四、结论

开发一款类似 WorkBuddy 的程序是可行的，也已经有足够丰富的开源积木。DeepSeek Harness 提供 Agent 运行时、Web UI、插件架构和 Electron 桌面壳，适合作为执行底座；Electron 适合快速构建 Windows、macOS 和 Linux 客户端；Capacitor 或 React Native 可以承担移动端界面；MCP、Skills 和业务插件负责连接外部能力。

真正的产品并不是把这些项目拼在一起就结束。团队仍要持续建设可靠的任务状态和错误恢复、清晰的工作区和成果管理、最小权限与执行隔离、桌面执行与手机控制的职责划分、行业化模板和质量验证，以及企业身份、成本、插件与数据治理。

如果目标是尽快做出第一版，最务实的路径是先运行 DeepSeek Harness 的 Web UI，围绕三个高价值场景完成桌面闭环；然后用 Electron 打磨桌面体验；再增加云端 Worker 和 Capacitor 手机控制端。不要从“万能 Agent”开始，而要先让少量任务稳定完成、成果能够直接使用、风险能够被控制。

当系统真正做到用户提出目标、Agent 在明确权限内执行、过程可观察、结果可验证、失败可恢复，它才从一个带工具的聊天机器人，成长为真正的 AI 工作助手。

参考资料

产品与生态： WorkBuddy 产品概述、WorkBuddy 移动端概述、WorkBuddy MCP 使用说明、WorkDSH、OpenClaw、learn-workbuddy。

DeepSeek Harness： 官方仓库、官方文档、工具执行管线、沙箱系统。

跨端工程： Electron 官方介绍、Electron 进程模型、Electron 安全指南、Capacitor 官方文档、React Native 官方文档。