自从Agent火了以后，我感觉自己越来越懒了——懒到鼠标键盘都不想碰，就幻想着靠打几个字把活儿全干完。
过去用办公软件，都是人对着图形化界面（GUI）指指点点。可现在呢？越来越多场景开始由Agent替人操作电脑或工具，GUI的频率自然就降下来了。
取而代之的是我以前最不喜欢的CLI——命令行界面。但今时不同往日，我们根本不需要记那些复杂的指令，只要对着输入框发一句话，AI自然会帮我们把事办了。
以前聊办公软件，大家在意的无非是功能好不好用、协同顺不顺、开放平台强不强。随着各家功能日趋完善，现在更多公司盯上了一个新问题：如果未来大量工作不再由人来操控，而是交给Agent，那谁家的系统更适合被Agent调用？
这也是为什么3月底那几天，飞书、钉钉、企业微信像约好了一样，轮流把自家的CLI搬上了GitHub。
今天的CLI早就不只是开发者黑框框里的小玩意儿了，它更像是AI进入企业工作流的一层标准接口。你让Agent去点GUI，和让它直接调用结构化的命令，完全就是两个难度级别——前者像隔着玻璃抓东西，后者等于直接把大门敞开。
这段时间我把三家的CLI都过了一遍，也拿几个真实办公任务做了测试。不卖关子，先说结论：如果你想让Agent进入企业办公流程，飞书这套明显更成熟，也更像是一套已经准备好供Agent长期使用的基础设施。
当然，这个结论虽然有主观成分，但确实有事实依据撑腰。
为什么我觉得飞书更合适？
① 用真实数据说话
首先我承认我跟风了。
这三家的发布时间非常接近：钉钉是3月27日，飞书3月28日，企业微信3月29日。这个时间窗口很有意思，几乎就是同场竞技，像约好了一样。
一个多月后再看，飞书的GitHub热度明显领先——Star、Fork以及互动量都更高，截至目前已有12K星标。
而且飞书的版本更新也更频繁，就在几个小时前又更了一版。
当然，我也不想把Star直接吹成“绝对实力证明”。开源实战项目的热度本来就会受品牌、传播、文档表达、开发者关系等多种因素影响。但同样是大厂，同样都在Agent这个热门窗口发布，飞书能更快地把关注度转成持续讨论，本身就说明它更容易被开发者看懂，也更容易被拿去尝试。而CLI这种东西，恰恰最看重“能不能快速跑起来”。一个项目发出来大家看两眼就走了，那再完整的能力也很难形成生态。
② 在开源这件事上，飞书态度很端正
作为一个非专业开发者，一个开源项目能不能留住我，很大程度上就取决于项目首页给我的第一印象。
先看飞书CLI的项目首页。排版非常工整，功能介绍和使用教程都罗列得很清楚，这让我更愿意去了解和尝试。
再来看看钉钉CLI的首页。信息虽然也丰富，但细致程度明显不如飞书，整体还可以接受。
而企业微信这边就稍微有点敷衍了。整个项目只有寥寥几行介绍，可能是想引导大家进群交流。
相比之下，飞书的能力显然更开放，整合得也更好。它几乎覆盖了日历、消息、文档、表格、幻灯片、邮件、会议、审批、考勤在内的所有核心业务，而且还在疯狂更新。
在飞书的开源资料里，最容易让人记住的两个数字是：200+命令、2500+Raw API。这个量级至少说明它开放得足够深——很多能力不是摆样子的“演示能力”，而是尽可能把底层可调用的内容都摊开了。
再往里看，它不是只把API做成一排命令，而是做了分层：快捷命令、标准API命令、Raw API，再往上还有面向Agent的Skills。难怪星标涨得这么快。
这点很关键。很多平台做CLI，容易停留在“开发者能调起来”这个层面。但Agent真要高频、稳定地干活，光能调还不够——它需要能力边界清晰、调用路径短、输出结构化、报错尽量少、命令语义明确。飞书这套设计，明显是在往这个方向靠拢。
为了不只停留在读README，我自己选了个最常见的场景做实测。一个原则：不比冷门炫技，就比大家平时真正会遇到的办公任务。
场景实测
作为一个职场打工人，平常肯定少不了和各种云文档打交道。以前需要手搓文档，现在有了CLI的加持，一句话就能轻松搞定。而现在我们要比的，就是谁在处理过程中更流畅、结果更好。
这里我准备了一个统一任务，在龙虾中安装各家CLI并执行。
提示词：请使用xxcli生成一份云文档，帮我搜集并整理昨天最热门10个Github开源项目，附带项目简介，填入云文档中，标题是《今日开源项目精选》，完成后把文档链接发送给我。
这个任务看起来简单，但很适合测试“首轮上手体验”。因为它会碰到最核心的问题：授权顺不顺、命令找不找得到、创建结果能不能稳定返回。
① 飞书CLI
飞书这一轮给我的感受是整个流程非常直接。该授权就授权，该创建就创建，完成后把文档链接返回，整体就像一条连贯动作。
而且文档的完成度也很高，每个项目都附带了简介和数据分析，还贴心地提供了超链接——整个过程只授权了一次。
② 钉钉CLI
钉钉收到请求后，也很快完成了任务。
它也确实按我的要求整理了项目名称和相关信息，但说实话，整体美观度和信息呈现效果相比飞书还是欠了点火候。
当然，钉钉这份文档也算合格。
③ 企微CLI
企微也能完成，属于稳扎稳打那种。
但在交互流畅度上，我个人感觉它没有飞书那么顺，信息丰富程度和排版美观度也跟飞书有些差距——不过也算及格。
最后总结一下：上面这三份文档，只有飞书这份是我可以直接拿过来分享给别人看的，另外两份在内容和排版上可能还得手动微调一下。
这里不是说谁不能用，而是当你把执行方换成Agent之后，那种“少一次打断、少一次来回修改”的价值会被放大。人可以忍受多点几下，但Agent改起来会花费更多时间和Token。
第二个任务：批量整理简历并上传到多维表格
如果说“生成文档”主要考验的是内容创建能力，那么更贴近企业日常的，其实是另一类任务：把外部资料结构化整理进业务系统里。
所以第二轮我换了一个更贴近真实办公的任务：创建一个多维表格，并批量上传面试人员简历。
这个任务乍一看不复杂，但其实更能测出Agent是否真的适合进入办公流程。因为它要连续完成创建多维表→设计表格字段→分析文档内容填入信息→上传简历附件→返回表格链接这多个步骤。只要中间任何一个环节没打通，Agent就得反复中断、补权限、改调用方式——这种感觉懂的都懂。
同样我还是通过龙虾下达任务，提示词如下：
请根据目录"C:\Users\admin\Desktop\简历归档"里的15份简历，总结相关信息，并使用xxCLI创建一个xx多维表，表格名称为"面试候选人管理表"，表格里要有候选人姓名、年龄、手机号、邮箱、学历、意向岗位、期望薪资、技能特长这些字段，并在对应的人员信息表格后面上传对应的简历附件。
下面来直接验收成果。
① 飞书CLI
讲真，飞书在这个场景里的优势，比“生成文档”时还明显。它不只是把表建出来，而是能比较顺畅地把字段、记录和附件上传这几步串起来。
尤其是附件上传这一点，非常能体现平台是否真的为Agent开放了完整链路。飞书这边的整体表现更像是：它已经把这些能力提前整理成了适合编排的接口，Agent调起来比较自然。
最终产物也比较完整：表结构清晰、记录内容规范、附件能直接挂在对应条目下面，基本已经是能直接进入后续协作流程的状态。
② 企微CLI
企业微信整体表现中规中矩。不知道是受龙虾影响还是什么原因，它明明可以上传文件，却频繁让我自己通过它生成的脚本来上传，让人有点费解。
经过我再三强调之后，它虽然按要求把简历附件上传了，但在表格里漏掉了大量信息——除了姓名以外全是“待补充”的状态，并且还重复添加了一条人员信息。
总体来说，算是完成了一半的任务。
③ 钉钉CLI
最后是钉钉。老样子，它还是会时不时弹个授权窗口让我点击确认。
经过一番等待后，它也给到了结果：表格创建成功了，简历信息也填写了，但貌似由于CLI的限制，它并不支持上传附件。
最后我打开文档看了看，附件确实没上传，同时也漏掉了一些信息。
所以整体来说，只算完成了50%左右的任务。
这个任务说明了什么？
如果说“生成文档”更多是在比内容生产能力，那么“多维表格批量上传附件”比的其实是系统到底有没有把自己的业务对象真正开放给Agent。
因为对企业来说，AI未来真正高频处理的，往往不是帮你写一份漂亮文档，而是把信息不断写进业务系统、从业务系统里取出来、再自动流转下去。
从这个角度看，飞书的优势不只是“结果做出来了”，而是它在结构化对象、复杂字段和多步骤链路上的开放程度更高，也更适合被Agent当成稳定工作流的一部分来调用。
更关键的一点：实时监听能力
前面两个任务，更多测试的是“Agent能不能把事情做完”。但如果只停留在“接到指令再执行”，那它其实更像一个高级脚本。
真正让企业开始重视CLI的，往往不是一次性执行任务，而是Agent能不能像一个长期在线的助手一样，持续关注工作？
这时候就要看一个很关键、但很多人容易忽略的能力：实时监听。
飞书CLI给我的最深感受之一，就是它不只提供了“执行命令”的入口，还提供了让Agent持续挂住、实时接收事件的能力。
这意味着你可以让它长时间待命，实时接收消息，随时响应。这类能力本质上不是“多一个功能”，而是把Agent的角色从“临时工具”变成了“持续在线的数字员工”——是不是有点AI客服内味儿了？
相比之下，钉钉目前更偏向“命令触发式”的使用方式。也就是说，你给它发送命令它才执行，但如果你希望它自己长期守在那里7×24h实时接受新消息，那就有点难了。
从这个角度来看，CLI不只是“把功能做成命令行”，更是在决定一个平台是否愿意把自己变成Agent可持续接入的事件系统。而在这一点上，飞书显然走得更靠前。
工作流程的复用性
前面讲的是“能不能调”、“能不能监听”，但如果再往企业落地走一步，还会碰到第三个问题：一个好用的Agent工作流，能不能被固化、复用、持续演进？
因为真实办公里，很多流程不是一次性的。这些事情如果每次都从头让Agent理解一遍，效率其实并不高。真正成熟的做法，是把一套已经验证过的流程封装起来，让它变成一个可以反复调用的能力单元。
飞书这里有一个很值得注意的点，是它提供了一个叫 lark-skill-maker 的工具。它可以进一步允许开发者、甚至Agent自己，把常用工作流封装成一个新的“技能包”。
就拿写文章来说吧。每个人都有不同的写作风格，现在经常需要通过AI来写一份文章大纲，然后再一点点修改。写作风格也是自己慢慢调试出来的，为了方便后续复用，我们可以直接让飞书CLI帮我们把经验打包成Skill。
当我下次换了新选题时，直接调用这个Skill就能写出类似风格的文章大纲了，非常方便。
根据项目首页介绍来看，企微目前支持的技能不算多，主要围绕会议、消息、日程、文档几个方面。
钉钉支持的技能也不少，但貌似还没有围绕技能封装相关的工具脚本。
可以看到，虽然它们的能力开放，但还没走到“技能封装层”。
技术路线
测试结束后，我又深扒了一下几个项目不同的技术方案。
飞书是用 Go 开发，上层通过npm分发，兼顾了Go的高性能和Node.js生态安装便捷的优势。整个项目的工程化程度非常高，从自动构建、版本发布到文档更新都是标准化流程，每个命令都有完整的单元测试和集成测试，所以很少出岔子。
企微则是用Rust开发，性能确实不错，但整体工程成熟度差点火候，安装也比另外两个多些步骤。
钉钉CLI同样是用Go开发，工程化做得也不错。不同的是，飞书和企微用的是MIT协议，而钉钉采用的是Apache-2.0协议。
虽说都比较开放，但对于个人开发者而言，MIT协议的自由度还是更高一些；如果是企业项目，那么Apache-2.0会更稳妥。
最后
就当前阶段来看，飞书把这件事做得还是更彻底一点。它的优势不是一句“功能更多”就能概括的，而是几个层面叠加形成的：项目热度高，说明外部开发者愿意用；能力开放得深，说明不仅能演示，还能做事；命令和Skills设计更面向Agent，说明不是顺手做个CLI，而是真把它当成新入口在经营。
从实际体验来看，飞书的优势并不只是在某一个功能点上更强，而是它从开放深度、命令设计到跨模块联动，都更像一套为Agent长期工作准备好的基础设施。GUI时代比的是人用起来是否顺手，Agent时代比的则是谁更方便被调用、被编排、被持续执行。
当然，接下来这件事还会继续卷，三家都不会停下脚步。至少在现阶段，飞书显然走得更靠前一些。
技术文档中常常提到一个观点：真正的智能化不是让人学机器，而是让机器适应人。在办公人工智能这条路上，CLI正在重新定义我们与工具的关系——你准备好拥抱这种改变了吗？
发表于 1 小时前
|
查看: 4|
回复: 0
