“先进企业，先用飞书”，是飞书最具代表性的一句 slogan，它沿用至今很多年，一些新锐公司和老牌企业深受其影响，头也不回开启了企业数字化进程，一些企业则不无奚落：凭什么你用数字化进程定义一个企业的先进程度，数字化程度如何又凭什么是飞书说了算。
但无论如何，“先进企业，先用飞书”对应的，确实是中国企业过去十年经历的一轮协同办公变革——
沟通从邮件和层层转述转向即时群聊，文件从反复发送附件转向多人共同编辑，项目进展从口头汇报转向在线流程，越来越多原本需要 IT 部门开发的内部系统，也开始由业务人员通过多维表格自行搭建。
这一阶段，飞书所服务的核心对象始终是人。它要为企业和员工创造一个更高效、更透明，也更“丝滑”的工作环境。
但事情很快就起了变化。十年来搭建的企业数字化办公环境，在过去的三年被 AI 的发展迅速扭转成一个完全不同的形态。
飞书必须系统性地回答一个关键问题：如果驱动企业未来前进的最关键要素已经不仅是人，而是 AI Agent。飞书过去围绕着人建立起的一切数字化工作环境，是包袱，还是弹药？它不是一个问题，而是一系列彼此关联的问题的组合——
Agent 怎样进入企业？怎样获得组织身份？怎样理解群聊、文档和会议中的上下文？怎样调用企业工具、参与项目流程并交付工作成果？企业又该怎样限制、监督和审计它的行为？
它们指向的是飞书产品身份的一次彻底变化。
过去的飞书，是员工使用的一套协同工具；现在的飞书，越来越像“办公室”本身。人和 Agent 在这里获得身份、调用信息、开展协作、推动流程并留下工作记录。豆包工作和其他 Agent，则成为进入这间办公室工作的数字员工。
如果你相信“先进企业”一定是 AI 驱动的企业，那“先进企业，先用飞书”，就得往下接着走一步，变成“先进企业，先让 Agent 上飞书”。
如果它能做到的话。
从协同工具，变成 Agent 的工作环境
生成式 AI 最初进入办公软件时，基本没有改变原有的工作结构。
AI 可以帮员工总结会议、润色文档、生成图片、分析表格，但每一个环节仍然由人发起。人找到资料、输入指令、等待结果，再手动把结果复制到另一份文档或者另一个系统。AI 虽然提高了某些步骤的效率，但本质上仍是办公软件里的一个功能。
而 Agent 带来的变化在于，AI 开始从“被调用的功能”变成“持续工作的主体”。
一个真正进入企业的 Agent，不能只在聊天框里回答问题。它需要自己寻找资料、理解任务背景、拆解执行步骤、调用多个工具、询问相关人员，并把结果送回正确的业务流程。如果任务没有一次完成，它还需要记住此前进度，在几小时甚至几天后继续推进。
这时，过去为人设计的数字办公软件就会出现一系列不适配——系统越完善、信息沉淀越多、表格越多维、审批体系越完善，不适配程度就越高。飞书一不小心，就会成为最不适配的那个。
Agent 可能知道怎样分析数据，却不知道数据存放在哪张表里；它能够生成报告，却不知道应该发给哪个群、由谁确认；它可以执行命令，却没有明确的组织身份和权限边界；它也可能完成了大量操作，但企业无法完整回答它看过什么、修改过什么、调用过什么工具。
飞书正在进行的“适 Agent 化改造”，试图补齐这套工作环境，让它成为最适配 AI Agent 的办公系统。
它意味着这个系统必须从人的束缚中跳出来。
Agent 现在可以像同事一样被邀请进群。在群里直接@一个尚未入群的 Agent，系统能够自动邀请它加入并立即处理第一个任务。当多个 Agent 同时存在于群聊中，它们还可以互相@，把调研、写作、设计等工作依次交接，不再需要人充当每一步的传话筒。
Agent 也不再局限于收发消息。Agent 现在可以在飞书里创建和编辑文档、操作多维表格、管理日程待办、进入项目流程以及发起审批。人能在飞书里完成的大部分工作，正在逐渐转化为 Agent 可以调用和直接上手的能力。
如果站在一个 Agent 的视角，飞书的变化并不只是把原有模块开放给 AI，而是在为它补齐一套完整的入职手续——
群聊和会议让 Agent 持续感知组织正在发生什么；文档和多维表格构成它可以读取、更新的外部记忆与业务状态；飞书项目和审批告诉它任务进行到哪一步、接下来该做什么、何时必须把决定交还给人；
CLI、API 和连接器则把理解转化为行动。权限划定它能够行动的边界，操作日志让每一步都能被复核，而它生成的文档、表格、任务和数据不再消失在一次对话里，而是重新写回企业，成为下一名员工和下一个 Agent 可以继续调用的组织上下文。
这也解释了为什么飞书越来越强调 CLI 覆盖指标：飞书 CLI 覆盖的功能点从 247 个增加到 767 个，调用成功率从 78%提高到 95%，整体响应速度提升近 40%。
界面是否漂亮、按钮是否好找已经没那么重要了，Agent 对它们毫无感觉，Agent 在乎的是使用飞书是否足够稳定和顺畅，这是 CLI 决定的。
过去，企业软件的产品经理主要研究人怎样阅读信息、点击按钮和理解界面；进入 Agent 时代以后，他们还要考虑机器怎样取得上下文、理解数据结构、连续调用工具并验证执行结果。产品不仅要做到“人用得顺手”，还要做到“Agent 调得顺手”。
这就是“Make Something Agents Want”的实际含义。
它不是让 Agent 产生某种主观偏好，而是让一个工作平台的能力足够清晰、结构化和稳定，以至于各种 Agent 都愿意把它作为进入企业的默认入口。
过去的软件争夺人的屏幕时间，未来的软件还要争夺 Agent 的调用次数。飞书过去追求的是让工作在人与人之间顺畅流动，现在它必须得让 Agent 在同一套组织结构和业务流程里真正跑起来。
豆包工作原生融入了飞书
人们关心飞书和豆包的关系。在字节跳动不久前公布的组织架构调整中，它们越来越像一个统一的业务体系，飞书似乎被纳入了“豆包工作”的框架，缺失了一部分过去的独立性。
这是完全站在“人类”立场的思维方式，站在 Agent 的视角上，事情可能大有不同。
在这套新叙事里，飞书和豆包工作并不是同一个产品，也不是简单的入口与功能关系。
飞书提供的是组织环境：企业中的人员和部门关系、群聊和会议、文档与数据、项目和审批、权限与安全边界，以及工作成果最终沉淀和流转的地方。
豆包工作提供的则是智能与执行：理解复杂任务，调研和分析信息，生成文档、表格、PPT和网页，调用不同工具完成多步操作，记住长期上下文，并在没有人持续催促的情况下主动推进任务。
最直观的比喻是：飞书是数字办公室，豆包工作是进入其中的数字员工，而且可能是最佳员工。没办法，谁让它是“大厂嫡系”。
刚刚发布的飞书“团队智能体”进一步强化了这种关系——
按照飞书的设想，它拥有独立的组织身份，可以加入群聊、参加会议、阅读文档、查询代码，也能同时接受产品、研发和运营等不同角色派发的任务。多个群里讨论过的方案，它可以自行汇总；会议上提到需要向另一个团队确认的问题，它可以跨群追问，再把结论带回来；周末凌晨出现故障，它也可以提前读取代码和资料，等员工上线时交付初步分析。
这已经不再是一个围绕单个用户展开的个人助手。
个人助手只需要理解“我”的需求；团队 Agent 必须理解“我们”的关系。它需要知道谁在负责什么，哪些讨论属于同一个项目，哪些信息能够共享，一个结果应该交给谁，以及谁拥有最终决定权。
因此，豆包工作与飞书的原生整合非常重要。
其他 Agent 通过 CLI、API 或连接器进入飞书，像拿到门禁卡的外部专业人员；豆包工作则更像正式入职的数字员工。它天然处在飞书的组织、数据、权限和协作环境中，不需要用户每次重新告诉它应该去哪个群、查哪份文档、把结果保存在哪里。
这并不意味着飞书只为豆包服务。事实上，飞书项目 CLI 允许外部 Agent 进入项目流程，企业已有的业务系统、专业工具乃至自建 Agent，也可以通过连接器接入。OpenClaw、Claude Code 和 Codex 等不同类型的 Agent，可以成为这套生态叙事的一部分。
但这些新动作更重要的一个意义其实在于，它在提供一个此前各类产品从来没有提供过的Agent与组织之间的高度协同环境。
今天人们好奇的依旧是Agent进入组织究竟可以做到怎样的程度，那么给豆包工作这样的Agent一个真正从底层打通的最原生环境，比用任何诸如CLI等“搭桥”方式肯定来得更直接，也更能让人们挖掘Agent在生产力场景里的极限。
这是一个Agent 时代的企业工作平台必须要做的探索，你可以从今天飞书的一系列动作看出它未来可能长成的样子：Agent 们会扮演不同的角色，拥有原生整合优势的豆包工作和每个企业、每个用户因不同需求而“自带”的不同Agent一起在这个Agent原生的平台上协作，也只有这样才能带来真正的繁荣。
AI 上线 VS Agent 上岗
几乎所有企业软件都已经加入 AI，单纯宣布具备生成、总结和问答能力，早已不足以构成区别。飞书试图建立的新标准，是 Agent 能否进入真实业务流程。
比如在零食快消费品三只松鼠，“豆包工作”承担的不是一次孤立的内容生成，而是直播巡检、经营数据汇总、选品与投流建议、图文和视频生产、销售日报以及客服训练等一系列连续任务。人在其中设定目标、判断结果，AI 则开始接管大量执行工作。
在大北农这个听起来更不性感的农业公司，AI 反而更加接近一线业务。Agent 在销售拜访前整理客户信息、识别风险与机会、规划拜访路线；拜访过程中，销售人员可以调用养殖效益计算器和猪场改造模型，把原来依靠口头经验的产品推荐变成可以现场计算和展示的经营方案；拜访结束后，客户进展、服务问题和下一步动作又回到统一的经营看板中，由 AI 持续生成提醒和建议。
东风奕派的“设备大师智能体”则展示了另一种可能：它从点检数据中发现了一条被人工巡检漏掉的异常：台车四角高度偏差超过设备标准。随后，它结合设备手册和机理模型，把这一异常与喷涂距离、漏电流及电压变化联系起来，最终给出“不要换控制器，去调平台车”的具体维修建议。
这些案例真正值得注意的，不是 AI 得出了一次令人惊讶的答案，而是它完成了一条完整的工作链：取得现场数据，调用企业积累的维修经验，结合专业资料进行分析，把判断转换成维修任务，再由现场人员查看依据、确认并执行。
这就是“上线”和“上岗”的区别。
上线，是企业购买或者部署了 AI，员工能够打开它、向它提问；上岗，则意味着 Agent 已经足够可靠，企业愿意给它真实数据、真实权限和真实任务，让它进入生产流程，并由人对关键结果进行确认和负责。
按照这一标准，Agent 时代真正稀缺的可能并不是模型，而是企业工作的上下文，套用永远也不缺新名词儿的 AI 圈黑话来说，就是环境、Harness 和 CLI。
模型可以生成一份格式漂亮的报告，却未必知道公司真正关注哪些指标；它可以回答一个设备问题，却未必能够取得现场实时数据和企业过去十几年积累的维修经验；它可以提出行动建议，却未必知道该进入哪个项目、触发哪项审批以及通知哪位负责人。
飞书可能拥有的护城河，正是这些看起来并不像 AI 能力的东西：谁属于哪个部门，谁参加了哪个项目，一项决定在哪场会议中形成，一份文档对应哪次讨论，哪些信息可以被谁读取，一项任务应该交给谁，以及谁最终承担责任。
这些信息散落在群聊、会议、文档、表格、审批和项目之中。只有将它们置于一套统一的权限与协作体系里，Agent 才可能从“会回答问题”真正走向“能够完成工作”。
不过，进入真实工作也意味着承担真实风险。演示中一次惊艳的执行，并不能证明 Agent 能够在长期运行中保持稳定；拥有更多上下文，也可能意味着错误信息、过期信息和无关信息同时增加；能够调用更多工具，则意味着一次错误判断可能直接转化为错误操作。
因此，飞书必须证明三件事——
Agent 能够长期稳定执行，而不是偶尔完成一次漂亮演示；企业上下文能够被准确调用，而不是制造更复杂的幻觉；权限、审计和人工接管机制能够承受真实的生产事故。
这也是为什么企业 Agent 的竞争，最终不会只是一场模型能力竞赛。模型决定 Agent 聪不聪明，工作平台决定它知不知道该做什么、能不能做、应该做到哪一步，以及出了问题由谁接管。
衡量企业 Agent 的真正标准，也不再只是它回答得像不像人，而是企业究竟愿意把多少真实工作交给它。
飞书过去解决的问题，是怎样让一群人更顺畅地一起工作。飞书现在试图解决的问题，是怎样让一群人与一群 Agent 在同一个组织里共同工作。
这并不意味着人会从企业消失。相反，当检索、整理、生成、协调和持续执行越来越多地交给 Agent，人将更多负责目标设定、价值判断、例外处理和最终责任。企业真正需要改变的，也不只是购买哪些 AI 产品，而是怎样重新划分人与 Agent 之间的工作边界。
过去，“先进企业”意味着更早采用云文档、在线协同和数字化流程。下一阶段，企业先进与否，可能取决于它能否把知识整理成 Agent 能够理解的上下文，把业务系统转化成 Agent 能够调用的工具，把权限和责任设计成 Agent 不能越过的边界，并把个别员工摸索出的 AI 方法沉淀成整个组织的能力。
所以，“先进企业，先让 Agent 上飞书”，不在乎一下子往飞书里塞进去多少个 Agent，它描述的是一种正在形成的组织现实：当一些企业还在教员工怎样使用 AI 时，另一些企业已经开始为 Agent 安排身份、权限、工位和工作。
这就是飞书想要的，当然了，Codex 也想。