飞书为什么开始弃用 MCP、转向 CLI？
分类：AI 领域 · 难度：入门 · 预计 8 分钟 · 把前沿取舍讲成人话
一句话：飞书发现，把 AI 接进飞书，用"命令行工具（CLI）"比用"MCP 连接器"更全、更省、更安全。本文讲清两者区别、看懂飞书的取舍，再回头看我们的 Linger 平台能借鉴什么。
这篇要回答什么
- MCP 和 CLI 到底是什么，各自怎么干活
- 两者在"授权登录"上的关键差别（很多人忽略的一段）
- 飞书为什么开始弃 MCP、主推 CLI
- Linger 平台能从中借鉴什么
先认识几个词
术语 · MCP（Model Context Protocol，模型上下文协议）
打个比方：MCP 像给 AI 装的一排"万能插座"——把飞书、Notion 这些服务做成标准插头，AI 插上就能用它们的功能。
正式说：MCP 是一套标准协议，让 AI 客户端（如 Claude、Cursor）通过统一接口调用外部服务暴露出来的"工具"。飞书的 MCP server 就是官方做的"AI 连接器"，让 AI 客户端"直接变身飞书助理"。
术语 · CLI（Command-Line Interface，命令行工具）
打个比方：CLI 像一个"遥控器"，每个按钮是一条文字命令（auth login、docs create）；AI 在自己的终端里"按按钮"就能办事。
正式说：CLI 是通过文字命令操作的程序。飞书的 lark-cli 把"发消息、建文档、查日历"等能力做成一条条命令，AI（或人）在终端里敲命令来调用。
术语 · OAuth / token / 模型上下文
- OAuth（授权协议）：一种"授权"方式——你在官方页面点一下"同意"，第三方就拿到一张限定权限的"通行证"，全程不用把账号密码交出去。
- token（令牌）：那张通行证本身，一串代表"我已被授权"的字符；有有效期、可吊销。
- 模型上下文：AI 每次思考能"看到"的信息总量（有上限）。塞进去的工具说明越多，留给真正干活的空间就越少。
对你来说意味着：MCP 和 CLI 都是"让 AI 用上飞书"的桥，只是搭桥方式不同——一个走标准插座，一个走命令遥控器。差别就藏在后面。
它俩各自怎么干活
MCP 的路子：你先在飞书配置平台开一个 MCP 服务、挑好要开放的功能、点授权，拿到一个"服务器网址"，把它填进 AI 客户端。之后 AI 就能通过这个网址调用飞书。
CLI 的路子：让 AI（或你）用一条命令把 lark-cli 装上，再跑一条 auth login 登录，浏览器点个确认，凭证就存在本地，之后 AI 直接敲命令干活。
对你来说意味着：MCP 把"身份"塞进一个网址、交给客户端保管；CLI 把"身份"用标准登录换成本地令牌、自己保管。这就引出了授权上的关键差别。
授权逻辑：两者最大的不同
这是最值得细看的一段，也最能解释飞书为什么换路。
| 维度 | MCP 方案 | CLI 方案 |
|---|---|---|
| 怎么授权 | 在配置平台登录、点授权 | 一条 auth login，浏览器确认（OAuth） |
| 凭证形态 | 一个"服务器网址"，飞书明说"相当于个人密钥"，泄露 = 身份泄露 | 本地 token，可 logout 撤销、可查权限范围 |
| 有效期 | 2026-02 起新服务仅 7 天，过期要重新授权 | 本地令牌长期可用，到期可静默刷新 |
| 对 AI 友好度 | 网址要人手动贴进客户端配置 | auth login --no-wait 直接吐出授权链接、让 AI 转给你点，点完命令自动退出 |
一个细节，但很关键
飞书 CLI 的 auth login --no-wait 会"把验证链接抽出来发给用户，完成后命令自动退出"。这恰好解决了"AI 在后台跑、没法自己开浏览器"的尴尬——AI 拿到链接转给你，你点一下就行。
对你来说意味着：MCP 那张"网址即密钥 + 7 天到期"既不好保管又要反复重授；CLI 用标准 OAuth 换本地令牌，更安全也更省心。
飞书为什么开始弃 MCP、主推 CLI
把飞书官方文档里的原话和现象拼起来，三个原因：
- 功能覆盖：飞书 MCP "当前支持'云文档'场景"——功能有限；而 lark-cli 覆盖消息、日历、文档、表格、多维表格、任务，还能直接打原始 API。
- 凭证与安全：MCP 的"网址即密钥 + 7 天过期"，飞书已宣布"MCP Token 方案后续将逐步下线"，并直说 CLI"功能更全面、鉴权方式更安全可控"。
- 省模型上下文：MCP 会把工具清单常驻塞进 AI 的"思考空间"；CLI 的命令是用到时才查
--help，几乎不占上下文（能力弱一点的模型尤其受益）。
顺带：lark-cli 的技术底细（想深究再看）
- 主体用 Go 写（仓库里 Go 占 97.6%），用 npm 包装分发，
npx @larksuite/cli@latest install一行装上。 - 采"三层架构"：Shortcuts（人和 AI 都好用的快捷动作）→ API 命令 → 原始 API，开箱自带 24 个面向 Agent 的结构化技能。
- 开源、MIT 协议。
上手长这样（具体例子）
CLI 侧——一条条命令，AI 在终端里就能跑：
bash
# 1. 安装（推荐 npx，免预装）
npx @larksuite/cli@latest install
# 2. 登录授权：吐出链接、不阻塞，AI 把链接转给你点
lark-cli auth login --no-wait
# 3. 干活示例：发消息 / 建文档 …
lark-cli im messages-send ...
lark-cli docs create ...MCP 侧——在配置平台点几下，拿到网址 + JSON 配置：
创建 MCP 服务 → 勾选"云文档"工具集 → 点授权 → 复制"服务器网址 + JSON 配置"贴进 Cursor / Claude Code。
对你来说意味着：CLI 这套"发一条命令让 AI 自己装、自己登录"的体验，正是"把配置丢给 AI 就能搞定"的关键——对不懂技术的用户，越省事越好。
回到我们：Linger 平台能借鉴什么
Linger 平台现在的接入方式，恰好和飞书"换路前"几乎一样：一批 MCP 工具 + OAuth 登录。我们也撞上了同样三个坑：
| 飞书踩过的坑 | Linger 的对应现状 | 可借鉴的解法 |
|---|---|---|
| 凭证不好管、易过期 | OAuth 回调在客户端本地容易碎（"127.0.0.1 拒绝连接"反复返工） | 转 CLI：auth login 进程常驻等回调，--no-wait 吐链接 |
| 工具清单占模型上下文 | 一批工具常驻，弱模型吃不消 | CLI 命令懒加载，几乎不占上下文 |
| MCP 功能受限、要下线 token | 纯 MCP 仅在"无终端"场景才有优势 | 主推 CLI、MCP 留作兜底 |
应用到自己（这正是 Linger 已经定下的方向）
Linger 已决定"接入一步到位转 CLI 全切"，可直接照搬飞书的成熟做法：npx 零预装分发 + auth login --no-wait 吐链接 + 三层架构（快捷动作 → API → 原始 API） + 本地 token 管理。
一句话小结
MCP 是"标准插座"，胜在通用、即插即用；CLI 是"命令遥控器"，胜在功能全、省上下文、授权更稳。当 AI 已经能熟练敲命令时，CLI 往往是更顺的那条路——飞书用脚投了票，Linger 也正走上同一条路。
参考资料