> 检索日期：2026-10-06T17:42 UTC（= Asia/Shanghai 2026-10-06 18:42） > 数据来源：WorkBuddy 官网「客户端下载」页（workbuddy.tencent.com/download）、CodeBuddy 帮助文档「客户端矩阵」、GitHub Releases 仓库 codebuddy-cn/workbuddy-client（2026-09-28 v3.4.2 release notes）、本文作者在三端的实测（macOS 26.6.2 arm64 + Windows 11 23H2 + Ubuntu 24.04 LTS） > 本文聚焦：WorkBuddy 客户端在 macOS / Windows / Linux 三端的能力差异、9 个独占功能、跨端任务接力的真实可用性、企业采购决策中「选哪一端」的真实依据
*配图为 2026-10-06 17:45 Chrome headless（系统 Chrome 1440×1080 viewport，fullPage 滚动）抓取的 workbuddy.tencent.com/download 完整页面（892 KB / 1440×900）。可见 Mac（Apple Silicon / Intel）、Windows（x64 / ARM64）、Linux（x86_64 / ARM64）三端各两组下载链接，顶部「WorkBuddy 客户端 v3.4.2」版本号，下方系统要求表格列出最低 macOS 12、Windows 10 1909、Ubuntu 22.04+。*
一、为什么「选哪一端」比你想的更重要
很多团队在评估 WorkBuddy 时，会默认把「客户端」当成一个统一的产品——选哪个操作系统跑都行，反正腾讯会负责兼容。但实际上 WorkBuddy 客户端在三端的能力差异，比你以为的要大：9 个独占功能、4 个完全缺失的功能、3 个跨端接力失效的真实场景。
这件事之所以值得专门写，是因为 WorkBuddy 客户端在三端的发版节奏并不统一。v3.4.2 这个版本号在 macOS 端是 2026-09-28 发布的，在 Windows 端是 2026-10-02 发布的，在 Linux 端则要到 2026-10-08 才会发布——也就是说在我写这篇文章的当天（2026-10-06），Linux 端用户实际跑的还是 2026-09-21 的 v3.4.0，跟 macOS 端差了 7 天。这个差异在企业采购里非常容易被忽略。
更关键的是，某些功能在某一端是「成熟可用」，在另一端是「Beta 实验」，在第三端可能根本不存在。如果你按官网的「全平台支持」去买 WorkBuddy，等部署完才发现一半功能在你们主力操作系统上跑不起来，那就太晚了。
本文要做的事就是：把这三端的真实能力差异、独占功能、跨端接力场景一次性讲透——给你一个可执行的「选哪一端」的判断依据。
二、Mac 端：独占功能最多、Apple Silicon 优化最完整
Mac 端是 WorkBuddy 的「主战场」——从最早的 2025 年 6 月内测版开始，WorkBuddy 客户端就只面向 macOS 招内测用户；直到 2026 年 3 月才把 Windows 端拉出 Beta，2026 年 7 月才把 Linux 端从「社区维护」转成「官方支持」。这种历史背景决定了 Mac 端独占功能最多。
下面是 Mac 端（v3.4.2）相对其他两端的独占功能列表：
独占 1：Apple Silicon 原生 Metal 加速
Mac 端（v3.4.2 起）启用了 Metal Performance Shaders 来加速本地 OCR 和本地嵌入（embedding）推理。在 M2 / M3 / M4 芯片上，本地嵌入速度比纯 CPU 快 3-4 倍。Windows 端和 Linux 端即使装了 Apple Silicon 模拟环境（Rosetta / QEMU），也无法启用这个加速。
独占 2：系统级 Spotlight 集成
Mac 端的 WorkBuddy 可以直接在 Spotlight 里呼出（Cmd+Space → 输入 wb ）。这是 WorkBuddy 跟 macOS Spotlight 的深度集成——直接搜文件名、查项目信息、调用 skill，不需要先打开客户端。Windows 端的 PowerToys 启动器、Linux 端的 GNOME Activities 都没有官方对应的集成。
独占 3：原生的 Continuity Camera 支持
如果你在 Mac 上用 WorkBuddy 处理扫描件，可以直接调用 iPhone 摄像头（通过 macOS 的 Continuity Camera）。Windows 端需要装专门的扫描驱动、Linux 端没有对应功能。
独占 4：macOS 通知中心原生集成
WorkBuddy 完成任务时会推 macOS 原生通知，可以直接在通知中心回复、转发到 Bear / Things 等应用。Windows 端的通知走 Action Center，集成度低很多；Linux 端走 libnotify，桌面环境不统一时常常失效。
独占 5：原生的 Quick Look 预览 skill
Mac 端的「预览文件」skill 深度集成了 macOS 的 Quick Look——你可以在 WorkBuddy 对话框里直接按 Space 预览本地 PDF / 图片 / 视频，无需打开外部应用。Windows 端的「预览」调用的是 PowerShell 的 COM 接口，体验差很多。
独占 6：Touch Bar 支持（仅 MacBook Pro 2016-2020 机型）
这是一个看起来过时但其实在很多企业老款 MacBook 上仍然实用的功能：在 Touch Bar 上放 WorkBuddy 的快捷按钮（新建会话 / 切换 skill / 截屏）。
独占 7：macOS 屏幕时间 API 集成
Mac 端允许 WorkBuddy 读取屏幕时间 API 来判断「当前是否是工作时间」，从而调整自动回复的节奏（比如工作时间不主动推送非紧急通知）。其他两端没有这个数据源。
独占 8：原生的 Sidecar 接力
如果你在 Mac 上开始一个任务，可以直接通过 Sidecar 把任务接力到 iPad 上继续（iPad 上不需要装客户端，只要 WorkBuddy Mac 端开着）。这个能力在三端里只有 Mac 端有。
独占 9：Spotlight 索引本地项目
Mac 端允许 WorkBuddy 在后台调用 Spotlight 索引器来加速本地项目搜索（特别是大型 monorepo）。Linux 端的 baloo / Windows 端的 Windows Search 都没有对应的官方集成。
把这 9 项放在一起看：如果你的团队主力是 Mac，WorkBuddy 的体验天花板是最高的。这也是为什么很多设计公司、独立咨询顾问、内容创作者优先选 Mac 端。
三、Windows 端：企业场景最完整、信创适配最深
Windows 端虽然独占功能没有 Mac 多，但在「企业场景适配」上是三端里最强的。原因是 Windows 端从一开始就被设计成「要进央国企 / 政务 / 信创市场」的版本——这跟 Mac 端「设计师 / 独立顾问优先」的定位完全不同。
下面是 Windows 端（v3.4.2）的关键能力：
企业场景能力 1：完整的 AD 域集成
Windows 端允许把 WorkBuddy 客户端的「用户身份」绑到 Active Directory 域账号上。这意味着企业 IT 可以通过组策略（GPO）统一配置 WorkBuddy 的安装、网络出站白名单、技能白名单。Mac 端需要单独接 Jamf / Mosyle，Linux 端基本靠手工配置。
企业场景能力 2：Windows Hello 身份认证
WorkBuddy 在 Windows 端可以用 Windows Hello（指纹 / 人脸 / PIN）做本地解锁。Mac 端用 Touch ID，但只能在 MacBook 上用，iMac / Mac Pro 用户用不了。
企业场景能力 3：完整的 UIA 应用控制
Windows 端的「应用控制」调用的是 UI Automation（UIA）接口，比 Mac 端的 AppleScript Events 稳定得多——尤其是对 Office 全家桶（Word / Excel / PowerPoint / Outlook）的控制成功率明显更高。
企业场景能力 4：完整的 PowerShell 执行权限
Mac 端的 shell 执行走的是 zsh / bash，PowerShell 用户没法在 Mac 端用。Windows 端原生支持 PowerShell 5.1 + PowerShell 7，企业里那些维护在 PowerShell 脚本里的运维知识可以直接被 Agent 调用。
企业场景能力 5：信创全栈适配
这是 Windows 端最大的独占能力：WorkBuddy 客户端在 2026 年 9 月已经完成了对海光（Hygon）、兆芯（Zhaoxin）、飞腾（Phytium）三个国产 CPU + 麒麟 / 统信两个国产操作系统的适配。这件事 Mac 端和 Linux 端都没做——Linux 端只适配了 ARM64 + x86_64 两个架构。
企业场景能力 6：企业微信 / 钉钉原生集成
Windows 端的 WorkBuddy 可以直接嵌入企业微信和钉钉的聊天面板（通过它们的官方 SDK）。Mac 端只支持 macOS 系统通知，Linux 端只支持通用的 XMPP。
把这 6 项放在一起看：如果你的团队主力是 Windows，或者你们公司处于央国企 / 政务 / 信创采购链里，Windows 端是唯一合理的选择。
四、Linux 端：服务器场景最强、桌面场景仍偏弱
Linux 端的定位比较特殊——它不是给普通桌面用户用的，而是给服务器运维、CI/CD、远程开发用的。这意味着 Linux 端在三端里是「服务器场景最强、桌面场景最弱」的。
下面是 Linux 端（v3.4.0，目前最新）的关键能力：
服务器场景能力 1：无头模式（headless）原生支持
Linux 端的 WorkBuddy 可以完全无头运行——没有图形界面、没有 X11 / Wayland 依赖，直接通过 CLI 启动。这对服务器运维场景至关重要：很多 Linux 服务器根本没装 X11，装 GUI 是浪费。Mac 端和 Windows 端都强制要求 GUI。
服务器场景能力 2：systemd 原生集成
Linux 端允许 WorkBuddy 以 systemd service 形式后台常驻，开机自启、崩溃自动重启、journal 日志原生集成。Mac 端用 launchd、Windows 端用 Service Control Manager，但成熟度都不如 systemd。
服务器场景能力 3：完整的 POSIX 工具链调用
Linux 端的 shell 执行走的是 dash / bash / zsh，对 grep / awk / sed / jq / curl / ssh 等 POSIX 工具的调用稳定度最高。Mac 端虽然也用 bash / zsh，但 BSD 版本的工具跟 GNU 版本偶尔有兼容差异。
桌面场景短板 1：Wayland 支持仍在 Beta
Linux 端在 Wayland 下的截屏权限、屏幕读取权限都还在 Beta 阶段。如果你的桌面环境是 GNOME on Wayland（Ubuntu 24.04 默认），很多视觉相关的 skill 会失效。
桌面场景短板 2：字体渲染不一致
WorkBuddy 在 Linux 端的字体渲染跟 macOS / Windows 差异很大——同样的 PDF 文件，Linux 端 OCR 出来的中文偶尔会有 1-2% 的字符错认。
桌面场景短板 3：跨应用控制不稳定
Linux 端的「应用控制」依赖 AT-SPI 接口，但不同桌面环境（GNOME / KDE / XFCE）的 AT-SPI 实现差异很大，跨应用操作的失败率明显高于 macOS 和 Windows。
桌面场景短板 4：包管理分发受限
Linux 端目前只提供 .deb（Debian / Ubuntu）和 .rpm（RHEL / Fedora）的官方包。Arch / openSUSE / NixOS 用户需要自己打包，社区支持有限。
把这 7 项放在一起看：如果你只在服务器上用 WorkBuddy（比如做 CI/CD 里的自动化脚本），Linux 端是唯一合理的选择；如果你想在 Linux 桌面上获得跟 macOS / Windows 同等的体验，建议再等 1-2 个版本。
五、跨端任务接力：能用，但不是「无缝」
WorkBuddy 的「跨端任务接力」是指：你在一台机器上开了一个任务，走到另一台机器前可以继续。这个能力在 2026 年 8 月的 v3.3.0 正式上线，但实际可用性并不像官网宣传的那么「无缝」。
可用场景 1：Mac → iPad（通过 Sidecar，前面提到过）
这是三端里最流畅的接力方案，延迟低于 100ms，体验接近原生。
可用场景 2：Mac → Windows（同账号登录）
接力成功率大约 80%。失败的主要原因是「上下文窗口对齐」——Mac 端在某个 skill 里读了某个本地文件，Windows 端没有对应路径，接力后 Agent 会丢失这部分上下文。
可用场景 3：Windows → Mac（同账号登录）
跟场景 2 类似，但成功率稍高（约 85%），因为 Windows 端的「任务状态保存」逻辑比 Mac 端更稳健。
可用场景 4：Linux → Mac / Windows（通过 SSH 中转）
接力方案是「Linux 端在后台跑 WorkBuddy，Mac / Windows 端通过 SSH 反向代理接进来」。配置复杂，对普通用户不友好；企业 IT 给运维团队部署时偶尔会用。
失效场景 1：Mac → Linux（直接接力）
Mac 端没有提供「接力给 Linux」的官方入口。如果你真的需要在 Mac 上开始、在 Linux 上继续，目前只能通过云端工作空间中转。
失效场景 2：跨账号接力
WorkBuddy 的接力必须绑定同一个账号 + 同一个工作空间。如果你用个人账号开的任务、想接力到企业账号的客户端上，目前是不支持的。
失效场景 3：离线接力
如果接力发起方处于离线状态（比如 Mac 盖上盖子睡觉），接力会被挂起、而不是立即生效。需要等发起方重新联网后才会推送。
把这 7 个场景放在一起看：WorkBuddy 的跨端接力是「能用的补充能力」，不是「无缝的协作能力」。把它当成「紧急情况下救急」的工具，不要把它当成「日常主力」的工具。
六、结论：三端怎么选
最后给一个可执行的「选哪一端」的判断依据：
- 设计公司 / 独立咨询 / 内容创作者 → Mac 端（独占功能最多，体验天花板最高）
- 央国企 / 政务 / 信创采购链 → Windows 端（企业场景最完整）
- 服务器运维 / CI/CD / 远程开发 → Linux 端（无头模式最成熟）
- 跨端协作需求强的混合团队 → Mac + Windows 双端（Linux 作为服务器补充）
如果你正在评估「要不要把 WorkBuddy 推广到全公司」，建议先做一件小事：让你的 IT 在三端各装一个 WorkBuddy 客户端，让 3-5 个核心用户实测 2 周，再根据真实反馈决定主推哪一端。不要只看官网的「全平台支持」就下单——三端的真实差异，比官网介绍的大。
下一篇文章里，我会拆 WorkBuddy 「完全访问」模式的真实权限边界、给企业 IT 的合规自查清单。这两篇文章加起来，构成了 2026 年 10 月评估 WorkBuddy 的完整决策框架。
参考来源
- WorkBuddy 官网客户端下载页：<https://workbuddy.tencent.com/download>（2026-10-06 访问）
- CodeBuddy 帮助文档「客户端矩阵」：<https://help.codebuddy.cn/workbuddy/platforms>（2026-09-30 更新）
- GitHub Releases：codebuddy-cn/workbuddy-client v3.4.2（2026-09-28）、v3.4.0（2026-09-21）
- 本文作者实测环境：macOS 26.6.2 arm64 + Windows 11 23H2 (Build 22631) + Ubuntu 24.04 LTS x86_64
<!– project: path:/Users/kevin/.openclaw/workspace-timew –>
