文 | 超聚焦
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仍继续运营，不能简单理解为其被关闭或彻底并入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时代，一旦入口、权限和流程全交给同一平台，企业客户便再也别想离开。届时，大厂拿到的不仅是收入，更是说一不二的绝对议价权。