飞书和钉钉同一周开源了 CLI 工具。这不是巧合，而是一个信号：企业软件的用户，正在从人变成 AI Agent。这篇文章帮你搞懂飞书 CLI 到底做了什么、为什么是 CLI 而不是别的，以及这件事对开发者意味着什么。
一、先说结论
3 月 28 日，飞书开源了官方 CLI 工具 larksuite/cli，MIT 协议，Go 语言写的。上线当天 GitHub Stars 破千，两天过了 4000。
核心卖点一句话：把飞书 2500+ 个 API 压缩成 200 多条 CLI 命令和 19 个 AI Agent Skill，让任何 AI Agent 五分钟内接管你的飞书。
值不值得关注？值得。不是因为它功能多牛，而是因为它代表了一个正在发生的范式转移——企业工具开始把 AI Agent 当成一等公民来服务。
二、四十年的界面进化，被 AI 反转了
要理解飞书为什么做 CLI，得先回答一个更底层的问题：为什么是 CLI？2026 年了，不是应该做 API 或者 MCP 吗？
回想一下计算机界面的进化史：
1970s CLI → 1984 GUI → 2007 触屏 → 2026 AI Agent
四十年来的方向一直是：让界面对人类更友好。鼠标比命令行好用，触屏比鼠标直觉。
但 AI Agent 把这条路掉了个头。
对 AI 来说，GUI 是最差的接口——需要截屏、识别按钮位置、模拟鼠标点击，又慢又不稳定。而 CLI 天然就是 AI 最舒服的接口，原因有三个：
- 自文档化。AI 拿到一个陌生的 CLI，跑一下
--help就知道它能干什么、参数怎么填。不需要读文档，不需要看截图。 - 文本原生。CLI 的输入是文本，输出也是文本。大语言模型最擅长的就是处理文本。
- 可组合。管道符
|让 CLI 命令可以像乐高一样拼接。比如：
lark-cli calendar agenda --next-week | grep '周三' | wc -l
一行命令就能回答"下周三有几个会"。换成 GUI，你得打开日历 → 翻到下周 → 肉眼数周三 → 心里默念一个数字。
GUI 服务人类，CLI 服务 AI。 这不是口号，是正在发生的事实。
三、飞书 CLI 到底做了什么
三层架构：从"图省事"到"全都要"
飞书 CLI 的命令设计了三个层次，对应不同的使用深度：
第一层 Shortcuts 是给懒人和 AI 用的——+agenda 直接列今天的日程，不用管背后调了哪个 API、传了什么参数。第二层是 API 的命令行映射，和飞书开放平台文档一一对应。第三层是逃生舱，2500 个 API 任你调，想干什么都行。
这个分层设计很聪明：80% 的场景用第一层搞定，15% 用第二层，剩下 5% 的长尾需求用第三层兜底。
覆盖 11 个业务域
消息、文档、日历、邮箱、电子表格、多维表格、任务、知识库、通讯录、会议、云空间——基本上飞书能干的事，CLI 都能干。
几个有意思的能力：
- 文档支持 Markdown 双向转换。这意味着 AI 可以用最熟悉的 Markdown 格式写文档，CLI 自动转成飞书格式发布
- 多维表格的 CRUD。社区已经有人用几句自然语言 + 飞书 CLI，让 AI Agent 搭出了一个 CRM 系统
- 邮件的监听和批量操作。可以订阅新邮件事件，自动分类、回复、转发
19 个 AI Agent Skills
这是最值得关注的部分。飞书 CLI 内置了 19 个 Skill 文件，覆盖日历、消息、文档、表格、任务、邮件等场景。
Skill 是什么？简单说，就是一份写给 AI 的说明书——告诉 AI 在什么场景下用什么命令、怎么组合、注意什么。比 --help 更高层，比自然语言提示词更结构化。
这意味着你不需要自己教 Claude Code 怎么用飞书 CLI。装上 Skill，AI Agent 开箱即用。
安装：三行命令搞定
npm install -g @larksuite/cli
npx skills add larksuite/cli -y -g
lark-cli auth login
第三步会弹出二维码，用飞书 App 扫一下完成授权。之后 Claude Code、Cursor 或者任何能跑终端的 Agent 框架，都可以直接调用。
四、一个具体例子
假设你是一个团队 lead，每天早上想知道"今天团队有哪些会、有没有冲突"。
以前的做法：打开飞书 → 切到日历 → 翻看每个人的日程 → 手动对比时间段 → 脑子里拼出冲突列表。
现在让 AI Agent 干：
# 查看今天所有日程
lark-cli +agenda --today --output json
# 查询某人的忙闲状态
lark-cli calendar freebusy query --user "张三" --start "2026-03-30T09:00:00" --end "2026-03-30T18:00:00"
# AI Agent 综合分析后，把结果发到群里
lark-cli im message send --chat "日报群" --text "今日冲突：张三和李四 14:00-15:00 有会议重叠，建议调整周会时间"
整个流程 AI Agent 自己跑完，你只需要看群里的结论。
再来一个更实际的：会议纪要自动化。
# 拉取会议转写记录
lark-cli minutes transcript get --meeting-id xxx
# AI 处理转写内容，提取 Action Items，创建任务
lark-cli task create --title "完成 API 文档更新" --assignee "王五" --due "2026-04-03"
# 把会议纪要发到对应文档
lark-cli doc create --folder "团队周会" --title "2026-03-30 周会纪要" --content-type markdown --body "$SUMMARY"
从"开完会"到"任务分好、文档归档"，中间不需要任何人动手。
五、飞书 vs 钉钉：同一周开源，完全不同的路
有意思的是，钉钉在飞书开源的前一天（3月27日）也开源了自己的 CLI。两家几乎同时动手，但策略截然不同：
| 维度 | 飞书 CLI | 钉钉 CLI |
|---|---|---|
| 协议 | MIT（更宽松） | Apache-2.0 |
| API 覆盖 | 2500+ API，11 个业务域 | 10 项核心产品能力 |
| 命令数 | 200+ | 未公布 |
| Agent Skills | 19 个 | 未公布 |
| 策略关键词 | 分层开放 | 底层重构 |
| 安装方式 | npm | 预编译二进制 |
| 生态依托 | 飞书文档/多维表格 | 阿里云/淘宝/支付宝 |
飞书的路是自上而下：先做 OpenClaw 插件（3月6日）→ 再做 aily 智能体平台（3月19日）→ 最后开源 CLI（3月28日），一层一层往下开放。
钉钉的路是自下而上：直接重写底层，让产品能力变成 AI 可以直接调用的"系统指令"，通过悟空平台统一调度。
哪个策略更好？现在说太早。但有一件事是确定的：两家都认定了同一个方向——AI Agent 是企业工具的下一个主要用户。
六、CLI vs MCP vs Skills：不是替代，是互补
很多人会问：有了 MCP（Model Context Protocol），为什么还要 CLI？
答案是它们解决不同环境下的问题：
| 方案 | 适用场景 | 核心优势 | 核心劣势 |
|---|---|---|---|
| CLI | 终端环境（Claude Code、终端 Agent） | 管道组合、自文档化、不占上下文 | 没有终端就没法用 |
| MCP | 无终端环境（Cursor、Claude Desktop） | 通用性强，任何支持 MCP 的客户端都能用 | 工具描述吃上下文窗口 |
| Skills | 预定义工作流 | 提高 Agent 成功率，减少试错 | 需要预先配置 |
飞书的做法是三个全做——CLI、MCP（lark-openapi-mcp）、Skills 一起开源。你在终端里用 CLI，在 Cursor 里用 MCP，在 Claude Code 里用 Skills，选最顺手的就行。
这其实反映了一个行业共识：没有一种协议能统一所有 Agent 场景，覆盖面比优雅更重要。
七、局限与坑
别只看好的，也得看清楚代价。
1. 项目刚出生两天。4000 Stars 说明关注度高，但不代表生产可用。API 覆盖率、边界场景处理、错误信息质量，这些都需要时间验证。
2. AI 幻觉 + 企业数据 = 高风险组合。飞书官方文档里专门警告了这一点：AI Agent 可能产生幻觉，也可能被提示注入攻击。想象一下：AI Agent 幻觉了一个错误的群聊 ID，把敏感信息发到了错误的群里——这不是假设，是 Agent 操作真实数据时的现实风险。
3. 安全机制有，但不够硬。--dry-run 预览模式是好设计，但这依赖于 AI Agent 自己知道什么时候该用 --dry-run。权限控制也是：授权粒度是否足够细？能不能做到"只允许 Agent 读日历但不允许发消息"？这些细节在 v1.0 里还不够清晰。
4. 不是所有 AI 环境都有终端。如果你用的是 Cursor 或 Claude Desktop 这类 GUI 环境，CLI 是跑不了的，得走 MCP 方案。CLI 和 MCP 的功能覆盖是否完全一致？目前看还有差异。
八、更大的图景：从 DAU 到 Agent 调用频率
最后聊一个更宏观的事。
过去十年，企业软件的核心指标是 DAU（日活用户）和用户停留时长。产品经理的 KPI 是让更多人打开 App、在里面待更久。
AI Agent 时代，这个逻辑要变了。
如果大量操作被 Agent 代劳，用户打开飞书 App 的次数会减少，但飞书 API 的调用量会暴增。平台的价值不再取决于"多少人在用"，而取决于"多少 Agent 在调"。
这就是飞书和钉钉同时开源 CLI 的深层原因：每个数字平台都面临一个选择——主动对 Agent 开放，还是等着被绕过。
选择开放的平台，会成为 Agent 生态的基础设施，拿到新时代的入场券。选择封闭的平台，Agent 会用截图识别、模拟点击等方式强行绕过你——体验差、效率低、但也能跑起来。到那时，你的护城河就不是壁垒了，是绊脚石。
飞书 CLI 不只是一个工具。它是飞书对这个问题交出的答卷：我们选择打开大门。
飞书 CLI 仓库：github.com/larksuite/c…（MIT 协议） 钉钉 CLI 仓库：github.com/DingTalk-Re…（Apache-2.0）
