飞书CLI万星背后,Agent也开始用办公软件了

· · ·

3月27日，钉钉开源了命令行工具。3月28日，飞书跟上。3月30日，企业微信也发了。

三天之内，三大办公软件做了同一件事。

你可能会想，命令行？那不是程序员在黑屏幕上敲的东西吗，跟普通人有什么关系？

关系大了。因为这三家同时做这件事，目标用户根本不是程序员，是 AI。

· · ·

飞书的命令行工具叫 lark-cli，开源不到两个月，GitHub Star 已经破了 1.1 万。1 万 Star 什么概念？钉钉的同款工具是 1.8k，企微是 2k，飞书一家的数字超过两家之和。

而且差距还在拉大。

我仔细看了下原因。飞书做了几件同行没做的事。200 多条命令，覆盖建群、发消息、写文档、管日历，几乎把飞书所有核心功能都搬到了命令行。24 个开箱即用的 Agent 技能包，Claude Code、Cursor 这些 AI 工具装上就能用。每个命令都经过真实 AI 测试，输出格式对模型友好，还带 dry-run 预览防止手滑。

还有一个容易被忽略的数字，50 多位外部开发者提交了代码，10 位的代码合入了主干，包括土耳其的电商工程师、越南的独立开发者。同行那边，外部贡献者基本为零。

开源不只是开个仓库，得有人来建。Star 数已经替开发者投完票了。

larksuite/cli GitHub 项目页，11k Stars

lark-cli Star 增长曲线，3月底开源后急速攀升

· · ·

但这个故事的重点，不是飞书赢了。

重点是，三大厂为什么在同一周，抢着把自家办公软件的”控制权”交给命令行？

陈航在钉钉发布会上说过一句话，「过去是人用钉钉来工作，未来是AI用钉钉来工作。」

过去我们用办公软件，靠的是图形界面，按钮、菜单、弹窗。这是给人设计的交互方式，AI 没法用。AI 不会点按钮，不会拖鼠标，它只会一件事，输入文本，读取文本。

而命令行，恰好就是纯文本的输入输出。

图形界面是给人造的门，命令行是给 AI 造的门。三大厂同时给 AI 开门，说明他们判断，下一个大量使用办公软件的”用户”，不是人类，是 AI Agent。

· · ·

到这里你可能会问，MCP 不就是干这个的吗？

去年 Anthropic 提出了 MCP 协议，各家 AI 工具争相接入，GitHub 上几千个 MCP Server 冒出来，看起来 AI 连接工具的问题已经解决了。

但 MCP 和 CLI 解决的不是同一个问题。

MCP 解决的是”AI 怎么跟工具说话”，它是一套语法协议，统一的接口格式、统一的认证方式、统一的安全边界。CLI 解决的是”AI 能对工具说什么”，它是能力本身，200 条命令意味着 200 件 AI 能直接干的事。

有了语法但没有词，AI 还是说不出话。MCP 定义了对话格式，CLI 提供了对话内容。

社区里有个说法很准确，CLI 是 Agent 的母语，MCP 只是语法。大语言模型训练时吃进去的海量语料里，终端命令、输出日志、报错信息占了极大比例。对模型来说，读一条 CLI 命令，就像读一句它从小就会的话。而 MCP 的 JSON Schema 是近两年才出现的新格式，模型能学会，但远没有 CLI 那么自然。

数据也印证了这一点。有开发者做了基准测试，同样的任务，CLI 消耗 1,365 个 token，MCP 消耗 44,026 个，差了 30 倍。可靠性上，CLI 是 100%，MCP 是 72%，剩下 28% 超时了。

所以两者根本不是对立关系。在真实的 Agent 系统里，CLI 负责执行层，本地、低延迟、高频调用；MCP 负责连接层，远程服务发现、统一认证、审计合规。它们是上下层，不是左右站。

· · ·

回头看三大厂这波操作，真正的信号在这里。谁先把自己的能力变成 CLI 命令，谁就先定义了 Agent 操作企业工具的”词库”。

如果飞书的 200 条命令体系成了 AI Agent 操作办公软件的事实标准，那飞书拿到的就不只是一个开源项目的 Star 数，而是 Agent 时代企业级 token 分发的生态位。

2006 年 AWS 推出 EC2 和 S3，定义了云计算的接口标准。三大厂同时开源 CLI，可能是同一级别的起点。

入口不在 App 里了。AI 的入口在命令行，而命令行的入口，三家公司正在抢。