把 WorkBuddy 和 Codex 放在一起比较，前提就先错了一半。两者官方定位一个是「全场景职场 AI 办公工作台」，一个是「coding agent」，交付物根本不是一回事。workbuddy和codex区别的关键不在功能表，而在三条赛道的分工，以及那 3 处真实的交叉。 两者的区别先看官方那两句话
两边的官方文档里，定位这一层都写得非常短。WorkBuddy 官方产品介绍写的是「腾讯推出的全场景职场 AI 智能体桌面工作台，适配全职场角色使用」，首页副标题是「AI Agent 办公新范式」。Codex 的官方仓库首行写的是「Codex CLI is a coding agent from OpenAI that runs locally on your computer」，帮助中心那篇进一步写成「an AI agent that helps you write, review, and ship code」。
把两句并排看，主语一个是职场角色，一个是代码。
定位差异会落到具体设计上。WorkBuddy 强调「授权本地文件夹读取权限」与「交付可验收的成果」，Codex 强调「在你自己电脑上本地运行」。前者把电脑当资料柜，后者把电脑当开发机。
| | | |
|---|
| | | |
| | | |
| | | |
| 桌面端 + 网页 + 手机 App + 微信小程序 + 微信客服号 | | |
| | | |
两边都说自己有云端，但云端在各自体系里的位置不一样。WorkBuddy 官方把移动端与小程序写成「双模式执行」，云端工作与连接电脑可以随时切换，后者的作用是远程操控桌面端继续干活；Codex 那边的表述是本地覆盖命令行、IDE 扩展与桌面工作流，云端承接的是被委托出去的任务。
交付物不同：一个交办公稿，一个交代码
最实际的一条分界是问自己一句：要交出去的东西是文件还是代码。
WorkBuddy 官方列出的适用场景包括文档生成、数据分析、PPT 与报告生成、深度研究、邮件与周报，以及批量文件处理。它的官方能力清单里写的是「多模态任务处理：支持文档、表格、PPT、数据分析等多种任务类型」。
Codex 这一侧，README 里把它叫 coding agent，官方帮助文的动词是 write、review、ship 三件事，全部围着代码转。它也确实有代码之外的构建能力，比如官方提到 Sites 可以在 Codex 里把想法变成网站并拿到预览，但那本质上是代码的延伸，而不是 Office 交付物。
Codex 官方帮助文自己就写明了：用户如果想要的是「longer research and deliverable tasks」，官方让他去看另一个产品。办公交付物这件事，OpenAI 也没让 Codex 来承担。
同门对照：各自真正的对手不是对方
两家的产品线是同构的，只是国内用户常常只看到其中一半。
腾讯这边，WorkBuddy 之外还有一条编码线 CodeBuddy，WorkBuddy 自己的官方文档就写得很直白：进行代码开发时，WorkBuddy 支持读取项目工作目录下的 .codebuddy/ 项目级配置，「行为与 CodeBuddy Code 保持一致」；斜杠命令补全也写明「与 CodeBuddy Code 一致」；云端 Agent 的环境字段里，有一项直接叫「CodeBuddy 初始化命令」。同一个文档站里还并列着 CodeBuddy 云端的说明。
OpenAI 这边的分工同样明确。Codex 是编码 Agent，办公与交付物类任务指向 ChatGPT Work；两边共用同一份额度池，官方原文写的是 Codex、ChatGPT Work、ChatGPT for Excel 与工作区智能体「use a shared allowance and credit pool」。
按这张表看，把 WorkBuddy 拿去和 Codex 对比，相当于拿办公台对比编译器。该横向比较的两组，是 WorkBuddy 对 ChatGPT Work、CodeBuddy 对 Codex。
重叠区：两边都能做的事有3类
说「完全不同」也不准确。有三处是两边都能接的。
第一类是代码开发。WorkBuddy 文档里有一页专讲 Git 集成与并行开发，开头就写明「这是 WorkBuddy 开发者体验能力的一部分」。当工作空间里包含 Git 仓库时，创建任务即可看到当前分支并切换；需要同时推进多个任务时，可以开 Worktree，系统会在独立目录下建一个任务分支，命名形如 workbuddy/main-8位哈希，与手动建的分支区分开。WorkBuddy 能接代码活，但官方把这部分定位成「开发者体验」，不是主业。
这类并行任务有明确的数量约束。官方写的是达到 25 个时，首页在创建新任务时会提示数量较多、建议清理；达到 50 个则必须先选择清理范围才能继续创建，清理选项是 7 天、15 天或 30 天前的任务工作区。非 Git 项目根本不展示这个开关，只能创建普通任务。
第二类是沙箱与权限确认。两边都默认拦住越界操作、都提供一键放开，差别在于拦在哪一层。
第三类是扩展协议。两边都支持 MCP，项目指令文件这一层还出现了兼容现象：Codex 读 AGENTS.md，而 WorkBuddy 的官方说明里写着兼容「CODEBUDDY.md、.codebuddy/CODEBUDDY.md、AGENTS.md 及用户级 ~/.codebuddy/ 配置」。为 Codex 写好的项目说明，WorkBuddy 可以直接读，这是两边唯一有官方依据的互通点。
| | |
|---|
| Git 集成加 Worktree 并行任务，有数量上限 | |
| | |
| .codebuddy/ 目录体系并兼容 AGENTS.md；插件分五类 | AGENTS.md 体系；通过 MCP 接入外部服务 |
权限与沙箱怎么管：默认拦法不一样
两边都是「默认拦、越界问、可一键放开」的思路，但拦在哪一层差别很大。
WorkBuddy 提供两档：默认权限与完全访问权限。默认权限下，写入敏感路径、删除重要目录或批量删除、执行脚本命令、访问网络这几类动作会停下来让你确认；确认弹窗要重点看操作内容、影响范围和执行理由三件事。切到完全访问权限会关闭这些二次确认，而且是全局生效，当前客户端内所有任务都会跟着变，不跨设备同步。此外还有一层安全中心，可对沙箱、文件路径、命令前缀、网络域名分别配置白名单和黑名单，另有删除保护与批量删除审批。
Codex 这一侧是沙箱模式与审批策略两个维度组合。沙箱模式三档：只读、工作区可写、完全放开；审批策略里按需请求与从不停下两类，官方的默认低摩擦组合是「工作区可写 + 按需请求」。审批人还能选择是给用户还是交给评审智能体自动判断。
Codex 在工作区可写模式下，会把带 .git/ 或 .codex/ 的目录设为只读，所以 git commit 默认会失败，需要向用户申请权限。而 WorkBuddy 走的是另一条路：它把 Git 操作提前到任务创建那一刻，切换分支时如果工作区有未提交改动，弹窗直接给你三个选项，提交到当前分支、暂存变更、丢弃变更，默认选中最安全的提交。
拦在命令执行层的，适合习惯命令行的人；拦在任务发起前的，适合不想碰终端的人。
扩展与配置能不能互相沿用
两边都靠「装东西」扩容，但容器不一样。
WorkBuddy 的插件分五类：Skill 加领域能力、MCP 接外部服务、Hook 在特定时机自动执行、Agent 提供专门的任务处理能力、Rule 定义行为规范。技能的启用状态记录在用户全局配置里，可随账号在多设备间同步，关闭技能不会改动技能原文件。
Codex 的扩展集中在配置层面，项目指令走 AGENTS.md：全局那份放在 ~/.codex/ 下，项目那份从仓库根目录一路检查到当前工作目录，越靠近当前目录的文件越靠后拼接、优先级越高；同名覆盖文件是 AGENTS.override.md。合并后的总大小有上限，默认是 32 KiB，超出部分会被截断。
两套体系的写法不同，但都建立在纯文本约定上，迁移成本主要是改目录名和文件名。
workbuddy和codex的注意事项
- 先想清楚要交的是文件还是代码。这是选哪一个最快的判据，比对着功能清单逐条比更省事。
- 不要指望两者互相替代。WorkBuddy 的代码能力是「开发者体验」的一部分，Codex 不做 Office 交付物，交叉覆盖的部分比宣传印象里窄。
- 完全访问权限是全局开关。WorkBuddy 切到这一档后，当前客户端内所有任务都会减少确认，且不跨设备生效，用完建议立刻关回去。
- 别在只有唯一副本的资料上开完全放开。官方列出的不建议场景包括生产资料、客户资料、财务资料，以及工作目录贴着桌面或下载目录的情况。
- Codex 的 git commit 默认会被拦。工作区可写模式下含 .git/ 的目录是只读的，提交代码需要额外授权，这不是故障。
- Codex 的 untrusted 审批策略已退役。旧配置里还留着这个值会导致启动报错，需要改掉。
- 额度用尽后等周期刷新，别指望客服补。Codex 官方明确写了支持团队不重置用量上限，WorkBuddy 的积分也是按月发放、当月有效不累积。
- AGENTS.md 可以两边共用，但别期待行为完全一致。WorkBuddy 是「兼容读取」，两边的加载顺序与合并上限各有一套规则。
- 两边的能力边界都在变，选型前看当期说明。产品线会调整，型号与档位以各自官方页面实际显示的为准。
workbuddy和codex区别常见问题
Q：workbuddy和codex区别能用一句话说清吗？
A：能。前者是交付办公文件的办公工作台，后者是交付代码改动的编码智能体，两者不在同一条赛道上。
Q：那为什么很多人把这两个放在一起比？
A：因为两家都把「自动干活」放在宣传首位，加上国内用户常只看到其中一条产品线，就容易把办公智能体和编码智能体当成同类竞品。
Q：WorkBuddy 真正的对标产品是谁？
A：按官方分工看是 ChatGPT Work 这一类办公与交付物助手；Codex 那一侧的对标是腾讯自家的 CodeBuddy。
Q：WorkBuddy 能写代码吗？
A：能。它有独立的 Git 集成与 Worktree 并行任务，官方把这部分定位成「开发者体验能力」，但项目类型仅限 Git 仓库，非 Git 项目不支持。
Q：Codex 能做 PPT 或表格吗？
A：不作为主线能力。官方把研究与交付物类需求指向 ChatGPT Work，Codex 的定位表述是写、审、交付代码。
Q：两边的项目规则文件能通用吗？
A：可以部分通用。Codex 读 AGENTS.md，WorkBuddy 明确写了兼容 AGENTS.md，但两边的加载顺序与合并上限各有一套规则，复杂配置仍需分别调整。
Q：都是「默认拦、越界问」，管理方式一样吗？
A：思路一样，拦的位置不同。Codex 拦在命令执行层并区分沙箱三档，WorkBuddy 则把权限分成两档，还把 Git 操作提前到任务创建时确认。
Q：哪个对新手更友好？
A：看背景。不写代码、要交文档表格的人适合 WorkBuddy，多个入口加图形界面；以仓库为单位工作的人适合 Codex，CLI 与 IDE 扩展更顺手。
Q：两个都装会冲突吗？
A：不冲突，工作对象和配置目录都不同。只要注意各自的额度是分开计的，不要拿一边的余额去估另一边的成本。
workbuddy和codex区别最终落在各自被设计来交付什么，而不是功能表的长短。按官方分工找到自己那一格，就不必在两条赛道之间反复权衡；想跟进这两条产品线的后续调整，可以关注本站的 AI 工具栏目。
AI 速览
