Agent丨MCP 和 Skills 有什么区别？它们分别解决什么问题？

type

Post

status

Published

date

May 2, 2026

slug

agent26

summary

一句话结论

MCP 解决的是“Agent 如何连接外部世界”的问题；Skills 解决的是“Agent 如何按团队经验稳定完成一类任务”的问题。
MCP 更像 Connector / Tool Runtime / USB-C 协议，把数据库、GitHub、CI、浏览器、设计稿、日志平台等外部能力标准化暴露给 Agent。
Skills 更像 SOP / Playbook / 可复用工作流包，把“什么时候做、按什么步骤做、用什么标准验收、遇到异常怎么办”沉淀成可按需加载的技能。

MCP 官方规范将 MCP 定义为连接 LLM 应用与外部数据源、工具的开放协议，并通过 JSON-RPC 2.0 在 Host、Client、Server 之间通信；Skills 官方规范则把 Skill 定义为一个包含 SKILL.md 的目录，可附带脚本、参考资料和资产，并通过渐进式披露按需加载。(Model Context Protocol)

一、为什么 MCP 和 Skills 容易被混淆？

这两个概念都在回答同一个大问题：

如何让 Agent 不只是聊天，而是能稳定完成真实工作？

但它们切入的层级完全不同。

MCP 关心的是：

Agent 要怎么调用外部系统？
工具怎么声明？
参数怎么校验？
返回结果怎么标准化？
权限、认证、传输、服务发现怎么做？

Skills 关心的是：

Agent 面对一类任务时应该怎么做？
团队经验怎么复用？
SOP 怎么沉淀？
大段提示词怎么按需加载，而不是每次塞进上下文？
如何让结果更稳定、更符合组织规范？

Linux.do 上有一个很贴切的总结：Skills 是对运作的描述，MCP 是对能力的封装；Skills 可以替代一部分 workflow 定义，而 MCP 更像功能节点。 这个判断和官方定义基本一致。(LINUX DO)

二、先看 MCP：它是 Agent 的“外部能力协议”

MCP，全称 Model Context Protocol。你可以把它理解成：

给 Agent 用的标准化外设接口。

以前每个 AI Coding 工具都要自己写 GitHub 集成、数据库集成、浏览器集成、Figma 集成、日志系统集成。这样会产生很多重复问题：

问题	没有 MCP 时的表现
集成碎片化	Claude Code、Cursor、Copilot、Codex 各写一套插件
工具描述不统一	每个平台的 tool schema、鉴权、返回格式都不同
企业系统难接入	内部 DB、CI、监控、知识库都要定制开发
安全边界模糊	Agent 到底能调用什么、如何授权，不容易统一治理
迁移成本高	一个工具只能服务一个 Agent 客户端

MCP 的目标就是把这些外部能力抽象为标准协议。官方规范中，MCP 应用由 Host、Client、Server 组成：Host 是发起连接的 LLM 应用，Client 是 Host 内部的连接器，Server 则负责提供上下文和能力。(Model Context Protocol)

MCP 架构图

MCP Server 通常暴露三类核心能力：

能力	作用	例子
Tools	可执行动作	查 issue、跑 CI、发请求、查数据库
Resources	可读取上下文	文件、日志、文档、API 响应、图片
Prompts	可复用交互模板	让客户端按某种固定方式发起任务

MCP 的 Tools 明确用于让模型与外部系统交互，例如查询数据库、调用 API、执行计算，每个 tool 通过名称和 schema 描述。(Model Context Protocol)

从源码看 MCP 的本质

下面是一个简化的 MCP Server。它暴露了一个 get-pr-info 工具，Agent 可以通过 MCP 调它来读取 PR 信息。写法参考官方 TypeScript SDK 的 McpServer / registerTool 风格，官方示例也是通过注册工具、声明输入 schema、返回标准 content 来暴露能力。(GitHub)

这段代码说明了 MCP 的核心：

MCP 不是在教 Agent 怎么审 PR，而是在提供“查询 PR 信息”这个可调用能力。

也就是说，MCP 的关注点是：

它并不关心：

这些正是 Skills 该解决的问题。

三、再看 Skills：它是 Agent 的“可复用工作流知识包”

Agent Skills 是一种目录化的能力包装方式。官方规范要求一个 Skill 至少包含一个 SKILL.md，其中必须有 YAML frontmatter，至少包括 name 和 description；Skill 还可以包含 scripts/、references/、assets/ 等目录。(Agent Skills)

Skills 的目录结构

Agent Skills 的核心不是“暴露一个外部 API”，而是把某类任务的经验封装成文件：

allowed-tools 在 Agent Skills 规范中是实验字段，用于声明技能可预批准使用的工具，不同 Agent 实现支持情况可能不同。(Agent Skills)

Skills 的关键机制：渐进式披露

Skills 不是简单的“提示词模板”。它更重要的能力是 progressive disclosure，渐进式披露：

Agent Skills 规范明确说明：启动时只加载 metadata，大约包括 name 和 description；Skill 被激活后才加载完整 SKILL.md；脚本、参考资料、资产等资源只在需要时读取。(Agent Skills)

Claude API 文档也强调，Skills 是文件系统资源，用来为 Claude 提供领域专长、流程、上下文和最佳实践，并通过按需加载避免每次重复提供相同指导。(Claude Platform)

这也是为什么 Linux.do 讨论里有人会说：Skill 一定程度上也是预设提示词，但它的渐进式披露让它可以按需加载，从而节省上下文空间。(LINUX DO)

四、MCP 和 Skills 的核心区别

维度	MCP	Skills
本质	协议、运行时、外部能力连接层	文件夹、说明书、工作流知识包
主要解决	Agent 如何访问外部工具和数据	Agent 如何稳定完成一类任务
抽象层级	偏底层，类似 Connector / Tool / API	偏高层，类似 SOP / Service / Workflow
典型内容	tool schema、参数、鉴权、传输、返回格式	步骤、规则、模板、边界条件、验收标准
是否执行代码	MCP Server 自己执行工具逻辑	Skill 可包含脚本，但通常由 Agent 决定何时执行
是否连接外部系统	是，核心用途之一	可连接，但通常通过已有工具或 MCP 完成
是否按需加载	取决于客户端实现；传统 MCP 工具描述容易占上下文	原生设计就是渐进式披露
适合沉淀什么	外部系统能力	团队经验、领域流程、任务范式
类比	USB-C、RPC、插件协议、工具网关	操作手册、Runbook、团队最佳实践、技能包
是否互相替代	不替代	不替代

更工程化地说：

MCP 是“可调用能力”的标准化。
Skills 是“如何使用能力完成任务”的标准化。

五、用 AI Coding 场景理解：一次 PR Review 里两者怎么协作？

假设用户对 Agent 说：

帮我 review 这个 PR，重点看鉴权和数据迁移风险。

一个成熟 AI Coding Agent 的执行链路可能是这样的：

这里的边界非常清楚：

动作	归谁负责
查 PR diff	MCP
查 CI 状态	MCP
读团队安全审查清单	Skill
决定审查顺序	Skill
输出报告格式	Skill
判断风险并写结论	Agent
真实调用 GitHub API	MCP Server

Linux.do 讨论中也提到一种协作模式：把 SOP、风格规范、验收标准写入 SKILL.md，当需要触达外部系统时通过 MCP 调用工具。(LINUX DO)

六、为什么光有 MCP 不够？

很多开发者接入 MCP 后会遇到一个问题：

工具是有了，但 Agent 还是不知道该怎么稳定地用。

例如你给 Agent 接了这些 MCP 工具：

Agent 现在“能做很多事”，但它仍然可能犯这些错：

这就是 MCP 的边界：

MCP 提供动作能力，但不保证任务策略正确。

MCP 像函数库：

Skills 像业务服务层：

它会规定：

所以，如果只接 MCP，Agent 可能“会用工具但不会工作”；如果加上 Skills，Agent 才更像“知道团队流程的新同事”。

七、为什么光有 Skills 也不够？

反过来，只有 Skills 也有明显边界。

比如你写了一个很完整的发布检查 Skill：

这个 Skill 很会“描述怎么做”，但如果 Agent 没有外部工具，它就不能真正查询：

这时就需要 MCP：

所以 Skills 的边界是：

Skills 能沉淀流程，但真实世界的数据和动作仍需要工具层支撑。

这也是为什么更合理的架构不是“Skills 替代 MCP”，而是：

Skills 编排任务，MCP 连接外部系统。

八、成熟 AI Coding 工具正在怎么做？

1. Claude Code：Skills 成为可复用能力入口

Claude Code 文档说明，创建 SKILL.md 后 Claude 会在相关时使用 Skill，也可以通过 /skill-name 显式调用；并且 Skill 正文只有在使用时才加载，不像 CLAUDE.md 那样长期占上下文。Claude Code 还说明，自定义命令已经合并到 Skills 体系中，.claude/commands/deploy.md 和 .claude/skills/deploy/SKILL.md 都可以创建 /deploy。(Claude Code)

这意味着 Claude Code 里的 Skills 不只是“知识文件”，也在承接过去 slash command、任务模板、团队流程的角色。

2. Codex：Skills 是 reusable workflow 的 authoring format

OpenAI Codex 文档将 Agent Skills 定义为扩展 Codex 任务能力的方式：一个 Skill 打包 instructions、resources 和 optional scripts，让 Codex 更可靠地遵循工作流。Codex 也采用渐进式披露，先加载每个 Skill 的名称、描述和路径，只有决定使用某个 Skill 时才读取完整 SKILL.md。(OpenAI开发者)

这说明 Skills 已经不只是 Claude 生态概念，而是逐渐成为跨 Agent 的工作流知识包格式。

3. VS Code / GitHub Copilot：Skills 和 MCP 都是 Agent 定制能力

VS Code 文档说明 Agent Skills 是 folders of instructions, scripts, and resources，GitHub Copilot 可在相关任务中加载；它还明确区分了 Skills 和 custom instructions：Skills 用于专门能力和工作流，支持脚本、示例和资源，并按需加载；custom instructions 主要用于编码规范，通常总是应用。(Visual Studio Code)

4. OpenCode：Skills 作为原生 on-demand instruction

OpenCode 文档说明 Agent Skills 让 OpenCode 从仓库或用户目录发现可复用指令，并通过原生 skill 工具按需加载完整内容；它还兼容 .claude/skills、.agents/skills 等路径。(OpenCode)

5. Cursor：把 MCP 和 Skills 都放进“动态上下文发现”

Cursor 在 2026 年的文章中提到，它支持 Agent Skills open standard，并把 Skills 看作通过文件告诉 Agent 如何执行特定领域任务的方式；同时它也指出 MCP 工具描述过多时会显著膨胀上下文，因此 Cursor 会把 MCP 工具描述同步到文件夹，让 Agent 只拿到少量静态上下文，按需查找工具定义。在调用 MCP 的运行中，这种方式使总 token 降低了 46.9%。(Cursor)

这个实践非常关键：

MCP 自身解决连接问题，但 MCP 工具太多也会带来上下文膨胀。
Skills 天然按需加载，而 MCP 也需要被 Agent 客户端做动态上下文发现。

九、从“上下文工程”角度看两者区别

在 Agent 系统里，最贵的不是代码，而是上下文。

传统写法：所有信息都塞进系统提示词

结果是：

MCP 的改善

MCP 让工具接入标准化：

但如果一次性把很多 MCP 工具描述都塞进上下文，仍然会膨胀。

Skills 的改善

Skills 让工作流知识按需加载：

这就是 Skills 对上下文工程的核心价值。

Agent Skills 规范也明确建议把长参考资料拆到 references/，让 Agent 只在需要时加载较小、聚焦的文件。(Agent Skills)

十、源码级类比：MCP 是函数，Skill 是调用策略

MCP：提供原子函数

这个 MCP Tool 的职责很窄：

给定服务名和时间范围，查日志。

它不负责判断：

Skill：提供排障方法论

这个 Skill 的职责是：

教 Agent 如何排障。

真正查日志时，它仍然可以调用 MCP Tool。

十一、组合形态：Skill 调 MCP，MCP 服务 Skill

生产级 Agent 最常见的形态应该是：

在这个架构里：

Linux.do 帖子里也提到类似观点：Skills 可以写清“何时/如何使用某工具”，例如选择哪个数据源、调用顺序、审计红线、失败重试策略和验收清单；MCP 则提供工具面。(LINUX DO)

十二、什么时候应该用 MCP？

场景 1：需要连接外部系统

例如：

这些都适合 MCP。

因为你要解决的是：

场景 2：需要强类型参数和确定性执行

例如：

MCP Tool 可以用 schema 限制输入，减少 Agent 乱传参数。

场景 3：需要隔离敏感能力

比如：

这些能力不能直接靠 Prompt 管控，应该放在 MCP Server、权限系统、审批系统里治理。

场景 4：希望“一次开发，多 Agent 复用”

只要客户端支持 MCP，一个 MCP Server 就可以被多个工具使用：

这正是 MCP 协议层的价值。

十三、什么时候应该用 Skills？

场景 1：你总是在重复同一段 Prompt

例如你经常对 Agent 说：

这就应该做成 Skill。

Claude Code 文档也建议：当你反复粘贴同样的说明、检查清单、多步骤流程，或者 CLAUDE.md 的某一段已经变成流程而不是事实时，就应该创建 Skill。(Claude Code)

场景 2：团队流程比工具本身更重要

比如：

这些不是单个工具能解决的，而是“如何组合工具和判断结果”的问题。

场景 3：你要减少上下文污染

如果所有规则都写进 CLAUDE.md、AGENTS.md 或系统提示词，Agent 每次任务都会读到一堆不相关内容。

Skills 的按需加载更适合大量垂直流程。Agent Skills 规范要求 description 描述 Skill 做什么以及何时使用，Agent 启动时只加载这些轻量信息，命中后才读取完整内容。(Agent Skills)

场景 4：你要沉淀“人的经验”

例如：

这些经验放 MCP 里并不合适，因为它们不是 API 能力，而是团队上下文和工作方法。

十四、MCP 能不能实现 Skill？

技术上可以模拟一部分，但不建议混为一谈。

你可以写一个 MCP Tool：

但这样会有几个问题：

MCP 更适合封装稳定、可执行、边界明确的外部动作。

Skills 更适合封装可读、可改、可组合、偏流程的知识。

Linux.do 讨论里也有人提到：Skills 对模型来说更像白盒描述，MCP 更像运行时黑盒调用。(LINUX DO)

十五、Skill 能不能替代 MCP？

也不建议。

你可以在 Skill 里写脚本：

但如果这些脚本开始处理复杂鉴权、API 调用、分页、重试、权限控制、审计日志，它们其实已经在变成一个“小型 MCP Server”。

Skill 里放脚本适合：

MCP Server 适合：

一个简单判断：

如果它更像“脚本辅助工作流”，放 Skill。
如果它更像“对外服务能力”，做 MCP。

十六、工程落地建议：如何设计 MCP + Skills 分层？

推荐分成四层：

Layer 1：基础工具

这是 AI Coding Agent 的本地工作能力。

Layer 2：MCP Connectors

这一层负责连接外部世界。

Layer 3：Skills

这一层负责把团队经验变成可复用流程。

Layer 4：Agent Orchestration

这一层由 Claude Code、Codex、Cursor、OpenCode、Copilot 或自研 Agent Runtime 承担。

十七、一个更完整的组合示例：发布检查 Skill + MCP

1. MCP 提供外部能力

2. Skill 规定发布检查流程

3. Agent 运行时效果

这个例子中：

十八、安全边界：MCP 和 Skills 的风险不同

MCP 的安全风险

MCP 的风险主要来自：

所以 MCP Server 要重点做：

Skills 的安全风险

Skills 的风险主要来自：

Anthropic 的工程文章也提醒，Skills 通过 instructions 和 code 给 Claude 新能力，因此恶意 Skills 可能在运行环境中引入漏洞，或诱导 Claude 外传数据、执行非预期动作；官方建议只安装可信来源的 Skills，并审计其中的文件、依赖、资源和外部网络连接指令。(Anthropic)

十九、常见误区

误区 1：MCP 是新版插件系统，Skills 是旧版 Prompt

不准确。

MCP 是协议层，Skills 是工作流知识层。两者不是新旧关系，而是上下层关系。

误区 2：有了 MCP，Agent 就会自动变聪明

不一定。

MCP 只是让 Agent 能接触更多能力。没有好的 Skill、上下文工程和验证机制，Agent 可能只是“拥有更多犯错方式”。

误区 3：Skills 只是 Prompt 模板

不完整。

Skills 确实包含指令，但它们还有：

Agent Skills 官方规范明确了目录结构、frontmatter 字段、可选目录和渐进式披露机制。(Agent Skills)

误区 4：Skills 会替代 MCP

不会。

Skills 可以写“什么时候调用工具”，但真实外部系统连接仍然需要 MCP 或其他工具运行时。

误区 5：MCP 一定会导致上下文爆炸

不是 MCP 必然导致，而是客户端如果把所有 MCP 工具描述一次性塞进上下文，就容易膨胀。Cursor 的做法是通过动态上下文发现减少 MCP 工具描述常驻上下文，并在调用 MCP 的运行中降低 token 使用。(Cursor)

二十、选型决策表

需求	用 MCP	用 Skills	两者结合
连接 GitHub / DB / CI / SaaS	✅	❌	✅
封装团队 PR Review 流程	❌	✅	✅
读取生产日志	✅	❌	✅
规定线上排障步骤	❌	✅	✅
调用高危生产操作	✅	❌	✅，但要审批
沉淀团队最佳实践	❌	✅	✅
避免重复粘贴长 Prompt	❌	✅	✅
多 Agent 复用外部工具	✅	❌	✅
多 Agent 复用工作流	❌	✅	✅
做权限、鉴权、审计	✅	部分支持	✅
做模板、checklist、SOP	❌	✅	✅

二十一、我推荐的实践原则

原则 1：先拆“能力”和“流程”

设计 Agent 系统时先问两个问题：

原则 2：MCP Tool 保持原子化

不建议写这种巨型 MCP Tool：

更建议拆成：

然后用 Skill 编排它们。

原则 3：Skill 写“判断和流程”，不要写太多工具细节

Skill 应该写：

不应该把大量 API 调用细节塞进 SKILL.md。否则 Skill 会变成难维护的伪代码仓库。

原则 4：把长资料拆进 references

不要写一个 3000 行的 SKILL.md。

原则 5：为 Skill description 做测试

Skill 能不能触发，很大程度取决于 description。Agent Skills 文档强调，description 是 Agent 判断是否加载 Skill 的主要机制；描述过窄会漏触发，过宽会误触发。(Agent Skills)

可以准备两组测试用例：

然后反复优化 description。

二十二、最终结论

MCP 是 Agent 的“手”和“接口”。
它让 Agent 能触达 GitHub、数据库、CI、日志、浏览器、设计稿、内部系统。

Skills 是 Agent 的“经验”和“方法”。
它告诉 Agent 面对 PR Review、发布检查、线上排障、安全审计、文档生成等任务时，应该按什么流程做、遵守什么规范、如何验收结果。

两者最好的关系不是替代，而是组合：

在 AI Coding 场景里，一个成熟团队最终会形成这样的资产结构：

真正的生产级 Agent 系统，不是只堆 MCP，也不是只写 Skills，而是把两者分层：

用 MCP 标准化外部能力，用 Skills 标准化团队经验。