WorkBuddy 和 Codex 的核心差距在于：它们根本不是同一赛道的选手——WorkBuddy 交付的是文档（PPT、表格、调研报告），Codex 交付的是commit（代码改动）。所以问“差距有多大”，其实问法本身就偏了，有点像拿五菱宏光和 F1 赛车比加速，比的姿势不对，真要比得看在具体的路面上谁跑得动。
一、定位差异：一个给职场人，一个给开发者
WorkBuddy 是腾讯云 CodeBuddy 团队推出的全场景办公 AI 智能体工作台，面向 PM、运营、销售、市场、行政这批人，你在微信或企业微信里丢一句话过去，它在后台跑几分钟到几小时，把 PPT、表格、调研报告从同一个聊天窗口发回来。
它的核心能力包括本地文件全流程操作、多模态办公内容创作、专业数据处理与报表生成、跨平台远程控制（手机端远程操控电脑）以及定时自动化任务。
Codex 则是 OpenAI 的编程智能体，有终端 CLI、云端 Web 和桌面 App 几种形态，核心是读代码、改代码、跑代码，能在沙箱里并行处理多条任务线。
它对“完成”的定义是：把每一次改动都变成能审查、能撤回、能重新运行测试的 diff。
| 核心定位 | 全场景 AI 工作台 | 软件工程 Coding Agent |
| 默认优势 | 文档、数据、研究、PPT、本地文件 | 代码仓库、修改代码、测试、调试 |
| 主要上下文 | 文件、知识库、连接器 | 仓库、代码文件、Git 变更 |
| 典型输出 | 报告、表格、演示文稿 | 代码修改、测试结果、Review 结论 |
| 适合人群 | 运营、产品、内容、综合办公用户 | 程序员、开发者、研发团队 |
二、真正的差距在“壳”上，不在模型分
很多人以为 agent 的强弱就是模型的强弱，这个认知在 2026 年已经过时了。同一个模型只换外壳就能差十几分。
腾讯自己搞了个 WorkBuddy Bench，260 道真实工作题分代码、Web、办公、安全四类，7 个模型跑两套 harness。结果 Claude Code 在 28 组同模型对比里赢了 17 组，CodeBuddy 赢 11 组，代码类更是 7 比 0 被剃了光头，所有模型换到 Claude Code 上分都涨了。
OpenAI 那边的数据同样惊人：同一个模型在 ARC-AGI-3 上，外壳优化前后从 13.3% 涨到 38.3%，输出还省了六倍。
这背后藏着一个关键差异——任务有没有裁判。代码天生自带判卷老师：编译过不过、测试绿不绿、CI 挂没挂，全是客观信号，所以 Codex 敢放开手自己跑、自己错、自己修，错了回滚就行。
办公任务没有这个东西，你让它做一份竞品分析，谁来判定“对”？办公 agent 的天花板从来不在模型能力，在验收标准写得清不清楚。
三、底层路线的分野：纵向协同 vs 横向适配
WorkBuddy 和 Codex 在模型与 Harness 的耦合方式上也走了完全相反的路：
Codex 追求模型与 Harness 的纵向协同。 OpenAI 不只是把一个通用模型接到 Shell 上，而是让模型在训练和后训练阶段就适应 AGENTS.md 的指令结构、apply_patch 的差异格式、Shell 输出以及持续执行的 Agent Loop。
它追求的是让自家模型在这套行动轨迹中减少犹豫、误用工具和无效往返。2026 年 8 月 19 日 OpenAI 把整个 agent harness 完全开源了（Apache 2.0），连底层 Rust 的 codex-rs 和 app-server 驱动层都放出来了。
WorkBuddy 采用横向适配路线。 产品同时内置混元、GLM、MiniMax、Kimi 和 DeepSeek 等模型，还允许接入自定义 API 与本地 Ollama。
它首先要解决的是如何让不同能力、不同协议的模型，共用一套文件操作、办公制品、Skills、连接器、权限和任务编排体系。
前者追求纵向协同，后者追求横向可替换性——这是两条完全不同的产品哲学。
四、用户体验层面：速度差距明显
从实际使用体验看，WorkBuddy 最大的抱怨是慢。有用户反馈：同样的活别人 1 分钟能干完，WorkBuddy 得花 5 分钟。慢的原因主要有两点：
模型响应时间太长：指令发过去后，会看到它一直显示“正在等待模型响应”，这里得十几秒到一分钟；
模型思考时间过长：即使选了 Flash 模型（如 Deepseek v4.1 Flash、GLM 5.3 Flash），仍然会长时间思考，内心戏非常丰富，思考的时间比干活的时间长太多。
热衷于自动更新 Skill：每跑一次之后都会把遇到的新问题更新到 skill 里，导致 skill 里充满大量冗余 edge cases，文档越来越长，注意力涣散，消耗的 token 也越来越多。而 Codex 一个任务跑完了就跑完，立即交付。
所以说，简单任务上两者结果可能差距不大，但复杂工程任务很难完全替代。差距不只在模型能力，更在于：上下文理解方式、工具调用能力、权限控制、执行流程和结果验证机制。
Codex 把力气花在让每一次改动可审查、可撤回、可重跑；WorkBuddy 把力气花在把成品送进微信。模型的差距，配置一个 API Key 就能拉近一截；交活的方式，就不是加几个功能能补上的了。
