当钉钉和飞书几乎同时开源CLI工具，将办公平台的核心能力拆解为命令行接口，一场面向AI智能体的平台重构正在悄然发生。这两大办公巨头不约而同地采用三层架构设计，将日历、文档、消息等模块封装成AI可调用的技能包。本文深度对比两家产品的技术路径与开放策略，揭示办公软件从'人操作'到'AI操作'的范式迁移。

钉钉和飞书前后脚开源了CLI：钉钉开源了 dingtalk-workspace-cli，飞书开源了 lark-cli。

两个中国最大的办公平台，这两天做了同一件事——把自己的全部能力，拆成一条条命令行，交给AI Agent去调用。

这不是巧合。这是一个信号。

它们到底是什么？

先说本质：这两个工具都是”让AI Agent操作办公软件的遥控器”。

以前，AI Agent想帮你在飞书上发条消息、查个日历、建个文档，要么走API自己拼请求，要么通过MCP协议做中转。现在，飞书和钉钉各自把自己的产品能力封装成了CLI命令——AI Agent只需要”敲命令”就行了。

飞书 lark-cli：11个业务域（日历、消息、文档、多维表格、邮件、会议等），200+条命令，19个AI Agent Skills。npm install 直接装，MIT开源协议。

钉钉 dws：覆盖日历、待办、通讯录、消息等核心模块，同样配备Agent Skills，一键shell脚本安装，Go编写的独立二进制。目前处于灰度共创阶段，需要加官方群走白名单才能用。

两者都用Go写，都提供了结构化JSON输出方便Agent解析，都支持 –dry-run 让你预览操作再执行。

架构上的”不约而同”

有意思的是，两家不约而同选择了同一种三层架构：

第一层：Shortcuts（快捷命令）。 飞书用”+”前缀（比如 +agenda 看日程），钉钉也有类似的语义化命令。这层是给人和AI都友好的——参数少、默认值智能、输出可读。

第二层：API Commands（平台命令）。 和开放平台的API一一对应。适合需要精确控制的场景。

第三层：Raw API（原始接口）。 直接调任意开放平台端点，覆盖全部API。飞书号称可覆盖2500+接口。

这个分层本身就值得产品经理细品：它回答了一个很实际的设计问题——同一个工具，既要给人用，又要给AI用，怎么设计？

答案是分层。人类用第一层就够了，AI大多数时候也用第一层（犯错少），遇到复杂场景再往下钻。这比”一套API打天下”聪明得多。

关键差异：开放策略完全不同

架构像，策略却截然不同。

飞书更激进。 npm install 一行命令装完，README英文在前中文在后（面向全球开发者），MIT协议，v1.0.0 直接发 GitHub Release。它赌的是”先铺量再收割”——让尽可能多的AI Agent先接进来。

钉钉更谨慎。 虽然代码也开源了，但实际使用需要走灰度共创流程：加官方钉钉群 → 提交企业应用的Client ID → 管理员确认 → 官方配白名单。这个节奏明显是”企业管控优先”。

这背后是两家的基因差异。飞书从第一天就更”开发者友好”（海外有Lark品牌），钉钉的核心盘是中国企业客户，安全合规是命脉。两种策略说不上谁对谁错，但对于想尝鲜的个人开发者来说，飞书显然门槛更低。

值得一提的是，钉钉还做了一件飞书没做的事：官方出了 OpenClaw（龙虾）连接器插件，支持把钉钉机器人直接接入龙虾网关，包括AI Card流式响应。这对龙虾用户来说是个实实在在的增量。

对普通用户意味着什么？

先泼盆冷水：这两个工具目前都是给”AI Agent开发者”用的，不是给普通飞书/钉钉用户用的。你不会在飞书的设置页面里看到一个”开启Agent CLI”的按钮。

但它释放的信号很重要——

办公软件正在从”人操作”变成”人指挥、AI操作”。 以前我们自己打开飞书写文档、查日历、发消息。现在办公平台主动把自己拆成积木块，等着AI来拼装。

这跟我之前聊过的趋势一致：AI Agent要真正有用，光有大脑（模型）不够，还得有手和脚（工具调用能力）。飞书和钉钉今天做的事，就是在给AI Agent”装手脚”。

而且它们选择了同一种装法：CLI + Skills。不是MCP，不是自定义插件，是最朴素的命令行。为什么？因为命令行是所有AI编程Agent（Claude Code、Cursor、Antigravity……）最成熟的交互方式。这些Agent天生就会敲命令。

当办公平台开始主动”拆自己”给AI用的时候，对于用户来说，办公的变革来了。对于开发者来说，“移动互联网”的信号也来了。

项目地址：

钉钉CLI：https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli

飞书CLI：https://github.com/larksuite/cli