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