一文讲透 WorkBuddy 和 CodeBuddy 到底有什么区别

起因：越搜越乱

我最近在研究腾讯的 WorkBuddy，想搞清楚这个工具到底能干什么。但搜着搜着，事情开始变得奇怪。

打开 WorkBuddy 的官网，域名写的是 codebuddy.cn。点进文档，链接里满眼都是 codebuddy。登录页面挂在 copilot.tencent.com 下面。客户端打开之后，登录入口还分中国站和国际站。再一搜网上的文章，有人说 WorkBuddy 是办公工具，有人说 WorkBuddy CLI 对标 Claude Code，有人说 CodeBuddy 和 WorkBuddy 是两个独立产品，有人又说它们共享一套会员。

WorkBuddy 和 CodeBuddy 到底是一个东西还是两个东西？中国站和国际站又是怎么回事？

花了不少时间把这些全理清楚了，今天一次性说透。

第一层：它们压根就是一家人

答案其实就藏在那些让人困惑的域名和代码里。

WorkBuddy 中国站的文档地址是 codebuddy.cn/docs/workbuddy/，登录走的是 copilot.tencent.com，两者共享同一个账号和 Credits 积分池。买一份会员，两个产品都能用。WorkBuddy 的智能体内核，直接继承自 CodeBuddy 团队的技术底座。

所以 WorkBuddy 并不是一个独立于 CodeBuddy 的产品。它是 CodeBuddy 产品矩阵里的一个成员。

社区里有人用"一个底座，四个入口"来概括整个产品关系。底座是腾讯云的 AI 智能体内核（混元大模型 + 任务拆解引擎 + 工具调用框架 + 多 Agent 协作能力）。四个入口分别是：

CodeBuddy IDE，一个基于 VS Code 底座的独立桌面编辑器，也就是 GUI 形态

CodeBuddy 插件，嵌入 VS Code 或 JetBrains 系列 IDE 里用

CodeBuddy CLI，命令行工具，也叫 CodeBuddy Code

WorkBuddy，桌面 AI 办公智能体

四个入口，同一套后端能力，通过不同的前端界面暴露给不同类型的用户。

紧接着来了第二个问题：既然是一家人，为什么要拆成两个独立客户端？它们之间的区别到底在哪？

第二层：网上说的全是错的

搜到的大多数文章都会给出一个简单的结论：CodeBuddy 是给程序员写代码的，WorkBuddy 是给职场人做办公的。

这个说法太表面了，经不起追问。

WorkBuddy 官方场景里本来就包含代码开发模式，它能写代码、能生成完整可运行的项目。反过来，CodeBuddy IDE 的"对话即编程"模式，产品经理拿来做原型也完全没问题。

如果两边都能写代码也都能处理文档，那真正的区别到底在哪？我们发现区别体现在三个层面，而且这三个层面是层层递进的。

第三层：真正的区别

交互范式不同

这是最根本的区别。

CodeBuddy 的 IDE 和插件形态，工作方式是人和 AI 一起看着代码协作。AI 在编辑器里做行间补全、做内联 diff，人始终能看到每一行代码，随时可以介入修改。这是 copilot 模式，人在循环中，AI 打辅助。

WorkBuddy 的工作方式完全不同。用户在对话框里用自然语言描述一个需求，比如"帮我把这份 PDF 里的数据提取出来做成 Excel 表格"，然后 WorkBuddy 自己拆解任务、调用工具、操作文件，过程对用户来说基本是黑盒。这是委托模式，人下指令，AI 自主执行。

WorkBuddy 背后该写代码一样得写代码，该调工具一样得调工具。但这些细节被隐藏了。用户不需要理解目录树、终端、Git 这些概念，只需要描述想要什么结果。据社区文章说，超过一万名非开发者在硬用 CodeBuddy，他们忍着看不懂的目录树和终端在硬撑。WorkBuddy 就是为这些人（以及他们背后更大的市场）专门设计的入口。

默认权限边界不同

CodeBuddy 有一套精细的沙箱机制和权限配置系统。从官方文档可以看到，它能精确控制 AI 可以读哪些文件、写哪些目录、执行哪些命令。比如可以配置 "allow": ["Read", "Edit(src//.ts)", "Bash(npm:test)"]，同时 "deny": ["Edit(/.env)", "Bash(rm:)", "Bash(sudo:)"]。沙箱模式下，AI 默认只能在当前项目目录和临时目录内写入，超出范围需要额外授权。

WorkBuddy 的典型任务场景长这样："把 D 盘那份 PDF 和 E 盘那份 Excel 合到一起""帮我整理桌面上 500 个混乱的文件按类型分类归档"。这些任务天然就需要跨目录操作，所以 WorkBuddy 对文件系统的默认访问范围要宽得多。

这里有一个容易混淆的点需要说清楚：项目工程当然也在本地文件系统上，两者是重合的。区别不在于"一个能操作文件一个不能"，而在于产品默认允许的操作范围大小不同。CodeBuddy 技术上也能写一段 Python 脚本去整理桌面文件，但沙箱默认会拦住。这是产品策略的选择，不是技术限制。

前端形态不同

CodeBuddy 活在编辑器或终端里，以代码项目为单位组织工作。WorkBuddy 是一个独立的桌面应用，以任务为单位组织工作。

而且 WorkBuddy 还多了一个 CodeBuddy 完全没有的能力：Claw 远程控制。

Claw 是 WorkBuddy 内置的远程操控功能。简单说，就是把 WorkBuddy 和手机上的 IM 工具打通。电脑上跑着 WorkBuddy 客户端，通过 Webhook 或 API 对接到企业微信、微信、QQ、飞书、钉钉（国际站还支持 Slack、Telegram、Discord），绑定之后，在手机的聊天窗口里给机器人发一句指令，消息就会转发到电脑上的 WorkBuddy 进程。WorkBuddy 在本地执行任务，用的是本机的文件、Shell 环境和权限，执行过程和结果实时回传到手机聊天窗口。

前提是电脑得开着、WorkBuddy 得在后台跑着，因为所有任务都在本地机器上执行。

场景大概是这样：在外面开会，掏出手机在微信里发一句"帮我把昨天的周报数据整理一下发到我邮箱"，办公室的电脑就开始自动干活，干完了结果出现在微信对话里。加上小程序和移动端 App，WorkBuddy 总共覆盖了九个远程入口。这个能力 CodeBuddy 的任何形态都没有。

几个绕不开的追问

理解了上面三层区别之后，有几个问题大概率还是会冒出来。我们当时也问了同样的问题，干脆一起说清楚。

"AI 自己写代码就行了，没有代码补全有什么关系？"

如果是让 AI 从零开始生成一个全新项目，确实不需要代码补全，WorkBuddy 完全能干。

但如果是在一个已有的十万行代码库上做日常开发，需求变了。AI 需要理解现有代码的上下文，补完正在写的那一行，给出精准的内联 diff，跟开发者在具体的代码行上来回讨论。这时候 IDE 集成、项目上下文感知、语法高亮这些能力就成了效率关键。WorkBuddy 的对话框界面覆盖不了这种场景。

所以这不是"能不能"的区别，而是"在什么场景下效率最高"的区别。全新项目让 AI 自己跑，WorkBuddy 没问题；大型已有项目里做增量开发，CodeBuddy 的 IDE 和插件形态效率更高。

"CodeBuddy 写代码也能操作文件啊，为什么做不了整理 500 个文件？"

技术上确实可以。CodeBuddy CLI 写一段 Python 脚本来批量操作文件，完全没有障碍。

但产品的沙箱默认限制了写入范围，只允许在项目目录和临时目录内操作。让它去碰 ~/Desktop 或 D:\Documents，默认配置下是被拦住的。当然可以手动放开权限配置，但那已经不是产品的默认体验了。

WorkBuddy 的产品设计就是为了"操作整台电脑上的文件"这个场景而生的，默认权限边界就更宽。

"Claude Code 一个产品什么都能干，为什么腾讯要拆成两个？"

这个问题其实是整件事里最值得想的。

Claude Code 确实把编程和文件操作放在了同一个产品里，通过权限和沙箱在内部管理边界。腾讯的做法是一开始就拆成了两个完全独立的客户端，甚至不能同时运行，会端口冲突。

从公开信息来看，拆分有几个原因。开发者习惯看代码、看终端，非技术人员看到目录树和终端会直接懵掉，两拨人塞在同一个 UI 里体验互相打架。安全策略也有矛盾，面向开发者的工具需要默认收紧权限（沙箱保护代码安全），面向办公的工具需要默认放开权限（要能操作整台电脑），这两种默认策略共存在一个产品里容易出问题。再加上商业上两个产品可以各自对标不同竞品、覆盖更大市场。

但说到底，这是产品策略的选择，不是技术上必须这么做。

行业视角：大家都在往同一个方向走

腾讯把编程 Agent 和办公 Agent 拆成两个产品，这个思路并不孤立。

Anthropic 的 Claude Code 后来孵化出了 Cowork（现在叫 Claude Cowork），面向非开发者用户。字节的 Trae 也从开发者专属工具升级成了 Trae Work，Code 模式加 Work 模式双核驱动。

整个行业都在做同一件事：编程智能体先做成熟（因为代码场景的任务验证更明确、成功率更高），然后把积累的 Agent 能力迁移到通用办公场景，再给非技术用户一个更友好的入口。

所以 CodeBuddy 对标 Claude Code，WorkBuddy 对标 Claude Cowork，这个对应关系是清晰的。社区里直接有人说"CodeBuddy CLI 就是 Claude Code 的去风险版，同样的 Claude 能力，走合规通道"。国际站的 CodeBuddy CLI 底层确实支持直接调用 Claude 模型。

两种产品思路也有差异。有人做过专门的对比：WorkBuddy 更像 Android，开放、可定制、支持多模型、多 IM 接入、Skills 生态可无限扩展；Claude Cowork 更像 iOS，封闭、体验统一、单模型深集成、零依赖安装。格局基本一致，只是拆分方式和品牌策略不同。

还有一层混乱：中国站和国际站的命名完全打架

前面的问题都理清了，但还有一层命名混乱需要单独拎出来说，因为不知道这个，读网上的文章会一直晕。

中国站（codebuddy.cn）的叫法是：IDE / 插件 / CLI 三种形态统一叫 CodeBuddy，桌面办公智能体叫 WorkBuddy。两个名字，两个产品，很清晰。

国际站（workbuddy.ai）把整个产品家族统一叫了 WorkBuddy。于是国际站上出现了"WorkBuddy IDE""WorkBuddy CLI""WorkBuddy 插件"这些说法。这些东西在中国站全叫 CodeBuddy。

这就是为什么有些文章说"WorkBuddy CLI 是 Claude Code 的去风险版"。这里的 WorkBuddy CLI 其实就是中国站叫的 CodeBuddy Code，同一个东西换了个品牌名。不了解这层命名差异，读起来会非常混乱。

顺便说清楚：四种登录入口是怎么回事

打开 WorkBuddy 客户端，会看到四个登录选项，对应完全不同的服务和计费体系。

中国站登录，走 copilot.tencent.com，微信扫码就能登。国内模型为主（混元、DeepSeek、GLM、Kimi 等），积分可以通过签到和运营活动免费积累，人民币定价。个人版四档，体验版限时免费。

国际站登录，走 www.workbuddy.ai，在浏览器里用邮箱、验证码、GitHub 账号登录。内置 Claude、GPT-5、Gemini 等国际模型，不用翻墙就能用。美元定价，大额积分主要靠月订阅。

这两站的账号体系是独立的，定价也是完全独立的两套体系，档数不同、档名不同、每档积分数不同。不能做档位对应，也不能做汇率换算。

另外两个入口是企业版。企业旗舰版是 SaaS 云服务，通过腾讯统一身份认证登录（手机验证码 / 邮箱 / SSO），￥198/人/月起，1 坐席起购。企业专享版是私有化部署方案，使用独立客户端，账号密码登录，数据完全不出域，面向金融、政务等对安全要求极高的行业，￥316/人/月起，100 坐席起购。

写在最后

CodeBuddy 和 WorkBuddy 的关系，与其说是两个产品的区别，不如说是同一套 AI 能力在面对不同用户群时必然出现的前端分裂。编程 Agent 和办公 Agent 在底层技术上正在快速趋同，区别越来越集中在交互范式和权限策略这两个维度上。

至于腾讯选择拆成两个独立客户端，而 Anthropic 选择在一个产品里通过模式切换来覆盖，哪种做法更好，现在还很难下结论。这个赛道变化太快，半年前的判断半年后可能就过时了。唯一确定的趋势是：编程 Agent 的边界正在向通用办公扩张，通用办公 Agent 的能力正在向编程场景渗透，两者最终大概率会在同一个产品里合流。

只是那一天到来之前，我们得先搞清楚现在这一堆名字都是什么意思。希望这篇文章帮大家省了这个时间。

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。