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不是終點，它是通向那個未來的一扇門。

三個月后再看，也許會有完全不一樣的發現。