飞书打通豆包之后的第一款产品终于出来了，回归朴实无华的命名原则：豆包工作。

经典的三端产品，此时的三端是指，在豆包客户端、飞书客户端、以及独立的豆包工作客户端，都能开启使用，而且上下文互通。

上下文的重要性应该不需要多说了，基本上实现了无痛整合，尤其对于飞书用户而言，该怎么用还是怎么用，以前的数据资产都不需要去做额外的迁移流程，字节的工程师都帮你处理好了。

昨天刷到A16z的周报也很应景，半年以来，Agent的Token消耗量暴涨1400%，目前已经是人类消耗Token的5倍，企业场景占了绝大部分，而且排名前10%的企业用量还在继续拉大差距中。

所以「工作新习惯、先让豆包干」这句Slogan，还真不是说说而已，属于一个确定性很高的落地趋势。

而这些 Token 究竟烧出多少价值，分水岭其实就在上下文。同样一句「帮我把这个季度的情况理一下」，如果它不知道你在哪个部门、跟进的是哪条业务线、上个季度的结论是什么、上周的会上谁提了什么反对意见，那它只能给你一份放到哪家公司都成立的通用模板；反过来，这些前情它都拿得到，交上来的就是能直接用的东西。

差别不在模型多聪明，而在它能不能看见你的工作现场。这也是办公场景和通用聊天最本质的区别：聊天可以每次从零开始，工作不行，工作是有前史的。而所谓的数据资产，其实就是这份前史 —— 文档、会议、群里的讨论、过往的结论，过去它们只是躺在那里等你去翻，现在它们是喂给 Agent 的燃料。

所以飞书和豆包打通这件事，我觉得是个太正确的决策，甚至可以说是天然就该发生的。一个组织最完整的上下文本来就长在飞书里，一个最好用的 Agent 本来就在豆包这边，这两样东西分开放着，各自都只能发挥一半 —— 协同工具存了一屋子的前史却没人来读，Agent 能干活却总是从零开始问你背景。它们凑到一起，才是一个完整的生产力工具。

我自己用Codex也是一样，比如这次Q2财报季，每家公司的财报都是一个独立工作流，Codex自己抓取文件、跟进会议、收集反馈、修正判断，按照我指定的框架汇总，不再需要实习生来交作业。

以此类推，我是觉得面向协同的飞书，和面向个人的豆包工作，非但完全不冲突，而且在上下文同步的支持下，可以非常融洽地互补，飞书负责交付并对齐结果，豆包工作解决结果如何产出。

组织的效能，这不就来了吗？

从「先用飞书」，到「先让豆包干」，敢为人先这个主张，一直保留在字节对于生产资料的核心定位里，无论是做企业还是当员工，本质上都是以竞争力为向上价值，好的工具，就是应该丝滑无痛地提高竞争力。