最近看到飞书开源了 lark-cli，我觉得这件事挺有代表性。

表面上看，它只是多了一个命令行工具：可以发消息、查日历、写文档、建多维表格、处理任务。可如果放到 AI Agent 的语境里看，它其实是在给 Agent 提供一套“可执行的软件接口”。

过去我们习惯给人设计界面，所以产品会强调按钮、菜单、图标和交互动效。Agent 不一样。Agent 不需要漂亮界面，它需要的是清楚、稳定、可组合、可回放的操作入口。CLI 恰好满足这些要求。

CLI 为什么适合 Agent

CLI 最大的优势不是酷，而是它天然是文本化的。

Agent 最擅长处理文本。命令是文本，参数是文本，输出也是文本。相比让 Agent 截图、识别按钮、移动鼠标、模拟点击，直接执行一行命令要可靠得多。

还有一个很关键的点：CLI 通常是自描述的。一个设计得好的 CLI，只要运行：

tool --help

Agent 就能知道有哪些命令、参数怎么填、输出长什么样。API 当然也能做集成，但 API 依赖文档、鉴权、端点和 SDK；CLI 则更像一个随手可用的工具箱。

MCP、CLI 和 Skills 的关系

现在让 Agent 操作外部服务，常见有三种方式：MCP、CLI 和 Skills。

我自己的理解是：

• CLI 是真正干活的手。
• MCP 是把工具提前注册给 Agent 的协议。
• Skills 是告诉 Agent 怎么用这些工具的说明书。

它们不是互相替代，而是分工不同。能访问终端的环境里，CLI 很轻量，也很灵活。不能访问终端的环境，比如某些桌面端或编辑器环境，MCP 就更合适。

Skills 则更像“经验包”。没有 Skills，Agent 也可以靠 --help 慢慢摸索；有了 Skills，它一开始就知道哪些命令适合哪些场景，成功率会高很多。

给 Agent 设计 CLI，要多留安全网

面向人的 CLI 和面向 Agent 的 CLI，有一个非常大的区别：Agent 会自己做决策。

所以，一个给 Agent 用的 CLI，最好至少具备三种能力。

第一，帮助信息要足够清楚。--help 不应该只是列几个参数，而要解释参数的用途、默认值、限制和典型用法。

第二，要支持 dry-run。所有写入、删除、发送、审批这类操作，都应该能先预演一遍。Agent 可以先告诉你“我准备删除哪些记录、创建哪些任务、发给哪些人”，你确认后再真正执行。

第三，错误信息要能指导下一步。不要只返回 Permission denied，而应该告诉 Agent 缺什么权限，以及下一步该执行什么命令。

对 Agent 来说，好的错误信息不是报错，而是恢复路径。

我为什么关注这件事

CLI 的回归很有意思。

过去几十年，软件界面一直在从命令行走向图形界面，因为我们在服务人。现在 Agent 也开始成为软件的使用者，文字接口反而重新变得重要。

这并不意味着人要重新回到黑底白字里工作。更准确地说，是我们负责表达意图，Agent 负责在命令行里执行。

比如你可以说：“把这次会议里的待办整理出来，生成文档，给相关同事建任务，并先给我看一遍计划。”Agent 背后可能会连续调用日历、文档、任务和消息 CLI。你看到的是结果，它操作的是命令。

所以飞书做 CLI，不只是多一个开发者工具，而是在为 Agent 时代铺企业协作的基础设施。真正难的地方也会随之出现：权限怎么给、审计怎么做、哪些操作必须人确认、哪些操作可以自动化。

我会把这件事看成一个信号：未来软件如果希望被 Agent 使用，除了给人看的 GUI，也需要给 Agent 用的操作层。而 CLI，很可能是最朴素也最有效的那一层。