当你对 Claude Code 说"帮我在飞书里建个文档"——它到底是怎么把请求送到飞书的？用同一个任务跑两遍，把每一步拆给你看。读完你会明白，为什么 2026 年业界集体从 MCP 倒戈 CLI。
点击卡片翻面，看本质 ↔ 类比。三者不在同一个层次上，理解这一点是后面一切的前提。
使用 ← → 方向键也可以推进步骤
绿色高亮 = 该环节的赢家。最后一行注意看：飞书服务器从头到尾根本不知道是 MCP 还是 CLI 在调它——这一切的差异只发生在「Claude 怎么把请求送过去」这一段。
| 环节 | ⌨ CLI 流程 | 📡 MCP 流程 |
|---|---|---|
| 配置成本 | 装好 lark-cli，登录一次 | 装 Server + 改配置 + 由 Claude Code 拉起进程 |
| 启动时 | 啥也不发生 | Server 把全部工具说明书塞进 Claude 脑子（吃 token） |
| Claude 怎么调用 | lark docs +create … |
{tool, args} JSON |
| 谁来执行 | 终端启动 lark-cli，跑一次就结束 | 常驻的 mcp-server 进程接收调用 |
| 结果怎么回来 | 打印到终端，Claude 看屏读到 | 协议响应，Claude 直接拿到结构化数据 |
| 出错时 | 错误直接打印，Claude 像人一样看着改 | 错误包在协议里，Claude 不一定知道怎么调整 |
| 你能不能围观 | 能。每条命令、每段输出都看得到 | 看不到。中间通信全在对讲机里 |
| 飞书服务器视角 | 带 token 的 HTTP 请求 | 带 token 的 HTTP 请求（一模一样） |
2026 年 3 月，ScaleKit 跑了一批相同的 Agent 任务对比两种调用方式。这两张图是为什么业界集体倒戈的原因。
MCP 每次会话都要先加载完整工具 schema，仅 GitHub MCP Server 就吃掉 55,000 tokens——Claude 200K 上下文还没干活已被削掉 1/4。
CLI 出错时报错信息直接打印在终端，Claude 像人一样看着报错调整；MCP 错误被包装在协议里，难自我修复。
CLI 是 Claude Code 用"人类操作电脑的方式"（敲命令、看屏幕）来调飞书。
MCP 是 Claude Code 用"专门给 AI 设计的协议"（对讲机通话）来调飞书。
两者最底层都落到同一个飞书 API 上，但怎么把请求送过去走的是两条完全不同的路。