Skill 和 MCP 有什么区别？

先把“方法”和“连接”分开

Skill 更像办事说明书，告诉 AI 一类任务该怎么做； MCP 更像工具接口，让 AI 应用接上外部能力。 Agent 则负责结合任务，决定下一步并使用这些能力。

它们通常不是竞争关系。 你不必先选一个阵营，要先看自己缺的是方法、连接，还是两者都缺。

举个例子：让 AI 帮你处理 GitHub Bug

假设你说：“检查 GitHub 项目最近的 Bug，并整理成修复计划。”下面是帮助理解的工作流示例，不代表本站执行过这项任务，也不是在推荐安装 GitHub MCP。

只有 Skill：知道应该怎么处理

一份 Bug 处理 Skill 可以规定：

1. 先检查 Issue 标题。
2. 再阅读重现步骤。
3. 判断 Severity，也就是问题的严重程度。
4. 找到相关代码。
5. 给出修复方案。
6. 如果另获授权进行修复，修改后运行测试。
7. 最后总结风险。

它回答的是：“应该怎么处理 Bug？” 只要求修复计划时，不应顺便修改仓库。

如果 Agent 无法访问 GitHub Issue，这份 Skill 不会凭空带来数据。工作方法不等于外部工具权限。 它可能指导 Agent 使用已有连接，但连接、凭证与授权仍要真实存在。

只有 MCP：能够接触需要的资料

GitHub MCP 可以向支持 MCP 的客户端提供查询 Issues、读取 PR、获取仓库信息等工具；实际可调用范围取决于服务器能力、配置与账号授权。

它回答的是：“AI 怎么接触 GitHub？” 但有了这些工具，不代表 Agent 自然知道团队规定的七步 Bug 检查流程。

Skill + MCP：方法与连接配合

官方定义怎么理解？

官方定义不一定这么口语，但核心区别大致如此。

Skill：可复用的任务资源

以 Anthropic Agent Skills 为例，Skill 是可组织的能力资源，通常以文件系统或包的方式提供任务指令、工作流、背景知识和最佳实践，也可以包含脚本、模板和支持文件。Agent 在相关任务中加载或使用。

“按需”不代表所有平台的加载机制完全一样，也不代表安装后的全部内容都会一次塞入模型。要看具体平台如何发现 Skill、读取说明与使用资源。

MCP：连接外部系统的开放标准

MCP 的全称是 Model Context Protocol。官方 SDK 文档说明了 Server、Client 与 AI 应用之间的关系。Server 可以暴露三类能力：

• Tools： 可调用的动作，例如查询一条记录。
• Resources： 可读取的信息，例如服务提供的数据或文档。
• Prompts： 可供客户端使用的提示模板。

Host / Client 再决定如何把能力提供给模型或用户。MCP 不是另一个模型，也不意味着服务必在云端、一定联网，或一定调用外部 API。这里参考 2026-07-28 规范发布材料，不假定每个客户端都已实现同样的版本与能力。

核心比较：Skill vs MCP

Skill 的实际文件格式与加载方式依平台而异；MCP 的协议一致性也不等于所有客户端都展示同样的 Tools、Resources、Prompts。

什么时候应该优先考虑 Skill？

反复做同一类任务

Code Review、SEO 检查、YouTube 内容流程、写测试、生成报告、PR Review 或上线检查，如果每次都有较固定的步骤，值得整理为可复用方法。

总在重复同一套 Prompt

每次都说“先检查 A，再检查 B，最后跑测试并按这个格式输出”，说明重复的是方法。先把规则整理好，不必先增加外部连接。

需要专业领域知识

公司代码规范、UI Design System、内部流程、内容审核标准和特定框架用法，都可以组织成相关任务使用的知识与资源。内容仍需准确维护，过时说明不会因为叫 Skill 就自动正确。

已经有完成任务的工具

如果 Codex 已能利用项目文件、Shell、CLI 或已有连接完成任务，缺的只是稳定流程，可能只需要 Skill。不要为了显得“更高级”再加 MCP。

什么时候应该考虑 MCP？

需要外部数据或动作

例如读取 GitHub Issues、查询数据库、访问 Notion、操作浏览器，或与 CRM、云服务、业务系统交互。前提是存在合适的服务器，并且你有权使用对应能力。

希望多个客户端使用统一接口

同一个 MCP Server 可以服务多个支持 MCP 的 Host / Client；实际兼容性仍取决于客户端、协议版本与服务器实现，不是接上就保证一切可用。

没有更简单的现成方式

先比较内建 App、原生能力、现有 CLI 和 API。如果它们已经能解决问题，不一定还要维护一个 MCP Server。

缺少连接时考虑 MCP，而不是看到外部服务就默认必须 MCP。

真正常见的情况：Skill + MCP

GitHub Code Review

Skill 规定 Review 顺序、安全检查、测试要求与输出格式；MCP 在授权范围内提供 PR、Issues 和仓库工具。一个告诉它怎么审，一个让它拿到要审的资料。 如果现有 gh CLI 已经足够，也可以使用那条路径。

Figma → 前端实现

Skill 规定怎么读 Design System、复用组件、处理响应式与做 QA；MCP 或 App 提供设计信息、文件结构、Design tokens。两部分分别解决方法与数据接入，但不是所有 Figma 工作流都必须使用 MCP。

内容发布

Skill 可以规定：资料核实 → 标题 → 正文 → SEO 检查 → 敏感内容检查 → 发布前 QA。

如果有适当且获授权的服务，MCP 可以连接 CMS、Notion、Google Drive 等系统。如果只在本地写 Markdown，可能根本不需要 MCP。 能连接发布系统也不等于获得自动发布授权。

Skill 能代替 MCP 吗？

有时候能减少需求，但不能简单说“能取代”。

例如当前环境已经有可用的 git、gh、playwright-cli 或 curl，Skill 可以指导 Codex 正确使用它们。这里是在说明已有工具的可能性，不假设你的电脑已安装或授权这些程序。

• 有现成工具： Skill 可能已经够了。
• 缺少工具连接： MCP / App / API / CLI 之类的连接能力仍可能需要。

Skill 本身不会自动创造不存在的账号权限与数据源。Skill 如果附带实现连接的代码，也仍需要运行环境、相应授权与安全审查，并非“只有说明就能访问”。

MCP 能代替 Skill 吗？

也不能简单说能。即使 Server 提供 GitHub Tools，Agent 仍未必知道团队的 Code Review 标准。

Skill 可以提供检查步骤、判断规则、输出格式与项目约束。MCP 也可以提供 Prompts，但这不让 MCP 和 Skill 变成同一个概念。有工具，不等于有工作方法。

Skill 和 Prompt 有什么不同？

Prompt 通常是这次对话给 AI 的指令；Skill 更强调可复用、可组织、可在适当任务中使用，并能携带配套资源。

• Prompt：“帮我做 Code Review。”
• Skill：“这是我们的 Review 方法、检查清单、脚本和输出格式。”

需要再理解这个词，可以读 Skill 的人话解释。不是每次临时要求都值得制作一个 Skill。

Skill、MCP 和 Plugin 是什么关系？

Plugin 更像能力安装包。 在当前 OpenAI 体系中，它可以组合 Skills、Apps / 连接器等能力。某个插件如果提供 App Templates，也要看该插件的实际说明，不能当作所有 Plugin 的固定组成。官方说明区分了专门任务的可复用 Skill 与可安装、可组合服务的 Plugin。

Skill 可以是 Plugin 的一部分，但 Plugin 不等于 Skill，也不是所有 Plugin 都包含 MCP。

MCP 更偏协议与连接方式，Plugin 更偏安装、分发和工作流打包。具体实现随平台而异，不需要建立“Plugin 大于 MCP”或反过来的绝对层级。Plugin 词条尚未发布，这里只做文字解释。

Skill 和 MCP 都可能占 Context，但方式不同

Context 是 AI 当前能参考的信息； Token 则与这些内容如何被模型处理有关。不能仅凭名称判断谁一定更轻。

Skill 不是零成本

平台通常需要向 Agent 提供 Skill 名称、描述、instructions 或 metadata，正文和资源可能按需加载。Anthropic Managed Agents 文档明确指出，附加 Skill 会增加一定 session context 成本。发现和加载更多资源也需要工作，因此只附加实际需要的 Skills；不能把一种平台的实现推广到所有平台。

MCP 也不能简单说一定很重

Client 需要发现和理解 Server 能力。部分客户端会把 Tool Schema 放入 Context，返回的数据也可能进入上下文，但工具发现、延迟加载和使用策略都可能不同。

不提供未经统一测试的 Token 数字，也不做“谁重多少倍”的判断。 先看任务、工具数量、实际返回内容与客户端策略。

Skill 和 MCP 都不要乱装

Skill：要像安装软件一样谨慎

Skill 可能带 instructions、scripts、executable code 和外部依赖。恶意内容可能诱导 Agent 执行危险命令、读取文件、误用工具或泄露数据，实际风险取决于 Agent 拥有的权限。

Anthropic 安全指引建议只使用可信来源，并检查完整包内文件及外部依赖，而不只是看说明文案。尤其不要把生产密钥交给不可信 Skill。

MCP：先看它能接触什么

服务器可能涉及文件、浏览器、数据库、外部账号或 API 权限。接入前确认来源、授权范围和数据去向；不需要的权限不要授予。

本页没有安装器，不自动下载 Skill、不连接 MCP，也不执行任何第三方脚本。所有流程都是解释，不是自动化指令。

30秒决定你需要 Skill 还是 MCP

还有第五种答案：什么都不用装

如果 Codex 已能读取项目、运行已有 git / CLI、搜索代码与执行测试，而你只是要“把按钮颜色改一下”，通常直接说任务就行。

不需要为了这件事再连接 MCP，也不一定需要整理 Skill。先把当前任务完成，重复需求出现后再考虑复用。

不要为了使用 AI 工具，而给 AI 工具找工作。

按需求选，不按名字选

不知道项目该从哪里开始，可以先看 Codex 网页开发最小配置。它从项目本身、说明和验证开始，不要求先装插件。

五个常见误区

Skill 是“小号 MCP”？

不是。它们主要解决的问题不同。

MCP 是“高级 Skill”？

不是。MCP 是协议与连接机制，不是 Skill 的升级版。

Skill 永远只是一段 Prompt？

不是。实际 Skill 可以包含指令、脚本、模板和资源，具体依平台而异。

有了 Skill 就不需要外部工具？

不是。Skill 不会凭空创造权限与数据源；它可能指导你使用已有工具。

装得越多，Agent 越强？

不是。更多配置也可能增加 Context、权限、维护、冲突与排错成本。先确认需要什么，再逐个添加。

常见问题

Skill 和 MCP 哪个更重要？

没有统一答案。看缺的是工作方法，还是工具连接；有时两者都需要，有时都不需要。

Codex 应该优先装 Skill 还是 MCP？

已有工具但缺稳定流程，先考虑 Skill；必须访问当前环境没有的系统，再比较 MCP / Plugin / App / CLI。不是所有 Codex 任务都需要额外安装。

Skill 会占 Token 吗？

会有一定 Context 成本，具体取决于平台、元数据和内容加载方式，不能承诺零成本。

MCP 一定比 Skill 更耗 Token 吗？

不能一概而论。Client 的工具发现、加载策略以及实际任务会影响结果。

Skill 能执行代码吗？

视平台与内容而定。有些 Skill 包含脚本，Agent 可以在相应环境与权限下运行，因此第三方 Skill 也必须审查。

MCP Server 是 Skill 吗？

不是，它们是不同概念；Skill 可以指导 Agent 使用 MCP Server 提供的能力。

一个工作流可以同时用 Skill 和 MCP 吗？

可以。方法与连接经常配合，但需要哪一部分取决于任务，不是组合越多越好。

先确认问题，再选工具。需要方法，补方法；缺少连接，再补连接。