过去几十年里，大多数软件都在不断朝着同一个方向演进：图形界面——按钮、菜单和拖拽操作，低代码、零代码工具层出不穷。工具越来越易用，也让更多人能够参与到数字化工作中。
但在 AI Agent 开始参与工作的今天，一个看似“古老”的概念正在重新回到舞台中央——CLI（Command Line Interface，命令行界面）。
2026 年 3 月 28 日，我们正式开源 「飞书 CLI」（@larksuite/cli）。该项目由 Go 语言开发，通过 npm 分发，GitHub 仓库为 larksuite/cli，采用 MIT 许可证，发布首日即获得 1000+ Star。
飞书 CLI 的核心目标很简单：把飞书办公能力以命令行的形式开放出来，让人类和 AI Agent 都可以直接调用。
昨天，我们也举办了一场 「飞书 CLI」专场直播。在直播中，几位嘉宾分享了他们使用 CLI 在飞书中构建自动化工作流、连接 AI Agent 的实践案例。
但与此同时，我们也注意到，直播间的弹幕里反复出现几个问题：
- “CLI 是什么？”
- “CLI 和龙虾（OpenClaw）啥区别啊？”
- “Skill是什么，为什么要发起Skill创作大赛？”
- “龙虾过时了吗？”
这些问题其实非常典型。因为对于很多非程序员的用户来说，命令行的概念虽然存在多年，依旧稍显陌生。
但事实上，在 AI 时代，CLI 反而正在重新变得重要。
如果你最近正在关注 AI Agent、自动化办公、或 OpenClaw生态，试图理解 CLI 的角色，本文将会帮助你更清晰地看懂这波技术变化。
一、先搞清楚名字：CLI、AI Agent分别都是啥？
1. 先说 CLI——它不是飞书特有的东西
CLI 的全称是 Command Line Interface（命令行界面）。这名字听起来很技术，但其实你肯定早见过：
- Windows 的"命令提示符"（cmd）、PowerShell
- Mac 的"终端"（Terminal）
- 甚至你安装 Node.js、Git 时弹出的那个黑屏幕
250px|700px|reset
这些都是 CLI——一种通过文字命令来操作电脑的方式，跟你用鼠标点图标、打开窗口的图形界面（GUI）正好相反。
250px|700px|reset
飞书 CLI 就是飞书专门为 AI Agent 开发的一个命令行工具，装上之后 AI 就能操作飞书了。CLI 本身是个通用概念，飞书 CLI 只是其中一种。
2. AI Agent 又是什么？
AI Agent（AI 智能体）指的是一种可以自主完成任务的 AI 系统。
和传统聊天式 AI 不同，AI Agent 不只是回答问题，而是可以 理解目标 → 制定步骤 → 调用工具 → 执行任务 → 根据结果继续行动。
换句话说，它更像一个会使用工具的数字员工。
250px|700px|reset
最近一年，AI Agent 的爆发主要集中在 开发者工具领域。最常见的几类产品包括：
- Codex：OpenAI 推出的 AI 编程 Agent，可以在云端完成完整的软件工程任务，例如写功能、修复 Bug、分析代码库等。它可以通过 CLI、IDE 或 ChatGPT 直接运行，并逐渐发展为一个面向开发团队的自动化工程平台。
- Claude Code：是 Anthropic 推出的 AI 编程 Agent，特点是 完全基于终端（CLI）工作。
- Antigravity：Google 推出的 Agent-first 开发平台。
二、为什么 Agent 装了 CLI 才能"帮你干活"？
1. 没有 CLI 的 AI：能说，不能做
现在的 AI 模型已经非常聪明了——它能理解你的需求、帮你写方案、分析数据、甚至生成代码。但它有一个根本限制：它只能生成文字，不能直接操作你的工作软件。
你想让 AI 帮你查一下明天的日程？它会告诉你"你可以打开飞书日历查看"——而不是直接帮你查。
你想让 AI 帮你发一条消息？它会给你一段文字让你复制粘贴——而不是直接帮你发出去。
这不是 AI 不够聪明，而是它没有"手"。
Agent 要干活，就得调用外部工具——读文件、查数据库、跑命令。
目前主流有两条路：
- 一条是 Anthropic 在 2024 年底推出的 MCP（Model Context Protocol），它定义了一套标准化的 JSON-RPC 协议，让 Agent 通过统一的接口跟各种工具对话；
- 另一条就是直接用 CLI ——git、docker、curl 这些开发者用了几十年的老工具。
2025 年底到 2026 年初，行业里对 MCP 的态度发生了一次集体转向。
Vercel CEO rauchg 在 X 上直接说："CLIs are the de-facto MCPs for agents"——CLI 就是事实上的 Agent 工具协议。Perplexity CTO、Y Combinator 掌舵人 Garry Tan 也在同一时期公开站了 CLI 这边。中文社区更直接，有人甚至喊出了"MCP 已死"。
为什么会如此？因为 MCP 用起来太贵了。
"好不好用"是主观判断，但"贵不贵"可以算。
先看一组基础数据。一个标准的 GitHub MCP Server 会话，光是加载工具 schema 就要消耗约 55,000 tokens。Claude 的上下文窗口虽然有 200K tokens，但有效利用率远没有那么高。55K 的 schema 直接占掉超过四分之一的上下文——还没开始干活，空间就去掉了一大块。
社区里有人做了一组更严格的基准测试，直接对比同一批任务在 CLI 和 MCP 下的表现：
指标 | CLI | MCP |
单次调用成本 | 基准 | 高 10-32 倍 |
任务完成可靠率 | 100% | 72% |
初始化开销 | 几乎为零 | schema 加载（数万 tokens） |
错误恢复 | 重新执行命令 | 重新建立连接 + 加载 schema |
低 10 到 32 倍——这已经是数量级的差距了。可靠率从 72% 到 100%——用 MCP 跑 10 个任务有 3 个会失败或需要重试，CLI 全部一次通过。
Token 经济学回答的是"贵不贵"，但还有一个更根本的问题：为什么 LLM 用 CLI 就是比用 MCP 顺？
答案藏在训练数据里。
大型语言模型的训练语料包含了互联网上的海量文本——Stack Overflow、GitHub Issues、技术博客、man pages、Shell 脚本、终端交互记录。这里面有数十亿行 CLI 命令和对应的输出。模型在训练过程中"见过"了大量类似的模式：
$ git log --oneline -5
a1b2c3d feat: add user authentication
e4f5g6h fix: resolve memory leak in worker pool
i7j8k9l refactor: extract validation logic
这些模式在训练数据中反复出现，模型对它们的理解已经内化到参数里了。当 Agent 需要执行一个 CLI 命令时，它在做一件训练数据里见过无数次的事——命令格式是熟悉的，输出格式是熟悉的，错误信息的含义也是熟悉的。
MCP 的 JSON-RPC 协议和 tool schema 格式呢？这些是 2024 年才定义的新规范。模型的训练数据里几乎没有。它需要从有限的系统提示和少量示例中"学会"怎么使用 MCP——这个学习深度和从几十亿行真实终端数据中积累的 CLI 能力没法比。
- Skill又是什么：CLI 之上的场景化编排
Skill 是 CLI 之上的一层场景化封装，本质上是一个小型 Agent——它可以编排多个 CLI 调用、做条件判断、处理中间结果。
一个 Skill 由声明文件（描述 Skill 的名称、参数、用途）和执行文档（描述具体的执行步骤）组成。Skill 的执行步骤本质上就是对 CLI 命令的编排：
## Skill: 完整实验分析
### 步骤
1. 调用 mycli api get-experiment --id {id} 获取基础信息
2. 调用 mycli api list-metrics --id {id} 获取指标列表
3. 对每个指标组，调用 mycli api get-metric-data --id {id} --group {gid}
4. 如果发现异常指标，进一步下钻
5. 汇总分析结果，生成报告
为什么 Skill + CLI 比复杂的工具调用更好？
换句话说，这套组合的优势在哪：
- 本地执行，无 context 限制：模型可以先把大量数据写到文件，再选择性读取
- 管道过滤：| jq '.data | length' 在数据到达模型之前就精简了
- 脚本编排：模型可以写一个 bash 脚本，一次性完成多步操作
- 错误恢复：某一步失败了，模型可以看到具体错误并调整
- CLI vs MCP：简要对比
| CLI / Skill | MCP / Tool |
模型适配成本 | 零——模型天生会用 | 需要专门协议适配 |
组合能力 | 管道、重定向、脚本任意编排 | 受限于 server 暴露的工具集 |
调试 | 复制命令直接跑 | 需要连 server、看日志 |
认证 | 复用本机登录态 | 每个 server 单独配置 |
运维 | 无状态，跑完即退 | 需要启动/维护常驻进程 |
上下文效率 | 按需获取（--help），可控 | 工具描述可能吃掉大量 token |
三、OpenClaw 和 这两者是什么关系？龙虾废了吗？
别慌，OpenClaw 只是一种 AI Agent 的实现形态！
简单来说，OpenClaw 是目前全球最热门的开源“自主 AI Agent”项目之一。
如果把 AI Agent比作一种“车型”（比如自动驾驶汽车），那么 OpenClaw 就是其中的一个“明星品牌”或“标杆型号”（比如特斯拉）。
如果你已经在用 OpenClaw 的飞书插件，你其实已经在用 CLI 的能力了。插件会随着飞书 CLI 同步更新，你也不需要单独安装 CLI。
四、飞书 CLI 是什么？
在飞书 CLI 发布之前，AI Agent（如 OpenClaw）接入飞书需要三种方式并存：Plugin + SDK 直调 API（主力，但每个 Agent 平台要重写一套插件）、MCP Server（补充，需维护常驻进程）、直接 HTTP 请求（兜底，自行处理认证）。三套体系各有各的认证管理和调试路径。
飞书开源 Lark CLI 后，所有复杂度收敛为统一的命令行接口：
# 不需要写插件、不需要启 MCP server、不需要拼 HTTP 请求
lark-cli doc get --doc-id xxx
lark-cli im send --chat-id xxx --content "hello"
lark-cli calendar list --start 2026-03-01
通过 Lark CLI，Agent 可以直接在终端中操作飞书的文档、消息、日历等功能，无需任何额外的协议适配。
飞书 CLI 覆盖了飞书最核心的业务域，包括：
- 消息与群组：搜索消息和群聊、发送消息、回复话题
- 云文档：创建文档、读取内容、更新正文、评论协作
- 多维表格：管理数据表、字段、记录、视图、仪表盘
- 日历日程：查询日程、创建会议、查询忙闲、推荐时间
- 邮箱：搜索、读取、起草、发送、回复、归档邮件
- 任务：创建任务、更新状态、管理清单和子任务
- 知识库：查询空间、管理节点和文档层级
- 通讯录：查询用户、搜索同事、查看部门
飞书 CLI 和飞书 MCP 核心差异
目前飞书同时维护两个开源项目：CLI（larksuite/cli）和 MCP Server（larksuite/lark-openapi-mcp）。两者都能让 AI 操作飞书，但设计哲学和能力边界差异显著。
认证方式决定了操作身份。 CLI 支持 OAuth 登录，能以你个人的飞书身份执行操作——读取个人日程、搜索聊天记录、访问有权限的文档。MCP 使用 App_ID + App_Secret，操作身份是飞书应用（bot）。对于个人工作流场景，user 身份几乎是刚需。
文档能力是 CLI 的核心优势。 CLI 支持飞书文档与 Markdown 的双向转换并保留格式。MCP 处理飞书文档时只能获取纯文本，丢失所有格式信息。
五、飞书 CLI 和飞书 OpenClaw 插件有什么区别
1. 一句话说明白
飞书 CLI 和飞书 OpenClaw 插件，底层是同一个东西，只是面向的用户不同。
- 插件：面向 OpenClaw 用户，装完直接说话就能用
- CLI：面向其他 AI 工具用户
2. 飞书 OpenClaw 插件
适合谁用：已经在用 OpenClaw 的人
怎么用：装好插件之后，直接在 OpenClaw 里用自然语言跟它说话，它就能帮你操作飞书。你不需要懂什么是命令行，甚至不需要知道 CLI 是什么。
本质：插件是 OpenClaw 的"飞书能力包"，底层内置了飞书 CLI 的所有功能。
3. 飞书 CLI
适合谁用：不用 OpenClaw，而用 Claude Code、Trae、Codex、Cursor 等其他 AI 工具的人
怎么用：需要在你的 AI 工具里安装和配置 lark-cli，然后通过自然语言让 AI 调用 CLI 命令来操作飞书。
本质：CLI 是飞书开放给所有 AI 工具的通用接口。
4. 到底该用哪个
你在用 | 该用 |
OpenClaw | 装飞书插件，不需要装 CLI |
Claude Code / Trae / Codex / Cursor 等 | 装飞书 CLI |
其他接入了 MCP 的 AI 工具 | 查对应工具的文档 |
简单判断：如果你用的是 OpenClaw，装插件就行；如果你用的是别的 AI 工具，才需要装 CLI。
5. 能力会同步更新
插件和 CLI 底层是相通的，能力会同步更新。也就是说，无论你用插件还是 CLI，飞书的能力都是一样的。
六、外部 AI Agent 连接企业飞书，安全吗？
1. 权限受企业管控，不是随便谁都能访问
这是很多人最关心的问题。
飞书 CLI 创建的每个应用，都 follow 企业统一的权限规则。不是说你装了个 CLI，就能随便读取全公司的飞书数据——应用的权限是由企业管理员在飞书开放平台后台统一管理的。
关键点：CLI 只是帮助快速创建应用的方式，应用的管控完全 follow 企业现有的权限体系。管理员可以随时在后台开通或关闭某个应用的权限。
2. 可以按需授权，不是一开放就全开放
飞书 CLI 支持按业务域单独授权。你可以：
- 不授权：AI 仍能执行发消息、创建文档等公开操作，但无法读取你的个人数据
- 部分授权：只开放日历和文档权限，不开放消息权限
- 完全授权：以你的身份操作飞书的所有功能
按需授权是最小权限原则——只给 AI 它需要的权限，而不是全开放。
3. 管理员可以在后台统一管理
企业管理员可以在飞书开放平台后台：
- 查看企业内所有通过 CLI 创建的应用
- 开通或关闭某个应用的权限
- 设置应用的可用范围（哪些人可以用）
- 查看操作日志
4. 用户也可以随时撤销授权
作为个人用户，你也可以在飞书里查看和撤销已授权的应用。授权不是一锤子买卖，你可以随时收回。
安全建议：
- 优先使用个人账号体验，熟悉后再考虑接入工作环境
- 敏感操作（发消息、删数据等）建议先用"预览确认"模式
- 定期检查已授权的应用列表，不需要的及时撤销
七、命令速查表
按场景分组的常用命令快速参考。
安装与认证
日历
文档
即时通讯
会议与纪要
通讯录
操作 | 命令 |
搜索用户 | lark-cli contact +search-user --query "姓名" |
获取用户详情 | lark-cli contact +get-user --user-id "ou_xxx" |
八、参加我们的Skills活动！
超简单的参赛要求
- ✅ 只要你的作品基于飞书 CLI 开发，即可提交参赛。
- ✅ 双赛道并行：AI 玩家和开发者写代码/skill，普通用户拍视频/写帖子，都能参与。
- ✅ 一个人可以提交多个作品，不设上限，越多好作品获奖几率越大。但stars和内容热度均单独计算，不累加。
- ✅ 作品需为原创，不得搬运、不得抄袭或侵犯他人知识产权。
- ❌ 飞书内部同学禁止投递。
两大投递方式，任你发挥
作品要求细则
🏆 GitHub发布作品—奖项
🌟 社媒平台发布作品—奖项
参考资源
资源 | 链接 |
GitHub 仓库 | https://github.com/larksuite/cli |
npm 包 | https://www.npmjs.com/package/@larksuite/cli |
飞书开放平台文档 | https://open.feishu.cn/document/ |
飞书 MCP Server | https://github.com/larksuite/lark-openapi-mcp |
GitHub Issues（反馈） | https://github.com/larksuite/cli/issues |
飞书OpenClaw插件文档 |
