一切软件，都将为Agent开一扇门 —— 钉钉飞书、网易云 已经动手了，选了CLI，抛弃MCP

🍹 Insight Daily 🪺

Hi，这里是Aitrainee，欢迎阅读本期新文章。

Karpathy前几天在推特上回了一条帖子，只有几句话，但值得细品。

他回复的是Box CEO Aaron Levie一篇万字长文《Building for trillions of agents》。原话是这样的：

💯 "If you build it, they will come." 现在你去任何一家公司，他们还在用传统界面给你下指令。让你导航到某个网页，点某个按钮，在某个输入框里填某个东西。 这突然让人觉得很粗鲁。你为什么要告诉我该怎么操作？请直接给我一个能复制粘贴给Agent的东西。

"很粗鲁。"

这个词选得太精准了。你还在让我手动操作，是不是有点看不起我的Agent？

而2026年3月，中国有三家公司几乎同时开始动手。

3月17日，钉钉发布「悟空」平台，宣布全面CLI化改造完成。10天后，CLI代码开源。

3月23日，网易云音乐全面接入OpenClaw，标准化CLI和自动化Skill封装。

3月28日，飞书CLI开源，MIT协议。

同一个月，三家公司，分属三个完全不同的赛道——企业办公、音乐流媒体、协同工具——做了同一件事：

把自己的产品，压扁成了命令行。从"只有人能用"变成"Agent能调"。

如果再算上微信推出ClawBot插件——虽然只是"开了门缝那么大的一小个缝"。

这是Karpathy说的那件事正在发生：一切软件，都在为Agent重写。

先说清楚一件事：什么是CLI化

很多人一看到"命令行"三个字就头大。但其实概念很简单。

你平时用飞书，点按钮、拖文件、填表格——这叫GUI，图形界面，给人看的。

CLI就是把同样的功能，变成一行一行的文字命令。你敲一行字，电脑给你吐一行结果。

以前这是程序员的领地。

但现在，AI Agent来了。Agent最擅长的就是处理文字指令。它不需要看到按钮，不需要花里胡哨的界面。你给它一个命令入口，它就能替你操作整个软件。

所以CLI化的本质是：给AI开一扇门。

把产品能力从"只有人用鼠标点才能用"，变成"AI用一行命令就能调"。

钉钉：最早宣布，最激进

钉钉是这一波里第一个出手的。

3月17日，阿里发布悟空平台的同一天，钉钉CTO朱鸿说了一句话：

我们希望每一个AI Agent，都能像调用系统命令一样自然地调用钉钉。

注意用词——"系统命令"。不是API，不是协议，是ls、cd、grep那种东西。

钉钉做的事情不是在现有GUI上包一层壳。是重写底层代码，让Agent直接调用底层能力，绕过图形界面。

GitHub上叫dingtalk-workspace-cli，Go语言，8MB，Apache-2.0协议。装完之后本地多一个dws命令。 跑一下dws --help，11个服务模块：

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

命令结构是标准的"服务/资源/动作"三级。dws calendar event create，dws contact user search --keyword "张三"。

钉钉还做了几个专门给Agent设计的参数：

--yes
，跳过确认提示，描述写的是"AI Agent模式"。做过Agent开发的都懂——一个交互式确认弹窗就能让整个自动化流程崩掉。
--mock
，模拟数据测试，不用真连后台。
--dry-run
，先预览再执行。Agent要删个日程之前先看看要干什么。

安全方面：无感认证、批量熔断（防Agent失控批量操作）、安全沙箱。

钉钉的优势很明显——企业管理场景。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个shortcut命令。

第二层：API Commands。 100多条命令，跟飞书平台API一一对应。

第三层：Raw API。 直接调飞书底层2500多个OpenAPI端点。相当于万能逃生舱——不管飞书有什么API，即使CLI没封装对应命令，你也能直接调。Agent遇到边缘场景不会被卡住。

飞书还有个schema命令，查看任何API方法的参数、类型和所需权限。对Agent来说相当于一本随时可查的字典。

输出格式：JSON、NDJSON、table、CSV、pretty五种。钉钉只有JSON、table、raw三种。多出来的NDJSON和CSV在数据处理场景下很关键。

认证设计也更细——按域申请权限，--domain calendar,task只申请日历和任务权限，不用一口气开全。支持--as user和--as bot切换身份。

开源星标，飞书2.6k，钉钉0.9k，近3倍。

飞书的优势在开发者体验和文档协作——完整的邮件客户端、文档Markdown互转、电子表格读写、知识库管理、会议纪要搜索。

一个比喻：钉钉CLI像给企业行政部门配的数字助理，飞书CLI更像给研发团队配的效率工具。

网易云音乐：最出人意料的入局者

如果说钉钉飞书CLI化还在预期之内——毕竟都是效率工具，天然适合Agent操作——那网易云音乐的入局就有点出人意料了。

3月23日，网易云音乐宣布全面接入OpenClaw。

归藏在推特上的评价很精准：

现在都CLI和Skills化了，网易云音乐都有了。还是得感谢龙虾，让国内这些，把数据当成宝贝的公司一夜间都变得开放了。

功能还挺全——拉取红心歌曲、获取歌词、获取歌单。下歌当然不行，但元数据够用了。拿来做AI音乐推荐、播客背景音选曲，场景不少。

需要去网易云注册个人开发者、开通权限。个人开发者100次/分钟的rate limit，音频流不开放。但歌词+歌单元数据的开放，对于一家以"数据护城河"著称的音乐平台来说，已经是很大的一步了。

有人骂"噱头大于实际"，也有人说"龙虾确实功不可没，一己之力撬动国内互联网开放进程"。

评论区最辣的一条是："脱裤子放屁。网易云需要的是手机厂商开放系统级的语音助手支持更灵活的语音指令。"

但争议本身恰恰说明了一件事——连网易云音乐这种"数据即命脉"的公司都开始为Agent打开接口了，这件事的推力已经。。

还有谁

微信推出了ClawBot插件——用微信控制OpenClaw，四步搞定。虽然只是"开了门缝那么大的一小个缝"，具体开放程度还很有限，但微信愿意开这个口子本身就是信号。

Kimi、MaxClaw/Minimax，AI原生公司，也有一系列类 OpenClaw的产品。。

甚至有人做了OpenCLI，一个聚合平台，已经支持了50多个网站的CLI接入。

有条评论说的好：

MCP/Skills这波确实倒逼了一批国内厂商开放API。以前要爬数据，现在官方主动给你接口。生态位的压力比什么都管用。

为什么是CLI，而不是MCP

这一波里有个值得注意的选择：钉钉和飞书都没选MCP，选了CLI。

这不是审美偏好，是成本账。

ScaleKit用GitHub官方MCP服务器和gh CLI做了对照实验，跑的模型是Claude Sonnet 4：

• 查仓库语言：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倍的成本差距。

所有5项任务差异都具有统计显著性，p < 0.05。

问题出在架构层面。MCP的工作方式是把所有工具的schema一次性塞进大模型的上下文窗口。GitHub官方MCP服务器一次注入55,000 tokens的工具描述。Agent还没开始干活，光是"理解我能做什么"就吃掉了大量token预算。

而CLI的工作方式是按需发现。Agent先跑dws --help，看到11个模块。觉得日历相关？跑dws calendar --help。要创建日程？跑dws calendar event create --help。每一步只读当前需要的那一小段帮助信息。

这个区别看起来是技术细节，但它决定了一件根本性的事：CLI让Agent像人一样逐步探索一个产品，MCP要求Agent在动手之前先把整本说明书背下来。

哪种方式更接近真正的智能行为？

那为什么不直接用API

有人会说，CLI比MCP好我理解了，但直接用REST API不就行了？为什么还要包一层CLI？

因为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永远提供不了的东西：

第一，自描述性。 Agent可以跑--help来发现命令。REST API没有等价物——你得去读文档网站，而文档网站是给人看的HTML页面。

第二，环境集成。 CLI天然跑在shell里，可以用管道、重定向、环境变量。Agent已经极其擅长操作shell——LLM的训练数据里有天量的bash脚本和命令行用法。让Agent发HTTP请求需要额外的工具和环境，让它跑CLI指令几乎是零成本。

第三，认证简化。 CLI装好登录一次，后续所有调用自动带上token。REST API每次请求都要自己管理认证头。

Karpathy说的那句话恰好点题：

请直接给我一个能复制粘贴给Agent的东西。

CLI就是那个"能复制粘贴给Agent的东西"。REST API不是——它还需要一层封装才能用。

Karpathy和Levie到底在说什么

回到Karpathy回复的那篇文章。

Levie的核心判断：未来每个员工会有大量Agent替他干活，一家1万人的公司可能跑着100万到1000万个Agent。

这些Agent不再是"带了几个工具的聊天机器人"。它们有自己的沙箱计算环境，能写代码、跑代码，能直接调用API和CLI，有自己的文件系统和长期记忆。

Claude Code、Devin、Codex这些编码Agent，在过去半年完成了从"能用"到"好用"的跨越。而最近，这种能力已经从编码领域蔓延到了所有知识工作。

Levie说了全文最核心的一句话：

如果你的某个功能没有API，那它等于不存在。如果它不能通过CLI或MCP Server暴露出来，你就处于劣势。

"不存在"——不是夸张修辞。是字面意思。

Paul Graham的经典名言是"Make something people want"。

现在这句话正在变成：Make something agents want。

从people到agents，一词之差。

YCombinator的Jared Friedman也发了条帖子提醒所有人：「现在最好的开发者工具，大多数连注册账号都不能通过API完成。在Claude Code时代，这是个大失误。因为Claude没法自己注册。把所有账户管理功能放进API，现在应该是最基本的要求。」

Agent选软件的逻辑和人完全不同。人会受品牌、UI颜值、朋友推荐、广告、切换成本影响——所以很多明明更好的产品打不过先入为主的竞品。但Agent不认品牌，不看脸，没有社交圈，不会被广告打动，没有"习惯"这回事。它的选择逻辑极其冷酷：哪个API更好用、更稳定、更便宜、文档更清晰，就用哪个。

这是一种近乎纯粹的达尔文式选择。没有噪音，没有偏见，只有适应度。

品牌价值、用户惯性、渠道优势，这些传统护城河在Agent面前一文不值。剩下的只有：API质量、数据独占性、和性价比。

尾声

1980年代，Xerox PARC发明了图形用户界面。此后40年，整个软件行业都在做同一件事：把计算机的能力，翻译成人类能理解的视觉语言。

这层翻译做得越来越精美。Apple靠它成了全球市值最高的公司。

但GUI的本质是什么？一个翻译层。计算机底下跑的还是API调用、命令行指令、HTTP请求。GUI只是包了一层好看的外壳。

现在Agent来了。

Agent会写代码，会调API，会发HTTP请求。它不需要那层翻译。

所以软件的演化路径，40年前是CLI → GUI。

现在反过来了，GUI → CLI。

不是因为我们要回到过去。

是因为那个新的用户来了。

这个新用户，叫Agent。