飞书 lark-cli 开源后，为什么 AI Agent 时代又开始重视 CLI？

2026 年 3 月底，飞书开源了官方命令行工具 lark-cli。它不是单纯给开发者查 API 用的，而是从一开始就把 AI Agent 当成主要使用者之一。

目前 lark-cli 已经覆盖消息、文档、多维表格、电子表格、日历、邮件、任务、会议等多个飞书业务域，提供 200 多个命令和 20 多个 Agent Skills。Agent 获得相应权限后，可以直接通过终端查询日程、创建文档、发送消息、管理任务。

Google Workspace 这边也有类似方向。gws 同样强调面向人和 AI Agent，通过命令行访问 Gmail、Drive、Calendar、Sheets、Docs 等 Workspace API，并提供结构化输出和大量 Agent Skills。不过需要注意，gws 项目虽然位于 googleworkspace GitHub 组织下，但项目本身明确说明它不是 Google 官方支持的产品。

这类项目集中出现，背后其实是同一个问题：

当 AI 不再只是回答问题，而是需要真正操作软件时，应该给它什么样的操作界面？

CLI 又重新成为一个很合适的答案。

CLI 是什么？为什么以前的东西又被 AI 看上了？

CLI 是 Command Line Interface，也就是命令行界面。

对普通用户来说，它就是在终端里输入命令，让程序执行任务。例如查看飞书日程，可以直接运行：

lark-cli calendar +agenda

不需要先打开飞书，再找到日历页面、切换日期、点击按钮，结果直接返回到终端。

CLI 的历史当然比现在的图形界面早得多，但说它后来“没人用了”并不准确。普通消费者确实越来越少直接接触命令行，可在软件开发、服务器运维、云计算、DevOps 等领域，CLI 一直都是核心工具。

AI Agent 的出现，只是让它的价值从程序员圈子进一步扩大了。

原因也很好理解：GUI 主要是给人设计的，而 CLI 天生更接近机器能够理解和执行的形式。

为什么 AI Agent 很喜欢 CLI？

过去我们评价一个软件好不好用，往往看按钮是不是清楚、页面是不是直观、操作步骤是不是够少。

但 Agent 不在乎按钮漂不漂亮。

它更关心的是另外几件事：有哪些能力、参数怎么传、执行后返回什么、失败以后怎么继续。

CLI 在这些地方刚好很合适。

CLI 很容易被 Agent 自己探索

Agent 遇到一个没用过的命令行工具，通常可以先运行：

lark-cli --help

再继续查看某个模块：

lark-cli calendar --help

如果还不知道一个 API 需要哪些参数，lark-cli 又提供了 schema：

lark-cli schema calendar.events.instance_view

它可以继续拿到参数、请求结构、身份类型和权限范围。

所以，与其说“CLI 是自描述的”，更准确的说法是：设计良好的 CLI 很容易让 Agent 逐层发现能力。

API 本身并不是做不到这一点。OpenAPI、Google Discovery Service 等机制同样可以描述 API。区别在于，CLI 往往把认证、参数校验、帮助信息、输出格式和实际执行入口包装到了一起。

Agent 不一定需要先研究一整套 SDK，很多时候看几次 --help 和 schema 就能开始工作。

CLI 的输入输出和大模型天然合拍

Agent 最擅长处理的仍然是文本和结构化数据。

CLI 的输入是命令，输出可以是 JSON、CSV、表格或者普通文本，本身就处在 Agent 熟悉的世界里。

相比之下，让 Agent 操作 GUI 往往更绕。

例如查一个日程，如果只能操作图形界面，Agent 可能需要：

识别当前页面、找到日历入口、判断按钮位置、模拟点击、等待页面加载，再从屏幕内容中读取结果。

而 CLI 可能就是：

lark-cli calendar +agenda

GUI 自动化当然不会消失。有些软件根本没有 API 和 CLI，这时视觉识别加鼠标操作仍然有价值。

但只要软件已经提供可靠的命令接口，就没必要让 Agent 每次都学着“点鼠标”。

CLI 还特别适合组合任务

命令行真正厉害的地方不只是单条命令，而是可以和管道、jq、grep 等工具组合。

例如一个命令负责查数据，另一个程序负责筛选，然后再把结果交给下一步。

这种方式非常适合 Agent，因为很多真实任务本来就不是“一次调用一个接口”这么简单，而是：

查询 → 筛选 → 判断 → 修改 → 验证。

Agent 可以根据当前结果临时决定下一条命令，而不是要求开发者提前把所有流程都封装好。

这也是 CLI 在 Agent 场景里重新变得重要的原因之一：它给 Agent 的不只是功能列表，还给了它拼装工作流的能力。

CLI、MCP 和 Skills 到底是什么关系？

现在让 Agent 操作外部服务，经常会同时看到 CLI、MCP 和 Skills。

三者没必要争谁取代谁，它们解决的问题并不完全相同。

CLI：真正执行操作的入口

CLI 本质上是可执行程序。

Agent 可以调用：

lark-cli im +messages-send

发送消息，也可以：

lark-cli docs +create

创建文档。

前提是 Agent 所在环境允许执行终端命令，并且已经完成认证和权限配置。

对于 Claude Code、Codex、Gemini CLI 这一类本身就在终端或开发环境中工作的 Agent，CLI 尤其自然。

MCP：把外部能力标准化暴露给 Agent

MCP 更像一个统一的工具连接协议。

服务端把工具及其输入结构暴露出来，支持 MCP 的客户端发现这些工具，然后进行调用。

它的好处是不要求 Agent 自己拼 shell 命令，也不要求每个客户端针对每项服务重新写一套专有集成。

至于“MCP 会不会占很多上下文”，不能简单下结论。

如果客户端一次把几百个工具的完整 schema 全部塞给模型，确实可能产生明显的上下文成本。但现在已经可以通过工具筛选、延迟发现、紧凑工具集等方式减少这部分开销。

所以这更多是工具发现和客户端实现方式的问题，而不是 MCP 天生必须浪费大量上下文。

反过来，CLI 也有自己的前提：Agent 必须有 shell 执行权限。如果运行环境根本不允许执行本地命令，MCP 往往会更合适。

Skills：告诉 Agent 怎么把工具用对

Skill 更接近一份面向 Agent 的操作说明和工作流程。

例如它可以告诉 Agent：

哪种需求应该调用什么命令；
哪些参数必须填写；
如何查找缺失的 ID；
什么情况下必须先预览；
哪些操作需要用户确认；
出错以后下一步应该怎么处理。

没有 Skill，Agent 也可以通过 --help 一点点摸索 CLI。

有 Skill 以后，它少走很多弯路。

所以可以把三者简单理解成：

CLI 和 MCP 提供“怎么动手”，Skill 负责告诉 Agent“这件事最好怎么做”。

实际项目完全可以同时使用它们，不需要三选一。

给 AI Agent 设计 CLI，重点已经变了

以前设计 CLI，主要考虑的是程序员用起来舒不舒服。

现在如果 Agent 也是用户，设计重点会发生一些变化。

飞书 lark-cli 里就能看到不少很典型的做法。

`--help` 和 schema 不再只是附属文档

对 Agent 来说，帮助信息本身就是接口的一部分。

只写：

Usage: myctl deploy [flags]

意义不大。

更有用的是告诉它参数类型、默认值、风险等级、认证要求和常见用法。

飞书甚至把 API Schema 查询直接做进 CLI：

lark-cli schema <service.resource.method>

这样 Agent 遇到陌生接口时，不需要立刻跑去网上搜索文档，可以先自己检查调用方式。

面向 Agent 的 CLI，一个很重要的判断标准就是：

Agent 卡住的时候，能不能靠工具自己找到下一步。

`dry-run` 是很重要的安全机制

Agent 可以自己决定怎么执行任务，这也意味着它可能理解错。

比如你让它：

删除多维表格里已经失效的数据。

人脑里想的“失效”，和 Agent 判断出来的“失效”可能不是一回事。

这时候直接执行删除显然风险太高。

lark-cli 提供了 --dry-run，可以先预览请求，而不真正执行：

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

它的价值不是保证 Agent 永远不会犯错，而是把“准备执行什么”和“真正执行”拆成两个阶段。

对于删除、大规模修改、发消息、改权限之类的操作，这一步非常重要。

而且飞书 CLI 现在还进一步区分了普通读取、写入和高风险写入。部分高风险操作除了支持 --dry-run 之外，正式执行还需要显式使用 --yes，Skills 中也要求 Agent 在用户确认后才能继续。

这比单纯提供一个删除命令靠谱得多。

错误信息要告诉 Agent 怎么恢复

传统程序经常只扔一句：

Permission denied

对人来说，大不了去查文档。

Agent 最怕的是这种没有下一步的信息。

更适合 Agent 的错误应该告诉它：

缺什么权限、哪个参数有问题、应该执行什么操作恢复。

例如权限不足时，如果能够返回所需 scope，并提示重新授权，Agent 就有机会自己解决问题，而不是执行到一半直接停在那里。

好的 Agent CLI，错误信息其实也属于控制流程的一部分。

输出最好是结构化的，而且别一次吐太多

终端给人看的时候，表格很舒服：

--format table

但 Agent 往往更喜欢 JSON：

--format json

因为字段明确，不需要再从一段排版后的文字里猜哪个数字是什么意思。

如果还需要继续交给其他命令处理，可以使用 NDJSON、CSV，或者通过 --jq 直接筛出需要的字段。

还有一个很容易忽略的问题：输出不能无限膨胀。

假如 Agent 查一次云盘，命令直接返回几万条完整 JSON，结果还没分析，模型上下文先被塞满了。

所以分页、字段筛选和输出裁剪对 Agent 很重要。

飞书 CLI 提供 --page-limit、--jq 等能力，Google Workspace CLI 的 Agent 使用说明里也专门提醒，要通过字段筛选避免一次把庞大的 Workspace API 响应塞进上下文。

以前我们优化 CLI 输出，是为了人看起来舒服。

现在还多了一层：别浪费 Agent 的上下文。

真正有意思的，是 Agent 开始接管完整工作流

有了这些工具之后，变化最大的并不是“AI 可以替你运行一条命令”。

真正值得关注的是，它可以连续执行很多步。

例如一场会议结束后，你告诉 Agent：

把会议里的待办整理出来，需要建任务的建任务，需要补文档的建文档，最后把结果发到项目群。

Agent 可以先读取会议内容，识别负责人和截止时间，再调用飞书 CLI 创建文档和任务。

例如创建文档可以使用：

lark-cli docs +create

创建任务可以使用：

lark-cli task +create

需要通知团队时，再调用消息相关命令。

如果涉及写入，还可以先把准备执行的请求通过 dry-run 展示出来，确认后再继续。

这时候 CLI 已经不只是“程序员少点几次鼠标”的工具了。

它变成了 Agent 操作企业软件的一层执行接口。

同样的逻辑还可以延伸到很多场景：

你让 Agent 找一个五个人都有空的时间，它查询多个日历后给出候选时间；

你让它整理销售数据，它读取表格、筛选记录、生成汇总，再写回文档；

你让它根据文档评论修改内容，它读取评论、找到对应文档，再执行更新。

以前这些操作通常需要人在几个页面之间来回切。

Agent 接管以后，人负责表达目标、处理重要判断和审批，重复操作交给工具完成。

CLI 回归，但它不会取代 GUI

把这件事理解成“CLI 要取代 GUI”也不太准确。

GUI 仍然是给人最舒服的交互方式之一。

普通用户打开飞书，当然不会因为有了 Agent 就全部跑去敲命令。

真正发生变化的是：同一个软件现在开始面对两类用户。

一类是人。

人需要 GUI，需要清楚的按钮、页面和反馈。

另一类是 Agent。

Agent 更需要稳定的 API、CLI、MCP、结构化 Schema、权限系统和可恢复的错误信息。

过去软件公司主要优化第一套界面。

Agent 普及以后，第二套“机器操作界面”的重要性会越来越高。

从这个角度看，飞书开源 lark-cli 的价值就不只是增加了一个命令行工具。

飞书本身已经有消息、文档、日历、多维表格、邮件、任务和组织协作等能力，现在又把其中大量操作进一步整理成 Agent 更容易发现和执行的命令，再配上 Skills、安全门禁和结构化输出。

这相当于在原有 GUI 之外，又开始建设一套给 Agent 使用的操作层。

Agent 真正进入企业，难点还是权限和责任

工具能调用，并不等于企业敢把所有东西都交给 Agent。

问题最终还是会回到权限。

如果权限太少，Agent 每走一步都被拦住，自动化没有意义。

如果权限太大，又会出现另一个问题：

一句话理解错了，会不会群发消息？

表格筛错了一列，会不会批量改掉客户数据？

判断错了文档，会不会直接删除？

所以 dry-run 只能解决其中一部分问题。

真正进入企业环境以后，还需要更细的权限范围、明确的高风险操作确认、身份隔离、操作日志、审计追踪，以及哪些步骤必须由人确认的规则。

飞书 CLI 已经开始把读取、写入和高风险写入进行区分，并对部分危险操作增加显式确认机制。

这个方向比“让 Agent 拥有所有权限，然后希望它别犯错”现实得多。

AI Agent 真正落地企业，最后拼的未必是谁家的模型会调用更多工具，而是谁能把工具、权限、安全和人机协作边界一起做好。

CLI 只是其中一层，但它正在重新变得重要。

过去 CLI 是人告诉电脑“具体怎么做”。

现在，人越来越多只告诉 Agent“我想要什么”，再由 Agent 去决定应该执行哪些命令。

这可能才是这一轮 CLI 回归最有意思的地方。

参考资料

飞书 lark-cli GitHub 项目：项目说明显示其定位为面向人和 AI Agent 的官方飞书/Lark CLI，覆盖 200 多个命令及 20 多个 Agent Skills。
larksuite/cli GitHub 项目
飞书 lark-cli Changelog：首次开源版本 v1.0.0 发布于 2026 年 3 月 28 日。
lark-cli CHANGELOG
飞书 CLI Agent 安全规则：包含 --dry-run、高风险写入确认、--yes 门禁以及结构化错误处理说明。
lark-cli Agent Skills
Google Workspace CLI gws：项目提供 Gmail、Drive、Calendar、Sheets、Docs 等 Workspace API 的 CLI 访问和 Agent Skills，同时明确标注并非 Google 官方支持产品。
googleworkspace/cli GitHub 项目
Google Workspace CLI Agent 使用规则：包含 --dry-run、结构化输出、分页以及控制上下文输出量等设计。
gws Agent Skills