Agent 开发系列 · 03

Skill 与 MCP:让 Agent 变强的两种方式

给 AI Agent 加能力,有两条主流路径:Skill(教它怎么做)和 MCP(给它新工具)。 很多人分不清该用哪个。本教程讲清区别、给出决策标准,并拆解真实 Skill 的结构。 示例直接取自本机正在使用的 Agent 技能库。

难度 ★★☆☆☆约 25 分钟2026.08

01Skill 和 MCP 的区别

一句话区分: Skill 是「操作说明书」,改变模型的行为方式; MCP 是「新接口」,给模型提供原本没有的能力。

两种能力的本质差异

SkillMCP
本质 知识 + 流程:告诉模型「遇到这类任务,按这个步骤做」 通道 + 动作:告诉模型「你可以调用这个工具,它真能做事」
载体 Markdown 文档(SKILL.md)+ 可选脚本/模板/参考文件 一个可执行进程(Python/Node 等),通过 stdio 或 HTTP 通信
运行位置 模型「读进去」的上下文,不产生外部副作用 独立进程,真实操作外部世界(文件、网络、服务器)
给模型什么 步骤、规范、示例、禁忌——提升回答质量 工具列表 + 参数 schema——扩展能力边界
典型例子 「写中文技术文档用这套排版规范」「遇到 bug 先按五步排查」 「查服务器磁盘」「发飞书消息」「执行 nginx -t」

打个比方

Skill = 给新员工培训手册
  • 教他公司的行文规范、审批流程、禁忌事项
  • 手册本身不干活,但员工读了活干得对
  • 内容越具体,执行越稳定
MCP = 给员工配新工具
  • 给他一台服务器、一个数据库客户端、一部电话
  • 工具真能产生外部效果,也能造成外部破坏
  • 能力越强,越需要安全护栏
▎两者常常配合使用 一个 MCP server 提供「能查服务器」的工具,一个 Skill 教模型 「部署前先备份、验证用哪几个命令、回滚怎么走」——工具负责能做什么, Skill 负责该怎么做。本系列第一篇的 chengdu-mcp(23 个服务器运维工具) 就是这种配合的实例。

02哪些做 Skill,哪些做 MCP

决策表:拿到需求先过这四个问题

问题答「是」→ 倾向答「否」→ 倾向
需要真实操作外部系统吗?(写文件、发请求、跑命令) MCP(要通道) Skill(纯知识/流程)
核心价值是「教模型按什么套路做」吗? Skill(要行为规范) MCP
会被多个客户端 / 多种模型复用吗? MCP(协议标准,客户端通用) Skill(跟 Agent 框架绑定较紧)
能力是「稳定接口」还是「易变知识」? MCP(接口要稳) Skill(知识要常更新)

实战案例对照

需求该做什么理由
「帮我查一下服务器磁盘和 nginx 状态」 MCP 要真实执行命令、读远端文件,必须有通道
「写公众号文章按历史排版规范来」 Skill 是行为规范:查重规则、排版基线、发布流程,不碰新系统
「用公司内部 API 发审批」 MCP 稳定的外部接口,还要处理认证、错误码——封装成工具
「写代码前先写测试(TDD)」 Skill 纯流程规范,教模型按红-绿-重构套路走
「部署到服务器」 两者结合 MCP 提供 scp/nginx/备份工具;Skill 规定部署步骤与验证清单
▎最常见的误用 把「操作流程」硬写成 MCP 工具,或把「系统接口」硬塞进 Skill。 前者会让工具数量爆炸、每个工具都很「薄」;后者会让 Skill 里全是 「调用某 API 的命令」,换环境就失效。记住:工具是名词,Skill 是动词

03一个极简 Skill 示例(可落地)

一个 Skill 就是一个目录,核心文件是 SKILL.md(YAML frontmatter + Markdown 正文)。 以「部署前必须备份」为例——这个 Skill 的价值是让模型每次都记得先备份, 而不是偶尔记得:

backup-before-deploy/SKILL.md
---
name: backup-before-deploy
version: 1.0.0
description: "部署前必须备份。当用户要对线上站点/nginx 配置做任何修改、覆盖、回滚、升级时使用。不负责执行部署本身。"
metadata:
  requires:
    bins: ["ssh"]
---

# 部署前备份(强制)

**触发条件**:模型检测到用户要对线上资源做写操作(覆盖文件、改 nginx 配置、
重启服务、升级版本)时,无论用户是否主动要求,都必须先走本 Skill。

## 步骤

1. 确认目标路径属于可备份范围(站点目录 / nginx conf.d / 数据库文件)。
2. 执行备份,命名带时间戳:
   ssh chengdu "cp -a /var/www/zhugdamo_cn/site /root/backups/site-$(date +%Y%m%d_%H%M%S)"
3. 校验备份确实生成(ls 确认存在、体积合理),备份失败立即中止部署。
4. 向用户报告备份路径,再继续部署。

## 禁忌

- 绝不在没有备份的情况下覆盖线上文件。
- 备份失败 ≠ 继续部署,必须停下。

## 验证

部署完成后,把新文件与备份 diff 一遍,确认改动符合预期。

关键点

要素示例里在哪为什么重要
触发条件frontmatter description + 正文第一段让模型在「用户没明说」时也能主动想起用这个 Skill
编号步骤## 步骤 1-4模型对编号步骤的执行率远高于散文描述
禁忌(负面约束)## 禁忌只讲「怎么做」不够,要讲「什么不能做」
验证环节## 验证闭环:做完还要确认做对了

04常见 Skill 代码分析

下面拆解的是生产级 Skill 的完整结构(取自本机技能库中真实在用的 lark-approval 等技能,它们服务日常飞书审批等真实任务)。

4.1 frontmatter:给调度器看的元数据

---
name: lark-approval
version: 1.2.0
description: "飞书审批:查询和处理审批待办/已办/实例……当用户要处理审批任务、查看审批实例、搜索或发起审批时使用。审批待办不是飞书任务;非审批类待办走 lark-task。不负责创建审批定义;三方审批定义不走原生提单。"
metadata:
  requires:
    bins: ["lark-cli"]
  cliHelp: "lark-cli approval --help"
---
字段作用
name唯一标识,目录名保持一致
version语义化版本,改内容要升版本
description最重要的字段——Agent 靠它决定「什么时候加载这个 Skill」。要写清触发场景、边界(什么情况用它)
metadata.requires.bins前置依赖声明,缺了工具直接提示安装
▎description 是给「检索」看的 模型不是每次把所有 Skill 都读一遍,而是先扫描 description 决定加载谁。 写得模糊(「处理审批」)会被漏掉;写得具体(含触发词、排除边界) 才会在正确时机被想起。这个字段值得花最多心思。

4.2 正文:路由规则放最前

**CRITICAL — 开始前 MUST 先用 Read 工具读取 [`../lark-shared/SKILL.md`](../lark-shared/SKILL.md),
其中包含认证、权限处理**

所有命令默认 `--as user`(审批是人的动作)。调用前先按需读取 references 下对应的文件,
查参数结构,不要猜字段;**references 是第一信息源**……

## 路由优先级(先判断是不是审批,再选命令)

审批待办不是飞书任务。**只要用户的核心对象是审批单据 / 审批待办 / 审批实例,
就优先使用 `lark-approval`,不要让渡给 `lark-task`。**

### 明确归 `lark-approval` 的高优先级语义
- 审批待办 / 审批单据 / 审批实例 / 审批意见 / 审批定义
- 同意 / 拒绝 / 转交 / 退回 / 撤回 / 催办 / 加签 / 抄送
……

**判定规则:** 只要最终动作是对审批单据做同意、拒绝、转交……就归 `lark-approval`。
只有当用户处理的是**非审批类任务/待办**时,才走 [`lark-task`](../lark-task/SKILL.md)。

4.3 生产级 Skill 的共性结构

结构作用
CRITICAL 前置说明必须先读的共享前置(认证、通用规则)用粗体 + MUST 强调,模型不会跳过
路由优先级多个 Skill 边界重叠时,写清「什么情况归我、什么情况让给谁」
References 引用大参数表、完整命令清单放 references/ 目录,正文保持短——正文太长模型会「读不完」
「不要猜字段」明确禁止模型凭记忆编参数,强制查 reference——这是减少幻觉的关键指令
判定规则把「是/不是」的边界写成可判定的清单,而不是模糊描述

4.4 Skill 还能带什么

my-skill/
├── SKILL.md          # 主文档:触发条件 + 步骤 + 禁忌 + 验证
├── references/       # 参数表、API 文档、完整命令清单(按需读取)
├── templates/        # 可直接套用的模板(报告、prompt、配置文件)
└── scripts/          # 可执行脚本(skill 可调用,如验证脚本、转换器)

05Skill 写作的三个常见坑

表现修法
正文写成散文 一坨长段落,模型执行时丢步骤 拆成编号步骤、表格、清单;一条指令一行
只写怎么做,不写不能做 模型在边界场景自由发挥,出错 专门写「禁忌」「不适用场景」小节
一更新就全量重写 版本混乱,老逻辑被误删 改内容升 version;用 patch 局部更新;沉淀「踩过的坑」小节
▎Skill 的维护原则 用的时候发现 Skill 过时、步骤缺失、命令错误,当场修掉(patch),不要等下次。 技能库是活文档——每次踩坑都是它变强的机会。判断标准: 一个流程第二次遇到时,就该考虑固化成 Skill 了。