飞书、钉钉、企业微信都在做 CLI，它们到底在争什么

飞书、钉钉、企微最近都凑在一起发了自家的 CLI 工具。乍一看挺反直觉——大家都在往前卷，怎么突然退回命令行了？但这其实是在抢下一代 Agent 的调度入口。

人机交互和 Agent 操作完全是两套逻辑。人类依赖视觉导航、点击和反馈，但这些层级和动效对 Agent 来说全是噪声。Agent 要的只是稳定的调用、能串联的步骤、结构化的结果。

办公 SaaS 的底子（发消息、查日程、建文档）天然适合做成命令。厂商们把这层外壳剥掉，把动作重新打包成 CLI，就是为了让 Agent 能直接调这些动作来拼装工作流。

现在聊 Agent 肯定躲不开 MCP 协议。但你去看看目前真正跑得顺的主流 Agent（比如 Claude Code），起点恰恰都在终端。我觉得在现阶段，CLI 加上 Skills 的组合，比全量暴露 MCP 要好用得多。

这里面有个关键点叫“渐进式披露”。如果一上来就把满屏的裸 API 全塞给模型，往往会被无关的参数撑爆上下文。

有了 Skills 作为中间层，Agent 一开始只需要判断“我要不要用 schedule-meeting 这个技能”，而不用去管底层的 API 长什么样。这就把复杂的“选工具”变成了目标感很强的“选技能”。对模型来说决策面小了，对话也能一直保持轻量。

有了 MCP，还是得推 CLI，因为 CLI 离现在的开发习惯更近。

厂商不用从头重构，只要把手头的 OpenAPI 包成稳定命令，再配上一点脚本和 Skill 模板，马上就能接入现成的 Agent 场景。你看飞书的做法就很实在，他们一边发 lark-cli 抢短期的跑通，一边发 lark-openapi-mcp 铺长期的标准，两条腿走路。

这波集中发版释放了一个信号。以后做产品，终点就不只是“人类能不能顺畅点完这个流程”，还得想“模型能不能用最少的上下文准确调用完”。

GUI 还是留给人用，CLI 归给 Agent，中间零散的能力靠 Skills 按需加载。未来 Agent 习惯用谁家的办公套件，不是看宣传页写得多热闹，关键还是看谁能把工具暴露时机、多余弹窗剔除这些“脏活”干好。

谁更容易被调度，Agent 就用谁。