MCP、Skill、连接器、CLI、Tool Call 这五个词天天一起出现，但它们根本不在同一个层级上。混淆的根源很简单：有人在说协议，有人在说动作，有人在说剧本，还有人在说执行手段。
把它们按层级摆好，绝大多数争论会自动消失——包括「Skill 必须走 MCP 吗」「CLI 和连接器依赖 MCP 吗」「什么时候该给 CLI 包一层 MCP」这几个高频问题。本文按「先分层、再串联、最后看趋势」的顺序拆开，最后附上 2026 年 7 月 MCP 无状态化改版对这套分层的影响。
先给结论：五个概念的定位
| 概念 | 它到底是什么 | 一句话类比 | 所处层级 |
|---|---|---|---|
| Tool Call | 模型「调用外部能力」这个动作本身 | 你伸手按开关 | 模型接口层 |
| MCP | 一套开放协议，规定模型怎样发现和调用外部工具 | 开关的接口标准（86 型面板） | 协议层 |
| Skill | 预写好的指令包 + 脚本，封装一整套任务流程 | 一份操作手册 | 编排层 |
| Connector | 把外部服务（SaaS / 数据库 / API）接进来的适配器 | 转接头、插座适配器 | 集成层 |
| CLI | 终端里通过命令行操作程序的方式 | 直接在控制台敲命令 | 执行层 |
记住这句话就够了：
Tool Call 是动作，MCP 是协议，Skill 是剧本，Connector 是桥梁，CLI 是执行手段。
五者分处不同层级，日常是组合使用的关系，很少需要在它们之间做单选。
Tool Call：万物的统一出口
这是最底层、也最不可绕过的抽象。模型和外部世界打交道，只有这一个出口。
模型 → 发起 Tool Call（工具名 + 参数） → 系统执行 → 返回 result → 模型读取结果，继续推理或回复关键点在于：模型并不知道 result 是怎么来的。
- MCP Server 返回的 JSON —— 是 Tool Call 的 result
- Bash 脚本打印的 stdout —— 是 Tool Call 的 result
- 读文件工具返回的文本 —— 还是 Tool Call 的 result
对模型来说完全没有区别。这一点很重要：后面所有「要不要走 MCP」的讨论，都不影响这一层。
所以真实的工具版图长这样：
Tool Call ← 统一的「调用—返回」机制（最底层抽象） ├─ 内置工具（Bash / Read / Edit / Write） ← 直接执行，直接返回 ├─ MCP 工具（mcp__xxx__yyy） ← 走 MCP 协议，返回结构化结果 └─ Skill ← 一层封装，内部可以： ├─ 调 Bash 跑脚本 ├─ 调 MCP 工具 └─ 什么都不调，纯 prompt 指导模型自己推理MCP：让工具「可被发现」的协议
MCP（Model Context Protocol）由 Anthropic 在 2024 年 11 月推出，解决的是一个 N×M 问题：
过去：M 个模型 × N 个工具 = M×N 套对接代码 现在：M 个模型 + N 个工具 = M+N 套实现
它常被叫做「AI 时代的 USB-C」。让模型调用工具这件事，Function Calling 早就能做到了；MCP 真正带来的是标准化的发现机制：
- 工具列表（
tools/list）——我这有哪些能力 - 资源（resources）——我这有哪些数据可读
- 提示词（prompts）——我这有哪些预设模板
一次编写，处处可调。换模型不用重写工具定义，这才是 MCP 的核心价值。
MCP 只是通路之一
这是最容易误解的地方。MCP 只是把外部能力接入 AI 对话的一种标准化方式，此外还有别的路。后面三节会反复证明这一点。
Skill：剧本，不是引擎
Skill 本质上是**「一段指令（prompt）+ 可选的脚本 / 资源文件」**的打包。它回答的是：这个任务第一步干什么、第二步干什么、有哪些坑要避开。
Skill 一定要走 MCP 吗
不一定。Skill 有两种执行路径：
方式 A（经 MCP 加载）： Tool Call → mcp__skill-handler__Skill → 把 Skill 指令载入上下文 → 模型按指令行动方式 B（纯文件加载 / 直接执行脚本）： Skill 指令里写着「用 Bash 执行 xxx.sh」 → 模型直接调 Bash 工具运行脚本 → 全程不经过任何 MCP Server拿一个飞书操作 Skill 举例，它的实际执行是混合的：
- 第一步走 MCP —— 通过 skill-handler 这个 MCP Server 把 Skill 指令加载进来
- 第二步不走 MCP —— 指令说「用
lark-cli命令去操作」，模型直接用 Bash 跑 CLI
结论：MCP 只是 Skill 的加载 / 触发方式之一，可以完全绕开。 Skill 完全可以纯粹是一组 markdown 指令，让模型直接调内置的 Bash / Read / Write 完成任务。而脚本跑完的 stdout，同样以 Tool Call result 的形式回到模型手里——和 MCP 返回的 JSON 在模型眼里是同一种东西。
Skill 和 MCP 的真正分工
| MCP | Skill | |
|---|---|---|
| 解决什么 | 能不能调（连通性） | 该怎么调（方法论） |
| 内容形态 | 协议 + Server 实现 | 指令文本 + 脚本 |
| 谁在消费 | 客户端程序 | 模型本身 |
| 更新成本 | 要改代码、重启服务 | 改一个 markdown 文件即可 |
一个常见且高效的组合是：MCP 提供原子能力，Skill 提供组合方法。
CLI：最古老、也最不依赖 MCP 的一层
CLI 比 MCP 早了几十年。git、curl、aws、gh、psql——这些工具在 AI 出现之前就存在，之后也不会因为 MCP 而消失。
CLI 依赖 MCP 吗
完全不依赖。模型调用 CLI 有两条路：
路径 1（直接执行，最常见）： Tool Call: Bash("gh pr list --state open") → 系统跑命令 → stdout 作为 result 回到模型 → 全程零 MCP路径 2（包一层 MCP）： Tool Call: mcp__github__list_pull_requests({state: "open"}) → MCP Server 内部可能还是在调 gh 或 REST API → 返回结构化 JSON那为什么还有人给 CLI 包一层 MCP
包这一层不会改变「能不能调」，它买的是另外四件事：
| 好处 | 说明 |
|---|---|
| 结构化输出 | CLI 吐的是给人看的文本，MCP 返回的是模型好解析的 JSON |
| 权限收窄 | Bash 是万能的（也意味着危险），MCP 工具只暴露你允许的那几个操作 |
| 自描述 | MCP 工具自带参数 schema，模型不用猜 flag 怎么写 |
| 跨环境 | Bash 需要本地装好 CLI；MCP Server 可以跑在远端 |
代价也很明确：多一层维护、多一层延迟、灵活性下降（CLI 的组合能力 |、&&、xargs 在 MCP 里没有对应物）。
经验法则：一次性的、探索性的操作直接用 CLI；高频的、需要权限管控的、要给别人复用的，包成 MCP。
Connector：MCP 出现之前就有，之后也不会消失
Connector（连接器）是个更老的概念，泛指任何把外部服务接进来的适配层。iPaaS 时代（Zapier、MuleSoft、Airbyte）就是干这个的。
Connector 依赖 MCP 吗
不依赖。真实关系反过来看更准确：
外部服务（飞书 / Slack / Postgres / Stripe） ↑ Connector（认证、限流、重试、分页、数据格式转换） ↑ ┌────┴────┬──────────┐ │ │ │ MCP CLI 工具 SDK / 直接 HTTP │ │ │ └────┬────┴──────────┘ ↓ Tool Call ↓ 模型Connector 是被 MCP 包装的对象。 一个 MCP Server 的内部实现，往往就是一个 Connector：它处理 OAuth token 刷新、API 限流、分页拉取、字段映射——这些活儿和 MCP 一点关系都没有，MCP 只负责把它「暴露给模型」。
同一个 Connector 可以有多个出口：
- 暴露成 MCP Server → 给 AI 用
- 暴露成 CLI → 给人用 / 给脚本用
- 暴露成 SDK → 给应用代码用
完整的层级图与一次真实调用
┌─────────────────────────────────────────┐│ 外部世界：SaaS / 数据库 / 文件系统 / API │└────────────────┬────────────────────────┘ │ ┌────────┴────────┐ │ Connector │ 认证、限流、重试、数据转换 └────────┬────────┘ │ ┌───────────┼───────────┐ │ │ │ ┌───┴───┐ ┌────┴────┐ ┌───┴────┐ │ MCP │ │ CLI │ │直接 HTTP│ ← 三条并列的接入方式 └───┬───┘ └────┬────┘ └───┬────┘ │ │ │ └───────────┼───────────┘ │ ┌────────┴────────┐ │ Skill │ 指令剧本：告诉模型怎么组合上面这些 └────────┬────────┘ │ ┌────────┴────────┐ │ Tool Call │ 模型与外界交互的唯一出口 └────────┬────────┘ │ ┌────┴────┐ │ 模型 │ └─────────┘以「把这份报告上传到飞书文档」为例，一次任务会把五个概念全用上：
| 步骤 | 发生了什么 | 涉及概念 |
|---|---|---|
| 1 | 模型判断需要外部能力，发起调用 | Tool Call |
| 2 | 载入 feishu-cli 指令包，知道了操作方法和坑 | Skill（经 MCP 加载） |
| 3 | 按指令执行 lark-cli drive upload ... | CLI（Tool Call 的一种） |
| 4 | lark-cli 内部处理 OAuth、走飞书 Open API | Connector |
| 5 | stdout 回到模型，模型判断成功并回复用户 | Tool Call result |
五个概念各司其职，谁也没有取代谁。
延伸：2026 年 MCP 走向无状态
2026 年 7 月 28 日，MCP 发布了 2026-07-28 版规范，官方定性为「协议诞生以来最大、最系统性的一次修订」。
核心一句话：MCP 从「双向有状态长连接」转向「无状态请求 / 响应」，变得更像一个普通的 HTTP 服务。
核心变化对照
| 旧版（2025-11-25 及更早） | 新版（2026-07-28） | |
|---|---|---|
| 握手 | 必须先 initialize / initialized | 彻底移除，改为可选的 server/discover |
| 会话 | Mcp-Session-Id 头绑定会话 | 完全移除，每个请求自包含 |
| 能力协商 | 连接时交换一次 | 随每次请求放在 _meta 里传 |
| 水平扩展 | 需要粘性会话 / 共享 session store / 网关拆包 | 普通轮询负载均衡即可，可跑 Serverless |
新版的一次调用：
POST /mcp HTTP/1.1MCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: searchContent-Type: application/json{"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}, "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}把 Mcp-Method / Mcp-Name 提到 HTTP header 的意义很大：网关、WAF、计费系统不用拆 JSON body 就能知道 Agent 在调什么工具、有没有权限。
需要状态的场景怎么办
官方给的答案是 HTTP 用了二十年的老办法——显式句柄：
调用 create_basket → 返回 basket_id: "bsk_a1b2c3"调用 add_item(basket_id="bsk_a1b2c3", sku="shoes")状态由服务端存，ID 作为普通参数由模型传回来。相比隐藏在连接里的 session，句柄的好处是模型能「看见」它，因而可以推理它、组合它、跨步骤传递它。这套设计理念叫**「按需复杂度」**：核心保持精简，有状态性只在真正需要时才出现。
其他要点
- MRTR（多轮往返请求）：服务端返回
resultType: "input_required"，客户端补齐信息后重试原调用 - 可缓存列表：
tools/list等响应带ttlMs和cacheScope，列表不再随连接变化 - 扩展框架：首批正式纳入 MCP Apps（服务器直接提供交互式 HTML 界面）、Tasks（长周期任务标准化）、EMA（企业托管授权）
- 授权对齐企业标准：MCP Server 正式作为 OAuth 2.1 资源服务器；强制 RFC 9728、RFC 8707、RFC 9207；从 DCR 转向 CIMD（客户端元数据文档），可直接对接 Entra / Okta
- 弃用项（≥12 个月窗口）：旧 HTTP+SSE 传输、Roots、Sampling、Logging
- SDK：TypeScript / Python / Go / C# 已更新，Rust 在 beta
这次更新恰好印证了分层
- 无状态化之后，MCP 越来越像「一个标准化的 HTTP API 网关协议」。它主动放弃了自己管连接状态，把责任还给现成的 HTTP 基础设施（负载均衡、OAuth、分布式追踪）
- 换句话说，MCP 向 Connector 那一层的成熟做法靠拢了，不再自己发明分布式系统方案
- 而 Tool Call 这一层完全没变——模型侧感知不到这次改动，变的全是传输层和部署层
下层剧烈重构，上层毫发无伤。这正是分层的意义。
小结：什么时候用什么
| 场景 | 推荐 |
|---|---|
| 一次性的、探索性的操作 | 直接 CLI（Bash） |
| 高频、需要权限管控、要给他人复用 | 包成 MCP Server |
| 有固定流程和已知坑位的复杂任务 | 写成 Skill |
| 需要接入外部 SaaS / 数据库 | 先写好 Connector，再决定暴露成 MCP 还是 CLI |
| 只是想让模型做点什么 | 你只需要 Tool Call，其余都是实现细节 |
三条避坑经验：
- 不要为了 MCP 而 MCP。 一个能跑的 CLI 加一段清晰的 Skill 指令，往往比一个半成品 MCP Server 更实用。
- Skill 该写的是方法论和踩坑记录，API 参数表 MCP 自己会带，重复抄一遍只会增加维护负担。
- Connector 是最该好好写的一层。 认证、重试、分页、限流这些活儿，不管上面套 MCP 还是 CLI 都躲不掉。
这套分层判据同样适用于更上层的工具选型问题——先看约束条件，再看能力上限，可参考 WorkBuddy 和 Codex 怎么选 里的决策表。
下一步可以做的事很具体：把手上正在纠结「要不要做成 MCP」的那个需求，按上表的场景列对号入座一次，多数情况下答案会立刻清楚。