基础模型能否追上产品野心，将成为决定豆包工作能否承接核心工作、以及字节Token飞轮能转多快的关键。

作者 | 李威（北京）

在将飞书与豆包进行整合之后，字节又将TRAE、扣子团队整体并入了豆包体系，相关产品和运营团队统一向豆包产品负责人赵祺汇报。TRAE Work和扣子的工作场景能力也会与豆包整合，TRAE IDE及CLI则作为豆包品牌下的编程产品线继续发展。

在同一周，字节正式推出了独立产品「豆包工作」，作为围绕用户目标拆解任务、调用工具、持续推进复杂流程的平台，并与飞书实现了深度打通。这个产品的推出，也成为了字节一系列团队整合动作在产品层面的集中体现。

这些变化进一步验证了我们此前对豆包和字节AI的两个判断：豆包正在成为连接字节模型能力与应用场景的通用助手；字节则在围绕Token，重新组织模型、应用、算力、客户和收入。

在生产力场景中，这套逻辑可以概括为一条飞轮：更多工作进入豆包，产生更多模型调用；随着资料、Skill和上下文不断沉淀，用户的使用频率和任务复杂度继续提升，由此创造更多Token需求；这些调用再通过火山引擎等业务连接到算力、企业客户、交付和收入。

豆包工作补上的，正是这套飞轮中的统一生产力平台。但团队和产品的整合只能搭好飞轮的结构，不能自动推动它持续加速。用户是否愿意把核心工作迁移过来，最终仍然取决于产品整合是否真正改善了任务体验，以及模型能否稳定完成复杂工作。

一个入口，重新排列飞书、扣子和TRAE

此前理解豆包可以概括为「AI助理＋AI办公桌面」：移动端更强调陪伴、语音、拍照和随时响应；PC端则负责资料处理、内容创作与复杂任务。

近期字节围绕豆包的一系列动作，则是这一判断的延续：移动端从信息查询和情感陪伴，向订酒店、查商品等生活服务延伸；豆包工作则把原本分散在PC端的生产力产品整合起来，形成了更加明确的办公产品和品牌。

这种分化并不意味着字节要建设两套彼此独立的产品。生活与生产力的任务重量、交互方式和主要设备不同，前台产品需要分别适应各自场景；但用户身份、模型能力、工作资料和任务执行系统可以在后台逐渐打通。

具体到生产力场景中，豆包工作也在同时完成多个入口的链接与理解，以及组织和推进工作的统一操作平台的建设。用户可以在飞书文档中提出需求，由豆包工作调用云盘资料和相关工具去完成任务，然后再从手机或桌面端查看进度、补充要求或者接管结果。

Agent成为新的交互界面后，字节原有生产力产品的角色也在发生变化。

在AI办公产品成为主流之前，多维表格曾经有可能是字节生产力AI的统一操作平台，因为它能够同时承载数据、自动化和工作流。一个任务可以由豆包负责收集需求，然后依托飞书调用多维表格来完成具体任务操作。

当可以自主规划、执行任务的Agent出现后，用户不再需要自己手动搭建自动化流程。一个任务可以由豆包平台负责理解需求并执行操作，多维表格则从被人操作的任务组织界面，变成了被Agent操作的数据容器和自动化工具，成为了豆包工作完成任务的基础能力。

从交互界面转换的角度看，可以很清楚地理解为什么是飞书深度融入豆包，而不是豆包与飞书继续保持松散的连接——底层逻辑是，让一个更先进的交互界面去负责调用最全面的能力。TRAE和扣子被整合到豆包中，也遵循了同样的逻辑。

不同之处在于，飞书提供的是组织协同能力和工作上下文，TRAE和扣子提供的是任务拆解、工具调用、流程编排和结果交付能力。TRAE从AI编程切入，逐渐把任务拆解、终端调用和文件操作延伸到文档、数据分析和深度研究；扣子从Agent开发平台出发，积累了工作流、知识库、连接器和多Agent协同能力。

飞书、TRAE和扣子汇入豆包后，字节才更接近把模型、工具和工作环境组织成一套完整的生产力系统。这也让「豆包工作成为AI生产力场景的主干」有了更具体的产品体现。所谓主干，不只是豆包拥有最多用户或者获得最多资源，而是其他产品能够围绕它重新确定位置，共同服务一套任务系统。

不过，团队和产品被收拢到豆包之下，只能说明字节想搭建一套统一的生产力系统，还不能说明这套系统已经变得更好用。

对用户来说，这次整合最终需要回答三个具体问题：飞书中已经沉淀的资料能否被直接理解和调用；分散在扣子、TRAE等产品中的工具能否被自动组织起来；模型又能否准确判断任务重点，并交付用户真正需要的结果。

这也是评价豆包工作的三个主要维度。

深度打通比增加功能更关键

从基本产品形态看，豆包工作与其他生产力Agent没有根本差异。技能、连接器、伙伴和任务执行，正在成为同类产品的标准配置。

因此，评价豆包工作的重点，不是继续清点它增加了多少功能，而是这些原本分散在飞书、扣子和TRAE中的能力，被放进同一个平台后，是否真正缩短了用户从提出需求到获得结果的路径。

其中最直接的体现，是豆包工作与飞书上下文的打通。对于已经长期使用飞书的用户，既有文档、沟通记录、协作关系和组织权限可以直接成为豆包工作的任务背景。用户不必为了使用一个新的Agent，再把文件重新上传一遍，或者重新建设一套与原有工作割裂的资料库。这意味着，豆包工作进入的，是这些用户已经在飞书中形成的工作环境。

这与WPS Comate的选择相似。两者都没有把资料库能力独立于AI办公产品之外，而是在AI办公产品中直接嵌入了资料库功能。不同的是，WPS Comate的Wiki功能还可以自动生成知识图谱，帮助用户建立不同资料之间的关系；豆包工作目前更强调Agent对飞书云盘的直接调用。

从实际工作需要来看，自动建立知识图谱是一个有用的功能点，能提升资料的利用效率。对于豆包工作来说，飞书解决了资料从哪里来的问题，下一步则需要进一步解决这些资料如何被持续整理、理解和维护。否则，当用户的文档数量不断增加时，Agent获得的可能只是一个更大的资料池，而不是一套更清楚的个人或组织知识结构。

豆包工作对手机遥控电脑能力的重视，也反映了字节对生产力入口的进一步判断。

豆包工作未来很可能成为生产力场景的主要操作平台，而大量复杂任务仍然需要依赖本地电脑中的文件、软件和计算环境。但用户不会始终坐在电脑前，新的任务入口可能存在于手机、AI眼镜、耳机或其他随身硬件中。豆包工作在提供跨硬件的连接能力来满足用户的这种需求。

这应该会让人想到豆包手机助手的尝试。这是字节在上述的使用需求下，对核心硬件产品的AI化改造——Agent也会成为驱动硬件的主要界面，豆包手机助手则与豆包工作一样，成为豆包通用AI助理的另一个变体。这两个变体之间的连接，就会是以现在手机遥控电脑能力为基础搭建起来的。

对个人用户来说，产品整合带来的另一个变化，是减轻了在字节体系内执行复杂AI操作、建设长期AI基础能力时的心理负担。

比如，我此前一直想建设一套资料收集和整理的工作流，也知道飞书多维表格、扣子和伙伴可以提供相应能力，但真正阻止我开始的，不是缺少工具，而是需要先理解这些产品分别能做什么，再决定如何组合、搭建和调试。

试用豆包工作时，我首先想到的，就是能否直接用它完成这项工作。一个统一、贯通的平台，提高了我对任务能够被完成的预期，也减少了我在多个产品之间选择和组合工具的成本。

过去，我需要先判断飞书多维表格、扣子、伙伴和Aily分别适合做什么，再决定如何搭配；现在，我至少可以先把需求交给豆包工作，再由它判断需要调用哪些能力。

这种整体感未必能立即提高每个任务的完成质量，却能提高用户开始使用整套系统的意愿。对于生产力产品来说，降低任务的启动门槛，有时比增加几个独立功能更重要。

当然，豆包工作的整合还有待继续完善。在豆包工作的伙伴对话中，既能看到我在Aily平台上搭建的AI助手，也可以开启智能体小队界面。但这个AI助手明显是可以被豆包工作取代的。

可能直接用智能体小队，突出多智能体协作会更清楚一些。这也是整合之后，豆包工作要继续推进的解决旧入口、旧伙伴、旧工作流和已有资料如何被新平台继承的问题。

模型能力会影响Token飞轮的转速

产品和团队的整合只是搭好了飞轮，不会自动带来核心工作平台的迁移。用户是否愿意把主要工作持续放在豆包工作上，还取决于背后的模型能否高质量、高效率地完成生产力任务。

AI办公产品的任务完成品质很大程度上取决于个人Skill的质量。而沉淀Skill又会受到底层模型能力的影响。用户只有相信底层模型可以持续、稳定地完成复杂任务，才会愿意花时间为其调试Skill，并把重要资料和工作流程交给它，在工作中持续迭代Skill。

从目前的使用体验上看，豆包2.1系列模型和豆包工作的组合还不足以说服我将主要工作放在豆包工作上执行，即便飞书是我使用的主要办公软件，我的工作上下文也都沉淀在其中。

相比Codex，豆包工作更像一个用力过猛、抓不住重心的新手。比如，一个稿件的评估任务还会被豆包工作归类为知识讲解类任务，在反馈评价的过程中生成一个交互页面。

从这个角度看，张一鸣近期在Seed内部会议上的表态，也变得更容易理解。张一鸣在谈及模型蒸馏问题时，要求模型团队坚持长期主义和延迟满足，不要为了短期效果和榜单表现过度依赖外部模型输出的数据，并愿意为长期目标承受阶段性的收益损失。这表明了字节高层对模型研发的重视和决心。

目前来看，模型仍然是驱动Token飞轮转动的主要动能。模型越强，用户越愿意迁移自己的核心工作平台；迁移的工作越多，资料、技能和上下文沉淀越深；沉淀越深，使用频率和任务复杂度越高，由此产生更多Token消耗。真实任务的反馈，又可以帮助模型团队进一步优化模型能力。

字节可以通过整合飞书、扣子和TRAE，迅速补齐上下文、工具编排和复杂任务执行能力，但如果模型不能稳定完成复杂任务，再统一的平台也很难在AI办公竞争中形成优势。

正如《从流量到Token，火山在成为字节的新引擎》中总结的，Seed负责继续生产模型能力，豆包工作、飞书、TRAE和扣子创造使用场景与调用需求，火山引擎则把模型调用连接到算力、企业客户、交付和收入。

豆包工作很好的一点是为字节补上了生产力场景的统一平台，也降低了用户开始使用这套系统的心理门槛。但它目前提供的是让Token飞轮更容易启动的产品架构，而不是足以推动飞轮持续加速的全部动力。围绕产品和团队的整合初步完成后，基础模型能否追上产品野心，将成为决定豆包工作能否承接核心工作、以及字节Token飞轮能转多快的关键。