在之前的 MCP 相关文章中，我们深入探讨了它在智能体中的作用。近期，由 Anthropic（Claude 的创造者）提出的 Skills 概念同样变得火热。那么，首先需要澄清的就是：MCP 和 Skills 到底有什么区别和联系？
MCP 和 Skills 的关系？
一、两者的区别
MCP（Model Context Protocol）本质是一种模型与外部系统交互的协议标准。而 Skills 则是被封装成“可直接调用能力单元”的工具能力。
| 维度 |
MCP |
Skills |
| 本质 |
协议标准，外部工具接口 |
能力封装，操作手册/提示词 |
| 解决问题 |
模型如何调用外部资源 |
模型具体能做什么 |
| 层级 |
基础设施层 |
应用能力层 |
| 面向对象 |
开发者 |
开发者 + 运营 + 普通用户 |
| 技术难度 |
高 |
中低 |
| 可视化程度 |
无 |
强 |
| 可组合 |
弱 |
强 |
| 商业化潜力 |
基础设施 |
极强 |
二、两者的联系
MCP 是底层连接机制，Skill 是上层能力产品化。未来的趋势非常明确：MCP 将逐渐隐藏，Skills 成为舞台上的主角。但这并非完全的取代关系。简单来说：Skills 让大模型做得更好，MCP 让 Claude 做得更多。两者可以结合使用，例如，用 MCP 获取 Google Drive 的文件，再用处理 docx 的 Skill 来高效处理它。
模型
↓
MCP（协议层）
↓
Tool / API
↓
Skill（能力封装）
↓
用户调用
+----------------------+ +----------------------+ +---------------------+
| User / Frontend | <---> | Orchestration Layer | <--->| Skill Registry |
| (web/app/cron/etc) | | (Agent Manager) | | (discoverable SKILL)|
+----------------------+ +----------------------+ +---------------------+
^ ^
| |
v v
+----------------------+ +----------------------+ +---------------------+
| LLM / Model Host | <--> | MCP Adapter / Proxy | <-> | Backend Services |
| (local or cloud) | | (auth， sandboxing) | | (DB， API， Scripts) |
+----------------------+ +----------------------+ +---------------------+
重要组件说明（架构层级）：
- LLM / Model Host：运行模型、决定调用 Skill 的主体（本地模型或云模型）。
- MCP Adapter / Proxy：协议适配、消息规范、输入/输出验证、限流与审计（MCP 在此处实现或被替代）。
- Orchestration Layer（Agent Manager）：调度 Skill、执行工作流、管理状态机与回滚。
- Skill Registry（能力市场/目录）：Skill 的元数据、权限、版本、用量计费与发现。
- Backend Services：真实执行单元（DB、第三方 API、脚本、容器化服务等）。
（注：不同厂商会在 MCP 与 Orchestration 的边界上有不同的实现侧重点。）
Skills 构建方式
从构建方式来看，主要分为两类：
- 源码方式（开发者模式）
- 界面方式（低代码/可视化方式）
虽然 Claude 最先提出 Skill 概念，但使用它有一定的门槛（例如账号问题）。幸运的是，现在其他大模型平台也逐渐支持了类似的能力。
| 平台 |
支持形态 |
主要能力（能做什么） |
接入方式（典型） |
私有化 / 企业适配 |
适合场景 |
| 百度 文心智能体 |
智能体/Agent 平台、低代码 + SDK + 能力包市场 |
智能体/Skill 编排、低代码 AgentBuilder、能力包（Skill）管理、接入检索/知识库 |
Web 控制台、API、能力包市场安装、SDK |
支持企业接入与私有化部署（企业能力包 & 权限管理） |
企业客服、行业智能体、知识型 Skill 快速落地。 |
| 腾讯 混元 |
大模型平台 + 插件/联网能力（SDK/API） |
混元模型接入、知识增强、插件/联网功能、生态整合（微信/小程序） |
云 API、SDK、云控制台、插件体系 |
企业云产品线支持私有化/专属实例与权限控制 |
需要与腾讯生态（内容，社交）整合的 Skill 场景 |
| 阿里 通义灵码 |
IDE + 编码智能体 + 插件市场（面向开发者的 Skill 工具化） |
代码生成/智能体/插件化能力，把代码或 API 快速包装成能力 |
Lingma IDE、云服务、插件市场 |
面向企业开发者友好，易与阿里云服务打通 |
开发者工具链内构建 Skill、工程化自动化能力 |
| 字节 Trae |
AI-native IDE / 平台（强调模型与插件） |
AI IDE、模型接入、多模型切换、支持 MCP/Skills（厂商叠加） |
IDE 插件、API、企业集成 |
面向产品/研发团队，企业版支持更深整合 |
代码相关 Skill、创作类 Skill、与字节内容生态集成的场景 |
| Dify |
开源 LLM 应用平台（低代码 + 工作流） |
应用/Skill 工作流编排、模板市场、支持私有化部署 |
部署到云/私有机房、REST API、工作流 UI |
强调开源 + 私有化（社区与企业部署案例） |
中小团队快速搭建自定义 Skill，LLM Ops 场景 |
| Flowise |
可视化工作流 / 节点式编排（基于 LangChain） |
节点拖拽式 Skill / Agent 编排，便于实验与原型 |
本地部署、Web UI、支持多模型后端 |
适合快速原型与 PoC，企业化需做扩展 |
快速搭建数据到能力的原型 Skill、教学与试验 |
| LangChain 生态 |
开源编排/SDK 生态（构建 Skills/Agent 的开发框架） |
强大的工具链（chains/agents/tools）、向量检索、插件化 |
SDK（Python/JS）、多后端接入 |
最灵活、最适合私有化/深度定制 |
需要高度定制化的企业级 Skill 与复杂编排 |
Claude Skills 最优实践总结
基于《The Complete Guide to Building Skills for Claude》整理
一、核心架构设计
三层渐进式披露（Progressive Disclosure）
这是整个 Skills 系统最关键的设计哲学：
| 层级 |
内容 |
加载时机 |
| 第一层 YAML frontmatter |
技能名称 + 描述 |
始终加载在系统提示中 |
| 第二层 SKILL.md 主体 |
完整指令和工作流 |
Claude 判断相关时加载 |
| 第三层 链接文件 |
references/ 详细文档 |
按需导航加载 |
设计目的：最小化 token 消耗，同时保持专业能力。
二、文件结构规范
your-skill-name/ ← kebab-case 命名，不能有空格/大写/下划线
├── SKILL.md ← 必须，大小写精确匹配
├── scripts/ ← 可选，Python/Bash 等脚本
├── references/ ← 可选，详细文档
└── assets/ ← 可选，模板/字体/图标
| 错误 |
正确 |
skill.md / SKILL.MD |
SKILL.md |
Notion Project Setup |
notion-project-setup |
skill 文件夹内放 README.md |
README 放仓库根目录 |
frontmatter 中用 < > XML 标签 |
禁止使用 |
| skill 名称含 “claude” 或 “anthropic” |
保留字，禁止使用 |
三、YAML Frontmatter 黄金写法
Description 公式：[做什么] + [何时使用] + [关键触发短语]
---
name: your-skill-name
description: >
做什么的简洁说明。Use when user mentions “具体词A”、
“具体词B”，or asks to “执行某操作”。
license: MIT
metadata:
author: YourName
version: 1.0.0
mcp-server: your-server
---
描述对比：
| 差 |
好 |
帮助处理项目。 |
管理 Linear 项目工作流，包括冲刺规划、任务创建和状态跟踪。当用户提到“冲刺”、“Linear 任务”，或要求“创建工单”时使用。 |
创建文档系统。 |
分析 Figma 设计文件并生成开发交接文档。当用户上传 .fig 文件，或询问“设计规范”、“组件文档”、“设计转代码交接”时使用。 |
实现带层级关系的项目实体模型。 |
PayFlow 端到端客户入驻流程，处理账户创建、支付设置和订阅管理。当用户说“入驻新客户”、“设置订阅”或“创建 PayFlow 账户”时使用。 |
核心原则： 必须同时包含 WHAT（做什么） + WHEN（触发条件/用户实际会说的词语），上限 1024 字符。
四、五种核心工作流模式
Pattern 1：顺序工作流编排
适用场景： 有严格步骤顺序的多步任务
Step 1 → 验证 → Step 2 → 验证 → Step 3 → 回滚机制
关键技巧：
- 每步之间声明依赖关系
- 每步验证通过后再继续
- 提供失败回滚指令
Pattern 2：多 MCP 协调
适用场景： 工作流跨越多个服务（如 Figma → Drive → Linear → Slack）
Phase 1: Figma MCP → 导出设计资产
Phase 2: Drive MCP → 存储并生成链接
Phase 3: Linear MCP → 创建开发任务
Phase 4: Slack MCP → 发送交接通知
关键技巧：
- 明确的阶段分隔
- 跨 MCP 的数据传递方式说明
- 集中错误处理逻辑
Pattern 3：迭代精炼
适用场景： 输出质量需要多轮迭代提升（如报告生成）
初稿生成 → 验证脚本检查 → 发现问题列表 → 修正 → 再验证 → 达到质量阈值后终止
关键技巧：
- 明确的质量判断标准
- 使用脚本做验证（确定性更高）
- 设置迭代终止条件，避免无限循环
Pattern 4：上下文感知工具选择
适用场景： 同一目标，根据上下文选择不同工具
判断文件类型/大小
├── >10MB → 云存储 MCP
├── 协作文档 → Notion/Docs MCP
├── 代码文件 → GitHub MCP
└── 临时文件 → 本地存储
→ 向用户解释选择原因
关键技巧：
- 清晰的决策树
- 提供备用方案
- 对用户透明地说明选择逻辑
Pattern 5：领域专业智能
适用场景： 嵌入特定领域知识（合规、法律、金融等）
获取数据 → [合规前置检查] → 通过则执行 / 不通过则标记审核 → 生成审计日志
关键技巧：
- 执行前先做合规/风险检查
- 完整记录审计日志
- 清晰的治理和审批流程
五、测试的三个维度
1. 触发测试（最重要）
应触发：直接表述 / 同义改写 / 不同措辞，各测一遍
不应触发：无关领域话题（天气、其他完全不同的任务）
调试技巧： 直接问 Claude「你什么时候会用 [skill名称]？」，它会把 description 复述出来，你就能看出哪里写得不够精准。
2. 功能测试
- 输出格式和内容是否正确
- API / MCP 调用是否成功
- 边缘情况和异常是否有处理
3. 性能对比（有/无 Skill）
| 指标 |
无 Skill |
有 Skill |
| 对话轮次 |
~15 轮 |
~2 轮 |
| API 调用失败次数 |
3 次 |
0 次 |
| Token 消耗 |
12，000 |
6，000 |
六、常见问题速查
| 症状 |
原因 |
解决方案 |
| Skill 不自动触发 |
description 太模糊 |
加入用户实际会说的触发短语 |
| Skill 触发太频繁 |
描述范围太宽泛 |
加负向触发词：Do NOT use for... |
| MCP 调用失败 |
连接/权限问题 |
先单独测 MCP，排除 skill 问题 |
| 指令不被遵循 |
关键步骤被淹没在正文中 |
用 ## CRITICAL 置顶关键指令 |
| 响应变慢/质量下降 |
SKILL.md 体积太大 |
详细内容移到 references/，主文件控制在 5000 词以内 |
| 上传报错 |
YAML 格式错误 |
检查 --- 分隔符是否完整，引号是否闭合 |
七、最优实践精华
设计阶段
- 先定义 2-3 个具体用例，再动笔写 SKILL.md
- 区分「问题优先」vs「工具优先」视角，选择合适的 Pattern
- 用结果而非功能描述 skill 价值
编写阶段
- Description = 用户说的话，而不是技术描述
- 关键指令置顶，次要细节放
references/
- 为每种常见错误写明：原因 + 解决步骤
- 确定性要求高的验证逻辑，用脚本而非语言描述（代码是确定性的，语言不是）
迭代阶段
- 先把一个复杂任务做到完美，再扩展覆盖更多场景
- 善用
skill-creator skill 生成初稿和评审
- Skill 是活文档，根据触发过多/过少的信号持续迭代
分发阶段
- GitHub 开源 + MCP 文档交叉链接
- 对外描述用价值语言：「节省 30 分钟手动配置」，而不是「包含 YAML frontmatter」
八、快速验证
开发前
- 已识别 2-3 个具体用例
- 已确定所需工具（内置或 MCP）
- 已规划文件夹结构
开发中
- 文件夹名为 kebab-case
- 文件名精确为
SKILL.md
- YAML 有
--- 开闭分隔符
name 字段：kebab-case，无空格，无大写description 包含 WHAT 和 WHEN- 无 XML 标签
< >
- 指令清晰可操作，包含错误处理和示例
- 详细文档放在
references/ 而非内联
上传前
- 测试：明显相关任务可触发
- 测试：改写措辞后仍可触发
- 测试：无关话题不触发
- MCP 工具调用正常（如适用）
上传后
- 在真实对话中测试
- 监控触发过多/过少
- 收集用户反馈
- 根据反馈迭代 description 和 instructions
一句话核心： Skill 的本质是“把你的领域经验和工作流程，结构化地教给 Claude 一次，之后每次都自动复用”。写好 description 让它能自动触发，写好 instructions 让它每次都能稳定执行，是成功的两大关键。
如果你想了解更多关于智能体开发、大模型平台选型或类似 MCP 协议的技术细节，欢迎到 云栈社区 的对应板块进行深入交流和探索。这里汇集了许多实战经验和开源项目，例如探讨如何利用 LangChain 生态构建更复杂的智能体工作流。
扩展阅读资源：
发表于 3 小时前
|
查看: 3|
回复: 0
