26年开年，随着OpenClaw和Agent的爆火，CLI越来越浮出水面。

Karpathy也说，命令行这种传统技术，更令人兴奋了，因为AI Agent可以用它轻松组合、交互、完成复杂任务。

3 月底前后，企业微信、飞书、钉钉前后脚，都不约而同把 CLI 推上台面；一个多月后的现在，谁才是企业用户眼里的头号玩家？

刷GitHub的时候，看到飞书和钉钉相关的Star数，肉眼可见在涨，但是真实效果，还真有挺大差别。

今天说说我在办公场景，用Agent的一些感受。

直接说结论：和其他产品相比，飞书已经逐渐进化成了显著领先的新物种。

新一代AI原生的先进团队，已经在拥抱全新的效率范式。

01开发者和企业家，为啥选飞书CLI

GitHub Star的数量，开发者眼里，是张很诚实的选票。

先看看数据。

钉钉3月27日开源，dingtalk-workspace-cli用的是Apache-2.0协议。

飞书3月28日开源，larksuite/cli是MIT协议。

企业微信3月30日开源，wecom-cli同样是Node.js加Rust的组合，协议没过多宣传但给了访问权限。

一个月跑下来，飞书CLI的数据最扎眼。

开源当天就冲到了1000+Star，一个多月后在5月中旬突破了一万星。目前已经11.4k了。

这个速度放在全球办公SaaS CLI的坐标系里看，也确实是第一梯队的水平。

钉钉的star大约在几千的量级，企业微信稍微慢一点，但也破了千。

我更关心的，是数字背后反映的工程表达的差异。

飞书CLI的仓库给我的感觉，是很精心打理过的。

文档结构清晰，README写得让一个对飞书完全陌生的人看完就知道怎么跑起来。

Issue区活跃，核心团队的回复频率和态度都很在线。Release的节奏也快——47天出了32个releases，这个迭代速度说明背后有人在认真维护。

钉钉的仓库则呈现出一种不太一样的风格。

代码量扎实，但文档的友好度和飞书比有一些差距，上手难度稍大。

企微的仓库最小巧，但可能是因为入场时间稍晚以及能力范围的限制，活跃度和讨论浓度相对不高。

但我得说句实话：Star数能说明一部分问题，但最关键的其实不是数量，是持续讨论的质量。

飞书的开发者生态密度和讨论度，明显高出不止一个身位。

在飞书的Issue里，有人在讨论怎么用CLI做自动化审批流，有人在分享自己写的小脚本，有人在提改进建议。钉钉的Issue里，更多是关于技术细节的探讨，比如某个命令的参数含义、特定场景下的行为预期。

包括身边玩龙虾、配置各种个性Agent的，飞书的CLI已经开始在开发者手里被玩嗨了，也真有人拿去跑业务。

企微的Issue则相对集中在安装配置相关的问题上，玩家略显沉默。

我就在自己的一个测试环境里，用飞书CLI接了一个简单的Agent流程，让它在早上定时把当天的会议日程拉出来、从多维表格里读取待办事项、然后往群里发一条汇总消息。

整个过程从配好到跑通，大概花了十几分钟。

关键是还几乎不需要翻阅大量API文档，一行lark schedule list就拿到了日程数据。

不管是新手开发者Vibe Coding，还是老法师魔改调用，选飞书，都是最优解。

任务效果，对比也很直观。

同样的指令：帮我整合最新的AI公众号资讯文章并统计。

飞书CLI的效果就明显更清晰全面，多维表格互动性更强，版式和数据分析能力都更好。

相比之下，钉钉生成的就是普通传统表格了。大概就是普通二本实习生和麦肯锡清北实习生的区别。

02能力开放的广度深度，谁真的敢把家底翻出来

一个CLI到底好不好用，最终要看它能干什么、干得怎么样。

飞书的态度很直接：能给的都给了，只用一个飞书就够了。

CLI覆盖了消息与群组、云文档、多维表格、日历、视频会议、邮箱、任务、知识库、通讯录、搜索等十几个业务域的200多条子命令，背后是2500多个原始API的封装。

不仅仅是有人开会、写文档这些通用功能，智能表格的数据读写、权限管理这种需要深度操作的能力，也都暴露出来了。

而且飞书的迭代速度巨快，个多月新增100多项能力，

我最感兴趣的是多维表格和权限管理这两个模块。

很多办公平台开放CLI的时候，会把权限部分包装成一个黑箱，CLI只管调用，具体能不能干成看系统心情。

但飞书CLI的处理方式不一样，你可以在命令级别明确指定权限范围和操作粒度，这让Agent在做跨模块操作的时候，不需要在多个界面之间来回切换。

钉钉的开源策略是另一条路。

它的CLI覆盖了AI表格、日历、日志等能力，相对来说有些功能入口藏的比较深，很多功能让人想不起来、或者略显别扭。

飞书拿出来的能力模块数量明显更多，覆盖面更广，属于一种平台级开放策略，不仅全而且深。

企业微信的CLI，老样子相对保守，开放了消息、日程、文档、智能表格、会议、待办、通讯录七大类能力。

我试着分别用三家的CLI跑了一个完整的场景：让Agent帮我处理一个工作日的任务。

用飞书CLI，流程是这样的：

Agent收到一个自然语言的待办提醒，然后调多维表格查一下今天的任务列表，再根据任务的优先级生成一份简单的日程表，最后通过消息模块发给相关群聊。整个流程用到了表格查询、消息发送两个模块，Agent从头到尾没有离开过终端。

用钉钉的dws，跑同样的场景，结果稳定性一般，效果会有波动。

用企微的CLI，能做的操作相对基础一些，比如收消息、查日程、读文档，更复杂的跨模块串联就有点吃力了。

能看出来，飞书想做的是让Agent能在办公流程里无缝穿梭，需要什么能力随时调。

这是绝对有魄力也有能力的，实现效果更令人满意。

03技术路线的分野

说完了能干什么，再来说怎么干。这是最让一个技术人员兴奋的部分。

飞书选了Go语言，14MB的二进制文件，MIT许可证，通过npm分发。

Go的跨平台能力、单文件部署的便利性、启动速度这些特性，让飞书CLI的开发者体验从一开始就比较顺。

lark --help一看，三层设计很清晰：底层是裸CLI命令，中间层封装了一些常用场景的快捷命令，上层是19个开箱即用的AI Agent Skills。

Skills很有意思，不用自己去组装命令，前置准备了一堆预制好的功能组件，直接拿过来就能用。

飞书还搞了Skill创作大赛，鼓励社区贡献，生态搭建的思路很明确。

钉钉也是Go语言写的，8MB的二进制，但走的是Apache-2.0协议。

各种结合AI的动作也不少，但是似乎有些还是停留在发布会和汇报层面，实际上没有太得到开发者的认同。

企业微信走的是Node.js + Rust的路线。

在安装流程上比飞书的一键安装，稍微复杂一些，除非是有硬性理由，不然工作量是更大的。

技术路线的差异，背后是工程哲学的不同。

飞书在追求开发者友好度，力求让一个从没接触过飞书开发环境的人，几分钟内就能跑通第一条命令。还有很多模版可以调用。

再说说工程细节。

飞书CLI在dry-run预览模式、分页查询、限流控制、防注入、凭证管理和输出脱敏这些事情上，都做得比较到位。

我跑一个批量更新多维表格的操作时，先用--dry-run跑了一遍，确认数据范围没问题之后才正式执行。

输出结果默认是JSON格式，对Agent来说非常友好——拿到结构化数据直接处理，不用再去解析乱七八糟的文本。

玩Skill现在很流行，也确实很有价值，而价值的进一步放大、工程能力的进阶，还是得靠飞书。

04写在最后

一个多月前，三家几乎同步开源CLI的时候，很多人以为这是又一次大厂之间的军备竞赛，比谁的功能多、谁的文档全。

目前来看，飞书的CLI在开发者体验、生态搭建和迭代速度上确实走到了前面。

GitHub破万星的数据不是天上掉下来的：背后是32个release的持续迭代、19个开箱即用的Skills、覆盖10+业务域的能力开放，以及社区里真实、活跃的讨论氛围。

某种程度上，在国内，飞书已经超越了其他产品不止一个身位。

成为了AI创业者、开发者的默认选项，更是目前企业跑Agent工作流最合适的工作平台。

我其实更关心的是另一个视角：CLI这个看起来在往回走的交互方式，在Agent时代究竟会变成什么样子。

过去的软件设计，默认使用对象是人类，所以图形界面是主流。未来的软件设计，默认使用对象可能有一半是Agent。当Agent的数量超过人类用户的数量时，为人类设计的GUI还会是默认的第一界面吗？

我没有确定的答案，但有一点是肯定的：当Agent开始大规模干活的时候，谁家的平台能让Agent干得最顺手，谁就更有可能成为那个时代的操作系统。

CLI不是终点，它是通向那个未来的一扇门。

三个月后再看，也许会有完全不一样的发现。