一文搞懂 AI Agent、Skill 和 MCP：它们到底是什么关系？

近几年，大语言模型（Large Language Model，LLM）的发展速度非常快。

从最初的“输入一个问题，模型生成一个答案”，到现在能够搜索资料、读取文件、分析数据、调用外部工具甚至连续执行多个任务，AI 的角色正在发生一个非常明显的变化：

从“回答问题”逐渐走向“完成任务”。

例如，我们不再只是问 AI：

“怎么整理最近收到的邮件？”

而是希望直接告诉它：

“帮我整理最近收到的重要邮件，把需要处理的事情列出来。”

甚至进一步：

“检查最近收到的重要邮件，如果里面提到了会议时间，就帮我查看日历，并整理出我需要参加的会议。”

当任务发展到这个程度，仅仅依靠传统的“Prompt → LLM → Response”模式就不够了。

于是，AI Agent、Skill、MCP 等概念开始频繁出现。

那么，它们分别是什么？又有什么关系？

---

1. 从 LLM 到 Agent：AI 开始“行动”

理解 Agent 之前，可以先看看传统 LLM 的基本工作方式。

最简单的模式可以表示为：

User
  ↓
Prompt
  ↓
LLM
  ↓
Response

用户提出问题，模型理解问题，然后生成答案。

例如：

用户：Python 怎么读取 CSV 文件？

LLM 可以直接告诉我们应该使用 pandas、csv 等工具，并给出相应代码。

但是，如果用户提出：

“读取我的 CSV 文件，分析里面的数据，然后生成一份销售趋势报告。”

情况就不同了。

AI 不仅需要“知道答案”，还需要真正执行一系列操作：

理解用户目标
    ↓
读取 CSV
    ↓
检查数据结构
    ↓
清洗数据
    ↓
进行统计分析
    ↓
生成图表
    ↓
整理报告
    ↓
返回最终结果

这已经不是一次简单的文本生成，而是一个完整的任务执行过程。

这就是 Agent 出现的重要背景。

---

2. 什么是 AI Agent？

Agent 通常翻译为“智能体”。

简单来说：

AI Agent 是一个能够围绕目标进行判断、规划、调用工具，并根据执行结果继续采取行动的 AI 系统。

如果说普通 LLM 更擅长回答：

“这个问题应该怎么解决？”

那么 Agent 更强调：

“我来完成这个任务。”

Agent 的核心通常不是一次生成，而是一个循环过程：

Goal
 ↓
Reason
 ↓
Plan
 ↓
Action
 ↓
Observation
 ↓
Reason Again
 ↓
Next Action
 ↓
...
 ↓
Final Result

也就是：

目标 → 思考 → 行动 → 观察 → 再思考 → 再行动

直到任务完成。

举一个简单的例子。

用户说：

“帮我安排明天下午和李教授的会议。”

一个 Agent 可能需要执行：

1. 理解用户想安排会议；

2. 查看用户明天下午的 Calendar；

3. 找到空闲时间；

4. 获取李教授的联系方式；

5. 创建会议；

6. 返回会议安排结果。

这里最重要的区别在于：

LLM 负责生成和推理，而 Agent 更强调围绕目标组织和执行一系列动作。

因此可以简单理解为：

LLM ≈ 大脑

Agent ≈ 大脑 + 规划 + 工具 + 执行循环

当然，这只是为了方便理解，并不是严格的系统定义。

---

3. Agent 有了“大脑”，但是它怎么知道具体任务应该怎么做？

假设我们现在已经有了一个 Agent。

用户告诉它：

“分析这篇学术论文。”

Agent 确实知道自己需要完成“论文分析”。

但问题来了：

到底应该怎么分析？

是先总结 Abstract？

还是分析 Method？

要不要整理实验结果？

要不要评价论文的创新点？

要不要分析论文存在的局限？

不同类型的任务通常都有相对稳定的工作方法。

于是就出现了另一个非常重要的概念：

Skill。

---

4. 什么是 Skill？

Skill 可以直接翻译为“技能”。

在 Agent 系统中，我们可以把 Skill 理解为：

针对某一类任务封装起来的、可以重复使用的能力或工作流程。

例如：

PDF Analysis Skill

Paper Analysis Skill

Data Analysis Skill

Presentation Skill

Web Research Skill

Code Review Skill

假设我们定义了一个：

Academic Paper Analysis Skill

里面规定：

Step 1：读取论文基本信息

Step 2：提取研究背景

Step 3：确定研究问题

Step 4：分析提出的方法

Step 5：整理实验设计

Step 6：分析实验结果

Step 7：总结创新点

Step 8：分析局限性

Step 9：生成结构化报告

以后 Agent 再遇到：

“帮我分析这篇论文。”

就不需要每次重新决定整个分析流程，而是可以使用已经定义好的 Skill。

因此：

Skill 的核心价值之一就是“复用”。

它把一些重复出现的工作方法封装起来，让 Agent 在面对类似任务时能够按照相对稳定的流程执行。

---

5. Skill 不等于 Tool

这里有一个很容易混淆的问题：

Skill 和 Tool 是一回事吗？

通常不是。

例如：

读取 PDF

可以是一个 Tool。

而：

分析一篇学术论文

更适合作为一个 Skill。

因为“分析论文”可能需要调用多个工具：

Paper Analysis Skill
        │
        ├── PDF Reader
        ├── Search Tool
        ├── Citation Tool
        └── Document Generator

因此可以粗略理解为：

Tool 更接近“一个具体动作”。

而：

Skill 更接近“完成某类任务的方法”。

例如一个研究生需要完成论文综述。

他可能掌握一个“论文综述 Skill”，但在实际执行过程中会使用：

• Google Scholar

• PDF 阅读器

• Excel

• Word

• Zotero

这些软件和服务类似于 Tool。

而“应该如何完成一篇论文综述”则更接近 Skill。

不过需要注意：

Skill 并不是像 HTTP、MCP 那样具有完全统一定义的行业协议。

不同 Agent 平台可能会用不同方式实现 Skill。

有些 Skill 只是：

Instructions + Prompt

有些可能包含：

Instructions
+ Prompt
+ Scripts
+ Tools
+ Templates
+ Examples

因此，在阅读不同 AI Agent 项目的文档时，需要具体看这个项目如何定义 Skill。

---

6. Agent 有了 Skill，为什么还需要 MCP？

现在假设我们的 Agent 已经知道：

应该做什么。

也知道：

应该怎么做。

但还有一个问题：

它怎么访问外部世界？

例如 Agent 惏完成：

“查看 GitHub 中最新的 Issue，然后总结最近出现的 Bug。”

它需要访问 GitHub。

如果用户说：

“查询数据库中的销售数据。”

它需要访问数据库。

如果用户说：

“读取电脑中的文件。”

它需要访问文件系统。

于是就会出现大量外部系统：

GitHub
Google Drive
Database
Slack
Notion
File System
Browser
Calendar
...

如果每一个 AI 应用都为每一个外部系统单独设计连接方式，整个生态会变得非常复杂。

于是，MCP 出现了。

---

7. 什么是 MCP？

MCP 的全称是：

Model Context Protocol

中文通常称为：

模型上下文协议。

MCP 最初由 Anthropic 推出，是一种开放协议，目标之一是标准化 AI 应用与外部工具、数据源和系统之间的连接方式。

简单来说：

MCP 解决的是“AI 怎么标准化地连接外部能力”的问题。

可以把 MCP 类比成计算机世界中的 USB。

以前不同设备可能需要不同接口：

设备 A → 接口 A
设备 B → 接口 B
设备 C → 接口 C

USB 出现以后：

        ┌── Keyboard
Computer├── Mouse
  USB   ├── Camera
        └── Storage

不同设备可以通过相对统一的标准与计算机连接。

MCP 想解决的问题有些类似。

传统情况下可能是：

AI ── GitHub API ── GitHub

AI ── Database API ── Database

AI ── Files API ── File System

AI ── Slack API ── Slack

而在 MCP 架构下，可以形成更加标准化的连接方式：

                 ┌── GitHub
                 │
AI Application ─ MCP ─ Database
                 │
                 ├── File System
                 │
                 └── Other Services

所以：

MCP 本身不是 Agent。

它也不是某个具体的 AI 模型。

更准确地说，它是一套连接协议和规范。

---

8. MCP Client 和 MCP Server

进一步理解 MCP，需要知道两个重要角色：

MCP Client

MCP Server

可以先用一个简化结构理解：

┌──────────────────────┐
│     AI Application   │
│                      │
│        Agent         │
│          │           │
│     MCP Client       │
└──────────┬───────────┘
           │
           │ MCP
           │
┌──────────▼───────────┐
│      MCP Server      │
│                      │
│ Tools / Resources    │
└──────────┬───────────┘
           │
           ▼
     External System

其中：

MCP Client

通常位于 AI 应用这一侧。

负责和 MCP Server 建立通信。

MCP Server

负责向 AI 应用暴露某些能力。

例如：

GitHub MCP Server

可能向 Agent 提供：

读取 Repository

查看 Issue

创建 Issue

查看 Pull Request

Agent 不需要自己理解 GitHub 内部所有实现，只需要按照 MCP 所定义的方式使用 Server 提供的能力。

这也是 MCP 很重要的原因之一。

---

9. Agent、Skill、MCP 到底是什么关系？

现在把三个概念放到一起，就比较容易理解了。

可以用一个人的工作过程来类比：

Agent = 员工

Skill = 员工掌握的工作方法

MCP = 员工连接各种业务系统的标准接口

例如，我们给 Agent 一个任务：

“帮我分析最近收到的论文，并整理成一份研究报告。”

整个过程可能是：

                 User
                   │
                   ▼
              ┌─────────┐
              │  Agent  │
              └────┬────┘
                   │
            理解目标并规划任务
                   │
                   ▼
         ┌───────────────────┐
         │ Paper Analysis    │
         │      Skill        │
         └─────────┬─────────┘
                   │
          确定论文分析流程
                   │
                   ▼
              需要外部数据
                   │
                   ▼
              ┌─────────┐
              │   MCP   │
              └────┬────┘
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
        Files    GitHub   Database

所以可以用三句话总结：

Agent 负责：我要做什么，以及下一步做什么。

Skill 负责：这类事情应该怎么做。

MCP 负责：如何标准化地连接完成任务所需要的外部能力。

---

10. 一个完整案例：让 AI 自动完成论文分析

假设用户提出：

“帮我分析 mPLUG-Owl3 这篇论文，并结合我的研究方向整理成一份报告。”

Agent 首先理解任务：

Goal：

完成论文分析报告

然后 Agent 判断：

需要执行 Academic Paper Analysis Skill

Skill 中规定：

1. 获取论文
2. 提取基本信息
3. 阅读 Abstract
4. 分析研究背景
5. 分析模型结构
6. 整理实验
7. 总结创新点
8. 分析局限
9. 联系用户研究方向
10. 生成报告

执行过程中发现论文位于某个外部文件系统。

于是 Agent 通过 MCP 提供的能力读取文件。

Agent
  ↓
Paper Analysis Skill
  ↓
需要读取论文
  ↓
MCP
  ↓
File System
  ↓
PDF

读取之后，Agent 根据 Skill 继续完成论文分析。

最终生成：

研究背景
研究目的
模型结构
实验方法
实验结果
创新点
局限性
与研究方向的关联

这时候：

Agent、Skill、MCP 和 Tool 就形成了一个完整的协作体系。

---

11. 为什么最近这三个概念越来越重要？

原因其实和 AI 的发展方向有关。

过去我们关注的是：

模型能不能生成更好的答案？

现在越来越多的问题变成：

模型能不能真正完成任务？

于是 AI 系统开始从：

Prompt
 ↓
LLM
 ↓
Answer

逐渐发展成：

             User Goal
                 │
                 ▼
              Agent
                 │
       ┌─────────┴─────────┐
       │                   │
     Skills              Tools
       │                   │
       └─────────┬─────────┘
                 │
                MCP
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
     Files    Database    Services

AI 不再只是一个“聊天窗口”。

它开始具备：

理解目标、规划任务、调用能力、访问数据、执行操作、检查结果和继续行动的能力。

这也是为什么 Agent 正在成为当前 AI 应用开发中的重要方向之一。

---

12. 最后总结

如果只记住这篇文章中的几个概念，可以记住下面四句话：

LLM 是核心推理与生成能力。

Agent 是围绕目标组织推理、工具调用和行动的系统。

Skill 是可以重复使用的专业能力或工作流程。

MCP 是 AI 应用连接外部工具和数据的一种标准化协议。

进一步简化就是：

Agent：谁来做？

Skill：怎么做？

Tool：具体用什么能力做？

MCP：这些外部能力怎么标准化地接进来？

不过，Agent、Skill 和 MCP 并不是三个必须绑定在一起使用的组件。

一个 Agent 可以不使用 MCP，也可以直接调用 API；一个 Skill 也不一定依赖 MCP；MCP Server 同样可以服务于不同类型的 AI 应用。

因此，与其把它们理解成固定的：

Agent → Skill → MCP

不如把它们理解成 AI 应用体系中的三个不同层次：

Agent
负责决策与执行

Skill
负责能力与流程复用

MCP
负责外部能力的标准化连接

理解这一点之后，再去学习 Tool Calling、RAG、Workflow、Multi-Agent、MCP Server 等概念，就会容易很多。

而这些概念背后其实都指向了同一个趋势：

我们正在尝试让 AI 从“会回答问题的模型”，逐渐变成“能够使用工具完成任务的系统”。