WorkBuddy 跑出来之后钉钉和飞书最明显的变化不是功能列表突然多了一截而是对“入口”这件事的态度变得很微妙。过去几年这两家一直在争用户每天打开的第一个办公应用是谁——消息、审批、文档、会议、考勤、日程全部往同一个客户端里装恨不得你在电脑前坐下的那一刻第一步就是点开自家 Logo。但现在像 WorkBuddy 这类基于大模型能力的 AI Agent 助手跑出来后用户可以直接说一句话让助手去飞书多维表格里查数据、到钉钉群发通知、把审批状态更新掉、再按定时任务跑一遍巡检。整个过程里用户可能根本不需要先打开某一个 App。入口不再是胜负手。真正值钱的变成了谁能接住这些指令、谁能安全地读取数据、谁能把流程编排得不出错。这篇文章不聊 WorkBuddy 是不是标配也不站队钉钉或飞书只从实际使用和产品观察的角度拆一下为什么这类 AI 助手出来后钉钉飞书会放下“入口”执念以及作为普通用户、管理员、开发者或产品经理该怎么理解这个变化怎么判断自己的团队到底该怎么跟。1. 先搞清楚WorkBuddy 这类助手为什么能动摇“入口”1.1 以前的入口思维所有工作都从客户端开始钉钉和飞书在企业办公里的定位过去十年核心就是“统一入口”。考勤、审批、消息、文档、会议、直播、外部联系人、低代码应用全部收进同一个 App。对普通用户来说入口越统一越省事不用判断“查审批该开哪个软件”对平台方来说用户打开次数、停留时长、消息高度、企业数据沉淀全部从“入口”进来。所以“入口之争”的本质是用户注意力之争也是数据归属权之争。谁能成为企业员工每天打开的第一个办公软件谁就掌握了下一条商业化的通道。这也是为什么钉钉和飞书过去在产品界面上越做越满功能入口越塞越多。它们的目标不是做某个单点工具而是做企业工作系统的总开关。但总开关这个定位在 AI Agent 出现之后开始露出裂缝。因为 AI 助手的工作方式不是“先打开一个软件再在里面找功能”而是“先用自然语言描述目标再由助手去调用多个系统完成动作”。用户的起点从“点开 App 图标”变成了“发出一条指令”。1.2 AI Agent 改变的是“工作从哪开始”WorkBuddy 这类助手本质上是一个能理解任务、拆解步骤、调用工具、最后交付结果的智能体。它不需要用户进入某个协作平台的界面也能完成很多原本必须打开 App 才能做的事。举个例子。以前要做“每周运营数据周报”用户的路径很长先打开飞书找到多维表格手动筛选最近 7 天记录复制到表格里再打开钉钉找到工作群粘贴内容点发送。现在如果接好了 WorkBuddy流程可以变成用户在聊天窗口里说一句“把飞书多维表格里最近 7 天的销售数据汇总一下按渠道分组发到钉钉运营群”。助手自己去读表格、做筛选汇总、生成文案、投递到指定群。这个变化最关键的不是省了十分钟操作而是任务起点变了。用户不再需要先想“我要用哪个系统”只需要想“我要达成什么结果”。工作流的起点从应用客户端转移到了自然语言指令上。入口不再是 App 图标而是对话本身。1.3 平台为什么愿意放下执念很多人会觉得奇怪钉钉和飞书怎么会允许外部助手来调用自己的能力和数据这不是把入口让出去了吗从实际产品动作看它们并不是真的放弃入口而是在重新定义入口。如果坚持只做“用户手动打开的客户端”AI 时代数据被别的 Agent 隔空调度平台反而沦成管道价值更被动。反过来如果把自己变成一套可以被 Agent 调用的运行环境提供开放的 API、机器人通道、事件订阅、数据读写能力那么平台就从“入口”变成了“中台”。用户可能不再从钉钉图标打开钉钉但所有任务的数据、审批流、消息投递、审计日志仍然跑在钉钉和飞书之上。钉钉的 AI 助理、飞书的智能伙伴本质上都是这个思路不拒绝 Agent 调用而是把平台能力开放出来让 Agent 在自己的轨道上跑。对平台来说放下“入口执念”不是放弃价值是换一种更符合 AI 时代逻辑的价值承接方式。2. 从工作流看WorkBuddy 这类助手真正替代的不是 App是“搬运工”2.1 最常见的三个场景我观察到的落地场景其实没有想象中复杂主要集中在三块。第一块是消息与通知。助手按规则把审批待办、系统告警、定时报表发送到钉钉或飞书群。这个场景最成熟因为 Webhook 推送已经是很稳定的机制AI 只是把“手动复制粘贴到群聊”变成了“自动拼装内容并推送”。第二块是数据查询与汇总。助手通过 API 读取多维表格、电子表格、数据库视图按条件筛选、分组、统计再把结果返回给用户。这里最典型的就是飞书多维表格因为它结构很像轻量数据库字段类型丰富还支持自动化非常适合被 Agent 调度。第三块是任务编排。定时触发、过期数据提醒、状态同步、跨系统写入。比如每天凌晨检查待办列表把超过 2 天的未处理记录汇总到群里并 负责人或者某个表格字段更新后自动触发下游系统的同步写入。这三块业务过去都需要人来做“搬运”从系统 A 导出数据整理后贴到系统 B。WorkBuddy 这类助手替代的正是这个搬运过程。它不是替代钉钉也不是替代飞书而是替代人肉在多个系统之间来回切换的重复劳动。2.2 自然语言不再只是搜索框以前你在钉钉或飞书里输入关键词本质是搜索搜聊天记录、搜文档、搜联系人。输入框是个检索入口。现在基于大模型的助手出现后输入框开始变成调度入口。区别在哪里搜索框返回的是“信息位置”比如“这段记录在哪个群、这份文档在哪个目录”而任务指令返回的是“动作结果”比如“我已汇总 12 条记录已发送到钉钉运营群已更新 3 条状态为已完成”。这意味着会话框的语义从“帮我找东西”升级成了“帮我把事情做完”。对用户来说工作台不再是一个需要主动翻找的界面而是一个可以派活的下属。WorkBuddy 这类助手本质就是这个下属的“执行大脑”——它理解你说了什么去把相关系统里的数据拉出来再按照要求完成动作。2.3 判断一个助手能不能落地的标准这里我给一个相对保守的判断标准。不要看演示视频里多流畅要看六个问题是否支持按账号区分权限能不能限制助手读哪些表格、发哪些群是否保留操作日志谁在什么时间让助手做了什么能不能追溯到任务失败后是否自动重试重试失败有没有通知到人是否支持定时触发能不能像 cron 一样稳定运行输出格式是否可配置能不能按团队习惯生成表格、卡片或普通文本是否支持企业内网或私有化部署数据会不会被发到外部接口这六个问题能过基本就能从“聊天玩具”升级成“办公机器人”。如果有一个不行比如没有审计日志那就算演示效果再好我也不会让它直接接触生产审批流。3. 钉钉和飞书在“入口后时代”各自偏向哪条路3.1 钉钉把 AI 能力嵌进高频动作旁边从近两年的产品动作和用户反馈看钉钉更偏向智能协同方向。它把 AI 能力嵌入到群聊、会议、文档、表格这些高频场景里典型做法就是“在所有协作动作旁边放一个 AI 按钮”群聊里可以艾特 AI 做摘要文档里可以让 AI 续写表格里可以用 AI 生成公式或分析。钉钉的思路更像是在原有入口之上叠加 AI 层。它没有放弃客户端而是希望让客户端里的每一个功能都变成可对话、可调度的对象。对普通员工来说这降低了学习和使用成本对开发团队来说钉钉开放平台提供的机器人、应用 API、免登能力也让外部 Agent 有比较明确的接入路径。3.2 飞书多维表格加自动化天然适合被 Agent 调度飞书则走了另一条更“结构化”的路线。飞书多维表格本身在团队内部经常被当作轻量数据库使用字段类型丰富、支持视图筛选、有自动化流程和机器人。最近几年大量团队用飞书多维表格做项目管理、客户跟进、库存登记、内容排期很多数据已经天然沉淀成结构化表格。这个特点对 WorkBuddy 这类 Agent 非常友好。因为 Agent 最擅长处理的恰恰是结构化数据。字段清晰、记录有状态、接口可读助手就能按条件筛选、排序、汇总、更新。很多已经跑通的案例里飞书多维表格的定位就是“数据底座”而 Agent 是“调度层”最终消息通过群机器人或 Webhook 投递到钉钉或飞书会话。3.3 两者的共同点连接协议比客户端重要不管钉钉还是飞书现在都提供机器人 Webhook、应用 API、事件订阅、免登授权这类连接能力。这背后其实是一个共识未来办公协作里客户端只是表现层真正能形成长期价值的是连接协议和数据模型。对企业用户来说这也是好消息。你不再需要纠结“公司到底该用钉钉还是飞书”。只要团队里有人能把 Agent 和这些平台接通你就可以用同一个助手去连接企业微信、钉钉、飞书任意一家数据可以同步通知可以转发审批可以跨系统汇总。你在选协作平台时也不再是一锤子买卖而是看它对外提供的 API 是否够用、权限模型是否清晰、审计能力是否完整。4. 真正决定落地效果的不是入口而是权限、数据和流程4.1 权限模型是第一个门槛AI Agent 接入钉钉飞书最怕的就是权限过宽。一个负责汇总表格的助手如果拿到了全量读写权限一旦指令被误触发或输出被错误调用问题就大了。我一般会建议团队用“最小权限”原则来配每个 Agent 只绑定一个应用身份只授权它必须读取的表格和必须发送的群组。比如运营汇总助手只需要读取“运营数据”这张表的只读权限只允许向“运营周报群”发送消息不允许删除记录不允许拉取通讯录。审批类任务必须走人工确认节点Agent 可以发起审批但不能代替审批人做最终通过。权限收紧是比权限放开更难补救的事。一开始就留最小权限后续再加比一开始全开再收回来要安全得多。4.2 数据格式比接口数量更容易卡住很多团队第一次接飞书多维表格时就会被分页卡住。一次请求最多拿几百条记录要拿全量数据必须处理分页如果表格里还带附件、人员字段、创建时间过滤条件稍微写错返回结果就对不上。钉钉的审批事件推送需要订阅回调机器人发送消息的格式也有限制不是一段纯文本直接塞进去就行。这些都不是模型能力问题而是数据接口和市场逻辑问题。实操时我建议先导出一份真实数据确认字段名称、字段类型、分页上限、过滤条件字段名再写 Agent 的调用逻辑。不要靠文档想象直接把接口对接文档和真实数据对照一遍能省下大量排查时间。4.3 流程编排要保留人工兜底Agent 可以自动发起审批、发通知、更新状态但一定要保留人工干预节点。比如批量发送之前先预览清单、删除记录前必须二次确认、异常任务直接进入人工队列。一个没有兜底的自动化在办公协作环境中非常危险。我以前见到过类似的翻车案例定时任务触发后把未确认的数据全部标记为完成因为判断条件少了一个“负责人已确认”字段结果整个团队看到的周报状态全错了。后来加了“人工确认后再更新状态”的节点问题才算解决。AI 调度能提升效率但流程里最重要的节点仍然是“谁对结果负责”。5. 给开发者和产品经理的观察建议别只盯入口看五个可量化指标5.1 从“日活入口”转向“任务完成率”以前衡量一个办公平台好不好看日活、打开次数、停留时长。现在观察 WorkBuddy 这类 Agent 在企业场景的落地我更建议关注五个可量化指标任务完成率发起的指令里有多少能完整跑完没有被中途打断数据更新及时性定时任务是否按计划执行数据拉取是否过期审批平均耗时引入 Agent 后审批链路是否真的变短了告警漏报率漏发、错发、重复发送的情况占比有多少用户手动接管次数用户因为不信任或结果不对手动修正的次数这五个指标能比较真实地反映 Agent 有没有产生价值。如果任务完成率高但用户手动接管次数也很高那说明完成是完成了结果质量可能还不行。5.2 搭建本地测试的最小闭环如果你想验证“WorkBuddy 类助手 钉钉/飞书”适不适合自己团队不建议直接上生产环境。先搭一个小闭环第一步建一个测试群只放开发者和两三个业务侧同事。 第二步创建一张多维表格模拟真实字段比如待办事项、负责人、状态、更新时间。 第三步配置一个定时任务让助手每天固定时间读取表格中状态为“待处理”的记录汇总后发到测试群。 第四步连续跑 3 到 5 天观察任务成功率、消息格式、字段过滤是否正确。这个小闭环不需要复杂架构半天就能搭好。跑通之后再逐步接入真实数据和审批流程。5.3 常见排查顺序如果助手没反应、消息没发出、表格没读到不要一上来就怀疑大模型出了问题。按这个顺序排查先确认 Agent 进程是否在线日志里有没有报错再确认 Webhook 地址、密钥、回调 URL 是否有效再看数据源权限机器人是否被移出群、多维表格有没有共享给应用再看分页参数、过滤条件、字段名是否和接口文档一致最后看超时和重试长时间运行的任务有没有被外部服务断开我之前见过一个案例助手一直说“读取不到数据”排查半天发现是多维表格没有把应用添加为协作者。这类问题很常见就是权限和配置问题不是模型能力问题。6. 入口没有消失只是定义变了6.1 入口从 App 变成了会话和任务卡片你打开钉钉和飞书看到的主界面确实和几年前差别不大。但用户真正开始工作的路径已经悄悄变了。以前是“打开 App找到审批点击发起”现在是“在聊天框里说一句审批自动发起”。入口从 App 图标变成了会话窗口、任务卡片、定时通知、审批节点。用户不再需要先想“该打开哪个软件”只需要想“我要达成什么结果”。钉钉和飞书没有消失它们正在从“入口型应用”变成“承载运行环境的数据底座”。你不一定每天手动点开它们但你的数据、流程、审批记录、消息通知仍然在它们的系统里流转。6.2 对普通用户和团队的建议不要因为 WorkBuddy 这类助手火了就急着把所有流程都交给 Agent。先盘点一下自己手里有哪些流程可以被自动化哪些数据可以被结构化读取哪些环节需要人工审批。从单一场景试点跑稳了再扩。先让助手处理最枯燥的“搬运”工作再慢慢让它参与更复杂的判断和协作。如果只是学习默认配置和小规模测试足够如果要长期使用日志、输出目录、权限策略、失败重试这些前置工作越早整理好后面积累越多。6.3 一句话总结观察WorkBuddy 跑出来后钉钉飞书放下“入口”执念本质上是办公协作平台正在接受一件事未来企业工作的起点不再是某一个 App 图标而是用户说出口的那句指令。谁能把数据、权限、流程和 AI 调度之间的路铺好谁才是下一个阶段真正的赢家。