这两个概念最近出现频率都很高，而且经常被放在一起讨论，容易让人觉得它们是同一类东西。

但其实它们解决的是两个不同层面的问题。

先说 MCP 是什么

MCP 是 Anthropic 推出的一个开放协议，解决的是"AI 模型怎么标准化地连接外部工具和数据源"这个问题。

在 MCP 出现之前，每个 AI 应用要接入外部工具，都得自己写一套对接逻辑。接 GitHub 一套写法，接 Slack 又一套，接数据库再一套，重复劳动，而且互不兼容。

MCP 做的事情是：定一个标准接口，工具提供方按这个标准暴露能力，AI 应用按这个标准来调用，双方对上就能用。

你可以把 MCP 理解成 AI 世界的 USB 接口——统一了插头标准，设备不用管是什么品牌的电脑，插上就能用。

再说 Agent Skill 是什么

Agent Skill 解决的是另一个问题：Agent 自身的执行能力怎么组织和管理。

它是一种架构设计，把 Agent 的各种执行能力拆成独立的技能包，每个技能包含三层：

• Metadata：描述这个技能是什么、什么时候用
• Instruction：具体告诉 Agent 怎么执行这个任务
• Resources：执行时按需加载的外部资源

核心目的是：让 Context Window 里只出现当前任务需要的内容，避免把所有能力一股脑塞进 Prompt 导致执行飘移。

两者的本质区别

一句话区分：

MCP 管的是"能连什么"，Agent Skill 管的是"怎么做事"。

展开来说：

	MCP	Agent Skill
解决什么问题	工具连接的标准化	执行能力的结构化管理
核心角色	协议 / 接口标准	架构设计模式
关注点	我能调用哪些外部能力	我怎么组织自己的执行逻辑
类比	USB 接口标准	工作手册 / SOP

用一个场景感受区别

假设你在开发一个 AI 代码助手，需要它能读取 GitHub 上的代码，然后做 Code Review。

MCP 负责的部分：
怎么连上 GitHub？通过 MCP，GitHub 提供了标准化的 MCP Server，你的 Agent 直接接入，就能调用"读取仓库文件"、"获取 PR 详情"等能力。这一层解决的是连接问题。

Agent Skill 负责的部分：
拿到代码之后，Agent 怎么做 Review？按什么维度审查？输出什么格式？这些执行逻辑封装在 code-review 这个 Skill 的 Instruction 里，需要的时候加载进来，指导 Agent 完成任务。这一层解决的是执行问题。

两者在这个场景里是配合关系：MCP 把数据取回来，Skill 告诉 Agent 拿着这些数据该怎么办。

它们可以组合使用

这是很多人没意识到的一点——Agent Skill 的 Resources 层，完全可以挂载通过 MCP 连接的外部工具。

code-review Skill
├── metadata.yaml
├── instruction.md          ← 告诉 Agent 怎么审查代码
└── resources/
    ├── security_rules.json
    └── github_mcp_tool     ← 通过 MCP 连接的 GitHub 工具

Skill 定义了"做什么、怎么做"，MCP 提供了"用什么工具去做"。

总结

• MCP 是协议层，解决 AI 和外部世界的连接标准化问题，让工具接入变得可复用、可互操作
• Agent Skill 是架构层，解决 Agent 自身执行能力的组织问题，让复杂任务的处理更稳定、更可维护
• 两者不是竞争关系，而是不同层次的解决方案，实际项目里经常组合使用

如果你在做 Agent 开发，MCP 帮你解决"接什么"，Skill 帮你解决"怎么做"，搞清楚这个分工，架构设计会清晰很多。

做 Agent 开发一段时间后，大部分人都会遇到同一个问题：

Prompt 越写越长，模型执行越来越飘。

你把所有规范、流程、示例一股脑塞进系统 Prompt，token 蹭蹭涨，模型的注意力却被稀释了——它在"同时看着"几十件事，结果每件事都做得不够准。

Agent Skill 就是在解决这个问题。

核心思路：按需加载

把不同能力拆成独立的"技能包"，Agent 根据当前任务，只加载需要的那一个。

就像你电脑装了几十个软件，但你只打开当前要用的那个，其他的不占内存。

Context Window 就是 Agent 的"内存"，留给当前任务的空间越干净，执行越稳定。

一个 Skill 的三层结构

第一层：Metadata（元信息）

技能的"身份证"——叫什么、能干什么、什么时候触发。

name: code-review
description: 审查代码，识别安全风险、逻辑问题、性能瓶颈
triggers:
  - "帮我看一下这段代码"
  - "review 一下"
input:
  - code_snippet: string
output:
  - review_report: string

Metadata 很轻，系统可以把所有技能的 Metadata 一起加载，让 Agent 先选用哪个技能，而不需要把完整内容全暴露出来。

第二层：Instruction（执行指令）

真正告诉 Agent "这件事怎么做"，只在执行这个技能时才加载进上下文。

## Code Review 执行指南

按优先级审查以下维度：
1. 安全性：SQL 注入、XSS、敏感信息硬编码 → 标记 [HIGH]
2. 逻辑正确性：边界条件、空值处理、并发问题
3. 性能：循环内重复计算、不必要的数据库查询
4. 可读性：命名是否清晰，复杂逻辑是否有注释

每条问题注明 [HIGH/MEDIUM/LOW]，说明位置、问题、修改建议。

第三层：Resources（外部资源）

有些技能执行时还需要额外的东西：规则库、模板、脚本、外部工具调用等。这些放在 Resources 层，Agent 按需拉取，用完即走。

/skills/code-review/
  metadata.yaml          ← 索引，常驻
  instruction.md         ← 执行时加载
  resources/
    security_rules.json  ← 按需拉取
    review_template.md

三层各司其职

层级	作用	加载时机
Metadata	技能索引，用于路由选择	始终在上下文
Instruction	执行指南，指导 Agent 行为	技能被选中时
Resources	外部数据/脚本/模板	执行过程中按需

这就是所谓的渐进式披露——信息随执行进度逐步展开，而不是一开始全部堆在上下文里。

设计 Skill 时最容易踩的坑

粒度问题。 一个技能对应一个完整的用户意图，不要太粗也不要太细。

code-review ✅ 对应"帮我 review 代码"这个完整意图
backend-development ❌ 太粗，一个技能管了太多事
check-variable-naming ❌ 太细，组合起来很麻烦

描述要精准。 Agent 靠 Metadata 的 description 来判断用不用这个技能，描述模糊就容易选错。

---

举例

比如我们现在需要生成一个视频，但是并不知道怎么做，这时候可以借助这个skill，skills.sh/vercel-labs…，我们把这个 skill 安装到本地

npx skills add https://github.com/vercel-labs/agent-skills --skill vercel-react-best-practices

然后直接向 ai 提问，ai 会自动寻找这个 skill，并利用这个skill生成视频

帮我生成一个前端行业报告，使用remotion-best-practices这个skill

可以看到 ai 最后直接帮我创建了一个前端项目

执行看看效果，为了较少大小，我调整为4倍速，可以看到效果还不错，这个就真的像一个视频编辑器一样, 如果不借助 skill，恐怕很难实现这个效果。

写在最后

Agent Skill 的本质是对执行能力的结构化管理。

三层结构解决的问题很实际：让 Context Window 里只出现当前任务需要的内容，让模型更专注，执行更稳定，技能库更好维护。

规模小的时候感受不明显，一旦你的 Agent 需要处理十几二十种不同任务类型，这套结构的价值就很清楚了。