最近几个月，腾讯、字节、阿里、百度，几乎是前后脚，全都在推同一件东西——一个“能自己干活”的AI。
腾讯WorkBuddy早在3月就已经进入密集迭代，一路小步快跑到5.x版本；百度搭子DuMate3月22日全量开放；千问办公7月下旬整合QoderWork、悟空、MuleRun三条产品线，8月初开启公测；豆包工作则是8月25日才正式独立发布，发布前一天字节还专门把TRAE、扣子的团队并了进来。
时间线拉出来看，几乎是卡着节点在赛跑。
各家大厂说的话也高度一致：不再是“我问一句，AI答一句”，而是“我把事情交给你，你把结果拿给我”。
举个具体点的例子。让AI帮你做一份行业研究报告，过去的流程是它给你一个提纲、几条资料线索，写一版初稿——然后呢？你还得自己去搜网页、下数据、整理表格、画图表、排版PPT，最后把这一堆东西拼到一起。AI干的是“辅助”，真正“完成”这件事的还是人。
现在这几个产品想改的就是这一步。你可以直接甩过去一句“研究一下最近一个月AI Agent行业发生了什么，整理成报告并做成PPT”，剩下的事——搜索、筛选、写、画图、排版——它自己拆解、自己决定顺序、自己判断中间要不要调整。这中间真正难的不是“生成一段像样的文字”，是它得连续做对十几个步骤，还得在中途根据结果动态调整下一步该干什么。当然，真让它长时间干活，消耗的就不只是一次问答，而是额度、积分、订阅资源，或者你自己的本地算力。
这才是“聊天机器人”和“Agent”之间真正的分界线。
但如果把目光放远一点，会发现这条路线，Codex和ClaudeCode已经走了不短一段时间，而且走的距离比大多数人以为的要远得多——远到“AI编程工具”这个标签本身，已经装不下它们现在在做的事情。
办公类Agent到底跑到哪一步了，跟Codex、ClaudeCode之间的差距具体在哪，以及——这几家在架构选择上其实走了完全不同的路，而不是简单的“抄同一份作业”。
一、Codex和ClaudeCode，早就不是“写代码的AI”了
OpenAI在介绍Codex App时，已经不只把它写成一个传统意义上的编程助手，而是把它描述为“a command center for agents”——一个面向多Agent协作的指挥中心。
在介绍Codex App的时候，OpenAI的核心意思是：挑战已经从“Agent能做什么”，变成了“人该怎么去指挥、监督、协作一整支规模化的Agent队伍”——现有的IDE和终端工具，并不是为这种工作方式设计的。Codex仍然以软件工程为核心场景，但它的桌面应用已经明显在服务多个agent、并行工作流与长时任务：开发者开始跨项目编排多个agent，分派任务、并行运行，把可能持续数小时到数周的大型项目交给agent推进。
换句话说，一个人不再是“操作一台电脑”，而是在管理“一支数字员工队伍”。
Codex用GitWorktree解决了多个Agent同时改同一个仓库会冲突的问题——每个Agent有自己独立的工作区，人只需要最后看Diff、决定要不要合并。配合Skills和Automations，它已经可以按计划自动跑Issue分类、CI失败分析、日报生成这类重复工作。
Codex正在从“写代码的Agent”，变成“通过代码完成工作”的Agent。读Excel、抓网页、调API、处理PDF、跑脚本，这些事表面上不属于编程，但对Agent来说背后都能靠代码实现。两句话看着差不多，产品边界完全不是一回事——前者还是开发工具，后者已经在往通用WorkAgent上靠。
Claude Code走的是另一条更“重工程”的路。它现在已经形成了CLAUDE.md、Rules、Skills、Hooks、Subagents、MCP、权限系统、Worktree、后台Agent、AgentTeams这一整套基础设施——这套东西的专业说法叫Harness（挽具），可以理解成“围绕大模型搭建的一整套怎么干活的规则和脚手架”。
这里有个细节特别值得记一笔：Hook和Prompt有本质区别。Prompt本质上是“建议AI这么做”，Hook则是在已配置、未禁用且环境正常的前提下，某个事件一旦发生，对应脚本或规则就会被触发——比如强制要求代码改完必须跑测试、执行危险Shell命令之前必须拦截确认。它把AI的行为从“建议”往“制度”方向推了一步，这对真正要进企业生产环境的Agent来说，分量完全不一样。
所以Codex和Claude Code真正建立优势的地方，从来不只是“模型多聪明”，而是一整套“Agent工程能力”，即怎么拆任务、怎么管理上下文、怎么隔离环境、怎么在失败之后恢复、怎么让多个Agent协同不打架。这一层，才是真正的护城河。
两条路线，正在往中间汇合
有意思的地方也正在这里冒出来。
Codex和Claude Code是从软件开发出发，不断把能力往其他工作场景延伸；而WorkBuddy、豆包工作、千问办公、百度搭子是从文档、表格、浏览器这类办公场景出发，不断往里面加终端、代码执行、MCP和自动化。
一条从代码往外扩，一条从办公往里收，方向正好相反，但终点看起来是同一个地方。这一点后面聊完五个产品会再回来讲。
二、WorkBuddy先跑一步：从个人工具到企业级平台
如果只从产品动作的时间线看，WorkBuddy确实是国内跑得最早、迭代最密的一个。
它现在已经是腾讯云代码助手CodeBuddy产品线下的桌面Agent。3月开始，WorkBuddy进入了非常密集的迭代节奏：3月陆续补上专家中心、MCP、自动化定时任务、Bot集成和Skill市场；4月29日接入腾讯文档资料库（此前一天的4月28日，腾讯云先发布了计费方案调整公告，两件事日期相邻但不是同一件事）；6月前后继续补安全中心、沙箱拦截、文件版本、目录写保护、用量与计费展示等管控能力。这里更准确的说法不是“某一个月突然完成跃迁”，而是持续把办公、自动化、连接器和安全治理能力一层层补上。
较新的版本更新里，WorkBuddy加入了创建Worktree任务的能力——可以在同一个工作区里并行处理多个开发任务、代码改动互不干扰，并配了独立本地终端和后台命令运行面板；同一批更新还在持续修复长对话、连接器、MCP、任务切换和PPT/表格生成的稳定性问题。（这里没有标注具体版本号：不同下载渠道当前展示的版本号并不一致，8月20日、5.4.0这类具体数字目前只在个别转述来源里出现，没有查到官方更新日志的一手佐证，发布前如果要点名版本号，建议直接登录客户端查当天的“检查更新”记录。）这一变化说明WorkBuddy已经不满足于“办公聊天机器人”，开始往软件工程Agent的方向探。
WorkBuddy自己的说法是“跟开源的OpenClaw、Hermes类似，完全兼容这类Skills”。这句话要抠一下字眼：它字面意思是Skill格式兼容，不是代码或依赖层面的血缘——WorkBuddy是腾讯自研的闭源产品，跟OpenClaw之间目前没有能查到的代码或依赖关系，两者只是约定了同一套Skill的写法。看到“兼容”就默认“师出同门”，是这套判断方法里最容易踩的坑，后面讲DuMate的时候还会再遇到一次。
WorkBuddy真正的护城河，其实是腾讯自己的生态位：腾讯文档、腾讯会议、企业微信、微信生态，这些平台本来就攥着大量企业的日常协作数据。腾讯持续完善WorkBuddy相关产品与服务生态，已初步形成覆盖个人、开发者及企业级部署的智能体矩阵，路线是“把办公工具箱一件一件焊死在自己的产品体系里”。
也正因为这个定位，WorkBuddy吸引的更多是技术能力比较强、工作内容又不只是写代码的用户——产品经理、数据分析、运维、技术管理，喜欢折腾MCP、Skill和自定义模型的那一类人，会更容易发挥它的优势。
从我自己这段时间的使用体验看，WorkBuddy的完成度确实比预期高，尤其是在多模型、MCP、Skill和本地工具联动这些环节上，重度用户会很容易感受到优势。不过这句话只能算个人体验，不是通用评测结论；具体模型免费额度和活动政策，也要以发布当天官方页面为准。
三、百度DuMate：安全和血统，是两件被绑在一起讲的事
百度的产品叫DuMate，中文名“搭子”，3月22日全量上线。跟前面几家不太一样的地方在于，它在自我介绍和媒体传播里直接把“血统”摆到了台面上——多篇报道把它称为“首个国产企业级满血版OpenClaw”。这个措辞比WorkBuddy的“兼容Skill”要重得多，暗示的是更深一层的技术传承，而不只是接口层面的约定。但这中间的差别必须说清楚：公开资料能确认的是，百度及多家媒体使用了这个产品定位；至于代码复用、依赖关系、核心运行时继承到什么程度，目前没有看到可验证的公开证据。这一点暂时只能算“厂商自述和媒体转述的定位”，不能直接写成“查得到依赖关系图的血缘”。
DuMate真正花力气的地方是安全层。它通过预装安全沙箱实现与本机设备环境隔离，代码、任务、文件闭环执行，不影响本地环境、不扩散风险、不泄露数据；针对文件删除、系统修改、数据外发这类高风险操作，会强制要求用户明确授权后才执行，同时具备文件夹级权限管控和操作过程可查看、可追溯的能力。另有公开资料整理称其通过了信通院相关安全测评，但这类背书最好以证书或官方公告为准，本文不把它当成一手事实支柱。
这条路线背后是一个很直接的问题：当Agent真的能看屏幕、操作软件、登录系统、点击按钮、修改资料之后，“它敢不敢做”和“公司敢不敢让它做”是两件事。当问题从“AI能不能操作电脑”变成“AI凭什么可以操作、谁批准、出了事能不能追溯”，DuMate押的这条路线的重要性就会越来越明显。这个问题今天看着不起眼，未来很可能会变成企业Agent最重要的一层基础设施，因为权限失控的代价，远比一次任务失败严重得多。
四、千问办公：三条产品线合并出来的“全家桶”
千问办公（QwenWork）值得单独说一下，因为它跟前面几家的出场方式不太一样——它不是从零发布的新产品，而是公开资料中多次提到的三款产品整合之后重新亮相：QoderWork、悟空和MuleRun。关于QoderWork在阿里内部的规模、MuleRun此前面向哪些市场，更多来自行业报道和公开整理，不宜写成官方已确认事实。更稳妥的说法是：千问办公把办公文档、网页/应用生成、工作流自动化和专家能力打包到同一个入口里，重点是把多步骤任务封装成自然语言可配置、可重复触发的工作流。
千问办公现在已经补齐了一整套Agent基础设施：Skill不是模型也不等于外部工具，而是一份交给它的“专业工作说明书”——规定触发条件、输入、步骤、工具、输出标准、边界与异常处理，内置了pptx、xlsx、docx、pdf这类办公文件处理的示例Skill。
定时任务这块做得比较彻底：到了预定时间会自动新建一个对话任务，按写好的Prompt执行，并把结果保存在该对话里；每次触发时，它拥有跟手动对话完全一样的能力——调用MCP工具、使用连接器、运行技能、读写本地文件。也就是说，手动对话能干的事，定时任务基本都能干，这跟“到点自己醒过来”的Always-on Agent已经很接近了。不过它的调度仍依赖本地桌面客户端：如果电脑休眠或关机，任务无法触发。Hooks也已经支持，只是目前需要自己动手配置，比如拦截rm -rf这类危险命令。
值得记一笔的是它对“权限”这件事的态度：在连接器和企业数据场景里，可访问内容由当前账号原有权限、企业配置、用户授权与接口能力共同决定，使用千问办公不会自动提升权限；授权后可能执行真实动作，比如发送消息、生成写入文档、发起审批、公开发布、删除文件，执行前必须核对对象、内容、范围。这跟DuMate的安全沙箱思路不完全一样，但指向的是同一个问题：Agent权限一旦真实存在，就必须有边界。
千问办公的生态位很清楚：深度绑定钉钉，适合深度使用钉钉生态的企业、需要定时任务加多步工作流的场景、需要全栈网页交付、以及电商运营数据聚合的需求。随着Skill、MCP、Hook和定时任务不断补齐，它已经不只是一个写文档的AI，更像是在往完整的WorkflowAgent方向演进——对希望理解这套体系、又不想直接扎进ClaudeCode命令行的人来说，是个不错的过渡产品。
五、豆包工作：最晚发布，但护城河可能最深
豆包工作是这一批里发布最晚的，8月25日才正式独立成为一个品牌。但它的组织动作比产品发布更值得注意：发布前一天，字节跳动对旗下办公AI产品完成了一轮团队整合，TRAE、扣子（Coze）团队整体并入豆包体系，而在这之前，飞书产品团队与豆包产品团队已经整合，成立了新的豆包产品团队，飞书GTM团队也和火山引擎团队合并。
这个组织架构的调整，比功能列表更能说明豆包工作真正想干什么。
功能层面，豆包工作展示了四个核心能力：全栈内容生成，覆盖文档、表格、PPT、图片视频生成，乃至网页搭建和系统开发；操作电脑与浏览器，且全程可视化、支持随时暂停接管；长时间任务在部分场景下可以借助云电脑在后台继续跑；AI精准编辑，选中文档、PPT、网页里的具体位置就能“指哪改哪”，不用整篇重新生成；以及深度打通飞书，能接入企业沉淀在群聊、文档、会议纪要里的知识库。获得用户授权后，它能跨软件完成任务，用专业软件处理数据、浏览网页收集信息、填表单、比对资料；但“电脑关机后还能持续推进”应理解为云电脑/远程任务这类特定能力，不宜泛化成所有本地任务都能离线运行。
这套组合拳落到具体场景里是什么样？比如做一场新品发布，传统AI大概率只帮你写完发布稿就结束了。但一场发布真正要交付的东西远不止一篇稿子——还有发布用的PPT、产品图片、公众号推文、小红书文案，可能还要一段短视频脚本。市场、运营、新媒体、电商这类岗位，日常面对的就是这种“多材料、多形态”的任务，而不是单纯“给我一段答案”。豆包工作能把这些环节接得比较完整，靠的不是某一项能力做到全网第一，而是组合得够全——对大多数普通用户来说，“能把事情整体做完”往往比“允许你配置二十个MCP”重要得多。
但真正有杀伤力的，还是飞书。一个通用AI最大的短板，从来不是“不会写”，而是它不知道你公司昨天开会说了什么、哪份文档是最新版、谁负责哪个项目。每次用AI都要重新上传材料，这件事本身就是摩擦。豆包工作与飞书深度打通之后，在用户授权范围内，能够调用飞书的聊天记录、文档、会议纪要、日程等上下文来理解目标并判断问题，最终交付工作。
这意味着AI不再是一个外部工具，而是开始进入公司的“工作记忆”。未来企业Agent最关键的数据，很可能根本不是互联网上的公开数据，而是企业自己的上下文——这条护城河，飞书本来就有，字节现在把它接了进来。
六、跟Codex、ClaudeCode比，差距具体在哪
前面这四个产品放在一起看，基本已经从“能不能调用工具”的ToolAgent阶段，走到了“能不能自主拆解任务、串联多个工具”的WorkflowAgent阶段。真正的差距，不在于“有没有MCP”“能不能做PPT”这类功能清单，而是集中在四个更具体的地方。
第一，长任务的稳定性。 让Agent完成一个十分钟的任务，和让它连续运行几个小时，是完全不同的问题。任务越长，越容易出现上下文丢失、工具调用失败、错误不断累积、方向跑偏。Codex和ClaudeCode这两年在真实软件工程场景里踩的坑——阅读几百个文件、修改几十处、跑测试、发现错误、再改一遍——本质上都是在解决这一件事。国产办公Agent目前在十几步到几十步的任务上已经越来越稳，但真正超长链路上的可靠性，还缺足够的验证。
第二，Agent Harness的成熟度。 国内产品现在已经陆续补齐了Skill、MCP、Hook、Worktree这些组件，但“有这些功能”和“这些功能已经在大量真实项目里被反复验证、沉淀成一套工程方法论”，是两件不同的事。ClaudeCode这套Harness是被无数开发者在复杂Repository里连续使用、连续踩坑、连续修正出来的，这种工程积累没有捷径。
第三，真正的多Agent协同。 现在几乎每个产品都会提“多Agent”，但真正难的不是同时开三个任务窗口，而是谁负责拆任务、Agent之间怎么共享上下文、发生冲突谁来仲裁、某个Agent失败了谁负责重新分配、最后由谁判断整个任务算完成。这更接近组织管理问题，而不是简单的并发调用。国内产品目前大多还停留在“功能已经有”的阶段，成熟的Agent组织体系还没真正跑出来。
第四，后台持续工作，也就是Always-on Agent。 一个真正的数字员工不该要求你一直开着电脑：该在晚上自己跑任务，出异常自己检查，失败了自己重试，只在真正需要人拍板的时候才提醒你。Codex的Automations已经明显在往这个方向走，而国内不少办公Agent目前还比较依赖桌面客户端在线——千问办公的定时任务如果电脑休眠或关机就无法执行，就是一个具体例子。这一层很可能是接下来国产Agent最需要补的一块。
七、但国内的优势，也可能恰恰不在模型本身
只讲差距，对国内这几家也不公平。
因为它们手里握着一个Codex、ClaudeCode短期内很难复制的东西：企业办公生态本身。飞书、钉钉、腾讯文档加企业微信，这些平台本来就攥着聊天、会议、日历、审批、文档这些真实的企业工作数据——不是互联网上能搜到的公开知识，而是企业自己的“工作记忆”。
未来办公Agent真正的竞争力，很可能不完全取决于底层模型在Benchmark上高几分。一个模型能力稍弱、但知道你团队过去一年所有项目背景、清楚最新版文档在哪、记得上次会议做了什么决定的Agent，实际工作效率完全可能超过一个更聪明但对企业一无所知的Agent。
国外CodingAgent先解决的是复杂任务的执行能力；国内办公Agent更有机会先解决组织上下文这一层。如果这两种能力最终能结合起来，才可能真正接近所谓的“AI数字员工”。从这个角度看，国产办公Agent完全可能走出一条跟Codex、ClaudeCode不一样的路，而不是简单地“追赶”。
八、现在到底应该用哪个
没有绝对意义上的第一名，更应该看自己的工作对象是什么。
如果核心工作对象是代码仓库，希望Agent真正参与功能开发、重构、测试、Git和CI/CD，Codex依然属于第一梯队，适合程序员、技术负责人和研发团队，尤其是已经开始尝试把完整开发任务交给Agent的用户。
ClaudeCode更适合高级开发者、架构师、DevOps，以及喜欢Terminal工作流的人。如果希望深度定制Rules、Hooks、Skills、Subagent、MCP和权限体系，自己搭一套AI软件工程工作方式，它目前仍然是最值得研究的一套Harness。
WorkBuddy适合技术能力比较强、但工作内容不只是写代码的人——产品经理、数据分析、运维、技术管理，以及喜欢折腾MCP、Skill、自定义模型和本地终端的重度用户。
豆包工作更适合绝大多数普通职场用户：市场、运营、新媒体、销售、行政、内容创作者、飞书用户。日常大量涉及文档、PPT、Excel、图片、视频和飞书资料的人，会是它最合适的受众——不需要理解Agent的底层技术，只需要把事情交出去。
千问办公适合知识型办公用户、数据分析人员、研究人员，以及阿里、钉钉生态里的企业用户，尤其是经常需要做研究、处理长文档、跑数据分析和定时任务的场景。
百度搭子DuMate适合更看重权限、安全和企业治理的组织——政企、金融、大型机构，以及流程型岗位和企业自动化团队。它未必是今天个人体验最领先的一款，但它盯着的问题，很可能是Agent真正进大型企业绕不开的一道坎。
简单来说
你常用的软件是哪个“系”的，就近用哪个即可。比如经常用微信、企业微信、腾讯会议、腾讯文档，那就直接WorkBuddy；如果飞书用得多，那就直接上豆包工作，在线文档、在线表格、知识库功能很给力；如果钉钉用得比较多，就可以考虑千问办公。
写在最后
这几个产品目前的差距，与其说是“谁更聪明”，不如说是“谁先把自己的核心资产变成了Agent能调用的上下文”。
腾讯有协作文档，字节有飞书，阿里有钉钉，百度赌的是权限和信任本身也是一种资产。至于Codex和ClaudeCode，它们手里握着的资产，是过去两年在真实软件工程场景里反复验证过的Agent工程方法论。
往远一点看，这场竞争真正争夺的可能不是“AI编程工具”或者“AI办公软件”这两个具体市场，而是一个更大的位置——谁能成为人和电脑之间新的默认入口。这个入口曾经是鼠标和键盘，后来是搜索框，再后来是ChatBot。下一步，很可能就是Agent。
你现在用的是哪一个？评论区说说你的真实体验——如果点了在看，也欢迎星标一下这个号，后面还会继续跟这几个产品的更新。
资料边界说明
- 一手信源（官方发布/官方文档）：OpenAI官方博客与Codex产品页；百度智能云DuMate官方文档与产品页；千问办公（QwenWork）帮助中心定时任务、Hooks、Skill与连接器文档；腾讯云CodeBuddy/WorkBuddy官方更新日志；飞书官网对豆包工作接入飞书的介绍。
- 实施方/行业媒体信源：IT之家、每经网、腾讯新闻、新浪财经关于豆包工作8月25日发布的报道；七牛云、CSDN关于千问办公三产品合并的深度分析；科技日报关于DuMate中关村论坛发布的报道。
- 第三方评测/社区信源：AIEqual关于WorkBuddy版本与安全中心的整理；IntuitionLabs、TheNeuron、TechRadar等对CodexApp的独立解读；AITop100、AIProductHub关于DuMate的产品页面整理。这一层信源里部分效率类数据（如具体处理时长、准确率）来自厂商产品页或第三方转述，未见更高级别信源交叉验证，正文中已回避直接引用此类未经核实的具体数字。
- “血统”类表述边界：文中关于WorkBuddy“兼容OpenClaw Skill”与DuMate“满血版OpenClaw”的表述，均为厂商或媒体自述定位，前者明确为接口/格式兼容，后者暗示更深血缘但未见可验证的代码依赖实锤，正文已分别标注置信度，不作等同处理。