文|超聚焦

7月30日，字節對旗下AI與企業服務業務進行了一輪重大組織架構調整。

其中，飛書產品團隊與豆包產品團隊合併，組成新的豆包產品團隊；而飛書原有的銷售、市場和客戶服務團隊，則與火山引擎相關團隊合併。

換句話說，飛書原本相對完整的產品與商業化體系，被分別接入了豆包和火山引擎：前者負責產品和用戶入口，後者負責企業客戶與商業化。

放眼整個行業並不令人意外。不久之前，阿里啱啱將QoderWork、悟空和MuleRun三條企業AI產品線進行整合；騰訊也將QClaw相關業務和部分團隊，收攏進WorkBuddy所在的組織體系。

這也意味着，在短短一個月的時間裏，BAT（字節、阿里、騰訊）幾乎同時對旗下AI辦公產品動了刀。

表面上看，這是大廠在結束內部賽馬、減少重複建設。但如果只是為了降本增效，未必需要在如此接近的時間裏，集體把分散的Agent、辦公軟件和企業服務重新歸攏到一起。

更值得注意的是，它們整合的，恰恰都是最接近企業客戶的入口。

01賽馬結束，大廠齊收繮繩

字節這次調整，力度比表面上看起來更大。

按照新的組織架構，飛書產品團隊將與豆包產品團隊合併，成立新的豆包產品團隊，由豆包負責人趙祺統一負責，飛書負責人謝欣也將轉向趙祺彙報工作。

與此同時，飛書原有的銷售、市場和客戶服務團隊，則與火山引擎相關團隊合併，成立新的To B GTM組織「創造力服務平台」，統一負責字節旗下MaaS、SaaS等企業服務的市場、銷售和客戶服務。

不過飛書並沒有因此消失，現有產品和服務也不會停止。但從組織關係來看，過去那個集產品、銷售、市場和客戶服務於一身，相對獨立的飛書，實際上被拆成了兩部分。

一部分進入豆包，負責企業生產力場景中的產品和用戶體驗；另一部分進入火山引擎，負責企業客戶、市場拓展和商業化。

這也意味着，字節不再單獨考慮飛書該怎麼賣、豆包該怎麼進入辦公場景、火山引擎又該怎麼向企業提供模型服務，而是把三者放進了同一套企業AI體系中：豆包提供AI能力和產品入口，飛書提供文檔、會議、表格、知識庫等工作場景，火山引擎則承接雲服務和商業化。

然而字節並不是臨時把三個團隊拼湊在一起。此前，豆包就已經進入飛書的會議紀要、智能表格、知識問答和雲文檔等場景。由此看來，此次調整，更像是產品融合之後，組織架構終於跟了上來。

類似的收攏，也發生在阿里和騰訊，在過去的半年中，兩家巨頭都同時放出了多條AI產品線同時賽馬，如今則開始收回繮繩，將團隊、資源和產品向少數主線集中。

7月初，阿里宣佈整合旗下QoderWork、悟空和MuleRun三條Agent產品線。新的產品將以QoderWork為基礎，吸收悟空和MuleRun的能力，面向企業生產力場景繼續升級，並由釘釘CEO陳宇森負責。

阿里表示，原有產品和用戶權益不會受到影響，但從產品方向來看，三條原本各自發展的辦公Agent路線，已經開始向一個統一入口集中。

騰訊的動作則發生在7月20日。騰訊將QClaw產品中心相關業務和部分團隊，調整至雲產品六部，而云產品六部正是另一款AI辦公智能體WorkBuddy所在的部門。

截至目前，QClaw仍將繼續運營，因此這還不能簡單理解為QClaw被關閉或者徹底併入WorkBuddy，但兩款定位接近的Agent，已經被放進了同一套組織和資源體系，未來共享資源、戰略協同已經成了板上釘釘的事。

不過，相比字節，阿里和騰訊的調整仍然更偏向產品層面的收攏：阿里整合的是三條定位相近的Agent產品線，騰訊則是把兩款辦公Agent放進同一個部門。它們解決的，主要還是產品重複、資源分散和內部賽馬的問題。

字節的變化則更加徹底。它並不是簡單合併兩款產品，而是直接拆開了飛書原有的完整組織，併入豆包和火山引擎當中。換句話說，阿里和騰訊是在「收馬」，字節則連馬廄、騎手和賽道都重新排了一遍。

不過，無論是收攏產品，還是重構整套組織，三家的動作卻都指向同一個方向：將分散的AI能力收進統一入口，並藉此更深地嵌入企業客戶的工作流程。

02從「上雲」到「上AI」，客戶更難離場

當然，結束內部賽馬確實可以減少重複投入。但對今天的BAT來說，省下幾支產品團隊的研發和營銷費用，恐怕只是微不足道的因素。而他們之所以急着統一入口，更重要的原因可能是：AI帶來的客戶黏性，遠遠超過了過去的雲計算。

事實上，在過去十幾年裏，雲廠商也一直都在嘗試「綁架」客戶，不過，雲廠商的方式是用基礎設施「綁住」客戶。企業一旦把服務器、數據庫和業務系統部署在某一家雲上，再想離開，就要重新遷移數據、改造系統，並承擔遷移過程中的業務風險。理論上，企業使用得越久、部署得越深，對雲廠商的依賴也就越強。

但實際情況並沒有這麼簡單。雲計算確實提高了企業離開的門檻，卻始終沒有徹底改變企業衡量成本的習慣。

小紅書就是一個典型案例。

創業早期，小紅書幾乎將全部技術體系搭建在公有云上，也是騰訊雲較早的一批客戶。對當時的小紅書而言，購買雲服務器不需要提前建設機房，也不必養一支龐大的基礎設施團隊，業務快速增長時還可以隨時擴容。公有云提供的彈性，幫助小紅書以更低的成本完成了早期擴張。

但隨着業務規模擴大，小紅書並沒有因此越來越依賴某一家雲廠商，反而開始不斷分散這種依賴。

一方面，小紅書逐漸採用多雲架構。2024年，它又將儲存過去11年原始數據、規模達到500PB的數據湖遷往阿里雲。換句話說，即便企業早期深度使用一家雲廠商，仍然可以把部分核心業務轉移到另一朵雲上，讓不同廠商相互替代、相互制衡。

另一方面，小紅書也開始建設自己的基礎設施。隨着計算資源達到數百萬核CPU，單純依賴公有云帶來的成本、調度和運維問題逐漸暴露。為此，小紅書形成了一套「自建優先、公有云兜底」的資源調度方式：穩定、可預測的業務優先放在自建集群，只有自建資源不足，或者出現突發流量時，才調用公有云進行補充。

這件事恰恰說明了雲計算黏性的邊界上限。

當企業規模較小時，公有云的彈性和低門檻更加划算；等到業務規模足夠大，企業仍然會重新計算成本，並通過自建、混合雲和多雲架構，削弱對單一廠商的依賴。雲廠商可以提高客戶搬家的成本，卻很難

其中，最重要的是模型工程體系的沉澱。今天企業把大模型接入業務，早已不是寫幾個提示詞、調用一個接口那麼簡單。

一個模型要真正進入客服、銷售、財務或者研發流程，企業需要先建立自己的業務測試集，明確準確率、響應速度、調用成本和風險邊界，再圍繞不同任務配置模型路由、工具調用、輸出結構、人工審核和異常處理機制。

這意味着，企業沉澱下來的不是幾個提示詞，而是一套圍繞特定模型建立起來的生產標準。

哪種任務交給大模型，哪種任務交給小模型；什麼情況下允許它直接執行，什麼情況下必須轉給人工；一次調用可以容忍多少成本和延遲；模型升級之後，原有流程是否會出現新的錯誤，這些都需要經過長期測試和真實業務驗證。

而如果切換到其他的辦公應用，所調用的大模型也會改變，企業往往需要重新跑一遍業務評測，確認新模型在數百乃至數千種真實場景中，仍然能夠穩定運行，而這對於有一定體量的B端客戶來說，幾乎是無法承擔的後果。

這也解釋了為什麼三家都在此時停止了內部賽馬，開啓了辦公產品的整合。

過去產品分散時，客戶可以在QoderWork、悟空和MuleRun之間選擇，也可以同時試用WorkBuddy和QClaw。對大廠來說，這種競爭雖然有利於探索產品方向，卻不利於形成真正的客戶黏性：賬戶分散、數據分散、資源分散，客戶也不會放心把核心業務交給任何一款前途未定的產品。

只有先確定一個長期存在的主入口，大廠纔有可能說服企業將更多系統和權限向它開放。

字節這次調整尤其明顯，豆包掌握模型和AI產品，飛書掌握企業辦公場景，火山引擎則掌握雲服務與商業化。

三者一旦被接進同一套體系，字節向客戶出售的就不再只是飛書席位、豆包模型或者火山引擎算力，而是一套從工作入口到任務執行的完整企業AI服務。

阿里和騰訊雖然暫時只收攏了產品線，但方向也是一樣的：先結束內部產品之間的競爭，再爭奪企業唯一的AI入口。並且可以肯定的是，未來的釘釘和企業微信，也註定會和飛書一般，成為Qwen和hy的「下屬產品」。

因此，這輪密集的組織調整表面上是在減少重複建設，背後卻是一場更直接的客戶爭奪，爭奪誰能成為企業客戶默認的AI入口。

一旦他們習慣從這裏發起任務，BAT們獲得的就不只是一筆軟件收入，而是一段不可分開的客戶關係，到時候哪怕提出一些「過分」的要求，客戶們也得捏着鼻子接受。

雲時代，企業還能算上雲和下雲的賬；AI時代，一旦入口、權限和流程都交給同一平台，企業客戶就再也別想離開。屆時，大廠拿到的就不只是收入，更是說一不二的絕對議價權。