从 WorkBuddy 到 DeepSeek Harness：开源构建跨桌面与移动端 AI 工作助手的完整指南

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

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

如果准备开发一款类似 WorkBuddy 的程序，真正需要回答的并不是“接哪个模型接口”，而是下面这些问题：

AI 如何理解并拆解一个需要持续数分钟甚至数小时的任务？
模型如何安全地读写本地文件、执行命令和访问网页？
如何让用户看到执行过程，而不是只能等待一个黑盒结果？
如何管理 Skills、MCP、插件、连接器和不同角色的专家 Agent？
如何同时支持网页、Windows、macOS 和手机？
手机系统权限有限，复杂任务究竟应该在哪里执行？
如何避免模型误删文件、泄露凭据或执行危险命令？
怎样把一个能演示的原型，变成可以长期维护的产品？

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

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

一、先理解产品：WorkBuddy 类程序不只是一个聊天界面

根据 WorkBuddy 官方产品说明，这类产品的核心目标是让 AI 从“回答问题”升级为“完成工作”。表面上看，用户仍然是在一个对话框中输入需求，但后台实际发生的是一条复杂的任务执行链。

例如，用户输入：

请读取项目文件夹中的需求文档和会议纪要，整理本周进度，找出三项延期风险，并生成一份适合管理层汇报的 PPT。

普通聊天模型只能根据上传到上下文中的少量内容生成文字。真正的工作助手则需要完成以下步骤：

确认被授权访问的工作目录；
枚举目录中的文件并识别格式；
读取 Word、PDF、Markdown、Excel 等内容；
判断需求文档和会议纪要之间的关系；
提取任务、负责人、日期与完成状态；
识别延期风险和缺失信息；
生成汇报结构与图表；
创建 PPT 文件并保存到指定目录；
在界面中提供预览、下载和后续修改入口；
记录执行日志，便于用户检查 AI 做了什么。

这十个步骤中，真正依赖大模型推理的可能只有一部分。其余部分属于文件系统、格式解析、命令执行、任务编排、权限控制、状态持久化、错误恢复和成果交付。

因此，一款 WorkBuddy 类程序至少由六种能力共同组成：

1. 对话与任务入口

用户需要通过自然语言表达目标，也需要上传文件、粘贴链接、选择工作区、确认权限，并随时补充要求。对话只是入口，后台必须把一段自然语言转换成可追踪的任务。

2. Agent 运行时

运行时负责维护会话上下文、调用模型、决定下一步动作、调用工具、接收结果、处理错误并判断任务是否完成。它相当于整个系统的“执行内核”。

3. 工具与插件系统

AI 要真正完成工作，必须拥有文件、终端、浏览器、搜索、数据库、邮件、日历和企业 API 等工具。工具越多，系统越强大，但安全风险和维护成本也会同步增加。

4. 工作区与成果系统

用户需要明确知道 AI 可以访问哪些目录，任务生成了哪些文件，旧版本在哪里，哪些成果可以下载或继续编辑。没有稳定的工作区和成果管理，Agent 很容易退化为一次性演示。

5. 权限、审批与审计

读取文件、覆盖文件、发送邮件和执行 Shell 命令的风险完全不同。系统必须根据动作风险决定是否自动执行、请求确认或直接拒绝，并保存完整审计记录。

6. 跨端控制

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

理解这六个部分以后，就能看出为什么仅仅使用 LangChain、调用一次模型 API，或者做一个精美聊天页面，都不足以构成 WorkBuddy 类产品。

二、有没有可以直接二次开发的开源底座？

答案是有，但需要区分“完整产品”“Agent 运行时”和“教学参考项目”。不同开源项目解决的问题并不相同。

DeepSeek Harness：最适合作为执行底座

DeepSeek Harness 是 DeepSeek AI 开源的 Agent Harness。官方将其描述为建立在“一切皆插件”架构上的智能体框架，并采用 MIT License。

这里的 Harness 可以理解为“让模型持续执行工作的运行环境”。它不是一个新的大模型，也不等同于普通工作流编辑器。它负责把模型、会话、工具、插件、文件系统、沙箱、任务调度和界面连接起来。

它适合承担以下职责：

管理模型提供商及调用配置；
维护长期会话和任务上下文；
调用文件、终端、网页等工具；
加载 Skills、MCP 服务和外部插件；
启动子 Agent 或协作任务；
管理后台任务与任务状态；
提供 Web UI 与桌面壳；
为权限、审批和沙箱能力提供扩展点。

DeepSeek Harness 采用 MIT License，意味着开发者通常可以复制、修改、分发并用于商业产品，但需要保留相应版权和许可声明。第三方依赖仍然需要遵守各自的许可证，模型 API、商业数据源和第三方 SaaS 也不会因为框架开源而自动免费。

WorkDSH：更接近可以直接体验的产品壳

WorkDSH 是基于 DeepSeek Harness 构建的社区工作平台。它更接近“拿来运行和修改”的产品形态，适合希望快速验证界面、工作区、Skill 管理和插件体验的团队。

它的优势是启动快、产品结构直观，适合用来观察一个 WorkBuddy 类工作台应该怎样组织页面和入口。需要注意的是，早期社区项目通常会快速变化，正式商用前仍应检查版本稳定性、更新机制、数据迁移、权限模型和依赖许可证。

OpenClaw：更适合消息入口和个人助理场景

OpenClaw 更强调本地个人助手、多消息渠道、Skills、自动化和跨设备体验。如果产品重点是通过聊天软件给 AI 下达任务、让助手长期在线、连接多个渠道，那么 OpenClaw 是值得研究的另一条路线。

但“个人助理”和“企业办公工作台”并不完全相同。前者通常强调长期在线、消息接入和个人自动化；后者更关注工作区隔离、企业权限、成果模板、审批流程、审计和组织级数据治理。

learn-workbuddy：适合学习，不等于生产框架

learn-workbuddy 通过教程形式拆解 Agent Loop、工具调用、记忆、Sidecar、沙箱、审计和任务调度。它适合帮助开发者理解“一个类似 WorkBuddy 的系统内部究竟如何运作”，但教学项目与生产框架的目标不同，不能因为代码容易阅读就直接假设其安全性、性能和升级能力满足生产要求。

如果只给出一个选型建议，可以概括为：

想最快做出可见原型：参考或二次开发 WorkDSH；
想建立可长期扩展的 Agent 执行底座：优先研究 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。

如果需要从源码运行，可以使用：

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

官方仓库同时包含桌面端代码。桌面部分是一个 Electron shell，它把 Harness 运行时、Web UI 和外部插件整合进可安装的桌面应用中。因此，DeepSeek Harness 已经具备“浏览器界面 + 桌面壳”的基础结构，而不是要求开发者从空白窗口开始搭建。

不过，必须正确理解“有界面”的含义。它提供的是面向 Agent 开发与执行的工作台基础，不等于已经完成了所有行业产品功能。企业最终仍可能需要自行补充：

组织、用户和角色管理；
企业登录、单点登录和设备管理；
行业化导航与角色入口；
成果模板和品牌模板；
审批流与业务状态机；
多租户数据隔离；
计费、额度和成本中心；
运营后台与质量评估；
版本升级与数据迁移策略。

换句话说，DeepSeek Harness 解决的是最难的一部分基础设施问题，但不会替你完成全部产品定义。

四、Electron 到底是什么？为什么 AI 工作台常用它？

Electron 是一个使用 Web 技术开发桌面应用的开源框架。开发者可以使用 HTML、CSS、JavaScript、TypeScript、React 或 Vue 构建界面，再将它打包成 Windows、macOS 和 Linux 应用。

它的核心可以简化为两部分：

Chromium：负责渲染用户界面
Node.js：负责访问操作系统能力

在典型 Electron 应用中，至少存在三类代码：

1. Main Process：主进程

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

2. Renderer Process：渲染进程

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

3. Preload 与 IPC：受控能力桥梁

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

这种结构非常适合 AI 工作台，因为产品通常需要同时满足两类需求：

用 Web 技术快速构建复杂对话、文件树、任务列表、终端和预览界面；
访问本地文件、启动 Sidecar 服务、调用系统通知、读取剪贴板或管理应用窗口。

Electron 的代价也很明显：安装包和内存占用通常高于纯原生应用；每个桌面客户端都需要携带 Chromium 运行环境；如果主进程、渲染进程和 IPC 边界设计错误，还可能产生严重安全风险。

因此，Electron 适合“快速构建功能复杂的跨平台桌面产品”，但不等于可以忽略桌面安全。官方的 Electron 安全指南强调上下文隔离、限制导航、验证 IPC 发送方、避免加载不安全远程内容等措施。对于能够执行 Shell 和访问企业文件的 Agent 产品，这些措施更不是可选项。

五、为什么手机端不能简单地复制 Electron？

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

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

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

合理的职责划分如下：

手机端：输入需求、上传资料、查看进度、审批动作、接收通知
云端：运行可隔离的通用任务、处理在线数据、生成交付物
电脑端：访问本地文件、调用桌面软件、执行需要本机环境的任务

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

六、手机端应该使用什么框架？

如果桌面端已经使用 React 构建 Web UI，手机端主要有三条路线。

方案一：Capacitor，优先复用 Web UI

Capacitor 可以把 Web 应用封装为 iOS 和 Android 应用，并通过插件调用相机、通知、文件、分享等原生能力。

它最适合以下情况：

团队已有 React/Vue Web 前端；
第一版以对话、任务列表、审批和成果查看为主；
希望快速复用组件与业务逻辑；
不需要在手机本地运行完整 Harness。

对于 WorkBuddy 类产品，Capacitor 往往是最快的移动端 MVP 方案。桌面和手机可以共享设计系统、接口层、Markdown 渲染、任务状态组件和登录逻辑，但需要针对触摸操作、小屏幕和移动导航重新设计页面，不能把桌面三栏界面原样缩小。

方案二：React Native，追求更原生的长期体验

React Native 使用 React 思维构建 iOS 和 Android 原生界面。它比 WebView 封装更适合复杂手势、长列表、原生导航和深度系统集成。

如果移动端将成为产品的核心入口，需要大量使用语音、相机、分享扩展、推送、后台上传和系统级交互，那么 React Native 更适合作为长期方案。不过，界面代码无法像 Capacitor 那样直接复用，团队需要维护移动端组件体系。

方案三：Flutter 或原生开发

Flutter 可以用一套 Dart 代码构建多个平台，界面一致性和渲染控制较强。SwiftUI 与 Android 原生技术则能获得最深的系统集成，但开发成本更高。

对于早期创业团队，除非移动体验本身就是核心竞争力，否则没有必要一开始就同时维护 Electron、SwiftUI 和 Android 原生三套完整客户端。

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

开发一款类似 WorkBuddy 的产品，可以把系统划分为六层。

第一层：多端交互层

Web：React
桌面：Electron + React
手机：Capacitor + React，或 React Native

交互层负责对话、任务管理、工作区选择、工具授权、执行时间线、成果预览和通知。它不应该直接掌握模型密钥，也不应该自行决定高风险命令是否可以执行。

第二层：客户端 Host 层

桌面端需要一个 Host 负责：

启动和停止本地 Harness；
选择工作区并管理目录授权；
调用系统文件选择器；
保存本机配置和更新信息；
建立 UI 与本地运行时之间的安全通信；
在应用退出时清理子进程；
收集有限且可审计的运行日志。

Electron 主进程可以承担 Host，但更稳妥的做法是把复杂执行放入独立 Sidecar 进程。即使 UI 崩溃或被恶意内容影响，也不应直接获得无限制 Shell 权限。

第三层：Agent Runtime 层

这一层可以由 DeepSeek Harness 承担。它负责：

会话和上下文管理；
模型调用与模型切换；
Agent Loop；
工具选择和结果回传；
子 Agent 协作；
任务中断、恢复和超时；
插件生命周期；
运行状态事件流。

为了避免被单一模型绑定，业务层应该定义自己的模型能力接口，例如文本生成、视觉理解、工具调用、长上下文和结构化输出，并让不同供应商适配这些能力。

第四层：Skills、MCP 与业务工具层

Skills 适合描述角色经验、操作流程、模板和领域规则；MCP 适合用统一协议连接外部工具与数据源；业务插件则适合承载需要版本管理、权限检查和复杂 UI 的功能。

可以把三者理解为：

Skill：告诉 Agent 应该怎样完成某类任务
MCP：告诉 Agent 可以连接哪些外部能力
Plugin：向运行时安装一组代码、服务和界面扩展

例如，“生成周报”可以是一个 Skill；“读取 Jira 工单”可以通过 MCP；“公司项目治理模块”则可能是一个包含服务端逻辑、权限和专用界面的完整插件。

第五层：执行与隔离层

所有高风险动作都应该经过执行层，而不是由模型直接接触宿主机。执行层可以提供：

只读和读写工作区；
临时目录；
命令允许列表或禁止列表；
网络域名策略；
容器或一次性虚拟机；
CPU、内存、磁盘和运行时间限制；
人工审批；
命令输出和文件变更审计。

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

因此，正式产品不能只在界面上增加一个“确认”按钮就宣称安全。权限、隔离、备份、审计和恢复必须共同存在。

第六层：数据与成果层

建议至少区分以下数据：

用户和组织数据；
会话与消息；
任务状态和执行步骤；
工具调用记录；
授权工作区；
生成文件与版本；
Skill 和插件配置；
凭据引用；
成本和模型用量；
审计日志。

本地单用户 MVP 可以使用 SQLite，但企业版通常需要 PostgreSQL、对象存储、消息队列和独立审计存储。敏感密钥应保存在系统钥匙串或专用密钥管理服务中，数据库只保存引用或加密后的值。

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

以“根据销售数据生成月度分析 PPT”为例，一条可靠的任务链可以这样设计：

用户在手机端上传 Excel，并选择“月度经营分析”专家；
API 创建任务，返回任务 ID；
调度器选择云端隔离执行环境；
Harness 加载对应 Skill 和表格处理工具；
Agent 读取工作簿结构，识别日期、区域、产品和收入列；
系统生成一个执行计划并在手机端展示；
对只读分析步骤自动放行；
Agent 生成数据摘要、趋势图和异常点；
PPT 工具根据公司模板生成演示文稿；
质量检查工具验证页数、空白页面、字体和图表数据；
产物写入对象存储并生成受控下载链接；
手机收到完成通知，用户预览并提出修改意见；
新要求作为同一任务的新迭代继续执行，而不是重新开始全部流程。

这条流程展示了一个重要原则：对话不是任务状态。消息记录只是用户与 Agent 的交流界面，真正的任务还需要独立的状态机，例如：

created
→ planning
→ waiting_for_approval
→ running
→ validating
→ completed

异常状态也要明确：

failed
cancelled
timed_out
partially_completed

如果没有任务状态机，页面刷新、网络中断、模型超时或手机退出后，用户很难知道任务究竟是否仍在运行。

九、MVP 应该怎么做？不要第一天就复制全部 WorkBuddy

一个常见失败原因是第一版就同时开发模型市场、多 Agent、知识库、浏览器自动化、Office 全家桶、企业微信、手机 App 和插件市场。功能看起来丰富，但每个模块都不可靠。

更合理的路线是分阶段交付。

阶段一：桌面单用户闭环

目标是证明 AI 能在一个明确工作区内完成任务并交付文件。

建议功能：

Electron 桌面壳；
DeepSeek Harness Web UI；
一个模型提供商；
工作区目录授权；
文件读取、写入和基础 Shell；
任务时间线；
Markdown、PDF 和常见 Office 文件预览；
高风险动作确认；
本地 SQLite；
完整执行日志。

第一阶段不需要账号系统和手机端。成功标准不是“能聊天”，而是用户可以完成三个稳定场景，例如整理资料、生成周报和分析表格，并且每次都能找到最终成果。

阶段二：插件与角色化能力

第二阶段加入：

Skills 管理；
MCP 服务配置；
多模型支持；
角色专家；
企业模板；
任务定时执行；
子 Agent；
成本统计；
插件签名或来源提示。

角色专家不应该只是一段 System Prompt。一个可靠专家应该包含角色说明、输入要求、工具权限、工作流程、交付模板、质量检查和失败处理。

阶段三：云端与移动端

第三阶段再建设：

用户登录与设备绑定；
云端 Harness Worker；
任务队列；
对象存储；
推送通知；
手机对话与任务列表；
手机审批；
云端执行与连接电脑两种模式；
端到端加密或传输加密；
设备撤销和会话失效。

手机端第一版不需要完整文件管理器和终端。它应该先把“随时下达任务、随时查看进度、及时完成审批”做好。

阶段四：企业生产能力

进入企业场景后，重点会从“Agent 有多聪明”转向：

单点登录与组织架构；
RBAC/ABAC 权限；
数据保留策略；
敏感信息识别与脱敏；
审计导出；
插件白名单；
模型路由与预算；
高可用与灾难恢复；
质量评估和回归测试；
法务、隐私和许可证合规。

这些能力看起来不如 Agent 演示吸引人，却决定产品能否真正进入公司日常工作流。

十、安全设计：这是 Agent 产品最容易被低估的部分

普通聊天应用的主要风险是模型生成错误内容。能够操作电脑的 Agent 还可能产生真实世界副作用，例如覆盖文件、发送错误邮件、提交错误代码、上传敏感资料或执行恶意脚本。

建议至少建立以下防线。

1. 最小工作区授权

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

2. 按风险分级审批

可以把动作划分为：

低风险：读取已授权文件、创建临时文件；
中风险：修改工作区文件、访问指定网络服务；
高风险：删除文件、执行安装命令、发送外部消息、提交代码；
禁止动作：读取未授权密钥、关闭安全软件、绕过权限系统。

审批页面必须显示将要执行的具体命令、文件范围、目标地址和可能影响，而不是只显示“Agent 请求权限”。

3. 沙箱与专用环境

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

4. 凭据隔离

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

5. 插件供应链治理

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

6. 文件变更与备份

执行任务前可以创建快照，重要文件修改应保留 diff 或历史版本。即使权限控制失效，用户仍然需要恢复路径。

7. 日志不等于全部记录

日志中不能泄露密钥和敏感正文，但又必须保留足够信息用于调查。建议分离业务日志、执行审计和敏感数据，并为不同角色提供不同查看权限。

十一、最常见的七个产品误区

误区一：模型越强，产品就越可靠

模型能力很重要，但任务可靠性还取决于工具定义、输入校验、重试、超时、幂等、文件格式处理和质量检查。一个强模型搭配混乱工具，仍然会产生不稳定结果。

误区二：工具越多越好

工具数量增长会扩大决策空间和攻击面。第一版应该围绕少数高价值场景设计最小工具集，而不是一开始安装几百个未知来源插件。

误区三：把聊天记录当作任务系统

聊天记录不能可靠表达审批、重试、部分完成和产物版本。任务必须拥有独立状态和持久化结构。

误区四：桌面 UI 可以直接缩成手机 UI

桌面端适合多栏、文件树、终端和并行面板；手机端适合单任务、分步骤、语音输入和审批卡片。共享业务能力不等于复制布局。

误区五：有沙箱就绝对安全

任何沙箱都存在边界和配置问题。安全必须建立在最小权限、隔离、审批、审计、备份和运营流程共同作用的基础上。

误区六：开源等于零成本

开源框架减少的是从零构建的成本，不会消除模型费用、云资源、数据服务、Office 兼容、代码签名、应用商店、运维和安全审计成本。

误区七：只展示过程，不重视最终成果

用户最终购买的是节省时间和可用成果，而不是一串漂亮的 Agent 思考动画。文件是否正确、格式是否专业、数据是否可追溯、修改是否方便，往往比执行过程更重要。

十二、怎样形成自己的产品差异化？

如果只是把 DeepSeek Harness 换一个 Logo，再加入几个模型下拉框，很难形成长期竞争力。真正的差异化通常来自以下方向。

行业任务闭环

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

企业连接器

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

成果质量体系

为文档、表格、幻灯片和代码设置可自动验证的规则。例如 PPT 不应出现溢出文字，财务表格公式应可复算，引用应能够定位来源，代码修改必须通过测试。

本地优先与隐私

某些客户更重视数据不离开设备。可以提供本地模型、本地向量库、离线工作区和企业私有部署，同时清晰说明哪些功能仍需联网。

跨设备连续性

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

可治理的专家与插件市场

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

十三、推荐的技术组合

对于希望快速验证产品、又保留长期扩展能力的团队，可以采用下面的组合：

界面：React + TypeScript
桌面：Electron
移动：Capacitor，成熟后按需要迁移 React Native
Agent Runtime：DeepSeek Harness
工具协议：MCP + 自定义受控工具
角色能力：Skills + 版本化模板
本地数据：SQLite
服务端数据：PostgreSQL
任务队列：Redis 或其他可靠队列
文件成果：对象存储 + 本地工作区
执行隔离：容器、一次性虚拟机或专用 Worker
身份权限：OIDC/企业 SSO + RBAC/ABAC
监控：任务指标、模型成本、工具错误率、审计日志

这不是唯一正确答案，但它把“界面”“执行”“数据”“安全”和“跨端”分开，避免所有逻辑挤进一个 Electron 主进程或一个后端接口中。

如果团队规模较小，还可以进一步简化：

第一版：Electron + React + DeepSeek Harness + SQLite
第二版：增加云端 API、队列和对象存储
第三版：用 Capacitor 发布手机控制端
第四版：再建设企业身份、审计和插件治理

这种路线允许团队在每个阶段验证真实用户价值，而不是在没有用户之前投入大量时间建设完整平台。

十四、最终结论

开发一款类似 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 工作助手。