夜雨聆风
这几周里，只要在 AI 开发者社区多待一会儿，几乎都很难躲开扑面而来的“龙虾”热度。
而一旦准备部署这只“龙虾”，一个绕不开的问题就会冒出来：到底把它落在哪个平台最合适？
在中文社区里，一个明显的趋势是，越来越多开发者开始把它接入飞书。
OpenClaw 官方文档已将飞书纳入内置消息渠道之列，社区也迅速长出了一整套配套资源：专门的飞书接入仓库、迁移指南以及排障文档等。
从教程产出频率到讨论热度来看，飞书已经成为 OpenClaw 在中文语境下落地最清晰、也最成体系的去处之一。
这股 OpenClaw 对接飞书的热度背后，是飞书接口生态的开放性，以及官方近乎“追着需求跑”的更新节奏。
就在昨天，飞书还进一步发布了基于最新 OpenClaw 插件打造的合作生态，正式把更多主流模型和云服务厂商接入进来。
可以说，飞书的这波更新，是在把原本只属于少数极客的技术，推向官方化、产品化，并具备可规模复制的能力。
事实上，这波“飞书热”，并不是飞书官方点起来的。
早在 2026 年 1 月 26 日，就有开发者在 OpenClaw 官方仓库提出“请增加飞书和微信支持”。当时的理由很简单：国内公司的日常协作，本来就大量发生在这些工具里。
随后，围绕“怎么把 OpenClaw 接进飞书”的脚本、教程、排障帖，以及权限配置经验，开始密集出现。OpenClaw 官方文档也把飞书列为绑定渠道之一。
在开发者社区的“野生力量”里，OpenClaw 中文社区创办人杨明锋是很有代表性的一个。
根据媒体报道，他判断在国内环境里，飞书可能是最快、也是最合适接入 OpenClaw 的平台。在发现 OpenClaw 对中文用户不够友好后，先做了汉化，再补齐飞书扩展，让用户可以直接接入飞书；报道还提到，这部分代码后来被 OpenClaw 官方团队采纳。
GitHub 上的 OpenClaw-feishu 目前仍有约 598 个 star、47 个 issue、52 次提交。README 里明确把自己定义为“早期开发的社区飞书插件”，并说明如今飞书接入已经演化出三条路径：飞书官方插件、OpenClaw 内置飞书插件，以及这个更早期的社区方案。
可以说，飞书并不是主动对接 OpenClaw，而是先被开发者用代码、文档和实践，一点点抬进了生态中心。
当然，除了社区推动，飞书本身也确实具备更适合 Agent 生长的土壤。在一批更愿意尝鲜、也更重视效率工具的企业里，飞书已建立起相当深的用户基础。
这意味着，当 OpenClaw 需要在中文世界寻找一个默认落地场景时，飞书背后并不缺愿意拥抱新技术的用户群。
例如猎豹移动傅盛的实践。按照他的公开复盘，在春节 14 天里，他几乎只靠在飞书上与 OpenClaw 对话，就把一只“龙虾”养成了一个拥有 8 个 Agent、40 多个 Skill 的团队，而且很多时候根本不需要再回到电脑前操作。
李志飞那次“两天做一个 AI 原生版飞书”的实验，则从另一个侧面印证了这件事：他之所以会去做那样一个原型，恰恰是因为他判断，未来当大量执行者变成 Agent，协作平台的底层逻辑也会被重写。开发者会天然去寻找一个最容易让 Agent 接手真实工作流的平台，而飞书刚好最接近这种形态。
飞书这边，直到开发者们把飞书做成高频入口后，才开始迅速把这条路径“官方化”。
不过，飞书下场后，并不只是做一些插件，而是把整条链路一起补齐。例如飞书开放平台基础免费版企业自建应用 API 调用总量被限时提升到 100 万次 / 月；3 月 9 日，飞书又正式推出妙搭一键部署 OpenClaw，省去了开发平台配置流程，并且自带飞书官方插件。
目前，飞书开源的官方 OpenClaw 插件，已经与火山引擎、阶跃星辰、Kimi、扣子、MiniMax、智谱等主流模型与云服务厂商完成对接。从火山引擎和智谱的公开教程看，“接入飞书”已经被做成标准化、甚至一键化流程。
对开发者来说，真正有吸引力的，从来不是某个平台某一项能力有多强，而是它能不能满足两件事：一是足够开放、省事，二是功能边界足够大，足够有想象力。
过去，Agent 接入平台的流程都很繁杂。从创建应用，配置，公网 IP 或内网穿透，到随后处理鉴权、权限、事件订阅、证书等一整套问题。开发时往往是一边翻文档，一边盯日志，哪里报错就回去重改哪里。
OpenClaw 刚出来时，不少开发者就是按这套标准流程把它接进各种系统。结果是，模型跟业务逻辑还没打磨，时间就被接入消耗掉了大半。
而飞书这次特别的地方，在于它给出了一条不同的路径：让接入更简单、更统一，但能力边界并没有因此被压缩。
飞书开放平台已提供 2500+ 开放接口与事件，覆盖消息、文档、电子表格、多维表格、日历、任务、审批等多个业务域；OpenClaw 的飞书官方插件，进一步把一批工作对象封装成了直接调用的能力。
同时，OpenClaw 的飞书插件已在 GitHub 开源，开发者可以直接查看实现逻辑、提交优化或扩展功能。这种开放的方式也让插件的演进更贴近真实使用场景。
官方插件页面显示，目前这些能力已经被细化到非常具体的操作层面：文档创建与更新、多维表格中的管理，以及日程的增删改查、任务与评论管理等，而且仍在不断地迭代中。
在连接层，飞书也降了门槛。它的长连接模式，本质上是用 WebSocket 替代传统 WebHook：开发者不再需要公网 IP 和域名，也不必额外折腾内网穿透。
同时，企业自建应用也无需经过飞书平台审核，只要企业管理员审批通过，就可以在组织内部使用。对开发者来说，这意味着验证一个 Agent 场景，不再是一场高成本的消耗。
除了接入部署快，还让开发者心动的是，它能像“走进公司”的实习生一样干活。
飞书的价值，恰恰在于它把工作上下文、权限体系和执行工具放进了同一个协作空间。官方插件页面显示，目前这些能力已经被细化到非常具体的操作层面：文档创建与更新、多维表格中的管理，以及日程的增删改查、任务与评论管理等。
从开发角度，这些原本分散在不同系统里的对象，被纳入同一套开放体系，本身也能省掉很多工程烦恼。这样一来，开发者就不必再为每一类对象单独给 Agent 写一套连接器，也不必在多个系统之间反复拼接流程。
这带来的收益非常直观：一方面，开发者少做了大量“同步数据”“搬运上下文”的体力活；另一方面，Agent 的运行终于可以建立在真实、连续的工作环境之上，而不只是用户临时粘贴过来的一小段文本。
Agent 能干，但也不能出事。对开发者来说，永远都不愿意背安全的“锅”。好在飞书把身份和权限做成了底层工程能力。通过 Access_Token 机制，平台能够明确“是谁在调用、以什么身份调用、访问的是哪个租户的数据”。
这让飞书的 Agent 更像绑定了一个真实入职的员工账号，在组织既有规则内行动。
开发的最终站——运维对于开发者来说，也是重头戏。飞书并没有把这些问题一股脑丢给开发者自己处理。
开发者不仅可以直接在飞书里与 Agent 对话做灰度测试，还可以借助插件提供的能力做基础的“自我诊断”。出了问题，在群里发几条命令，往往就能完成初步定位；再结合官方和社区提供的大量防踩坑教程，整个调试与运维链路会顺畅很多。
从这个角度看，飞书这段时间，是在持续放大这条工程路径本身的吸引力。它不仅让开发者更容易接入，也让他们变的更敢于试错，更敢于放量。
这也就不难理解，为什么开发者会对它如此上头，很难不被这种诱惑打动。
没有人能断言 OpenClaw 会火多久。
但比单个项目热度更确定的是，智能办公的判断标准已经发生变化：企业和员工越来越关心，Agent 如何真正接入业务、嵌入流程，并把任务做成闭环。
从这个角度看，OpenClaw 的爆火，其实是把一个更大的问题提前摆到了企业面前：当 Agent 真正进入组织，什么样的平台能接得住它？
飞书之所以在这轮浪潮中被重新评估，是因为它本就是少数能将消息、文档、电子表格、多维表格、日历、任务等工作对象，统一纳入同一套账号、组织与权限体系的平台之一。
如果把 Agent 比作发动机，高质量的业务数据就是燃料。相比外部碎片化信息，可以说，飞书中沉淀的协作记录和文档，天然就是更整齐、连续的“企业级上下文”。
开发者看中飞书的一部分主要原因，也是因为它不是一个孤立的接口，而是一个自带真实逻辑的工作现场。
吴恩达前不久提出“AgenticWorkflow”，正是这种务实主义的方向：与其追求一个无所不能的超级模型，不如让由迭代、反思与协作构成的“智能体工作流”，去解决真实业务问题。
未来的公司，可能会演变为“少数核心决策者 + 大量 Agent 团队”共同运转的模式。这种变化与共识几乎是全球性的。
会看飞书这次更新，很像是一次身份转变的预告。它不再只是接入 Agent 的渠道，而是正向“入口级”智能平台靠拢：既要承载运行，又要连接私有数据，还能把结果写回工作流上。
工具也许会不断更替，但智能办公的深水区已经到来。而飞书正在做的，就是朝着“Agent 基础设施”的方向继续迈进。
