MCP 与 Skill 入门：给 AI 接上手脚，再给它一本操作手册

6 小时前
/ , , ,
3
摘要
AI 看得见了，但它什么都做不了。MCP 让它够得到外面的世界，Skill 让它把事做对。这篇从零讲起：为什么 AI 需要工具，MCP 和 RESTful API 有什么关系，Skill 跟写个好 Prompt 有什么区别。

MCP 与 Skill 入门：给 AI 接上手脚，再给它一本操作手册

AI 什么都懂，但什么都做不了——直到有人给它接上手

AI 的三堵墙

上一篇讲了 Prompt 和 Context Engineering：怎么跟 AI 说话，怎么布置它走进的房间。但看到信息是一回事，能做事是另一回事。

我最近碰到一个很能说明问题的场景。我对 AI 说："帮我查一下下周的日程，看看有没有冲突，然后把结果发给同事。"三件事，每件单独拿出来都不复杂。但 AI 做不了任何一件。

不是它不够聪明。是它有三个先天的硬限制：

AI 的三个先天限制

1. 知识有截止日期。 AI 的知识来自训练数据，而训练数据有一个截止时间。2026 年 4 月训练完的模型，不知道 2026 年 5 月发生了什么。你问它"昨天的新闻"，它答不上来。

2. 不能执行动作。 AI 只能生成文字。它可以"写出"一段发邮件的代码，但它不能真的发那封邮件。它可以"建议"你删除某个文件，但它不能真的去删。生成文字和执行动作之间，有一条不可跨越的线。

3. 不能访问私有数据。 你的日历、邮箱、公司内部文档、代码仓库——这些都在 AI 的训练数据之外。你不给它，它就看不到。

你可以把 Prompt 写得再完美、Context 布置得再周全，这三堵墙就在那里。要打破它们，需要一种全新的机制。

Function Calling：AI 学会了"调用工具"

在讲 MCP 之前，先理解一个前置概念：Function Calling（函数调用），也叫 Tool Use（工具使用）。

传统的 AI 对话是这样的：你说一句话，AI 回一段文字。输入是文字，输出也是文字。但从 2023 年开始，主流 AI 模型多了一种能力：它可以在回复中声明自己想要调用一个外部函数。

举个例子。你问 AI "今天北京天气怎么样？"，AI 不直接编造一个答案，而是返回类似这样的结构：

{
  "function_call": {
    "name": "get_weather",
    "arguments": {"city": "Beijing"}
  }
}

注意，AI 没有真的去查天气。它做的事情是：看了你的问题，判断需要查天气，然后"说出"了它想调用哪个函数、传什么参数。 真正去调用天气 API、拿到结果的，是包裹在 AI 外面的应用程序。应用拿到结果后，再把结果传回给 AI，AI 基于真实数据生成最终回答。

Function Calling 是什么？

一句话： AI 不只能生成文字，还能"说出"它想要调用哪个外部工具。

工作原理： 你预先告诉 AI "你有这些工具可以用"（一个函数列表及其参数说明），AI 在回答问题时会自主判断是否需要调用某个工具，并输出结构化的调用请求。实际执行由外部程序完成，结果再反馈给 AI。

关键点： AI 并不"执行"任何东西。它只是做出"我需要调用这个工具"的判断，然后用结构化格式表达出来。它从一个只能说话的嘴，变成了一个能指挥别人动手的大脑。

Function Calling 打破了 AI 的第二堵墙（不能执行动作）和第三堵墙（不能访问私有数据）。但它引出了一个新问题。

新问题：N x M 的爆炸

有了 Function Calling，AI 理论上可以调用任何外部服务。但实践中，每接入一个新服务都需要写一套对接代码：认证怎么做、API 怎么调、返回数据怎么解析、错误怎么处理。

如果你想让 AI 能查 Google 日历，写一套。想让它再能查 GitHub，写一套。想加上 Gmail，又一套。想加上 Slack、Notion、Jira……

N 个 AI 应用想要对接 M 个外部服务，就需要 N x M 套对接代码。做过企业系统集成的人对这个问题太熟悉了——这是一个经典的组合爆炸。

MCP：一套标准协议

MCP（Model Context Protocol，模型上下文协议）就是为了解决这个问题而设计的。

MCP 是什么？

一句话： 一套标准协议，让 AI 应用能以统一的方式连接各种外部服务。

跟 RESTful API 的对比： 如果你理解 RESTful API，你已经理解了 MCP 的大部分。RESTful API 定义了客户端和服务器之间通过 HTTP 通信的规范——用 GET 读、POST 写、统一的 URL 路径、JSON 格式的数据。MCP 做的事情类似：定义了 AI 应用和外部服务之间通信的规范。区别在于，RESTful API 是给程序员写的代码调用的，而 MCP 是给 AI 模型"理解和使用"的。

解决了什么问题： 有了 MCP，Gmail 只需要提供一个 MCP Server，任何支持 MCP 的 AI 客户端都能直接连上。N x M 的组合爆炸变成了 N + M——每个 AI 应用只需要实现 MCP Client，每个服务只需要实现 MCP Server。

用一个更生活化的类比：2000 年前后的电脑，键盘用 PS/2 口，打印机用并口，鼠标用串口，每种设备一种接口。USB 出来之后，一个口通吃。MCP 做的是同样的事，只不过连接的不是硬件设备，而是软件服务。

MCP 的三个组成部分

MCP 协议里有三个角色，理解它们就理解了整个通信链路：

1. MCP Client（客户端）

就是 AI 应用这边的接口层。比如 Claude Code、Cursor、ChatGPT——它们作为 AI 应用，内部实现了 MCP Client，能够跟任何 MCP Server 对话。你作为用户通常不直接接触 Client，它是应用内置的。

2. MCP Server（服务器）

外部服务提供的标准化接口。每个想被 AI 访问的服务（Gmail、GitHub、你的内部数据库）都可以包装成一个 MCP Server。它负责：告诉 AI "我能提供哪些工具"、接收 AI 的调用请求、执行实际操作、返回结果。

3. Protocol（协议本身）

Client 和 Server 之间通信的规则。MCP 用的是 JSON-RPC 格式——如果你做过 Web 开发，这就是一个非常标准的请求/响应协议，没有额外的学习成本。

协议里定义了三种东西可以被 AI 使用：

  • Tools（工具）： AI 可以执行的操作，比如"发送邮件"、"创建 GitHub Issue"
  • Resources（资源）： AI 可以读取的数据源，比如"最近的会议记录"、"项目文档"
  • Prompts（提示模板）： 预定义的交互模板，比如"用这个格式做代码审查"

MCP 的现实：标准能不能统一

技术设计是一回事，生态是另一回事。

USB 之所以成功，不只是因为技术好，更因为 Intel、微软、苹果这些巨头都站到了同一边。如果当年每家推各自的接口标准，今天你桌上可能还是一堆不同的线。

MCP 目前的势头不错——由 Anthropic 发起，多家 AI 厂商在跟进。但生态博弈远没有结束。这里没有确定的结论，只是提醒：一个协议的成功，技术只占一半，另一半是政治。

还有一个更实际的问题是安全。MCP 让 AI 能执行真实操作了——发邮件、改文件、操作数据库。一旦出了差错，后果不只是"回答了一个错误答案"，而是可能真的做了一件不该做的事。能力越大，风险越大。这个问题后面讲 Harness 的时候会进一步展开。

从"能做"到"做对"：为什么还需要 Skill

现在 AI 有手有脚了。但有手有脚不等于会干活。

让我用一个具体场景来说明。假设你让 AI 帮你把一篇 Markdown 文章发布到微信公众号。AI 有了 MCP，理论上能调用公众号的 API。但这个任务里有一堆细节：

  • 公众号的 HTML 渲染器不支持某些 CSS 属性（比如 flexbox）
  • 图片链接必须是 HTTPS，而且域名必须在公众号后台白名单里
  • 正文里的代码块需要特殊处理，否则在手机上显示会错乱
  • 封面图有特定的尺寸和格式要求

这些规则 AI "大概知道"一些，但不全、不准。如果你每次都在 Prompt 里把这些细节写一遍，不仅低效，而且容易遗漏——上次记得的细节这次可能忘了。

Skill 是什么？

一句话： 写给 AI 的标准操作手册，把"怎么把某件事做对"固定下来。

跟 Runbook/SOP 的对比： 运维领域有一种东西叫 Runbook（操作手册）或 SOP（标准操作流程）。服务挂了？第一步检查什么，第二步重启什么，第三步通知谁，每一步的前置条件和检查点都写得清清楚楚。Runbook 不是教你运维知识——它假设你已经会了，只是把"这件特定的事怎么做"钉死。Skill 做的是同样的事，只不过读手册的人从运维工程师变成了 AI。

关键洞察： Skill 不是在教 AI 新能力。AI 已经"大概会做"大部分事情。Skill 解决的是把"大概能做"变成"确定能做对"。差别在细节。

一个 Skill 的基本结构长这样：

---
name: publish-to-wechat
trigger: 当用户要求发布公众号文章时
---

## 步骤

1. 将 Markdown 转换为公众号兼容的 HTML
2. 检查所有图片链接，确保是 HTTPS 且在白名单域名
3. 如果有代码块，用 <pre><code> 包裹并添加行内样式
4. 调用公众号 API 创建草稿
5. 返回草稿预览链接供用户确认

## 约束

- 不使用 flexbox 或 grid 布局
- 封面图尺寸：900x383px
- 正文宽度不超过 600px

看起来很简单。但这种"简单"正是它的价值——它把散落在你脑子里的经验沉淀成了一个可重复执行的流程。你修了一个 bug，在 Skill 里加一条规则，以后所有使用这个 Skill 的场景都受益。

Prompt、Skill、代码：三者的区别

到这里你可能会问：Skill 跟直接写代码有什么区别？跟写一个好的 Prompt 又有什么区别？

PromptSkill代码
生命周期一次性，说完就没了持久化，版本管理，可分享持久化，版本管理，可分享
执行者AI 解读并执行AI 解读并执行机器精确执行
灵活性高，每次可以不同中，框架固定但 AI 可在框架内灵活应对低，严格按代码逻辑执行
适用场景一次性任务、探索性对话反复执行的标准流程需要精确控制的逻辑

用一个公式概括：Skill = 通用能力 x 特定约束 x 可重复执行。

Prompt 是一次性指令。代码是精确到每一步的确定性程序。Skill 在两者之间——它用自然语言定义流程和约束，但把具体执行的灵活性留给 AI。当某个步骤的细节变了（比如公众号 API 更新了），你改 Skill 里的一行描述就行，不需要重写代码。

MCP + Skill：一个解决能不能，一个解决对不对

把两个概念放在一起看：

MCP 解决的是"能不能做"。 AI 能不能访问你的日历？能不能读取 GitHub 上的代码？能不能发送邮件？这是能力边界的问题。没有 MCP（或类似机制），AI 再聪明也只能纸上谈兵。

Skill 解决的是"怎么做对"。 AI 能发邮件了，但邮件格式对不对？流程对不对？该检查的检查了没有？这是执行质量的问题。没有 Skill，AI 能做但不一定做得对。

两者叠加之后，一个新的问题浮出水面：AI 既能获取信息，又有标准流程可以遵循，它是不是已经具备了独立完成任务的条件？

当它真的开始独立行动，谁来控制它的行动边界？它删了一个不该删的文件怎么办？它做了一个"看起来合理但实际上错误"的判断怎么办？

这就是下一篇要讲的内容：Harness 和 Agentic Engineering——怎么控制一个会自己做决定的系统。

这是 AI 工程入门系列的第二篇。如果你已经理解了 MCP 和 Skill 的区别，推荐继续阅读进阶篇《MCP 与 Skill：给 AI 接上手脚，再给它一本操作手册》，那篇从实践角度讨论了 Skill 粒度的取舍和 MCP 生态的深层博弈。

  • Loading...
  • Loading...
  • Loading...
  • Loading...
  • Loading...