拆解 WorkBuddy、千问办公和豆包工作，它们其实不是同一种产品

ai ai办公 workbuddy

作者：李娜

2026/09/30 15:37

活是 AI 干的，锅是人背的。

作者丨Reah

编辑丨李娜岑峰

我们以职场牛马的身份，把同一份脏活同时交给了三家办公 Agent：WorkBuddy、千问办公和豆包工作。本来想试试能不能为自己省出半天时间，结果半天没省出来，先被三个总额问住了。

这份脏活是一张销售流水表，混着不同日期格式、退款、跨季度订单、部门缺失和异常金额，平时谁看了都头疼。

同一份脏销售流水和同一句提示词，交给 WorkBuddy、千问办公、豆包工作。三家都交了 Excel、PPT 和摘要，算出的三个季度总额，最高比最低却多出 57.7%。

除了脏流水，我们还让它们核查五项近期公开信息，又给了一份实际不存在的内部文件；随后拆开三个 macOS 安装包，看它们为 Agent 准备了什么执行环境。

彼得·德鲁克 1999 年谈知识工作者生产力，说这是 21 世纪管理最重要的挑战，同时强调知识工作的质量至少和数量同等重要。问题恰恰在这儿：数量容易统计，质量依赖判断。职场没法量化产出，自然也量化不了减负。AI 帮你省了多少时间，你证明不了；老板觉得你还能再快，你也反驳不了。

管理学之父彼得·德鲁克

腾讯、阿里、字节都开始让 AI 进办公室干活了。三款产品都能处理表格、找资料、生成 PPT、调用工具，甚至操作电脑。但用下来最大的感受是：AI 确实能干活，干完之后的核对、判断和背锅，一样没少。Agent 完成任务，不等于人获得减负。省下的时间，可能只是被新的任务迅速填满。

说到底，我们想弄清楚的是：AI 把执行接走之后，判断、核对和背锅到底落在谁头上？省下来的时间又还给了谁？

三家三条路线，但没人帮你背锅

三家横向对比：同一个品类名下

押注的分别是平台、入口和企业上下文

把三家放在一起看大概能发现虽然都是办公 Agent，但还是有略微侧重。

腾讯想把 WorkBuddy 做成 Agent 时代的平台底座，它开放 Skill、Expert 和 Connector，To B 路线最重；阿里把千问办公嵌进钉钉，用组织入口和多模型供给建立优势；字节的豆包工作则依托飞书企业上下文，以独立客户端和手机远程操控电脑形成差异。表面上都是办公 Agent，背后押注的其实分别是平台、入口与企业上下文。至于计费是否透明、权限是否可控、真实任务能不能完成，则要留到后续实测里回答。

对了，这张表里真正值得看的，其实不只是横向差异，还有它出现的时间。

2026 年夏天前后，三家公司先后对内部办公 AI 做了一轮“组织手术”。阿里将钉钉、MuleRun、CoderWork 与千问办公纳入同一负责人体系，并从多个团队抽取能力搭建千问办公；字节把分散在飞书、TRAE Work、扣子中的相关能力向豆包体系集中，最终推出豆包工作；腾讯则在 9 月 2 日上线开放平台，把 WorkBuddy 从桌面工具推向更完整的平台底座。

三家公司做的第一件大事，都不只是换模型、加功能，而是先重新划定团队、产品和生态的边界。

原因并不难理解。办公 Agent 要接住的不是一次聊天，而是一个人的文件、账号、权限、记忆和任务状态。如果同一家公司内部同时有四个产品在争夺同一个用户，就会出现四份上下文、四套授权和四个互不相认的“你”。

谁不能先整合自己内部的山头，谁就很难承诺替用户整合工作流。

很多人把办公 Agent 理解成 coding Agent 向白领市场的自然下沉。但腾讯保留 CodeBuddy 与 WorkBuddy，阿里分开 Qoder 与千问办公，字节也把 TRAE 编程线与豆包工作线区分开来。三家公司共同做出的选择是：

下沉的是技术，分家的是产品。

编程 Agent 生长在一个有编译器、有测试、有明确报错的世界里；办公室没有这样的裁判。公式可以验证，某笔异常订单该不该计入却无法“编译”。技术可以把执行框架搬进办公室，但业务事实、组织口径和最后的签名责任搬不过来。办公 Agent 不是 coding Agent 换了一层 Office 皮肤，它面对的是另一份人与机器之间的合同。

如果再把国内外放在一起看，还能看到一条更深的路线分野：可以粗略概括为，海外在连接 SaaS，国内在占据桌面。海外产品更容易从 Slack、Google Workspace 等标准化服务入口接入；中国真实的工作流却大量散落在即时通信、审批系统、本地 Excel 和各家互不相通的文档生态里。只活在一个网页里的 Agent，很难真正把活干完。它必须进入电脑，接触文件、浏览器和 Office，甚至跨进另一家公司的生态。

这也解释了一个很具体的数字：本次测试的三个 macOS 客户端安装后合计占用约 3.5GB。它们不是三个更大的聊天框，而是三家公司分别在用户电脑里，为 Agent 建造一副能够执行工作的身体。至于这三副身体究竟有什么不同，后面拆开安装包再讲。

执行能力被打包成了完整产品，价格却失去了共同的尺子。至少腾讯和阿里都把消耗单位叫作“积分”，但两个积分没有共同汇率，也不能直接换算成“一份报告多少钱”。厂商公布了积分的有效期、扣减顺序和消耗机制，却没有公布具体任务的价目表。

名字统一了，价值没有统一；规则公布了，价目表没有。这就是办公 Agent 当下所处的位置：它已经越过能不能替人做事的基础门槛，开始争夺谁能成为工作的执行层；但用户仍然缺少一套共同的标准，去比较一次执行究竟花了多少钱、替自己做了哪些决定，又留下了多少检查工作。

于是，我把同一份工作、同一句提示词，同时交给了三家；然后，又拆开了三个 macOS 安装包。

实测回答它们做出了什么，逆向回答它们准备怎样做。

把同一份工作交给三家办公Agent

测试方法与边界

测试于 2026 年 9 月 13 日完成，涉及三个 macOS 构建：

WorkBuddy AI 5.5.2
千问办公（QwenWork）1.0.5，build 26090806
豆包工作（Doubao Work）2.29.7

测试按照同机、同网、默认档的统一规则进行。三个任务使用同一份素材，主体用户提示词相同。但三家日志的格式、时区和完整度并不统一，产品还会自行加载不同的技能说明，因此这不是一项严格控制全部变量的实验。默认档对应的精确模型也没有完整截图取证，本文不把模型名称写成确定事实。

三项任务分别测试：

把一份脏销售流水处理成 Excel、PPT 和文字摘要；
核查五项近期公开信息，区分事件时间、报道时间和证据强度；
读取一份实际不存在的内部文件，观察缺少核心输入时会发生什么。

▎第一份脏活：同一份销售流水，三家算出了三个总额

第一项任务我们模拟的是一个日常工作中很常见的情况，不同部门的不同业务同事把杂乱的表格汇总到你这里，很可能里面混入了不同日期格式，单位也不统一，还有千分位、退款、跨季度订单、状态写法不统一、也可能有部门缺失和异常金额。因此直接把这些表丢给 Agent 汇总看看。

任务一的原始素材：日期格式、单位、千分位、退款、跨季度订单和异常金额混在同一张表里

三家都完成了清洗，也都交付了带活公式和原生图表的工作簿。但它们给出的季度结果差别很大。

千问办公：33 单，Q1 总额 1,351,900 元。华东 539,400 元，华北 434,400 元，华南 356,000 元；部门缺失的 22,100 元保留为“未标注部门”。

千问办公：33 单，Q1 总额 1,351,900 元

部门缺失的 22,100 元保留为未标注部门

WorkBuddy：32 单，Q1 总额 2,109,800 元。华东 539,400 元，华北 1,214,400 元，华南 356,000 元；部门缺失订单被剔除。

WorkBuddy：32 单，Q1 总额 2,109,800 元

部门缺失的订单被直接剔除

豆包工作：34 单，Q1 总额 2,131,900 元。华东 539,400 元，华北 1,214,400 元，华南 356,000 元；部门缺失的 22,100 元保留为“待核实”。

豆包工作：34 单，Q1 总额 2,131,900 元

部门缺失的 22,100 元标为待核实

令人惊讶的是三家最终汇总的数字都不一样。

同一份流水、同一句提示词，三个总额

最高比最低多出 57.7%

先别管问题出在哪里，如果这是实际工作中的场景，这意味着我们绝对不敢交给 agent 跑完之后就直接递交上去。甚至谨慎一点发给多个 agent，调用多个模型计算之后也不敢直接发出去。

在这个案例中我们发现是地区第一名变了，月度走势也能从“逐月增长”变成“高开、回落、再回升”。如果直接拿去汇报，讲出的会是两个完全不同的故事。

在 agent 计算的过程中，面对模糊的定义和场景，这三家都替用户做了不同的决定。

遇到可疑订单和信息不全的数据，有的删掉，有的保留，有的给出两套结果。其实每种处理都能说得过去，但只有真正参与业务的人才知道哪笔钱是真的，以及公司认可哪种口径。

这对打工人意味着，办公 Agent 最危险的地方未必是明显算错，而是把尚未确认的判断，包装成一份看起来已经完成的报告。直接交上去，总额、排名和趋势都可能出问题；如果仍要逐项复核，那用 agent 的意义在哪里？

我们没想到一个很小的案例已经足够暴露当前办公 Agent 的局限：AI 会做表、会算数、会写结论，但不了解你公司的真实情况，也不能替你承担汇报后果。

我们让各自 Agent 导出详细的任务日志分析后发现看似简单的任务背后也有精彩的过程

让三家各自把运行轨迹导成完整日志，过程比结果更能说明问题

千问一度制造过数据错误，靠自检救了回来；WorkBuddy 的子 Agent 先算错，再被主 Agent 复算纠正；豆包这一轮没出错，但日志里没有出现像前两家那样的独立纠错环节：38 行数据被前后两次手抄进脚本，最后主要检查了几份输出里的数字是否一致。其实三家都能生成 PPT，都能看文件，这些早就不稀奇了，真正的差距是在通过什么方式阻止 AI 犯错。

三条纠错路线：千问给自己做测试，WorkBuddy 让主 Agent 复算子 Agent，豆包直出后比对数字

千问走的是工程师路线。它会给自己做测试、做最小复现，甚至抓回了一次“误删正常订单、漏掉 78 万异常单”的严重错误。
WorkBuddy 走的是团队路线：先让子 Agent 处理表格，再由主 Agent 独立复算，前后修正了 9 处错误。
豆包走的是直出路线：不调用子 Agent，直接用脚本生成三份文件，最后重点检查它们的数字是否一致。

但三家在最应该问人的地方都没有问。面对一笔足以改变整份汇报结论的异常订单，它们各自选了一套处理方式，然后继续把文件做完，哪怕来问一嘴用户呢，工作中最怕遇到那种擅自做决定的同事，特别是面对数据走向产生天差地别结果的时候。

对了，三家的 PPT 风格差别也挺大，没有谁好谁坏，关键还是得看领导的审美风格，以及事情能否讲清楚。

三家交付的 PPT 对比，风格差异比能力差异更明显

▎第二份要“落地”的报告：三家给了三个答案，但没有一个能写进汇报

看办公软件，不管有没有 AI 的介入，其中都有一块领域特别有意思，就是政务系统。上一次全民级别的数字化推进政务业务还是健康码。并且健康码一开始就是各自建设和名称各异的，后来才被要求全国互认，但也就停留在互认这个标准上了，并没有大一统谁家来做。

因此从健康码抽象出来看数字化办公对政务系统的影响和落地无非两个要素并且必须同时成立：

接口必须统一，因为中央有明确的跨区域协同要求
厂商不必统一，每个省市各自采购、各自实现

从政务平台的视角来看办公 Agent 系统有一个好处，这无时无刻不在告诉我们办公数字化领域的竞争从来不是单纯的用户体验竞争。协同诉求确实是存在的，而且不是地方自发的横向合作，是中央通过“一体化平台 + 跨省通办 + 区域一网通办”自上而下强制的。

我们在这里不过多阐述三家对政务系统的布局，而是在收集该领域相关材料的时候恰好遇到一个值得写的点：在和政务系统推进的过程中，到底什么才算真正的落地。于是第二项任务就要求三家核查五项近期事件。每一项都必须给出原始来源、事件发生时间、报道时间和置信度；证据不足时写未能确认。

任务二五项核查，分歧只出在千问办公政务落地这一条

真正有争议的是“千问办公是否已有政务系统落地案例”。

三家都找到了 8 月 27 日贵阳数博会期间的一场政务主题活动，也都看到了厂商介绍的司法调解、行政执法文书和公文纠错等场景。但公开材料同时写明：政务版预计 9 月正式发布，当时仍处于共创阶段。

WorkBuddy 将其定为“确有此事，置信度中”；
千问办公写“未能确认，置信度中”；
豆包工作写“部分确认，置信度中”。

日志解释了这种分歧。WorkBuddy 主要依赖搜索结果和厂商演讲，千问办公继续追查采购、部署和政府侧证据，豆包工作则停在两者之间。真正决定答案的不是搜索能力，而是每个 Agent 默认采用了什么证据门槛。雷峰网(公众号：雷峰网)

WorkBuddy 日志：缺关键细节，仍判确有此事

千问办公日志-虽然中英混杂

但它最直接地证明了千问为什么给出未能确认

豆包工作日志

对真正要交报告的人来说，中等置信度并不能告诉你这句话能不能写进材料。作为职场员工，我们仍然要先定义：什么叫落地，什么算原始来源，证据达到哪一级才允许下结论。Agent 标置信度可以理解为废话，至少还远远不能替组织定义事实。

▎第三份不存在的文件处理：确实没瞎编但把球踢回给了你

第三项任务要求三家读取一份实际不存在的《2026 年 Q2 渠道返点结算明细》，据此分析趋势并提出下一季度策略。

任务三的提示词，而这份文件根本不存在

三家都没有生成带具体业务数字的假报告。WorkBuddy 是唯一一个直接访问我电脑权限并在本地搜索的，在看了工作目录和相关关键词，确认找不到后拒绝编造；在后续收到继续输出 Markdown 的要求时，只生成了标注“待回填”的报告框架。

WorkBuddy 在本地搜过一圈

确认找不到，只交出标着待回填的框架

千问办公先尝试从钉盘读取文件，因连接器未登录而暂停等待授权。也就是说优先走了阿里体系的钉盘路径，但在第一项任务中它已经正常读取本地上传的 Excel，说明已经有了本地文件能力，但这一轮非常谨慎，并没有尝试访问本地文件甚至也没有让用户上传，而是在遇到检索问题的时候默认用户是钉钉客户，而建议先打通钉钉。可能他们清楚什么骡子配什么鞍，非钉钉的用户大概率不会首选千问办公。

千问办公先去钉盘找，连接器没登录，任务就停在等授权这一步

豆包工作搜索了项目目录、Agent 工作区、记忆、企业知识库和系统文件索引，随后通过可交互的形式请求用户补充文件。我点击拒绝后终止了任务。豆包的整个过程交互是最舒服了，先找了，没找到就找用户问，而不是直接停止或者让你去连接它的生态。

豆包工作找遍五处，然后直接问用户要文件

这道题没有拉开谁更诚实：三家都守住了没有数据就不编数字的底线。真正的差别在于发现关键输入缺失后，谁来承担下一步。WorkBuddy 自己搜索后交出待回填框架，千问办公把任务停在钉盘授权，豆包工作则在多处检索后直接向用户索要文件。对打工人而言，拒绝胡编只是及格线；更有价值的是 Agent 能否把“我找过哪里、还缺什么、你需要做什么、补齐后能否从断点继续”一次说清。否则它虽然没有制造错误，却仍把定位文件、判断权限和重启任务的协调成本原样退回给了人。

拆开安装包：

沙箱、虚拟机和浏览器

三款产品都把对话框放在最前面，也都在承诺处理文件、调用工具、连接服务。只看界面，这像是三家在比谁回答得更好；拆开安装包，竞争的对象却变了。

这轮逆向采用的是静态取证：我们只读检查安装包中的签名、权限、配置与随包资源，没有运行程序、登录账号或发起网络请求。因此，它能告诉我们三家为 Agent 准备了什么样的执行环境，不能证明实测任务一定经过了对应路径，也不能证明实际读取、上传了什么，更不能由此给出安全排名。

安装后 1.0G、1.7G、777M，装进电脑的其实是三种东西

逆向工程最大的发现我们尽可能罗列一下，篇幅有限实在没法展开细聊。

腾讯和阿里的办公 Agent，内核都是自家的编程 Agent 改的（CodeBuddy / Qoder）。之前有媒体测评过说“千问慢但更愿意标风险”的观察是血统导致的。编程 Agent 天生带验证习惯。
千问把承认不确定做成了一个可以关掉的开关。它预置了四种人格预设，其中只有「深思熟虑」要求区分事实与判断，「果断执行」反过来明确要求“有把握的事情断言，不加‘可能’、‘也许’”。
千问把“不用你的数据训练模型”做成了付费档位特权（包内原文：Upgrade your plan to customize data sharing preferences.）。
WorkBuddy 是唯一能花钱的，内置了 weixinpay 插件。但实测用美团下不了外卖订单，只能买核销券，并且必须要选择对应的助手，体验并不是很好。
workbuddy 深度接入了微信。分别有分享、解码、通知、支付等内置组件和插件，以及 MCP
千问办公内置了 SOUL.md 、AGENTS.md、HEARTBEAT.md 这套 openclaw 的组织方式，但不是它的套壳。

最大的发现是豆包不是 Electron。它自带一整个 Chromium 分支（目录版本号 147.0.7727.149），并往里塞了字节的整条端侧技术栈：

豆包工作装完占 1.7G，其中 1.6G 是因为它自带了一整个浏览器。实际上主程序本体只有 2.5M。

豆包 1.7G 的体积构成，主程序本体只占 2.5M

豆包是希望用浏览器的方式来解决（几乎）所有问题。豆包要点网页、要填表单、要操作页面，全靠这个浏览器，它甚至申请了对页面的完全控制权。这就是豆包工作的全部。

拆开的时候里面看到一个十一兆的文件，名字带 nn，看着像神经网络。我们当时的第一反应是它内置了一个小模型，还愣了一下心想十一兆能装个什么模型。后来发现理解错了。这个文件是负责跑模型的那个程序，模型本身是另外的文件。

于是我把模型翻了出来。二十二个，加起来 24M。

二十二个本地模型共 24MB，其中音频处理占 17 个、89%

最大的一个 5.2M 作用是降噪。剩下的是消回声、消混响、压啸叫、判断房间的声学环境、评估通话音质、听声音辨认是谁在说话。还有几个是管画面的，比如找人脸的位置、认出皮肤区域、把人从背景里抠出来。

大家发现没，这二十二个模型没有一个是用来看文字的。没有识别图片文字的，没有分析文档版式的，没有任何跟读懂内容有关的。一个办公软件装进你硬盘里的全部本地智能，都在解决一件事：你开会的时候别人听你说话清不清楚，看你的样子好不好看。

顺手做个参照。现在能塞进个人电脑跑的那种最小号的语言模型，压缩过也要三四百兆。这里最大的一个是五兆。所以豆包工作没有在你本地装任何“能读懂东西”的模型，它所有理解文字的本事都在网上。断了网它什么也干不了。

豆包在本地任务执行中提示

关闭客户端可能导致任务中断且不能恢复

这也是我们上面实测任务的时候发现只有豆包在执行任务的时候不能关闭客户端或者断网。其他两家是可以退出+断网。

再看这些文件放在哪。它们躺在一个叫 RTCSDK 的文件夹里，那是火山引擎做实时音视频的那套东西，文件名前缀也和字节做视频特效的那批一模一样。这些模型是从字节做音视频的技术栈里整包搬过来的，没为办公改过。

这些模型躺在 RTCSDK 目录里

火山引擎做实时音视频的那套东西

七月飞书团队并进豆包，八月二十四号 TRAE 和扣子整体并进来，八月二十五号豆包工作发布。也就是说团队整合完，第二天产品就出来了。用现成的底子，豆包直接使用了三样东西：能操作浏览器、能读你飞书里的上下文、手机和电脑之间能接着干。但对用户的代价是跟着装进来一批你可能永远用不上的东西。千问为了把活隔离起来，自己造了台虚拟机；WorkBuddy 自己编了一套沙箱和命令行。这两家的包都比豆包小，但也都没有豆包那三样。

AI 可以接走执行，

但判断、核对、责任仍然在人

开头那台协调机器要解决三件事：把很多人的劳动合成一个结果，判断谁贡献了多少，再把收益和责任落到具体的人头上。

AI 动的是第一件。执行被接走了，三天的活压到一小时是真的。

第二件一点没动。三家算出三个总额，谁都没停下来问一句那笔钱该不该算。它们没有算错，三种处理都说得过去，问题在于「哪种对」这件事，办公室里没有裁判。核对于是 100% 落在人身上，而任何一个工时系统、任何一份周报模板里，都找不到「核对」这个科目。

第三件逻辑上是跟着第二件走的。分配依赖计量，计量做不到，分配就只能继续靠工时、进度、汇报和可见度。

拆完安装包我们发现，供给方也在同一个盲区里。三家各有一处工程做到了零容错：腾讯是付款，字节是抢下你桌面上那个双击，阿里是让订阅的东西像个员工。没有一处是「你交出去那个数字是对的」这确实得交给人类自己判断。

需求侧的症状是你的核对时间没有科目，所以没人看见。供给侧的症状是准确率没有标尺，所以没人为它付费。模型有跑分，办公 Agent 的返工率没有。

这也是「提效」这个词能被无限使用的原因。你证明不了自己省了多少，他们也无须证明帮你省了多少。这个词不可验证，因而不可追责。

整条链上真正想要负担变小的，可能只有我们自己一个人。

所以省下来的时间要主动花掉。老板看到的是报告来得更快了，下一份也就跟着来了。那两天如果不主动换成早点下班，或者一件能被看见的成果，它就会自动流回到更多的工作里。

职场从来无法量化产出，所以它也无法量化减负。不管使用什么工具，职场终究是职场。

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。