CLI - AI Agent 的「万能遥控器」，彻底搞懂 CLI、MCP 与 Skill 的关系
飞书 CLI：AI Agent 的「万能遥控器」，彻底搞懂 CLI、MCP 与 Skill 的关系
📌导读：2026年3月28日，飞书正式开源了飞书 CLI（
@larksuite/cli）。一个看似「古老」的命令行工具，为什么能让 AI Agent 真正「帮你干活」？CLI、MCP、Skill 到底是什么关系？这篇文章用通俗易懂的语言，带你彻底搞懂。
一、先搞清楚：CLI 到底是什么？
CLI = Command Line Interface，命令行界面。
这个概念并不新鲜——Windows 的 cmd、Mac 的 Terminal、安装 Git 时弹出的黑屏幕，都是 CLI。
它跟 GUI（图形界面）正好相反：
| 方式 | 举例 | 特点 |
|---|---|---|
| GUI（图形界面） | 打开飞书 → 点「新建消息」→ 输入内容 → 点击发送 | 直观，但慢，只能一步一步点 |
| CLI（命令行界面） | 终端输入一行命令敲回车，程序自动执行 | 快，灵活，可以脚本化、自动化 |
飞书 CLI 又是什么？
2026年3月28日，飞书正式开源了飞书 CLI（@larksuite/cli），用 Go 语言开发，通过 npm 分发。
它的核心目标很简单：把飞书的办公能力以命令行的形式开放出来，让人类和 AI Agent 都可以直接调用。
# 安装 npm install -g @larksuite/cli # 发消息 lark-cli im +messages-send --as bot --chat-id "oc_xxx" --text "会议提醒" # 读取文档 lark-cli docs +fetch --doc "文档链接" # 查看今日日程 lark-cli calendar +agenda # 搜索用户 lark-cli contact +search-user --query "张三"一行命令搞定，不用打开飞书 App，不用点鼠标，不用写代码调 API。
飞书 CLI 覆盖了飞书最核心的业务域：消息与群组、云文档、多维表格、日历日程、邮箱、任务、知识库、通讯录。
二、为什么 AI Agent 装了 CLI 才能「帮你干活」？
现在的 AI 模型已经非常聪明了——它能理解你的需求、帮你写方案、分析数据、甚至生成代码。
但它有一个根本限制：它只能生成文字，不能直接操作你的工作软件。
你想让 AI 帮你查明天的日程？它会告诉你「你可以打开飞书日历查看」——而不是直接帮你查。
你想让 AI 帮你发一条消息？它会给你一段文字让你复制粘贴——而不是直接帮你发出去。
这不是 AI 不够聪明，而是它没有「手」。
CLI 就是 AI 的「手」。装上 CLI 后：
你说：「帮我看看明天有什么会议」 AI → 调用 CLI 命令： lark-cli calendar +agenda --start "2026-04-14T00:00:00+08:00" CLI → 调用飞书 API → 返回结果 AI → 告诉你：「明天有3个会议：10点产品评审、14点技术方案讨论、16点周会」没有 CLI，AI 只能「动嘴皮子」；有了 CLI，AI 才能真正「动手干活」。
三、CLI 的底层原理
输入 → 解析 → 执行 → 输出
用户或AI输入命令 ↓ CLI程序解析命令（理解要做什么） ↓ 调用底层 API 执行（真正操作飞书服务器） ↓ 返回结果（成功/失败）CLI 只是一个「外壳」：把命令翻译成 HTTP 请求，发给飞书服务器。真正干活的还是底层 API。
为什么 LLM 用 CLI 特别顺？
答案藏在训练数据里。
大型语言模型的训练语料包含了海量文本——Stack Overflow、GitHub Issues、技术博客、Shell 脚本、终端交互记录。里面有数十亿行 CLI 命令和对应的输出。
当 AI 执行一个 CLI 命令时，它在做一件训练数据里见过无数次的事——命令格式是熟悉的，输出格式是熟悉的，错误信息的含义也是熟悉的。
CLI 是模型天生就会用的工具。
四、MCP 是什么？为什么行业在倒向 CLI？
MCP = Model Context Protocol
MCP 是 Anthropic 在 2024 年底推出的一套标准化协议，让 AI Agent 通过统一的 JSON-RPC 接口跟各种工具对话。
听起来很美好——一套标准搞定所有工具。但现实很骨感。
MCP 的三重成本
┌─────────────────────────────────────────────────┐ │ 1. 研发成本：必须实现一个 MCP Server │ │ • 熟悉 MCP 协议规范 │ │ • 写连接管理、协议解析、工具注册、认证代码 │ │ • 每个工具都要写清晰的 schema 描述 │ │ • MCP 协议升级，Server 要跟着升级 │ └─────��───────────────────────────────────────────┘ ┌─────────────────────────────────────────────────┐ │ 2. 维护成本 │ │ • 工具变了，schema 要同步更新 │ │ • 工具描述写不好，AI 就会选错工具 │ └─────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────┐ │ 3. 调用成本：比 CLI 贵 10-32 倍 │ │ • 一个 GitHub MCP Server 的 schema = 55,000 tokens │ │ • 直接占掉 Claude 200K 上下文的四分之一 │ │ • 还没开始干活，空间就去掉一大块 │ └─────────────────────────────────────────────────┘行业基准测试数据
社区做了严格的基准测试，对比同一批任务在 CLI 和 MCP 下的表现：
| 指标 | CLI | MCP |
|---|---|---|
| 单次调用成本 | 基准 | 高 10-32 倍 |
| 任务完成可靠率 | 100% | 72% |
| 初始化开销 | 几乎为零 | schema 加载（数万 tokens） |
| 错误恢复 | 重新执行命令 | 重新建连 + 加载 schema |
用 MCP 跑 10 个任务有 3 个会失败或需要重试，CLI 全部一次通过。
行业态度已经转向
2025年底到2026年初，行业对 MCP 的态度发生了集体转向：
- Vercel CEO rauchg：「CLI is the de-facto MCP for agents」——CLI 就是事实上的 Agent 工具协议
- Perplexity CTO、Y Combinator 掌舵人 Garry Tan也公开站了 CLI 这边
- 中文社区甚至有人喊出「MCP 已死」
原因很简单：MCP 的设计思路是对的（统一标准），但成本太高了。而 CLI 是模型天生就会用的东西，零适配成本。
五、Skill 又是什么？
Skill = CLI 之上的场景化编排
Skill 是 CLI 之上的一层场景化封装，本质上是一个小型 Agent——它可以编排多个 CLI 调用、做条件判断、处理中间结果。
一个 Skill 由两部分组成：
-声明文件：描述 Skill 的名称、参数、用途
-执行文档：描述具体的执行步骤（本质上就是对 CLI 命令的编排）
Skill: 完整实验分析 步骤： 1. 调用 lark-cli api get-experiment --id {id} 获取基础信息 2. 调用 lark-cli api list-metrics --id {id} 获取指标列表 3. 对每个指标组，调用 lark-cli api get-metric-data --id {id} --group {gid} 4. 如果发现异常指标，进一步下钻 5. 汇总分析结果，生成报告为什么 Skill + CLI 比纯 MCP 更好？
| 能力 | Skill + CLI | MCP |
|---|---|---|
| 本地执行 | 无 context 限制，数据先写到文件再选择性读取 | 受限于 schema 描述 |
| 管道过滤 | | jq '.data | length'在数据到达模型前就精简了 | 不支持 |
| 脚本编排 | 写一个 bash 脚本一次性完成多步操作 | 受限于 server 暴露的工具集 |
| 错误恢复 | 某步失败，模型看到具体错误并调整 | 需要重建连 + 加载 schema |
| 调试 | 复制命令直接跑 | 需要连 server、看日志 |
| 认证 | 复用本机登录态 | 每个 server 单独配置 |
| 运维 | 无状态，跑完即退 | 需要启动/维护常驻进程 |
六、三种组合方式：怎么选？
组合一：CLI + Skill（首选，最佳实践）
适用：工具固定、流程明确、有标准 SOP。
Skill（场景化编排） │ ├── 定义工作流程（先做A → 再做B → 最后做C） ├── 处理条件判断和错误恢复 └── 内部调用固定 CLI 命令 ├── lark-cli im +messages-send ... ├── lark-cli docs +create ... └── lark-cli calendar +create ... AI 只需说：「帮我安排明天的产品评审会议」 → Skill 自动编排多个 CLI 命令完成优点：成本低、速度快、可靠率 100%、维护简单。
组合二：CLI + MCP（慎用）
适用：工具种类多、变化快、需要 AI 自主决策。
AI 自主决策 │ └── MCP（动态发现工具） ├── MCP Server A → CLI → API A（飞书） ├── MCP Server B → CLI → API B（GitHub） └── MCP Server C → CLI → API C（数据库）缺点：三重成本高，可靠率只有 72%。慎用。
组合三：CLI + Skill + MCP（按需）
适用：既有明确 SOP（Skill），又有需要 AI 自主决策的灵活场景（MCP）。
Skill 处理固定流程（CLI） + MCP 处理灵活查询（动态发现）三种组合对比
| CLI + Skill ⭐ | CLI + MCP | CLI + Skill + MCP | |
|---|---|---|---|
| 成本 | 低 | 高 | 中高 |
| 速度 | 快 | 慢 | 中 |
| 可靠率 | 100% | 72% | 混合 |
| 灵活性 | 流程固定 | 高 | 高 |
| 研发成本 | 低 | 高 | 中 |
| 推荐程度 | 首选 | 慎用 | 按需 |
七、飞书 CLI 和飞书 MCP 的核心差异
飞书同时维护两个开源项目：CLI（larksuite/cli）和 MCP Server（larksuite/lark-openapi-mcp）。
| 维度 | 飞书 CLI | 飞书 MCP |
|---|---|---|
| 覆盖范围 | 200+ 精选命令 + 2500+ Raw API | 飞书 OpenAPI 全量映射 |
| 认证方式 | OAuth 交互式登录，支持 user/bot 双身份 | App_ID + App_Secret |
| 文档能力 | Markdown 双向转换，格式保留 ✅ | 仅纯文本 ❌ |
| 输出格式 | JSON / table / CSV / ndjson / pretty | JSON |
| 部署方式 | npm 全局安装 + Skills 注入 | MCP Server 配置到 settings.json |
认证方式决定了操作身份：CLI 支持 OAuth 登录，能以你个人的飞书身份执行操作——读取个人日程、搜索聊天记录。MCP 使用 App_ID + App_Secret，操作身份是飞书应用（bot）。对于个人工作流场景，user 身份几乎是刚需。
文档能力是 CLI 的核心优势：CLI 支持飞书文档与 Markdown 的双向转换并保留格式。MCP 只能获取纯文本，丢失所有格式信息。
八、常见问题
Q1：MCP 已死了吗？
A：没有。MCP 在「工具多、变化快、AI 需要自主决策」的场景下仍有价值。但对于大多数固定流程的场景，CLI + Skill 是更好的选择。两者是互补关系，不是替代关系。
Q2：飞书 CLI 和飞书 OpenClaw 插件有什么区别？
A：底层是同一个东西，面向用户不同。OpenClaw 插件面向 OpenClaw 用户，装完直接说话就能用。CLI 面向其他 AI 工具用户（Claude Code、Cursor 等）。能力会同步更新。
Q3：我不是程序员，能用 CLI 吗？
A：如果你用 OpenClaw，装飞书插件就行，不需要碰命令行。CLI 是给程序员和 AI Agent 用的。
Q4：安全吗？外部 AI 能访问企业飞书数据？
A：权限受企业管控，支持按业务域单独授权。管理员可以在后台统一管理，用户也可以随时撤销授权。
总结
| 概念 | 一句话理解 | 成本 |
|---|---|---|
| CLI | 命令行工具，AI 的「手」，模型天生就会用 | 低 |
| MCP | AI 与工具的「通用插头标准」 | 高（三重成本，贵 10-32 倍） |
| Skill | CLI 之上的场景化编排，小型 Agent | 低 |
行业趋势：CLI 正在成为 AI Agent 工具生态的主流。飞书 CLI 的开源，让所有 AI 工具都能通过命令行操作飞书——不需要写 MCP Server，不需要维护常驻进程，一条命令搞定。
最佳实践：CLI + Skill，成本最低、速度最快、可靠率最高。
💡下一步：想体验飞书 CLI？一行命令安装：
npm install -g @larksuite/cli
如果你觉得有帮助，欢迎点赞收藏！有问题欢迎评论区交流~