Skills vs. MCP同一个 Agent 项目里到底该用哪个最近后台收到不少类似的留言有人在 Claude Code 里配了 MCP Server 连接数据库转头又看到社区在推各种 “Skills”点进去发现是一堆 Markdown 文档就有点懵了——这两个东西到底是不是一回事如果我都想做是不是要先学两套东西先说结论Skills 和 MCP 不是同一个层级的概念也不是替代关系。一个偏“怎么做事”一个偏“接通外部世界”。但在实际项目里两者的边界确实容易被模糊掉甚至有不少项目会同时用到两者。这篇文章会用一套对比框架把 Skills 和 MCP 的关系、适用场景、配置方式讲清楚然后给出一个可以直接套用的决策清单。如果你正在做 Agent 相关的工程化落地或者刚接触 Claude Code、Codex、Dify 这类支持 Skills / MCP 的平台这篇文章会帮你少走不少弯路。1. 为什么大家会搞混 Skills 和 MCP搞混的根源在于两者都在解决“Agent 能力扩展”的问题而且表现形式上也越来越像。MCPModel Context Protocol模型上下文协议出现得早一些核心思路是让 Agent 通过一套标准化的协议动态调用外部工具、读取外部数据。很多人第一次接触 MCP是在配置数据库查询、连 Figma 设计稿、或者给本地 IDE 接 Playwright 的时候。Skills 则是最近随着 Claude Code 等工具火起来的另一种能力扩展方式。它本质上是一组结构化的 Markdown 文档里面写了某类任务的具体步骤、约束、示例让 Agent 在遇到特定场景时“按手册做事”。举个例子MCP 像给 Agent 安排了一个“文件系统读写接口”Agent 说“帮我读一下config.json”接口就返回内容。Skills 像给 Agent 发了一本《文件处理规范手册》里面写明了“处理配置文件时先做备份、再修改、最后校验格式”。一个是接口一个是流程指导听起来挺清晰。但问题是不少 Skills 也会写“调用哪些工具”“读哪个接口”不少 MCP Server 也会返回“建议的处理步骤”。一旦到了实践层面两者就会产生交叠。所以文章的核心任务不是给它们排一个高低而是帮你建立一套判断标准这个需求到底应该做成 Skills还是做成 MCP Server。2. 基础概念先用一个项目场景理解两者为了避免变成纯概念贴我们用同一个项目场景来对比。假设你在做一个“前端项目代码审查 Agent”它需要完成以下任务理解团队规范比如“组件文件必须用 TypeScript”“样式必须走设计系统 token”。读取目标项目的文件树找到src/components目录下的组件文件。调用 ESLint 检查代码规范。读取设计稿对比前端实现是否还原。现在把任务拆给 Skills 和 MCPSkills 负责的部分Skills 是“显式提供给 Agent 的知识包”。团队规范、审查流程、常见问题清单这类内容很适合放进 Skills。Agent 在收到审查任务时会去加载对应的 Skill 文档然后按照里面定义的步骤来执行。一个典型 Skill 可能是这样的--- name: frontend-review-workflow description: 前端代码审查流程适用于 React / Vue 项目 --- # 前端代码审查流程 ## 审查步骤 1. 读取项目 package.json确认技术栈。 2. 检查 src/components 目录结构。 3. 运行 eslint 检查记录错误级别。 4. 对照团队规范检查命名、样式、状态管理。 ## 强制要求 - 组件文件名必须使用 PascalCase。 - 禁止在组件内直接使用 window 全局对象。这段内容不需要连接任何外部系统它是“知识”和“流程”。MCP 负责的部分MCP 是“Agent 与外部系统之间的连接通道”。ESLint 工具本身、文件系统读取能力、设计稿数据源这些都适合通过 MCP Server 暴露给 Agent。Agent 的对话流程可能是这样Agent 判断需要: 读取 src/components/Button.tsx - 调用 fs_mcp_server.read_file({ path: src/components/Button.tsx }) Agent 判断需要: 检查 ESLint 规范 - 调用 lint_mcp_server.run_eslint({ path: src/components })MCP 让 Agent 拥有了“动作能力”但它本身不决定“Agent 应不应该做这个动作”。这个例子能看出最核心的区别了MCP 回答的是“能做什么”。Skills 回答的是“应该怎么做”。3. 核心差异从五个维度看 Skills 和 MCP这里用一张表来对比两者在工程实践中的差异对比维度SkillsMCP本质结构化的指令 / 知识文档标准化工具调用协议运行时嵌入在模型上下文中加载独立进程 / 服务通过协议交互数据来源文档内置静态知识外部系统实时数据扩展成本低写 Markdown 即可较高需要开发 Server 端动态性固定流程按需加载可实时交互有状态更新频率随文档更新随服务端逻辑更新适合场景团队规范、任务流程、提示词模板数据库查询、API 调用、文件系统、浏览器控制上手门槛几乎为零会写 Markdown 就行需要了解协议、JSON-RPC、Client/Server 模式这张表的核心信息用一句话概括就是Skills 是“软的”MCP 是“硬的”。Skills 改变 Agent 的判断和决策方式MCP 改变 Agent 的能力边界。再补充一个容易踩坑的点有些团队以为“MCP 能替代 Skills”于是什么逻辑都往 MCP Server 里塞结果 Server 端代码越来越重变成一个“拿着 HTTP 协议的工具箱”。实际上MCP Server 更适合做轻量、高频、通用性强的能力而重业务流程、多步骤决策、上下文相关的判断放在 Skills 里更合适。4. 什么时候用 Skills三个典型场景4.1 场景一团队规范与代码审查这是目前社区里使用最广泛的 Skills 场景。以前Agent 的能力取决于模型本身的训练数据。但团队内部规范通常不在训练数据里比如“接口返回必须包ResultT结构”“数据库表名必须带业务模块前缀”。这些如果写进系统提示词上下文会被撑爆每次对话都重复传入既不经济也不稳定。最好的方式就是做成 Skill让 Agent 在需要时主动加载。在 Claude Code 中Skill 目录通常长这样.skills/ frontend-review/ SKILL.md api-design/ SKILL.md database-naming/ SKILL.md每个目录就是一个 SkillSKILL.md是入口文件里面用 YAML front matter 写元信息正文写具体步骤。模型会在任务匹配时加载对应文档。4.2 场景二重复性任务模板比如“从需求文档生成 API 接口定义”这件事看起来简单但实际流程有几步解析需求文档中的功能点。梳理实体关系。生成 RESTful 接口路径。定义请求 / 响应 DTO。输出 OpenAPI 3.0 规范文件。这整套流程非常适合沉淀为 Skill。团队里任何人都能维护这份文档不需要写代码。新模型接入时只要它能读 Markdown就能复用这套流程。4.3 场景三模型能力增强提示词有些 Skill 并不包含团队业务逻辑而是用来弥补模型在某类任务上的通用短板。比如“代码重构”技能它会告诉 Agent重构前先建立测试基线。小步提交每次只改一个行为。重构后对比测试覆盖率。这种文档能显著提高 Agent 在复杂任务上的稳定表现。因为模型没有天生的“工程严谨性”但可以通过 Skill 注入。适合用 Skills 的判断标志内容是相对稳定的知识 / 流程。不需要实时读取外部数据。希望非开发人员也能维护。希望新模型接入时零成本复用。5. 什么时候用 MCP三个典型场景5.1 场景一数据库访问问一个高频点Agent 能不能直接查数据库答案是可以的但前提是提供 MCP Server。比如 WorkBuddy 通过 MCP 直接访问数据库本质上就是 MCP Server 把数据库连接封装成了标准工具接口模型收到用户提问后调用query_database这个工具服务端执行 SQL 并返回结构化结果。这种场景用 Skills 就完全无法覆盖因为 Skills 是静态文档它不能维护数据库连接、不能做 SQL 执行、也不能处理动态返回的分页数据。5.2 场景二外部系统集成Figma MCP、蓝湖 MCP、支付宝 MCP这些是近期热门的典型。它们把外部系统的资源暴露给 Agent。前端开发场景里Agent 可以直接通过 Figma MCP 获取设计稿信息然后生成还原代码——这比人工截图、切图、量尺寸再写代码的路径短得多。如果设计稿数据是实时变化的那么 MCP 是唯一合理的选择。Skill 无法承载动态连接它只能告诉 Agent“设计稿在哪里”“怎么通过 MCP 工具去获取”。5.3 场景三浏览器自动化与测试Playwright MCP、Selenium MCP 这类方案让 Agent 可以像人一样操作浏览器完成页面截图、点击、填写表单、检查控制台报错等操作。在测试场景里Agent 可以自动打开页面、复现 bug、收集错误日志再配合 Skill 里的测试规范判断哪些问题是真正需要修复的。适合用 MCP 的判断标志需要实时数据。需要动态操作外部系统。需要与既有服务集成而不是新写一套逻辑。需要复用生态里已有的 Server而不是从零开发。6. 混合架构真实项目里两个怎么协作实际落地时很少只选一种。更常见的组合方式是Skills 负责“决定怎么做”定义流程、规范、约束条件。MCP 负责“动手做”提供数据访问、工具调用能力。Agent 负责“编排”在运行时动态决策先读 Skill 文档再调用 MCP 工具执行。用一个具体例子来看完整链路假设你在 Claude Code 里接入了“支付宝 MCP”同时安装了“对账流程 Skill”。用户提问“帮我检查一下今天电商订单的对账情况。”执行链路Agent 识别到“对账”这个任务加载order-reconciliationSkill。Skill 文档告诉 Agent先查询订单总量再对比支付渠道流水最后输出差异报告。Agent 调用alipay_mcp的query_transactions工具获取今日流水。Agent 调用database_mcp的query_orders工具获取本地订单数据。Agent 按照 Skill 文档里的报告模板生成最终结论。在这个链路里Skills 和 MCP 缺一不可。没有 SkillAgent 不知道该按什么步骤做没有 MCPAgent 没有数据来源。这个协作模式在 Dify、Codex、OpenCode 等平台上也成立。Dify 支持添加本地 MCP 服务也支持加载 Agent SkillsCodex 近期也在补全 Skills 支持。可以预见未来主流的 Agent 工程化项目大概率都是“Skills MCP”的混合形态。7. 实操示例在 Claude Code 里同时挂载两者下面给出一个最小可运行的示例让你直观感受配置差异。7.1 安装一个 Skill在 Claude Code 中可以用命令从本地目录安装# 把本地 skills 目录链接到 Claude Code claude skill add ./my-skills/frontend-reviewmy-skills/frontend-review/SKILL.md内容示例--- name: frontend-review description: 前端代码审查技能检查组件命名、TypeScript 使用和样式 token 合规性。 --- # 前端代码审查 ## 执行步骤 1. 识别项目中所有 .tsx 文件。 2. 检查文件名是否使用 PascalCase。 3. 检查是否使用了禁止的 any 类型。 4. 检查样式是否引用了设计系统 token。 ## 输出格式 使用表格输出问题列表包含文件路径、问题类型、严重程度、修改建议。安装完成后可以在会话中这样验证claude --skill frontend-review --task 审查 ./src 下的组件代码预期效果是Agent 会先读取 Skill 文档然后按照步骤执行审查流程。7.2 创建一个最小 MCP ServerMCP Server 本质是一个 JSON-RPC 服务。这里用官方 SDK 的简化示例创建一个返回系统时间的 Server。// 文件路径src/time-server/index.ts import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new McpServer({ name: time-server, version: 1.0.0, }); server.tool( get_current_time, 获取当前系统时间, {}, async () { const now new Date().toISOString(); return { content: [{ type: text, text: 当前时间: ${now} }], }; } ); async function main() { const transport new StdioServerTransport(); await server.connect(transport); } main();7.3 配置 MCP 到 Claude Code{ mcpServers: { time-server: { command: node, args: [path/to/src/time-server/index.js] } } }配置完成后在 Claude Code 会话中提问“现在几点”Agent 就会调用get_current_time工具并返回结果。对比两个配置过程你会发现Skills 安装是“放文档”MCP 配置是“起服务”。前者是一步到位后者需要维护进程和通信。8. 常见问题与排查思路问题现象可能原因排查方式解决方案Agent 没有加载 SkillSkill 元信息中 description 与任务不匹配检查 SKILL.md 的 description 是否包含关键任务词完善 description 关键词让模型能准确匹配Skill 加载后行为不稳定文档步骤不够明确存在歧义检查步骤是否可验证、有无明确输出格式使用清单式步骤 示例减少开放描述MCP Server 启动失败依赖未安装或 SDK 版本不兼容查看终端报错、检查 package.json统一 SDK 版本重新安装依赖MCP 工具返回超时服务端处理慢或网络受限检查服务端日志测试单独调用增加超时配置优化服务端性能上下文过大导致异常同时加载过多 Skill / MCP 会话数据检查是否有“已进行多次自动总结但仍超限”提示精简 Skill 内容清理历史会话必要时只加载当前需要的能力分不清该用哪个项目里两者边界模糊用“静态知识还是动态调用”这个标准判断静态知识放 Skills动态能力放 MCP9. 最佳实践与工程建议9.1 命名与目录规范Skills 目录建议按领域划分不要把所有技能堆在一个目录下。.skills/ >