从钉钉飞书到网易云：为何集体转向CLI为AI开门

前几天，Andrej Karpathy在推特上的一个简短回复，点破了一个正在发生的趋势。他回应的是Box CEO Aaron Levie那篇讨论构建万亿级别Agent生态的长文。Karpathy的核心观点是：还在让用户手动点击网页、填写表单的传统软件交互方式，突然显得“很粗鲁”。用户真正需要的，是一个能直接复制粘贴给AI Agent去执行的指令。

就在2026年3月，国内多家公司似乎在同一时间听懂了这句话。钉钉、飞书、网易云音乐，这三家分属企业办公、协同工具和音乐流媒体赛道的公司，不约而同地做了一件事：把自己的核心能力，压扁成一行行命令行（CLI）。

什么是“CLI化”？

很多人看到“命令行”会觉得有距离感，但其概念并不复杂。你平时在飞书里点击按钮、拖拽文件，这叫GUI（图形用户界面），是给人看的。CLI化，则是将这些功能转化为一条条文本命令，你输入指令，系统返回结果。

过去，这是程序员的专属领域。但现在，AI Agent来了。Agent最擅长理解和处理文本指令，它不需要看到精美的按钮和布局。给它一个命令入口，它就能替你操作整个软件。因此，CLI化的本质，就是为AI Agent打开一扇可以直接调用服务的大门，让产品能力从“必须人工鼠标操作”变为“AI用一行命令即可调用”。

钉钉：最早行动，定位明确

钉钉是这波浪潮中率先行动的。3月17日，在阿里发布“悟空”平台的同时，钉钉CTO朱鸿表示，希望每一个AI Agent都能像调用系统命令一样自然地调用钉钉。

注意这里的用词是“系统命令”，而非简单的API。钉钉的做法是在底层进行重写，让Agent能直接调用核心能力，绕开图形界面。其在GitHub上开源的 dingtalk-workspace-cli (dws)，采用Go语言编写，体积约8MB。

安装后，本地会多出一个 dws 命令。运行 dws --help，可以看到它涵盖了11个服务模块：

• AI表格、考勤打卡、日历日程、群聊（含机器人消息）
• 通讯录、DING消息、OA审批
• 日志周报、待办任务、工作台、开放平台文档搜索

其命令遵循标准的“服务/资源/动作”三级结构，例如 dws calendar event create 创建日程，dws contact user search --keyword \"张三\" 搜索联系人。

钉钉还专门为AI Agent设计了一些参数：

• --yes：跳过确认提示，标注为“AI Agent模式”。对于自动化流程，交互式确认弹窗往往是致命障碍。
• --mock：使用模拟数据进行测试，无需连接真实后台。
• --dry-run：预览执行效果，再决定是否真实操作，适合删除等敏感操作前的确认。

安全方面则集成了无感认证、批量操作熔断机制和安全沙箱。钉钉CLI的优势在于其聚焦企业管理场景，覆盖了OA审批、考勤、DING消息、日志等飞书CLI尚未涉及的功能，适合需要帮管理者处理行政事务的Agent。

飞书：稍晚发布，架构深思

飞书的CLI工具名为 lark-cli，同样用Go编写，但通过npm分发，体积约14MB，采用MIT协议。运行 lark-cli --help 就能发现其架构设计的巧思——它采用了三层设计。

第一层：Shortcuts（快捷命令）。所有快捷命令以 + 为前缀，内置了大量智能默认值。例如 lark-cli calendar +agenda 查看今日日程，lark-cli im +messages-send --text \"hello\" 发送消息，无需手动拼装复杂的JSON请求体。仅多维表格模块就提供了68个快捷命令。

第二层：API Commands（API命令）。提供了100多条与飞书平台API一一对应的命令。

第三层：Raw API（原始API调用）。可以直接调用飞书底层超过2500个OpenAPI端点。这相当于一个“万能逃生舱”，确保即使CLI没有封装某个边缘功能，Agent也能通过原始API调用完成任务，不会被卡住。

此外，飞书CLI还提供了 schema 命令，用于查看任意API方法的详细参数、类型和所需权限，对Agent而言犹如一本随时可查的字典。输出格式支持JSON、NDJSON、表格、CSV和美化显示共五种，比钉钉的三种更丰富，其中NDJSON和CSV在数据处理场景中尤为关键。

认证设计也更精细，支持按域申请权限（如 --domain calendar,task），以及通过 --as user 和 --as bot 切换身份。在开源社区的热度上，飞书CLI的星标数约为钉钉的3倍。

飞书的优势更偏向开发者体验和深度文档协作，提供了完整的邮件客户端、文档与Markdown互转、电子表格读写、知识库管理、会议纪要搜索等功能。如果说钉钉CLI像是一位数字行政助理，那么飞书CLI则更像一位研发效能工程师。

网易云音乐：意料之外的入局者

如果说钉钉和飞书的CLI化尚在预料之中，那么网易云音乐的入局则让人有些意外。3月23日，网易云音乐宣布全面接入OpenClaw。

其将音乐推荐、搜索等基础能力封装成了标准化CLI和自动化Skill。用户已可以通过这些接口拉取红心歌曲、获取歌词和歌单信息（下载功能不开放）。这些元数据对于构建AI音乐推荐、播客背景音选曲等场景已经足够。

虽然需要注册个人开发者并开通权限，且存在调用频率限制，但对于一家以“数据护城河”著称的音乐平台来说，开放歌词和歌单元数据已是标志性的一步。市场的反应也印证了这一点，争议本身恰恰说明，连最珍视数据的公司也开始为Agent打开接口，这股趋势的推动力已不容小觑。

为什么是CLI，而不是MCP？

一个值得注意的细节是，钉钉和飞书都选择了CLI路径，而非时下更常被讨论的MCP（Model Context Protocol）。这并非审美偏好，而是基于成本和效率的务实选择。

一份由ScaleKit进行的对照实验揭示了关键差异。该实验使用Claude Sonnet 4模型，对比了GitHub官方MCP服务器与 gh CLI的性能：

• 查询仓库语言：CLI消耗1,365 tokens，MCP消耗44,026 tokens，相差32倍。
• 查询PR详情：CLI消耗1,648 tokens，MCP消耗32,279 tokens，相差近20倍。
• 查询仓库元数据：CLI消耗9,386 tokens，MCP消耗82,835 tokens，相差9倍。

可靠性差距更大：CLI运行25次全部成功，而MCP成功18次，失败率高达28%，且7次失败均为TCP连接层面的超时。

换算成月度成本，假设每月1万次操作，使用CLI约需3.2美元，而使用MCP则高达55.2美元，存在17倍的成本差距。所有这些差异均具有统计显著性（p < 0.05）。

根本原因在于架构。MCP的工作方式是在开始时就将所有可用工具的完整描述（Schema）一次性注入大模型的上下文窗口。例如，GitHub官方MCP服务器一次就注入约55，000 tokens的工具描述，Agent在开始工作前就已消耗了大量token预算来“理解自己能做什么”。

而CLI采用按需发现（Discovery on Demand） 的方式。Agent可以先运行 dws --help 查看有哪些模块，如果对日历感兴趣，再运行 dws calendar --help 查看日历相关命令，最后运行 dws calendar event create --help 了解创建日程的具体参数。每一步只获取当前需要的最小信息单元。

CLI让Agent像人类一样逐步探索产品，而MCP则要求Agent在动手前背下整本说明书。 哪种方式更贴近真实的智能行为？答案不言而喻。

那为什么不直接用API？

既然CLI比MCP有优势，那么为什么不直接让Agent调用REST API呢？因为API是为程序员设计的，而CLI是为Agent设计的，这并非文字游戏。

一个典型的发送消息的REST API调用如下：

POST /open-apis/im/v1/messages
Headers: Authorization: Bearer xxx, Content-Type: application/json
Body: {"receive_id":"ou_xxx","msg_type":"text","content":"{\"text\":\"hello\"}"}

而使用飞书CLI完成同样操作只需：

lark-cli im +messages-send --text "hello" --chat-id oc_xxx

对人类而言两者皆可，但对Agent来说，CLI提供了三个REST API难以比拟的优势：

1. 自描述性：Agent可以通过 --help 参数自主发现和学习命令。REST API没有对等的机制，Agent需要去解析给人看的HTML文档网站。
2. 环境集成：CLI天然运行在Shell环境中，可以无缝使用管道、重定向、环境变量。大语言模型的训练数据中包含海量的Shell脚本和命令行工具使用示例，让Agent执行CLI指令的学习成本极低。
3. 认证简化：CLI通常只需在安装后登录认证一次，后续所有调用自动携带凭证。而使用REST API，Agent需要自己管理每一次请求的认证头信息。

Karpathy所说的“请直接给我一个能复制粘贴给Agent的东西”，CLI正是这个东西。REST API则还需要一层封装和适配。

尾声：GUI → CLI，软件为谁重写？

回顾历史，自Xerox PARC发明图形用户界面（GUI）后的四十年，软件行业的核心任务之一，就是将计算机的底层能力“翻译”成人类易于理解的视觉语言。这层翻译做得日益精美，也成就了巨大的商业成功。

但GUI的本质是一层翻译壳，其下运行的仍是API调用和命令行指令。如今，新的用户——AI Agent——到来了。Agent会写代码、能调API、可发HTTP请求，它不需要那层为人类视觉设计的“翻译”。

因此，软件的演进路径正在发生逆转。过去是从CLI到GUI，现在则是从GUI回到CLI。这不是技术的倒退，而是为了迎接新的、更有效率的用户。当品牌价值、用户习惯等传统护城河在Agent纯粹的“效用至上”逻辑面前逐渐淡化，API的质量、数据的可访问性与调用成本，将成为决定软件生命力的新标尺。对于开发者而言，理解并适应这一转变，或许正是在下一波技术浪潮中构建竞争力的起点。关于开发者体验与工具选择的更多讨论，欢迎在云栈社区交流探讨。