飞书 CLI 牛皮啊，发布一个月多点就达到 10000 Star 了！

说明用户和市场相当认可这个动作

最近我们可以发现，越来越多的传统办公产品开始发布 CLI 和 Agent。

AI 时代的 SaaS 软件可能得换个做法了：UI 只是最基本的，接下来还要竞争对 Agent 的适配程度以及覆盖率。在这块，我觉得飞书走得相当靠前。

作为一个 IM 软件，飞书在 AI 时代去做这种开放自己所有能力的 CLI 工具，其实是一种非常不传统互联网的尝试。

这对于之前的互联网产品逻辑和经验来说，是一个非常不应该做的决定。

因为他们这个 CLI 几乎可以控制飞书的所有能力：你可以完全不跟飞书的传统 UI 去交互。只跟 CLI 交互，也可以完成飞书上所有的工作。

传统的 IM 办公软件通常非常复杂，入门门槛相对较高。无论从产品逻辑、UI 设计还是交互设计的角度来看，都没有办法太好地消解这种复杂性。

但是 CLI 工具交付给 Agent 以后，就可以快速消解这种复杂性。用户只需要进行对话，这是非常本能的行为，不需要在繁杂的层级列表 UI 里去寻找功能入口。

我拉了一下数据，他们迭代效率也非常恐怖，它们是 3 月 28 号开源的，一个多月发了 32 个版本、385 个提交。

这说明飞书对这块是非常重视的，投入的人力和精力也非常大。

他们在 CLI 本身的设计上也考虑得非常多，下了很多功夫。主要分为三层：

面向日常任务的快捷命令、开放平台对应的标准 API、兜底的 API 调用。

因为人和 Agent 都不喜欢从 2500 个 API 里去寻找参数，但又需要把这些能力暴露出来，所以他们采用了这种分层的形式。

即使做了分层设计，CLI 本身的内容和 API 依然非常多。所以他们把 CLI 作为工具本身，同时做了很多 Skills 用来充当 CLI 的说明书。

Agent 可以分层、分类型地了解应该如何调用这些 CLI 及其命令。

此外，他们在对 Agent 友好的命令包装上做了很多工作，例如：

(a) 内置了 Dry Run (b) 结构化输出 (c) 身份选择、权限检查与风险等级评估 (d) 允许 Agent 在发消息前预览请求 (e) 建立了输出格式的“契约”：将成功或失败的结果、原因以及风险提示都放在结构化数据里。

这样如果出错了，AI 可以非常清楚地进行调试和修改，而不是盲目猜测。

其实现在你如果要创业或者做自己的 Agent，就不需要非得写一个界面。

飞书 CLI 加上 Agent 框架可以完成所有的 Agent 产品常见的操作：

你的聊天界面就是你的 Agent 聊天界面；

你的数据库就是飞书多维表格和文档；

你的用户就是把你拉到组织里的群成员；