真正让人困惑的，往往不是工具太多，而是不同层级的东西被放进了同一个问题里比较。
大家好，我是十三！欢迎来到十三Tech。
最近看飞书 Agent 相关能力时，我发现一个非常典型的现象：很多人在问 飞书 CLI、MCP 和 OpenClaw 时，表面上是在比较三个名词，实际上是在把三类完全不同的东西放在同一个维度里讨论。
于是问题很快就会变形：
- 飞书 CLI 和 MCP 到底谁更强？
- 有了 OpenClaw，是不是就不需要 CLI 了？
- 我到底该装哪个，才能让 AI 用上飞书？
这些问题之所以难答，不是因为资料不够，而是因为提问的起点就混淆了层级。
我的判断很明确：
飞书 CLI 是工具，MCP 是协议，OpenClaw 是 Agent 运行时。
这三者不是简单的替代关系，更不是同类产品的横向竞争。只有先把这个前提立住，后面的接入方式、适用场景和选型建议才有讨论价值。
今天这篇文章，我就从工程视角把这个问题拆开讲清楚。
Part 1：为什么这个问题总会被问乱？
因为这三者都在回答同一个目标：如何让 AI 真正调用飞书能力去完成任务。
比如你希望 Agent 去发消息、读取文档、写入多维表格、创建任务，或者把飞书能力接进你的开发工作流，那么你在资料里大概率会同时看到三类表述：
- 有一个命令行工具，可以直接在终端中调用飞书能力
- 有一种标准协议，可以把飞书能力暴露给 AI 客户端
- 有一个 Agent 框架，可以让智能体持续运行并组织任务
这三种说法都在回答“怎么让 AI 用上飞书”，但它们回答的并不是同一个层面的问题。
更准确地说，它们分别对应三个工程问题：
- 怎么执行一次能力调用 —— 这是工具问题
- 怎么把能力标准化地接入 AI 系统 —— 这是协议问题
- 怎么让 Agent 长期运行并编排任务 —— 这是运行时问题
很多技术讨论一开始就乱，不是因为结论难，而是因为没有先把问题切对。
所以，理解飞书 CLI、MCP 和 OpenClaw 的第一步，不是去背定义，而是先识别它们各自落在哪一层。
Part 2：飞书 CLI 是什么？—— 它首先是一把可直接使用的工具
根据飞书官方资料，飞书 CLI 是飞书官方开源的命令行工具，包名为 @larksuite/cli。它面向的核心场景，是让开发者或 AI Agent 在终端环境中直接调用飞书能力。
如果把话说得再直接一点，飞书 CLI 解决的是这样一个问题：
我现在就在 Claude Code、Cursor 或本地终端里，能不能立刻对飞书发起操作？
如果你的问题是这个，那么 CLI 就是最短路径。
2.1 CLI 的本质，是“可执行能力”的封装
CLI 的核心形态不是接口契约，而是命令本身。
你发出一条命令，工具执行一次动作，结果返回，然后这次调用结束。它不是常驻服务，也不是跨平台的协议规范，而是一种面向执行的工具形态。
这意味着它最突出的价值不是“定义连接方式”，而是“把能力做成可直接调用的动作单元”。
从工程上看，这种形态有两个直接好处：
- 门槛低：不需要先理解完整协议体系，就能开始使用
- 反馈快：适合本地协作和即时操作，路径短，调试成本低
所以 CLI 更像一把已经做好的扳手，而不是一套工业标准。
2.2 CLI 更适合即时执行型工作流
飞书 CLI 的强项，在于它把飞书开放能力包装成更适合终端、脚本和 AI 工具调用的形式。
这决定了它特别适合以下场景：
- 在 Claude Code 中直接读取或操作飞书内容
- 在本地脚本中串联飞书动作
- 让 AI 按需完成一次性任务，例如读文档、发消息、写表格
- 以个人工作流为中心，快速完成单次协作动作
这类场景的共同特点是：你更在意能不能现在就做，而不是先搭一套长期运行的平台。
因此，CLI 更像一个即时可用的执行器。
2.3 CLI 的价值，不在于绕过系统，而在于贴近 AI 使用方式
飞书官方对 CLI 的定位有一个很重要的点：它不是浏览器自动化，也不是绕过权限体系的脚本集合，而是对飞书 OpenAPI 的一层 AI 友好封装。
这句话很关键，因为它划清了两个边界：
- 它依然运行在飞书开放平台的授权边界内
- 它的核心价值不是“偷偷替你做”，而是“让 AI 更自然地调用正式能力”
这也是为什么我更愿意把飞书 CLI 看成一种 面向 AI 工作流重构过的人机接口。它不是改变能力边界，而是改变能力的使用方式。
如果你的主要场景是在本地 AI 工具里直接使用飞书，那么 CLI 往往是最合适的起点。
Part 3：MCP 是什么？—— 它不是某个工具，而是一种统一接入协议
很多人第一次接触 MCP 时，会下意识把它理解成一个具体产品。但这个理解很容易带偏后面的判断。
MCP 不是某个工具本身，而是一套让 AI 客户端连接外部能力的标准协议。
MCP，全称 Model Context Protocol。它试图解决的问题是：
不同 AI 客户端、不同工具提供方，能不能通过统一方式暴露和调用 tools、resources、prompts 这些能力？
所以 MCP 的本质，不是提供某项具体能力，而是定义能力如何被看见、被描述、被调用。
3.1 协议层的价值，在于标准化和可组合
如果没有统一协议，不同 AI 客户端和不同工具方之间就需要各自做定制对接。短期看似能跑，长期一定会碎片化。
而 MCP 的意义就在于，它把这种连接关系标准化了：
- 客户端只要支持 MCP
- 工具方只要提供 MCP Server
- 双方就能按统一规则建立连接
这件事的真正价值，不在于“第一次接通”，而在于“以后每次接入都不再重新发明轮子”。
从这个角度看，MCP 更像 AI 工具生态里的公共接口层。
3.2 飞书 MCP 解决的是“如何把飞书能力标准化暴露出来”
当飞书以 MCP Server 的形态提供能力时，它回答的其实不是“如何执行一条命令”，而是：
如何让支持 MCP 的 AI 客户端，以统一方式接入飞书能力？
因此，飞书 MCP 更适合这样一些场景：
- 你有多个 AI 客户端，希望接入方式一致
- 你已经围绕 MCP 构建工具体系
- 你除了飞书，还要同时接入 GitHub、Figma、数据库、监控平台等外部系统
- 你关注的是长期扩展性，而不只是某一次调用是否方便
换句话说，MCP 的价值主要不在单点效率，而在系统性接入成本的下降。
3.3 协议只解决“怎么接”，不解决“怎么长期跑”
这里有一个很容易被忽略的判断：
MCP 解决的是连接规范，不直接解决 Agent 的运行时问题。
也就是说，它负责让能力进入 AI 系统，但它不天然负责：
- 会话如何持续
- 状态如何保存
- 多步任务如何编排
- Agent 如何长期在线工作
所以，“用了 MCP”并不等于“已经拥有完整的 Agent 系统”。
这是很多人理解 AI 工程化时最容易跳过的一层。
Part 4：OpenClaw 是什么？—— 它解决的是 Agent 如何持续工作
如果说 CLI 更接近工具，MCP 更接近协议，那么 OpenClaw 更接近一个 Agent 运行时与框架体系。
它关注的问题，不再是某次调用如何发起，而是更高一层的系统问题：
- Agent 如何常驻运行
- Agent 如何接入插件或外部能力
- Agent 如何组织上下文和任务流程
- Agent 如何在持续交互中完成一系列动作
这本质上是一个运行时问题，而不是一个单点工具问题。
4.1 OpenClaw 关心的是持续性与组织能力
CLI 的典型模式是“调用一次，完成一次”。
OpenClaw 这类 Agent 框架关心的则是：
- 一个智能体如何长期在线
- 它如何持续承接用户输入
- 它如何把多个能力串成稳定工作流
- 它如何在系统中承担一个可复用的角色
所以，OpenClaw 的重点从来不在“命令长什么样”，而在“Agent 系统如何运转”。
4.2 在 OpenClaw 体系里，飞书能力通常以插件方式挂载
飞书官方也提供了面向 OpenClaw 的官方插件。这个事实非常重要，因为它直接说明了一点：
在 OpenClaw 场景里，飞书能力往往不是以独立工具的形式裸露给你，而是被纳入更高层的插件化集成链路。
这也是为什么飞书官方会明确说明：如果你已经在 OpenClaw 体系中使用飞书官方插件，通常不需要单独再安装飞书 CLI。
这并不意味着 CLI 失去价值，而是因为在这个场景里，CLI 所承载的能力很可能已经被上层运行时整合掉了。
4.3 OpenClaw 更适合持续自动化，而不是本地即时协作
因此，OpenClaw 更适合解决的是这类问题：
- 我要一个常驻运行的 Agent
- 我要在群、机器人或自动化系统里持续使用飞书能力
- 我要组织多步任务编排，而不是执行单次操作
- 我要把外部能力统一纳入一个长期运行的 Agent 平台
一句话概括，OpenClaw 更像 Agent 的作战系统，而不是一把临时上手的工具。
Part 5：三者到底是什么关系？—— 先看层级，再看形态
如果用工程化的方式把三者放回各自的位置，我认为可以这样理解：
你在使用的 AI 客户端 / Agent
(Claude Code / Cursor / 自建系统 / OpenClaw)
│
┌───────────────┴───────────────┐
│ │
直接在终端调用飞书能力 通过标准协议接入飞书能力
│ │
▼ ▼
┌────────────────┐ ┌──────────────────┐
│ 飞书 CLI │ │ 飞书 MCP │
│ 具体命令行工具 │ │ 协议接口 / Server │
└────────────────┘ └──────────────────┘
或者
┌──────────────────┐
│ OpenClaw │
│ Agent 运行时/框架 │
└────────┬─────────┘
│
▼
┌────────────────────────┐
│ OpenClaw 飞书官方插件 │
│ 承接飞书能力的插件接入 │
└────────────────────────┘
这张图里最核心的不是箭头，而是判断顺序：
- 飞书 CLI 对应的是工具层
- 飞书 MCP 对应的是协议层
- OpenClaw 对应的是运行时层
只要层级分清，很多表面上的冲突其实根本不存在。
所以这三者不是谁替代谁，而是分别回答三类不同问题：
- CLI 回答“怎么直接调用”
- MCP 回答“怎么标准接入”
- OpenClaw 回答“怎么持续运行与编排”
这是理解三者关系时最重要的主线。
Part 6：真正有价值的，不是问谁更强，而是问你现在处在哪个场景
技术选型最怕的，不是工具太多，而是问题太含糊。
“CLI、MCP、OpenClaw 谁更强”不是一个有效问题。更有效的问题应该是：
我现在到底是在解决即时调用、标准化接入，还是 Agent 运行时编排？
一旦问题被问对，选型往往并不复杂。
场景一：你主要在 Claude Code、Cursor 这类本地 AI 工具里工作
这种情况下，我的建议通常是：优先考虑飞书 CLI。
原因很简单：
- 你要的是本地即时协作
- 你要的是尽快让 AI 具备飞书操作能力
- 你要的是更短的接入路径和更快的反馈闭环
- 你未必需要一个完整的常驻 Agent 平台
此时从 CLI 入手，最符合成本收益比。
场景二：你在建设统一的 AI 工具接入层
如果你的目标已经不是单点提效，而是围绕多种外部能力建设一套标准化工具体系，那么飞书 MCP 会更符合你的长期需要。
因为这时你真正关心的是：
- 工具接入是否统一
- 能力描述是否标准化
- 新工具接入成本是否持续下降
- 整体体系是否具备扩展性
在这种语境下，MCP 的价值通常高于一次性命令调用的便利。
场景三：你正在建设常驻 Agent 平台或持续自动化体系
如果你的问题已经上升到“我要一个长期在线、可编排、可扩展的 Agent 系统”，那就应该优先从 OpenClaw 这类运行时视角思考。
因为这时最重要的已经不再是某个能力能否调通，而是：
- Agent 如何持续在线
- 插件如何组织
- 多步任务如何编排
- 长期交互中的上下文如何承接
这时，飞书能力只是系统中的一块拼图，而不再是全部。
Part 7：这件事真正值得工程师学会的，是什么？
在我看来，飞书 CLI、MCP 和 OpenClaw 的区别，真正重要的地方不只是帮助你完成一次选型，而是它提供了一种更稳定的判断框架。
这个框架就是：
面对任何 AI 基础设施，先问它属于工具层、协议层，还是运行时层。
这是一个非常朴素，但极少有人真正坚持使用的方法。
因为一旦层级判断错误，后面所有比较都会失真：
- 你会拿工具去和协议比“功能多不多”
- 你会拿运行时去和命令行比“上手快不快”
- 你会把本该协同存在的东西，误判为彼此替代
从工程角度讲，很多“看起来复杂”的新概念，其实并不复杂。复杂的往往不是概念本身，而是没有把它放回正确的抽象层。
这也是我认为 AI 工程化最核心的一项能力：
不是追着新名词跑，而是快速判断一个新名词在系统里究竟承担什么职责。
这比记住十个产品名称都更重要。
总结：一句话分清三者
最后，把结论压缩成最容易记住的三句话：
- 飞书 CLI：适合“我现在就要让 AI 操作飞书”
- 飞书 MCP：适合“我要按标准协议把飞书接入 AI 工具体系”
- OpenClaw：适合“我要一个可持续运行的 Agent 框架”
所以，三者真正的关系不是替代，而是分层：
CLI 是工具，MCP 是协议，OpenClaw 是运行时。
如果你把这个判断框架记住，以后再看类似的 AI 产品和基础设施，大多数概念混乱都会迎刃而解。
参考资料
- 飞书官方对比文章：https://www.feishu.cn/content/article/7624059344114699194
- 飞书 CLI 官方介绍：https://www.feishu.cn/content/article/7623291503305083853
- 飞书 CLI 安全说明：https://www.feishu.cn/content/article/7641519075810069471
- 飞书 CLI 官方仓库：https://github.com/larksuite/cli
- 飞书 MCP 官方仓库：https://github.com/larksuite/lark-openapi-mcp
- OpenClaw 飞书插件官方仓库：https://github.com/larksuite/openclaw-lark
- MCP 官方架构文档：https://modelcontextprotocol.io/docs/learn/architecture
写在最后
如果你最近也在搭 AI 工作流，我建议把“工具、协议、运行时”这三个层级当成一个通用分析框架。它不只适用于飞书，也适用于你接下来会遇到的大多数 Agent 基础设施问题。
看清层级，往往比记住答案更重要。