騰訊 WorkBuddy,學不會豆包工作?

藍洞商業2026.08.28 16:25 · 來自雲南全文4561字00:00 / 10:45騰訊 WorkBuddy 會整合企業微信嗎?文 | 藍洞商業,作者 | 趙衛衛字節跳動的豆包工作上線當天,騰訊雲與智慧產業事業群 CEO 湯道生髮布了一篇內部信長文。Chatbot 的戰役已經是過去時了, AI 辦公智能體才是當下的熱點。湯道生提到了過去一年元寶與豆包的競爭,承認對手值得學習,而元寶在巨大的用戶增長壓力下,花了較多精力去做推廣與引流,當時模型與產品都還沒 ready,其實效果並不滿意。湯道生提到更多的,還是騰訊如今最當紅的 AI 辦公產品 WorkBuddy。
尤其是在談到組織形態時,他認為,團隊也在推動企業微信、騰訊文檔、ima、騰訊會議、iwiki 等產品與 WorkBuddy 的打通,在 WorkBuddy 可以一站式實現文檔處理、知識管理、會議總結、協作辦公和人機共創等高頻需求。此舉的目的,是為了集中力量做深度場景,「持續獲得更多真實任務數據、用戶交互反饋和場景化 Context,並將這些反饋用於調優、能力補齊和體驗優化。」組織收攏,一站式實現多種辦公高頻需求這一點,恰恰就是豆包工作目前區別於 WorkBuddy 的關鍵所在。
豆包合併了飛書,Agent 真正進入了組織工作內部,後來又吸收了 Coze 和 Trae Work 兩個團隊,成為目前 AI 辦公領域集中度最高的產品,統一歸趙祺管理;而阿里千問辦公也實現 ToB 一體化,整合了三款 Agent 產品 QoderWork、悟空、MuleRun,統一歸陳宇森負責。而相比之下,企業微信作為 IM 產品,隸屬於騰訊的微信事業群,WorkBuddy 和騰訊文檔等產品隸屬於騰訊雲與智慧產業事業群,IM 與 Agent 產品的組織壁壘,給騰訊的 AI 辦公產品生態協同帶來了挑戰與考驗。
所以,面對當下字節和阿里在 AI 辦公領域的一系列整合追趕動作,騰訊日活百萬級別的 WorkBuddy 還能保持住先發優勢嗎?飛書、釘釘都已經變了,企業微信能保持不變嗎?如果競爭進一步加劇,企業微信和WorkBuddy 能否進一步協同甚至合併?畢竟辦公 Agent 已是紅海,過去它們只是智能工具,而現在真實組織關係和上下文數據才是競爭的護城河。登錄框就是世界觀在今年第一季度財報中,騰訊把 WorkBuddy 稱為「中國使用最廣的效率 AI 智能體服務」,其先發優勢已經非常明顯,日活用戶達到百萬量級。進入 8 月,阿里千問辦公和豆包工作先後發佈。
AI 辦公趨勢已經驗證,Agent 能自主執行更復雜的工作任務,在這一前提下,字節和阿里如何在辦公市場競爭?豆包工作有兩個主要登錄方式,一個是飛書賬號,一個是豆包賬號;千問辦公也有兩種主要登錄方式,一個是手機號,另外一個是釘釘賬號;而騰訊的 WorkBuddy 最顯眼的登錄方式只有一個:微信。微信登錄,是 WorkBuddy 在 C 端慣性最誠實的一面,但豆包工作更大的慣性來自於飛書,而不是豆包。
用飛書賬號登錄豆包工作,意味著它會繼承你權限範圍內的全部企業資產,包括群聊、紀要、文檔、日程等等,能深度理解用戶工作上下文,這一點,是豆包工作跟騰訊和阿里 AI 辦公最大的不同,而與此同時,飛書內的原豆包企業版入口也已升級為豆包工作。也就是說,豆包工作要讓 Agent 變成工作的入口,而當下的趨勢就是辦公軟件不再是生產場景唯一的入口。而反觀 WorkBuddy ,它不是某個辦公套件的內置功能,而是一個獨立運行在你電腦上的 Agent,在權限上它看不到企業微信中的用戶聊天記錄和上下文,除非用戶提供相關文件,本質上它是跟企業微信接入的兩個獨立產品。
WorkBuddy 企業版文檔裡的「渠道接入」章節寫得很清楚,「支持接入企微 AIBot、QQ 機器人、飛書和釘釘接收和回覆 Agent 消息。」在企業後臺可以管理 Agent 的即時通訊渠道,但對於 WorkBuddy 來說,企業微信、飛書和釘釘是並行關係,並不存在深度綁定誰的問題。這也意味著,WorkBuddy 贏在輻射面更廣,而豆包工作要切入 AI 辦公賽道,必然會在場景深度上做文章。
豆包工作發佈當天的直播間,重點展示的 AI 能力也是關於飛書協同之後的任務處理,包括實時內容質檢、遠程內容生產和數據驅動的系統搭建,展示了豆包工作在瀏覽器操作、多模態理解、文件處理和應用生成等方面的能力,以及與飛書文檔、多維表格等產品的協同工作流。尤其是字節跳動生態內部的聯動上,豆包工作可以說是飛書的智能大腦,而 WorkBuddy 則是連接各業務系統的神經接口。
例如,在直播間實時巡檢上,豆包工作可以通過內置瀏覽器打開抖音直播間進行錄屏和視頻理解分析,再結合飛書妙記將語音轉寫為文字,對照質檢標準文檔自動掃描畫面佈局、話術合規性及違禁詞等項目,最終輸出包含完整逐字稿的飛書文檔,並支持針對問題進行二次巡檢。護城河在於組織上下文AI 辦公賽道,騰訊 WorkBuddy 贏在了零門檻和智能體通用能力,而豆包工作的入局,意味著下一階段的賽點是,誰能更深入組織內部,誰能拿到更多企業上下文數據。
一個 AI 辦公 Agent,往往都是三部分構成:最底層是模型,中間層是 Harness,也就是駕馭和規範模型行為的一整套工程基礎設施與運行框架,而最上層上下文數據,則是它對一個組織和工作目標的理解程度。當前,模型層的競爭還在持續,但很難拉開大的差距,中間層的工程也開始趨同,外接不同工具都可以實現文檔、表格和長任務的工作,唯獨最上層的數據權限,決定了一個企業辦公 Agent 的能力上限,不能只看誰的 Agent 更聰明,更要看誰的 Agent 站在離數據更近的地方。也就是說,上半場重要的是 AI 辦公能做什麼,下半場更重要的是 AI 辦公能知道什麼。
比如寫週報,本質上是基於過去一週的會議、群聊和文檔項目等上下文做一個總結,總結中要有數據和細節,如果 Agent 能讀到你所有的工作數據和組織上下文,就可以輕鬆完成,而如果需要你把所有文檔和項目都告訴它,那等於是你寫完了之後它再修改而已。所以,讀懂一週內的企業上下文,就成為了 AI 辦公產品真正能力的關鍵。但問題是,企業是否願意組織內的上下文數據被 AI 完全讀懂?這也是飛書、釘釘和企業微信作為辦公產品,過去多年積累的經驗所在。比如,豆包工作繼承的是組織現有權限體系,沒有權限的數據,員工的 Agent 也看不到,智能協作的邊界早已經劃清。
而對於企業來說,數據存在企業內部,企業才敢於把上下文交給 Agent。讓 AI 在企業安全邊界內釋放生產力才是關鍵,而首要的前提,就是Agent 接入之後,不需要重新搭一套安全架構,直接沿用組織已有的權限規則。不論是先發優勢的 WorkBuddy 還是剛剛發佈的豆包工作,它們當前的目標都是拿到更多的企業數據,讓企業長期沉澱下的會議記錄、文檔資產和業務流程跑在 AI 之上。AI 辦公是結果還是目的?當下的 WorkBuddy、豆包工作和千問辦公,都是 AI 進入企業的一種階段性結果,而不是目的本身。
過去,辦公賽道的主角是企業微信、釘釘和飛書,如今進入 Agent 時代,用戶的核心需求轉向智能協作,產品核心入口從 IM、文檔界面轉向能夠自主拆解任務、執行操作的 AI 智能體,主角變成了 WorkBuddy、豆包工作和千問辦公,所有業務單元勢必要服務於 Agent 業務。最明顯的就是飛書產品團隊併入豆包,成立新的豆包產品團隊,而飛書的 GTM 體系與火山引擎團隊合併,成立「創造力服務平臺」,這是字節過去 5 年間對 To B 業務最大的一次調整。
也就是在飛書調整的同一天,騰訊 WorkBuddy 發佈重大更新,打通騰訊文檔,推出「人機雙寫」,讓 AI 以虛擬協作者的身份進入雲端文檔的協同編輯流。但這樣遠遠不夠,所以才有了湯道生的內部信,要推動企業微信、騰訊文檔、ima、騰訊會議、iwiki 等產品與 WorkBuddy 的打通,真正實現一站式的 Agent 需求。在 AI 戰略面前,辦公只是服務 AI 的場景和閉環。大廠都在做調整,都朝著目標前進,字節邁出一大步,而騰訊走出一小步。對字節來說,飛書負責辦公領域的客戶滲透與場景落地,豆包負責大模型能力與產品體驗,火山引擎負責算力基礎設施、雲服務與商業變現。
這三層架構整合了 To B 資源,形成了 AI 閉環的業務通路,豆包工作是 AI 閉環的落地場景之一,這些真實辦公場景產生的任務流和反饋數據,是驗證和訓練 Agent 執行能力最真實語境。而對於騰訊來說,守衛 AI 入口依然是關鍵。WorkBuddy 已是騰訊 AI 應用中戰略優先級最高的產品之一,戰略價值不言而喻,甚至可以說是反駁「騰訊做 AI 慢了」這種論調的最佳證明,但要將 AI 時代的工作入口留在騰訊生態體系內,它的領先優勢要開始從規模廣度往場景深度上延伸,打破應用之間的部門壁壘,尤其是企業微信與 WorkBuddy 之間的協同。
這一趨勢正在走向深入,字節已經調轉方向,而騰訊將 WorkBuddy 與企業微信或騰訊文檔等產品合併,也勢必會發生。
Related
相關文章
Mistral AI Releases Timestral: A 209M Forecasting Model Family That Outperforms Google’s TimesFM-3
Mistral AI has released Timestral, its first family of time series foundation models. Timestral is a set of 4 zero-shot forecasting models from Mistral AI, sized from 5M to 209M parameters.
Google 開源 Harness²:遞迴代理程式框架,無需新模型也能提升效能
Google Cloud AI Research 開源了 Harness²,這是一個遞迴代理程式框架,透過改良凍結模型周圍的程式碼與檔案來增強效能。對開發者而言,重點很簡單:你的代理程式無需更強大的模型也能進步。重點摘要:規模為框架而非模型,訓練參數為0,包含8個可編輯的框架元件,版本0.1.0。執行環境為Linux、Python 3.12或3.13搭配uv,模型呼叫則透過Vertex AI。GPU需求未公開。效能方面:一次改良步驟即可在3個基準測試中,提升所有4個模型與框架組合的表現。最佳成果:GLM-5搭配OpenCode在WorkBuddy-Bench上從64.2提升至75.7(+11.5點);最差表現:GLM-5搭配Codex在JobBench上僅提升1.2點(23.6至24.8)。什麼是Harness²?它是Google研究推出的即插即用框架。
如何利用NVIDIA結構化資料模型進行零訓練表格預測
In this tutorial, we implement Structured Data Models, NVIDIA’s new library that puts several pretrained foundation models for tables behind one PyTorch interface, and use it to make predictions without training.
認識 Kyutai REKI:2.4B VLA 模型為機器人操控帶來高效記憶
Kyutai 與 Inria 及 École des Ponts 合作,推出了 REKI——一個用於機器人操控的 2.4B 參數視覺-語言-動作模型(VLA)。該模型僅使用公開數據進行預訓練,並配備了輕量級的近期記憶功能。在三個分佈外基準測試中,僅有規模約為其兩倍的模型能超越它。所有模型權重已於今日在 Hugging Face 上公開。核心資訊:規模:2.4B 參數(2.2B Qwen3.5-2B VLM + 0.2B 流匹配動作專家)。記憶涵蓋最近 3 幀,間隔 1 秒。運行環境:在 1 張 NVIDIA H100 上進行基準測試。從兩個 256×256 攝像頭輸入,編譯後每個動作區塊耗時 21.8 毫秒。權重以 BF16 格式提供,暫無量化版本。性能:在 LIBERO-Plus 和 RoboTwin Clean2Rand 基準測試中,為公開數據預訓練的 VLA 模型中最優;在 LIBERO-Plus 上達到 90.4% 的最高分。
DeepSeek 發布 V4.1-Flash-1017,DeepSWE 得分 77.0,並開放搜尋 API
DeepSeek 剛發布 DeepSeek-V4.1-Flash-1017,這是其 V4.1-Flash 模型的新檢查點,現已在 DeepSeek 網站、應用程式及 API 上線。DeepSeek 宣稱該版本在性能、任務完成速度與輸出簡潔度上均優於 9 月發布的 V4.1-Flash,並稱之為性能與成本的帕累託改進。同時,DeepSeek 也向所有開發者開放了搜尋與擷取 API。對代理建構者而言,這意味著更便宜的編碼模型加上單一 API 金鑰即可使用的第一方網路層。重點摘要:骨架參數 552B,另加 196B 的 Engram 參數;預填充階段每 token 啟用 8B 參數,解碼階段啟用 16B 參數;上下文長度達 1M tokens,最大輸出 384K tokens。運行於 DeepSeek API 的 deepseek-flash 模型。9 月版的 V4.1-Flash 權重(763B 參數,FP8)採 MIT 授權。
2026年20款Jev替代方案:挑戰TypeSafe的決策模型
TypeSafe於2026年9月15日推出Jev,這是一款決策模型而非聊天機器人。使用者可定義允許的答案,Jev將回傳標籤、分數或是否的機率。約4週內,至少20款Jev替代方案相繼問世,來自Cloudflare、OpenAI、Perplexity、Liquid AI、AWS的Strands Labs及獨立開發者。本指南比較各方案在規模、授權、硬體、價格、Jev API相容性及已發布基準測試的表現。重點摘要:規模範圍從287M(GLiNER2.5-multi-Decide)到35B-A3B(Mapika Decider),Jev規模未公開。執行環境:Von和Laya等編碼器可在CPU上運行,4B適配器適用24 GB GPU或32 GB Mac。效能:多數開源模型在困難推理上落後Jev,但在狹窄分類任務上數款與之匹敵或超越。最佳表現:Cloudflare Clef在BANKING7取得94.20分。