文 | 超聚焦
7月30日，字节跳动对其AI与企业服务板块进行了大刀阔斧的组织架构重组。
此次调整的核心逻辑是“拆分”与“重组”。飞书的产品团队并入豆包产品团队，组建新的豆包体系；而飞书原有的销售、市场及客户服务团队，则划归火山引擎相关团队管辖。
这意味着，飞书过去相对闭环的产品与商业化版图被拆解：一侧接入豆包，主攻产品形态与用户入口；另一侧接入火山引擎，专攻企业客户拓展与商业变现。
这一动作在行业内并未引发太多惊讶。此前不久，阿里巴巴已完成QoderWork、悟空和MuleRun三条企业级AI产品线的整合；腾讯也将QClaw相关业务及部分人员，收编至WorkBuddy所在的组织序列中。
短短一个月内，BAT（字节、阿里、腾讯）几乎同步对自家AI办公产品线进行了梳理。
外界常将此解读为大厂结束内部赛马、削减重复建设。但若仅为了降本增效，未必需要如此密集地将分散的Agent、办公软件及企业服务资源重新聚合。
更深层的信号在于，这三家巨头整合的，恰恰是最贴近企业客户的核心入口。
**告别赛马，统一指挥棒**
字节此番调整的颗粒度，远超表面所见。
根据新架构，飞书产品团队与豆包产品团队合并，成立新的豆包产品团队，由赵祺统管，原飞书负责人谢欣转而向赵祺汇报。
与此同时，飞书原有的销售、市场和客户服务团队，与火山引擎对应团队合并，组建名为“创造力服务平台”的新To B GTM组织，全面统筹字节旗下MaaS、SaaS等企业服务的市场、销售及客服工作。
飞书品牌虽保留，现有服务亦不停摆，但从组织逻辑看，那个集产研、销售、市场与服务于一身的独立实体已不复存在，被一分为二。
一部分融入豆包，聚焦企业生产力场景下的产品体验优化；另一部分进入火山引擎，承担客户拓展与商业化重任。
此举表明，字节不再孤立地考量飞书如何售卖、豆包如何切入办公场景或火山引擎如何输出模型服务，而是将其纳入统一的企业AI生态：豆包提供底层能力与入口，飞书承载文档、会议、表格、知识库等具体场景，火山引擎负责云服务支撑与商业落地。
这并非临时拼凑。早在此次调整前，豆包就已渗透进飞书的会议纪要、智能表格、知识问答及云文档等环节。因此，这次调整更像是产品深度融合后，组织架构随之跟进的结果。
类似的收敛动作，阿里与腾讯也在过去半年间陆续展开。两家巨头曾同时推进多条AI产品线并行测试，如今则开始收紧缰绳，将团队、资源及产品导向少数核心主线。
7月初，阿里宣布整合QoderWork、悟空和MuleRun三条Agent产品线。新产品将以QoderWork为基底，融合悟空与MuleRun的能力，面向企业生产力场景持续迭代，由钉钉CEO陈宇森挂帅。
阿里承诺原有产品及用户权益不受影响，但产品走向显示，三条原本各自发展的办公Agent路线，正逐步向单一入口汇聚。
腾讯的动作紧随其后，发生于7月20日。腾讯将QClaw产品中心的相关业务及团队，划入云产品六部，该部门正是另一款AI办公智能体WorkBuddy的归属地。
目前QClaw仍保持运营，不能简单视为其被关闭或完全并入WorkBuddy，但两款定位相近的Agent已被置于同一组织与资源框架下，未来共享资源、战略协同已成定局。
相较于字节，阿里与腾讯的调整仍偏向产品层面的合并：阿里整合的是三条定位相似的Agent产品线，腾讯则是将两款办公Agent并入同一部门。它们主要解决的是产品重复、资源分散及内部竞争问题。
字节的变化则更为彻底。它并非简单合并两款产品，而是直接拆解了飞书原有的完整组织，将其分别嵌入豆包与火山引擎。换言之，阿里和腾讯是在“收马”，而字节连马厩、骑手和赛道都重新规划了一遍。
无论采取何种方式，三家的指向一致：将分散的AI能力收敛至统一入口，从而更深地嵌入企业客户的工作流中。
**从“上云”到“上AI”，锁定更难挣脱的客户**
结束内部赛马确实能减少重复投入。但对当下的BAT而言，节省几支产品团队的研发与营销费用，或许只是次要因素。它们急于统一入口的根本原因可能在于：AI带来的客户黏性，远超过去十年的云计算。
回顾过去十几年，云厂商一直在尝试“绑定”客户，手段是通过基础设施实现锁定。企业一旦将服务器、数据库和业务系统部署于某家云平台，若想迁移，需重新搬运数据、改造系统，并承担迁移期间的业务风险。理论上，使用越久、部署越深，对云厂商的依赖就越强。
但现实情况更为复杂。云计算虽提高了迁移门槛，却未根本改变企业的成本核算习惯。
小红书便是典型例证。
创业初期，小红书的技术体系几乎全建在公有云上，成为腾讯云早期客户之一。对当时的小红书来说，租用云服务器无需自建机房，也不必维持庞大的基础设施团队，业务爆发时可随时扩容。公有云的弹性助力小红书以更低成本完成早期扩张。
随着规模扩大，小红书并未日益依赖单一云厂商，反而着力分散这种依赖。
一方面，采用多云架构。2024年，它将存储过去11年原始数据、规模达500PB的数据湖迁至阿里云。这表明，即便企业早期深度使用某家云厂商，仍可将部分核心业务转移至其他平台，利用不同厂商间的制衡机制降低风险。
另一方面，自建基础设施。当计算资源达到数百万核CPU时，单纯依赖公有云带来的成本、调度及运维问题逐渐显现。为此，小红书确立了“自建优先、公有云兜底”的资源调度策略：稳定且可预测的业务优先部署于自建集群，仅在自建资源不足或突发流量激增时，才调用公有云补充算力。
此事揭示了云计算黏性的边界上限。
当企业规模较小时，公有云的弹性和低门槛更加划算；等到业务规模足够大，企业仍然会重新计算成本，并通过自建、混合云和多云架构，削弱对单一厂商的依赖。云厂商可以提高客户搬家的成本，却很难彻底锁死客户。
相比之下，AI时代的锁定效应更为隐蔽且深刻。
其中，关键壁垒在于模型工程体系的沉淀。今天企业把大模型接入业务，早已不是写几个提示词、调用一个接口那么简单。
一个模型要真正进入客服、销售、财务或者研发流程，企业需要先建立自己的业务测试集，明确准确率、响应速度、调用成本和风险边界，再围绕不同任务配置模型路由、工具调用、输出结构、人工审核和异常处理机制。
这意味着，企业沉淀下来的不是几个提示词，而是一套围绕特定模型建立起来的生产标准。
哪种任务交给大模型，哪种任务交给小模型；什么情况下允许它直接执行，什么情况下必须转给人工；一次调用可以容忍多少成本和延迟；模型升级之后，原有流程是否会出现新的错误，这些都需要经过长期测试和真实业务验证。
而如果切换到其他的办公应用，所调用的大模型也会改变，企业往往需要重新跑一遍业务评测，确认新模型在数百乃至数千种真实场景中，仍然能够稳定运行，而这对于有一定体量的B端客户来说，几乎是无法承担的后果。
这也解释了为什么三家都在此时停止了内部赛马，开启了办公产品的整合。
过去产品分散时，客户可以在QoderWork、悟空和MuleRun之间选择，也可以同时试用WorkBuddy和QClaw。对大厂来说，这种竞争虽然有利于探索产品方向，却不利于形成真正的客户黏性：账户分散、数据分散、资源分散，客户也不会放心把核心业务交给任何一款前途未定的产品。
只有先确定一个长期存在的主入口，大厂才有可能说服企业将更多系统和权限向它开放。
字节这次调整尤其明显，豆包掌握模型和AI产品，飞书掌握企业办公场景，火山引擎则掌握云服务与商业化。
三者一旦被接进同一套体系，字节向客户出售的就不再只是飞书席位、豆包模型或者火山引擎算力，而是一套从工作入口到任务执行的完整企业AI服务。
阿里和腾讯虽然暂时只收拢了产品线，但方向也是一样的：先结束内部产品之间的竞争，再争夺企业唯一的AI入口。并且可以肯定的是，未来的钉钉和企业微信，也注定会和飞书一般，成为Qwen和hy的“下属产品”。
因此，这轮密集的组织调整表面上是在减少重复建设，背后却是一场更直接的客户争夺，争夺谁能成为企业客户默认的AI入口。
一旦他们习惯从这里发起任务，BAT们获得的就不只是一笔软件收入，而是一段不可分开的客户关系，到时候哪怕提出一些“过分”的要求，客户们也得捏着鼻子接受。
云时代，企业还能算上云和下云的账；AI时代，一旦入口、权限和流程都交给同一平台，企业客户就再也别想离开。届时，大厂拿到的就不只是收入，更是说一不二的绝对议价权。
