拆解 WorkBuddy、千問辦公和豆包工作，它們其實不是同一種產品

活是 AI 乾的，鍋是人背的。作者丨Reah 編輯丨李娜 岑峰 我們以職場牛馬的身份，把同一份髒活同時交給了三家辦公 Agent：WorkBuddy、千問辦公和豆包工作。本來想試試能不能為自己省出半天時間，結果半天沒省出來，先被三個總額問住了。這份髒活是一張銷售流水錶，混著不同日期格式、退款、跨季度訂單、部門缺失和異常金額，平時誰看了都頭疼。同一份髒銷售流水和同一句提示詞，交給 WorkBuddy、千問辦公、豆包工作。三家都交了 Excel、PPT 和摘要，算出的三個季度總額，最高比最低卻多出 57.7%。

除了髒流水，我們還讓它們核查五項近期公開信息，又給了一份實際不存在的內部文件；隨後拆開三個 macOS 安裝包，看它們為 Agent 準備了什麼執行環境。彼得·德魯克 1999 年談知識工作者生產力，說這是 21 世紀管理最重要的挑戰，同時強調知識工作的質量至少和數量同等重要。問題恰恰在這兒：數量容易統計，質量依賴判斷。職場沒法量化產出，自然也量化不了減負。AI 幫你省了多少時間，你證明不了；老闆覺得你還能再快，你也反駁不了。管理學之父彼得·德魯克騰訊、阿里、字節都開始讓 AI 進辦公室幹活了。三款產品都能處理表格、找資料、生成 PPT、調用工具，甚至操作電腦。

但用下來最大的感受是：AI 確實能幹活，幹完之後的核對、判斷和背鍋，一樣沒少。Agent 完成任務，不等於人獲得減負。省下的時間，可能只是被新的任務迅速填滿。說到底，我們想弄清楚的是：AI 把執行接走之後，判斷、核對和背鍋到底落在誰頭上？省下來的時間又還給了誰？01三家三條路線，但沒人幫你背鍋三家橫向對比：同一個品類名下押注的分別是平臺、入口和企業上下文把三家放在一起看大概能發現雖然都是辦公 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 安裝包。實測回答它們做出了什麼，逆向回答它們準備怎樣做。02把同一份工作交給三家辦公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 能否把“我找過哪裡、還缺什麼、你需要做什麼、補齊後能否從斷點繼續”一次說清。否則它雖然沒有製造錯誤，卻仍把定位文件、判斷權限和重啟任務的協調成本原樣退回給了人。03拆開安裝包：沙箱、虛擬機和瀏覽器三款產品都把對話框放在最前面，也都在承諾處理文件、調用工具、連接服務。只看界面，這像是三家在比誰回答得更好；拆開安裝包，競爭的對象卻變了。這輪逆向採用的是靜態取證：我們只讀檢查安裝包中的簽名、權限、配置與隨包資源，沒有運行程序、登錄賬號或發起網絡請求。

因此，它能告訴我們三家為 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 和釦子整體並進來，八月二十五號豆包工作發佈。也就是說團隊整合完，第