最近给一家公司做 AI 能力线下培训，深刻领悟到：对国内多数团队来说，WorkBuddy 比 Codex 更加适合。

我们早期课程用的是 Claude Code，这个工具能力很强，但命令行上手门槛相对陡峭。后来为了照顾部分非技术同学，我们又快速切换到了 Codex，可视化界面操作相对命令行友好太多了，门槛降低了很大一截。

但是，对于线下培训，又有些不太一样。

大家使用的电脑多数都是windows，而且很多是公司电脑，受安全权限管控，环境非常复杂，每个人遇到的问题可能都不同。第一天我们光是处理安装、账号、网络和环境问题，就花了挺多时间。

后来果断切换到 WorkBuddy，整个培训过程就顺畅多了。

于是，很多同学就问：WorkBuddy 能不能平替 Codex？

这篇文章，就从安装门槛、模型能力、使用成本、产品形态、生态整合、项目协作、安全策略和记忆机制几个方面，具体看看 WorkBuddy 和 Codex 到底有什么区别。

从安装到使用

workbuddy从下载到使用，在电脑不卡的情况，1分钟左右是可以搞定的，没有任何门槛。

codex就有点难度了，首先得有科学上网工具，你才能访问openai的网站去下载ChatGPT（Codex），这一步就拦住很大一部分人了。

安装完成后有两种使用路径：

路径一、官方订阅方式

1. 需要注册ChatGPT账号，目前最好的路径是使用Google 邮箱，但是当前google邮箱注册流程中增加了手机扫码确认，大多数情况都会失败。

2. 账号搞定之后，还要订阅会员，直接走官方订阅需要海外信用卡才能支付，很多同学是没有的。

路径二、接入国内模型

这种路径，不需要账号和订阅，可以通过CC-Switch接入国内模型，但是这种方式还有个问题，部分Token Plan或者Coding Plan接入进来，接口不兼容，还是没法用。不过说实话，你在Codex中用国内模型还不如直接workbuddy。

上面两种方式，每一步都是障碍，对于新手来说可能得一个小时才能完全搞定，比如这个CC-Switch就足够把很多人干晕了…

但其实Codex最大的门槛也就在这个环节了，这一步解决了，后续的整个使用方式跟workbuddy都相差不大了。

模型能力

两者都是桌面端通用Agent，除了工具本身架构差异外，决定其能力上限的核心是模型能力，我们知道国内和国外的模型能力还是有一定差距的。

Codex用的是GPT5.6系列，是当前OpenAI的旗舰模型，能力与Claude 4.8 Opus相当。而workBuddy提供的是国产模型，包括GLM5.2、Kimi k3、MinMax m3、deepseek-v4-pro、Hy3等，另外还支持自定义模型。

如果只是执行一些简单任务，可能感受不出具体的能力差异，但是执行复杂任务的时候，就能明显感受到模型能力差异还是很明显的。

这里不要只看模型打榜数据，要看进入实际生产环境的能力表现。

上周让workbuddy帮我初始化一个前后端项目，我指定了前端项目使用pnpm安装依赖，执行过程中遇到pnpm安装某个依赖版本出错，workbuddy反反复复进行修复40分钟，一直在循环：

我发现了xxx问题 -> 我尝试修复 -> 修复失败，等我吃完饭回来，发现消耗了我400个积分，然后啥功能也没有干成。

然后把同样的提示词给到Codex，5分钟左右完成了项目初始化搭建，我翻看执行过程，同样遇到了workbuddy遇到的问题，但Codex定位错误原因时做了根因分析，找到了根本性问题，然后一次性进行了修复。

在模型能力这块，Codex明显更加有优势，执行复杂任务时，它交付的质量就是更好，节约更多时间，甚至让我们少走一些弯路。

使用成本

从使用成本上来说，Codex的订阅费用肯定要贵一些，个人购买分为三个档位：

它是按照每周额度进行下发，如果消耗完了，就要等下一个重制周期，但是OpenAI最近时不时的就会给用户重置额度，订阅Plus的用户基本可以达到双倍用量。

而Workbuddy的订阅，按连续包年的价格是最划算的，也是三个档位：

另外，workbuddy每天可领取100积分，在套餐基础上可额外增加3000积分左右。

从使用体验来看，workbuddy的积分消耗非常快，特别是在做编程类任务时，一个中等复杂度任务执行完成需要几百积分，标准版本干不了几个任务积分就没了，价格便宜但是不咋耐用。

无论使用workBuddy还是Codex，想要省着用额度的话，最好根据不同复杂度的任务切换不同的模型，比如简单任务，用Deepseek-V4-Pro、复杂任务才用GLM5.2、Kimi-K3，而不是一股脑的用最贵的模型，这样可以利用特定的额度做更多的任务。

产品形态及稳定性

Codex支持桌面端App、命令行工具、编辑器插件、Cloud环境等方式使用，分别面向不同用户人群和使用场景。

而Workbuddy大家可能只知道桌面端App，其实背后还有Codebuddy IDE、Codebuddy CLI、编辑器插件，只不过Codebuddy更面向编程场景，Workbuddy面向办公场景，他们的订阅套餐都是同账号共享的。

在稳定性这块，Codex做得更好，毕竟它出来得更早，出现的bug都已经被修复得差不多了，从使用以来没有出现影响体验的bug。

workbuddy只能说还在追赶的路上，目前经常会出现任务执行报错、执行中断、界面显示异常等情况，不过随着持续迭代，这些问题应该会被逐渐解决。

生态整合

如果只看单点 Agent 能力，Codex 的模型能力和任务执行质量更强；但如果放到国内企业真实办公环境里，WorkBuddy 在生态整合上的优势非常突出。

workbuddy定位全场景的AI 办公工作台，天然打通了腾讯办公生态，可以无缝连接企业微信、微信、腾讯文档、QQ邮箱、腾讯会议、IMA知识库、乐享知识库等常用办公工具。

除此之外，Skill商店、连接器市场还存在大量腾讯生态体系中的产品服务，这对于本身就在使用腾讯系的办公OA工具的公司来说，是非常友好的。并且Skill的安装和连接器的安装体验，workbuddy是真的做到了零门槛。

下面我再看看几个其它的重要功能差异。

项目与任务的协作

Codex APP 和workbuddy都是非常经典的三栏布局：左侧是任务列表，中间是对话窗口，右侧是多功能区域，这种交互形式已经成为了桌面Agent的行业标准共识。

因为可以很方便的管理多个项目和任务，并观察每个任务的运行状态，还能快捷地在多个任务之间自由地切换。

在Codex和workbuddy的逻辑里，左边这栏分为两层：

第一层是空间

可以把它理解成一个个项目文件夹，或者一个个主题工作区，比如项目A、项目B、项目C，我们新建任务时需要选择一个工作空间。

第二层是任务

点开某个空间项目，会看到里面一条条对话，这些对话记录叫线程，每一条线程就是一个独立的任务。

所以整体关系是，一个空间项目里可以有很多个任务，每个任务是在同一个工作区里，围绕一个明确的目标执行。

如果新建一个任务，不选择任何空间项目，这种就相当于是临时性问答，这个任务会被收录到对话（任务）这一栏里面。一般用它做调研、做规划和一些零碎的问答性小任务。

然后不同的是，workbuddy支持团队化项目协作，而Codex是不支持的。

比如有一个项目，需要多人协作，A负责一部分功能，B负责一部分功能，按照Codex的方式，我们只能通过Git进行项目产物同步。

而workbuddy的做法是通过新建一个项目，这个项目也是基于某个工作空间，它直接把这个项目需要用到的指令、连接器、专家、技能、自动化进行统一配置，并共享项目计划、任务状态、项目资产、上下文信息，唯一要做的是把协作对象拉入这个项目即可，所有关于项目的信息通过云端实现共享，大家可以在同一项目中进行协作。

同项目并行执行多任务

在不同项目中我们可以并行执行任务，在Codex和Workbuddy中都没有任何问题，因为他们不存在文件冲突。但是如果在同一项目中，并行执行多个任务，如何保证这些任务执行时不会出现文件冲突呢？

这里先说结论，Codex可以通过内置功能Worktree实现，而workbuddy暂时还办不到。

Codex新建任务时，可以选择启动模式，包括Work Locally和Worktree， Work Locally顾名思义就是在本地工作目录中工作。如果项目中多个任务并行执行，都使用Work Locally，这些任务都在修改同一个本地文件夹中的内容，极有可能冲突，那么Work Locally肯定就不能满足。

对于并行任务，Codex中可以使用WorkTree来解决，它是用 git 创建一个新的分支，然后把这个新分支的代码完整地复制到一个新的文件夹里面，这个新文件夹就是一个 WorkTree，它们在底层通过 git 关联，是可以随时合并回去的。

那主文件夹和分支文件夹就可以并行工作，在两个文件夹里面各自修改代码，互相不干扰。甚至我们可以基于主干创建多个Worktree，让多个任务并行执行。

但是要注意，使用worktree的前提是，你当前的项目需要先初始化为一个Git仓库，否则无法使用。

安全执行策略

Codex 的权限控制全部是围绕沙箱来展开的，它是整个权限系统运行的地基。权限分为三个档位：

默认权限

Codex 会把当前的项目文件夹作为一个沙箱进行管理，在默认权限下面，Codex 具有读取修改沙箱内所有文件的权限，不会频繁的让你确认。

但Codex 沙箱有两个默认限制，不能修改沙箱外的文件和禁止联网。

如果 Codex 需要修改沙箱外的文件，或者需要联网，就需要向用户申请权限，这个操作叫做 提权操作。

在默认情况下，提权操作都是需要人工审核同意。

自动审查

开启自动审查，Codex 会自动调用一个小模型，对提权操作进行安全性审查。如果发现是低风险的操作，就会直接放行，只有高风险的操作才会触发人工审查。

这个挡位使得绝大部分操作不需要人工审批，在获取了较高安全性的同时，还极大提升了使用的便利度。所以一般情况下，在权限管理这里，都推荐使用自动审查。

完全访问

开启完全访问权限以后，Codex 会无视沙箱的限制，可以在电脑上执行一切操作，它完全不会跑来烦你。如果你想让Codex全自动跑任务的时候，开这个挡位是最爽的。

而Workbuddy的设计，沙箱安全机制是可以选择性开关的，开启后，跟Codex的安全机制基本一致，但是只有两个档位，分为默认权限和完全访问权限。在界面设置上提供了更多安全性设置功能。

记忆机制

记忆是Agent的标配，无论是Codex还是workbuddy都有，整体层级分为项目记忆和全局记忆。

1. 全局记忆，适用所有项目，这一层相当于定义顶层规范，告诉AI个人的做事原则、通用规则

2. 项目规则，仅当前项目有效，这一层告诉AI 这个项目的背景、有哪些约束规范、目录结构说明、项目启动命令、协作流程等。

Codex的记忆规则维护路径如下：

这也是当前主流Agent都默认支持的通用规范。

而WorkBuddy的记忆规则维护路径如下：

因此，同一个项目，如果记忆规则维护在AGENTS.md中，用workbuddy打开和用Codex打开都会默认加载到系统提示词中，但如果你是维护在.workbuddy/memory/MEMORY.md中，只有workbuddy能认识，Codex是无法识别的。

总结

回到前面的问题，WorkBuddy 能平替Codex吗？

结论是不能

我认为这两个Agent面向的是不同层级的用户、场景也不相同。

从模型能力、复杂任务执行质量、稳定性、开发者工作流、多任务并行能力来看，Codex 更强。尤其是在代码开发、复杂项目搭建、问题定位和工程化执行场景中，优势非常明显，它很适合技术人员和对交付质量要求较高的任务。

但如果放到国内多数企业的真实办公环境里，WorkBuddy 的优势更为突出。

它下载安装简单，上手门槛低，同时接入国腾讯办公生态，Skill、连接器、专家和团队协作能力也做得更可视化，很适合非技术团队快速使用。

我的建议是：技术团队、研发场景、复杂工程任务优先选 Codex；办公团队、非技术岗位、企业内部协作和腾讯生态较重的公司，优先WorkBuddy。