MCP 与 Skills 入门指南MCP 与 Skills 入门指南 1. 先讲结论如果你想让 Agent 更稳定、更

MCP 与 Skills 入门指南

1. 先讲结论

如果你想让 Agent 更稳定、更像一个可工程化的系统，最常见的两个抓手就是：

MCP：把外部能力接成标准工具接口
Skills：把一类任务的工作方法写成可复用操作规程

可以把它们简单理解成：

MCP 解决的是“Agent 能调用什么能力”
Skills 解决的是“Agent 遇到某类任务时应该怎么做”

一句话区分：

MCP 更偏“能力接入层”，Skills 更偏“任务方法层”。

2. MCP 是什么

MCP 可以理解成一种让模型安全、结构化调用外部资源和工具的协议层。

它的核心目标不是“多高级”，而是把下面这些东西标准化：

工具怎么暴露给 Agent
工具的输入输出是什么
哪些资源可以被读取
Agent 怎么在推理过程中按需调用它们

2.1 你可以把 MCP 想成什么

把它想成“给 Agent 接 USB 接口”会比较直观。

Agent 本身会理解、规划、生成，但它默认不直接拥有这些能力：

查数据库
读某个业务系统里的文档
调公司内部接口
执行某个固定脚本
访问某类外部服务

MCP 做的事，就是把这些能力包装成统一接口，让 Agent 能按规则调用。

2.2 MCP 常见会接什么

工具：例如查工单、跑测试、生成代码、调用接口
资源：例如文档、知识库、配置、数据库 schema
模板化资源：例如“传一个参数就能取某个模块文档”

2.3 MCP 最小关注点

一个最小可用的 MCP 工具，通常只要说清楚三件事：

这个工具叫什么
它接收什么输入
它返回什么输出

也就是说，MCP 更强调：

接口清晰
输入输出结构化
能被 Agent 稳定调用

它不负责替你定义“遇到某类任务的完整策略”。

3. Skills 是什么

Skill 可以理解成写给 Agent 的“任务说明书”或“可复用工作流”。

它的重点不是暴露新工具，而是减少 Agent 每次都从零规划的成本。

一个 Skill 通常会规定：

在什么场景下使用
先看什么上下文
优先用哪些工具
步骤怎么走
输出结果要长什么样
哪些事不要做

3.1 Skill 的本质

Skill 不是单纯的“输入 -> 输出模板”，而是：

输入 + 决策规则 + 执行步骤 + 输出要求 + 约束

所以它真正提供的是：

稳定的方法
收敛的规划空间
一致的产出风格

3.2 为什么 Skill 有用

如果没有 Skill，Agent 每次都要重新判断：

该先搜代码还是先问用户
该用哪个工具
结果应该怎么汇报
改动范围控制到哪里

如果这些决策每次都重来，效率和稳定性都会下降。

Skill 的价值就是把高频决策前置固化。

4. MCP 和 Skills 的区别

最容易混的点是：它们都在帮 Agent 做事，但职责不同。

4.1 一句话版

MCP：提供能力
Skills：规定方法

4.2 对比表

维度	MCP	Skills
核心作用	接入工具/资源	固化任务流程
关注点	能做什么	应该怎么做
形式	协议、工具、资源接口	Markdown 说明、流程约束
输入输出	强调结构化 schema	强调执行步骤和产出要求
解决的问题	外部能力调用	任务执行稳定性
适合沉淀什么	查数据、调系统、跑脚本	代码修改、文档撰写、评审流程

4.3 一个具体例子

假设你要做“读取 TAPD 用例，匹配接口，生成测试脚本”。

那么你可以这样拆：

MCP Tool
- 下载 TAPD 数据
- 读取 OpenAPI CSV
- 调用 Python 匹配脚本
- 写出 JSON 结果
Skill
- 遇到“测试脚本生成”任务时，先收集哪些输入
- 先做匹配再做骨架生成
- 输出时要包含哪些文件、风险、验证结果
- 如输入不完整要如何降级处理

所以：

MCP 负责“手脚”，Skill 负责“做事的方法”。

5. 什么时候该写 MCP，什么时候该写 Skill

这是最实用的一段。

5.1 适合写 MCP 的场景

当你发现某个能力是“确定性动作”，而且将来可能被很多任务复用，就适合做成 MCP。

典型特征：

输入输出边界清楚
不太依赖长篇推理
本质上是调用程序、接口、脚本、数据库、文件系统
多个 Agent 或多个任务都可能复用

例如：

根据工单号查询详情
执行自动化测试
读取某目录下的 API 定义
调用已有脚本生成报表

5.2 适合写 Skill 的场景

当你发现某类任务总在重复，而且步骤比较稳定，就适合写 Skill。

典型特征：

用户描述相似
处理步骤相对固定
输出标准比较明确
你总是在重复补同样的说明

例如：

做 code review
改一个现有页面
写一篇技术说明文档
对接 OpenAI API 并给最小示例

5.3 同时需要两者的场景

大部分真正有价值的 Agent 系统，都是两者一起用。

常见组合方式：

用 MCP 提供能力
用 Skill 规定使用这些能力的顺序和边界

也就是：

MCP 是底座，Skill 是工作流。

6. 自己写 Skill，最小结构怎么设计

如果你要自己写一个 Skill，建议先用最小六段式，不要一开始写得很复杂。

6.1 最小结构

Purpose
When To Use
Inputs
Process
Outputs
Constraints

6.2 每一段写什么

Purpose

说明这个 Skill 解决什么问题。

例子：

“用于在现有项目中完成中小型代码改动，并做最小验证。”

When To Use

说明什么时候触发，避免乱用。

例子：

“当用户要求修改已有功能、修复局部问题、补充小范围文档时使用。”

Inputs

说明执行前需要哪些上下文。

例子：

用户需求
目标文件或模块路径
技术栈
是否允许改接口或数据库
验证命令

Process

写稳定流程，不要写成口号。

例子：

先定位相关文件和入口
阅读现有实现和依赖关系
以最小改动完成需求
必要时补测试或保护逻辑
运行验证
汇报改动和风险

Outputs

规定最后必须交付什么。

例子：

已完成的改动
涉及文件
验证结果
剩余风险

Constraints

定义边界，避免失控。

例子：

不重构无关代码
不擅自修改用户未要求的行为
优先复用已有模式
如果高风险就先停下来说明

6.3 一个最小 Skill 模板

# Skill Name

## Purpose
这个 skill 用来解决什么问题。

## When To Use
在什么场景下触发。

## Inputs
- 用户需求
- 相关文件或模块
- 技术约束
- 验证方式

## Process
1. 先定位上下文
2. 阅读现有实现
3. 在最小改动范围内完成任务
4. 运行验证
5. 汇报结果与风险

## Outputs
- 改动结果
- 相关文件
- 验证结果
- 风险说明

## Constraints
- 不改无关模块
- 不做未授权重构
- 优先复用现有方案

6.4 判断 Skill 写得好不好

一个好 Skill 至少满足这几个标准：

触发条件清楚，不会被乱用
步骤稳定，换个相似任务也能复用
输出明确，不会答非所问
约束清楚，不会越做越大
不依赖隐含常识，别人接手也能看懂

7. 自己写 MCP，最小结构怎么设计

写 MCP 时，不要先想着“协议多复杂”，先把工具抽象对。

7.1 最小结构

一个 MCP Tool 最少要定义：

name
description
input schema
handler
output shape

7.2 每一段的重点

name

名字要一眼看懂用途。

例如：

query_tapd_case
run_local_tests
load_openapi_catalog

不要起成：

doTask
tool1
handleData

description

描述这个工具做什么、什么时候用。

重点是帮助 Agent 判断“该不该调它”。

input schema

把输入写清楚，而且尽量结构化。

例如：

{
  "caseId": "string",
  "projectId": "string",
  "includeSteps": true
}

handler

这里才是实际执行逻辑，比如：

查数据库
调 HTTP 接口
执行 shell 脚本
读文件

output shape

输出也要稳定。

例如不要一会儿返回字符串，一会儿返回数组，一会儿返回 null。

更好的方式是固定成：

{
  "success": true,
  "data": {},
  "error": null
}

7.3 一个最小 MCP Tool 设计模板

Tool Name: query_tapd_case

Description:
根据 caseId 查询 TAPD 用例详情，返回标题、前置条件、步骤和预期结果。

Input:
- caseId: string，必填
- projectId: string，可选

Output:
- success: boolean
- data:
  - id: string
  - title: string
  - preconditions: string[]
  - steps: string[]
  - expected: string[]
- error: string | null

7.4 判断 MCP 设计得好不好

名字是不是明确
输入是不是结构化
输出是不是稳定
工具是不是只做一件事
失败是不是能被明确处理

如果一个工具既查数据、又生成文档、又改文件、又发通知，通常就拆得不对。

8. 写 Skills 和 MCP 时最容易犯的错

8.1 Skill 写得太空

坏例子：

“收到需求后分析并完成任务，最后输出结果。”

这等于没写，因为没有任何可执行约束。

正确做法是写清楚：

先查什么
再做什么
如何控制范围
如何验证

8.2 Skill 写得太死

坏例子：

“必须先读 A 文件，再读 B 文件，再读 C 文件……”

如果任务稍微变化，这个 Skill 就失效了。

正确做法是固化原则和主流程，不要把每一步都写成机械脚本。

8.3 MCP 工具职责太大

坏例子：

“一个工具完成从读取需求到生成代码再到部署上线。”

这会导致：

难复用
难调试
失败点不清楚

正确做法是按确定性动作拆开。

8.4 输入输出不稳定

这是最常见也最伤的错误。

今天返回字符串，明天返回对象，后天字段又改名，这样 Agent 很难稳定消费。

MCP 工具尤其要避免这个问题。

9. 一个推荐的落地顺序

如果你现在要自己搭一套 Agent 能力，建议按这个顺序来，不要反过来。

第一步：先挑高频任务

先找你最常重复的一类任务，比如：

改现有页面
做代码审查
生成测试脚本
对接某类接口

第二步：先写 Skill

先把这类任务的稳定流程写出来。

因为大多数时候，真正缺的不是工具，而是“怎么做更稳”。

第三步：再抽 MCP

当你发现 Skill 里反复依赖某些确定性动作，再把它们抽成 MCP Tool。

例如：

查某类文档
跑某个脚本
取某个系统的数据

第四步：持续收敛

每做几次任务，就回头看：

哪些步骤是重复的
哪些工具还不稳定
哪些输入输出应该标准化

Skill 和 MCP 都不是一次写完，它们是随着任务密度逐步长出来的。

10. 一套实用心法

如果你只记三句话，记这三句就够了：

Skill 先解决“怎么做”
MCP 再解决“能调用什么”
先做最小可用，不要一开始设计大而全体系

更工程化一点地说：

重复决策，沉淀成 Skill
重复动作，抽象成 MCP Tool

这就是它们最实用的分工。

11. 你现在就可以怎么开始

如果你想自己练手，建议从下面两个最小练习开始。

练习 1：写一个 Skill

题目：

“写一个用于代码修改任务的 Skill。”

要求至少包含：

触发条件
输入
执行步骤
输出
约束

练习 2：写一个 MCP Tool 设计稿

题目：

“设计一个根据 caseId 查询测试用例详情的 MCP Tool。”

要求至少包含：

名称
描述
输入
输出
错误处理方式

如果这两个你能写顺，后面再继续扩展就很自然了。

12. 最后一句总结

MCP 是给 Agent 接能力，Skills 是给 Agent 定方法。

前者让它“能做更多事”，后者让它“做事更稳定”。

真正好用的 Agent，通常不是只靠其中一个，而是两者配合。