AI Agent 能力扩展的真相：Skill、MCP 和插件不是三选一

AI Agent 能力扩展：Skill、MCP 与插件的关系

它们解决的是同一个问题

AI Agent 的原生能力有限------它能对话、能推理，但不知道你的项目规范，也连不上你的数据库。要让 Agent 真正有用，必须给它扩展能力。

目前主流的扩展方式涉及三个概念：Skill（技能） 、MCP（Model Context Protocol）服务 和插件（Plugin）。它们的目标一致：让 Agent 做得更多、做得更好。但三者的关系并非平行并列------Skill 和 MCP 是两种原子能力，插件则是将它们打包分发的组合形态。理解这个模型，才能在正确的场景做出正确的选择。

核心模型：原子能力与组合分发

在深入每个概念之前，先建立整体认知：

markdown 复制代码

Skill（知识单元）    ─┐
                      ├──→ 插件（最佳实践分发包）
MCP 服务（能力单元） ──┘

Skill 和 MCP 服务 是两种不同性质的原子能力------一个教 Agent "怎么想"，一个给 Agent "怎么做"的手。插件不是第三种原子能力，而是把多个 Skill 和 MCP 服务按领域最佳实践组织起来的分发包。

这个区别很关键：Skill 和 MCP 解决的是"能力从哪来"，插件解决的是"能力怎么交付"。

用一个做饭的比喻来理解：Skill 是墙上贴的菜谱 （告诉你怎么做），MCP 是厨房里的供应链和设备 （帮你拿到食材、用上烤箱），插件则是一个"预配好的料理包"------它把特定的菜谱和对应的食材、调料打包在一起，你拿到后直接下锅就行，不用自己再去单独找菜谱、买食材。

Skill：把方法论写成操作手册

Skill 的本质是一段结构化的提示词。它是一个 Markdown 文件，用 YAML 元数据描述"什么时候用"，用 Markdown 正文描述"怎么做"。Agent 在需要时加载它，按照里面的步骤执行。

Skill 不引入任何新的运行时依赖。它不启动进程、不监听端口、不调用外部 API。它所做的全部事情，就是改变 Agent 的"思考方式"------告诉它按什么顺序检查、注意哪些陷阱、输出什么格式。

Skill 的核心特征：

纯文本，零依赖 ：一个 .md 文件，不需要安装任何东西，用任何文本编辑器就能修改
编码的是方法论：它不教 Agent 新工具，而是教 Agent 用已有工具时"按什么思路做"
人类可读可写：打开就是 Markdown，非技术人员也能参与编写和审查
上下文内执行：加载后成为 Agent 提示词的一部分，所有推理在模型内部完成

典型例子：你的团队有一套代码审查标准，涉及安全性、性能、可读性等多个维度。这些标准是"方法论"------告诉审查者按什么顺序检查、关注哪些点、输出什么格式。用 Skill 编码这套流程，每次审查时加载即可。

不适用的情况：如果审查过程中需要查询 Jira 上的历史 Bug 数据，Skill 做不到------它无法访问外部系统。这时候需要 MCP 服务。

MCP 服务：给 Agent 接上外部世界

MCP 是一个开放协议，定义了 AI Agent 与外部系统交互的标准接口。一个 MCP 服务是一个独立的进程，它向 Agent 暴露三样东西：工具（可调用的函数）、资源（可读取的数据）、提示词模板（预定义的交互模式）。

与 Skill 不同，MCP 服务引入了真实的运行时。它需要启动一个服务器进程，监听通信端口，处理 Agent 发来的工具调用请求，访问外部系统（数据库、API、文件系统），然后把结果返回给 Agent。

MCP 服务的核心特征：

有运行时依赖：需要启动服务器进程，可能依赖数据库连接、API 密钥等
提供真实能力：不只是"告诉 Agent 怎么做"，而是"替 Agent 做"------查数据库、调 API、操作文件
结构化接口：工具定义用 JSON Schema 描述参数类型，Agent 能精确知道每个参数该传什么
跨 Agent 通用：MCP 是开放协议，同一个 MCP 服务可以被不同的 Agent 框架使用

典型例子 ：Agent 需要查询禅道上的 Bug 详情。这不是"方法论"能解决的------Agent 必须真正连接到禅道 API、发送 HTTP 请求、拿到 JSON 响应。MCP 服务封装了认证、请求构造、响应解析等细节，向 Agent 暴露一个 zentao_get_bug 工具。

不适用的情况：如果你只是想告诉 Agent"审查代码时先检查 SQL 注入，再检查 XSS"，这不需要 MCP------这是方法论，用 Skill 就够了。MCP 的过度使用会引入不必要的进程管理和网络开销。

插件：最佳实践的分发包

插件不是第三种原子能力，而是一套完整的、经过 curated 的领域最佳实践配置包。它把多个 Skill 和 MCP 服务按特定领域的需求组织在一起，用户安装一个插件，就获得了该领域的完整 AI 辅助能力。

以 Cursor 插件市场中的真实产品为例：

AWS Core 插件：包含 1 个 AWS MCP 服务（提供所有 AWS API 的调用能力）+ 24 个 Skill（分别覆盖 Bedrock 生成式 AI、Cognito 认证、成本优化、基础设施即代码、数据库选型、可观测性等 AWS 开发的全生命周期）。用户装一个插件，就获得了"用 AI 做 AWS 开发"的完整最佳实践。

Google Drive 插件：包含 1 个 Google Drive MCP 服务（提供文件的搜索、读取、创建、分享等 API 能力）+ 1 个 Skill（指导 Agent 如何有效地使用这些工具------何时搜索、何时创建、如何组织文件结构、分享权限的最佳实践）。

插件的核心特征：

组合形态：包含 N 个 MCP 服务 + M 个 Skill，不是单一能力
领域聚焦：围绕特定领域（AWS 开发、Google 办公、DevOps）组织能力
开箱即用：用户不需要分别配置 MCP 和 Skill，一键安装即可获得完整方案
最佳实践沉淀：Skill 的选择和编排代表了该领域的专家经验，不是随机组合

典型例子：你的团队要做 AWS 云原生开发，涉及基础设施部署、数据库选型、成本优化、监控告警等多个环节。与其分别找 24 个 Skill 和 1 个 MCP 服务手动拼装，不如直接安装 AWS Core 插件------它已经把这些能力按最佳实践组织好了。

不适用的情况：如果你只需要 Agent 学会一种特定的代码审查流程，不需要任何外部系统交互，那写一个 Skill 就够了------没必要为了一个知识点去装一个完整的插件包。

三者核心差异对比

维度	Skill	MCP 服务	插件
本质	结构化提示词（方法论）	外部服务接口（能力）	最佳实践分发包（组合）
形态	一个 Markdown 文件	一个运行中的服务器进程	N 个 MCP + M 个 Skill 的集合
依赖	零依赖，纯文本	需要运行时环境、第三方依赖	依赖平台/市场的打包与分发能力
创建成本	低，用文本编辑器即可	中，需要编写服务代码	高，需要策划能力组合 + 编写多个组件
粒度	原子（单点知识）	原子（单点能力）	组合（完整解决方案）
执行位置	Agent 模型内部（推理层面）	Agent 外部（实际系统交互）	无独立执行位置（Skill 在模型内，MCP 在外部）
能做什么	指导 Agent 的思考和行为方式	让 Agent 操作外部系统	提供某领域的完整 AI 辅助方案
不能做什么	无法访问外部数据或执行真实操作	无法传递方法论和最佳实践	不是原子能力，无法单独存在
共享方式	文件复制、版本控制	部署服务、配置连接	应用市场发布、一键安装
调试难度	低，读 Markdown 即可理解	中，需要排查进程、网络	高，需要理解多个组件的协作
复用性	跨 Agent 通用	跨 Agent 通用（MCP 协议）	通常绑定特定平台/市场
适合谁	团队负责人、技术写作者	后端开发者、集成工程师	平台方、领域专家、解决方案架构师

一句话总结：Skill 是菜谱，MCP 是供应链和设备，插件是把菜谱和食材打包好的料理包------拿到就能下锅。

各自擅长的场景

Skill 擅长的场景

场景一：编码规范与审查流程

你的团队有一套代码审查标准，涉及安全性、性能、可读性等多个维度。这些标准是"方法论"------告诉审查者按什么顺序检查、关注哪些点、输出什么格式。这不需要访问任何外部系统，只需要 Agent 按步骤思考。用 Skill 编码这套流程，每次审查时加载即可。

场景二：文档生成工作流

生成一份符合公司模板的技术文档，需要按特定结构组织内容、使用统一的术语表、遵循固定的格式规范。这些是"怎么写"的知识，不涉及外部数据查询。Skill 可以把整个写作流程固化下来。

场景三：故障诊断思路

当系统出现性能问题时，有经验的工程师会按特定顺序排查：先看监控指标、再查日志、然后定位热点代码、最后验证修复。这个排查思路是纯方法论，用 Skill 编码后，Agent 就能按同样的思路引导用户排查问题。

场景四：团队约定的工作流

"提交代码前先跑 lint，再跑测试，最后更新 changelog"------这类团队约定是流程性知识，不需要任何外部工具支持，用 Skill 描述最合适。

MCP 服务擅长的场景

场景一：数据库查询

Agent 需要查询生产数据库中的用户数据来回答业务问题。这不是"方法论"能解决的------Agent 必须真正连接到数据库、执行 SQL、拿到结果。这需要 MCP 服务提供数据库访问工具。

场景二：第三方 API 集成

Agent 需要调用 Jira 创建工单、通过 Slack 发送消息、在 GitHub 上创建 PR。这些操作都需要与外部服务进行真实的 HTTP 交互。MCP 服务封装了 API 认证、请求构造、响应解析等细节，向 Agent 暴露简洁的工具接口。

场景三：实时数据获取

Agent 需要获取当前的股票价格、天气信息、服务器监控数据。这些数据是动态变化的，不可能编码在静态的 Skill 文件里。MCP 服务可以实时拉取数据并返回给 Agent。

场景四：禅道 Bug 查询

Agent 需要查看禅道上的 Bug 详情、任务状态、迭代进度。MCP 服务封装禅道 REST API 的认证和请求细节，暴露 zentao_get_bug、zentao_get_task 等工具，Agent 调用即可拿到结构化数据。

插件擅长的场景

场景一：领域完整解决方案

你的团队要全面采用 AI 辅助 AWS 开发，涉及基础设施、数据库、认证、监控、成本优化等多个方面。AWS Core 插件把 1 个 MCP（统一 API 访问）和 24 个 Skill（各领域最佳实践）打包在一起，一键安装即可获得完整能力。

场景二：跨系统工作流编排

一个 DevOps 插件可能包含 GitHub MCP（代码管理）、Jira MCP（任务跟踪）、Slack MCP（通知）三个 MCP 服务，再加上代码审查 Skill、部署流程 Skill、事故响应 Skill 等多个 Skill。这些组件协同工作，覆盖了 DevOps 的完整生命周期。

场景三：降低使用门槛

对于不熟悉 MCP 配置和 Skill 编写的普通用户，插件提供了一键安装体验。不需要理解 MCP 协议、不需要手动编写 Skill、不需要分别配置每个组件------装一个插件，所有能力就位。

场景四：平台方的能力分发

Cursor、VS Code 等宿主平台通过插件市场分发 AI 能力。平台方负责审核质量、管理版本、处理更新，用户通过市场发现和安装。这种分发模式让领域专家可以把最佳实践规模化地传递给用户。

如何选择：递进式决策

决策的核心逻辑是递进的，不是三选一：

第一步：你需要给 Agent 增加什么？ 如果是知识或方法论（怎么想），选 Skill。如果是外部系统交互能力（怎么做），选 MCP 服务。

第二步：你是否需要把多个 Skill 和 MCP 打包成一个完整方案？ 如果只需要单一能力，到第一步就够了。如果需要把多个原子能力组织成领域解决方案，并且要方便分发------做成插件。

简单说：Skill 和 MCP 解决"能力从哪来"，插件解决"能力怎么交付"。

真实案例：Cursor 插件市场的启示

Cursor 的插件市场为我们理解三者关系提供了最佳实证。

Google Drive 插件的构成：

组件类型	名称	作用
MCP 服务	Google Drive	提供 search、read、create、share 等 API 工具
Skill	google-drive	指导 Agent 如何有效使用这些 MCP 工具

MCP 提供"能不能做"（操作 Google Drive 文件的能力），Skill 提供"怎么做更好"（何时搜索、如何组织、权限最佳实践）。两者缺一不可------只有 MCP，Agent 知道怎么调 API 但不知道什么时候该用哪个；只有 Skill，Agent 知道最佳实践但没有实际操作能力。

AWS Core 插件的构成：

组件类型	数量	覆盖领域
MCP 服务	1 个	统一 AWS API 访问
Skill	24 个	Bedrock AI、Cognito 认证、成本优化、CDK 基础设施、数据库选型、可观测性......

1 个 MCP 服务提供所有 AWS 操作的底层能力，24 个 Skill 分别提供各子领域的最佳实践。这种"一多搭配"的模式说明：MCP 服务可以是通用的，Skill 可以是领域特化的，插件负责把它们组织好。

常见误区

误区一：Cursor 市场里的"插件"就是传统意义上的插件

Cursor 插件市场中的 Gmail、Google Calendar、AWS Core 等，详情页明确标注了 "MCPs" 和 "Skills" 的数量。它们的本质是 MCP 服务 + Skill 的组合包，不是通过宿主 Extension API 深度修改编辑器行为的传统插件。命名因平台而异，判断标准看技术构成而非 UI 标签。

误区二：MCP 服务能替代 Skill

不对。MCP 服务解决的是"能不能做"的问题（访问外部系统），Skill 解决的是"怎么做更好"的问题（思考方式）。一个 MCP 服务可以让 Agent 查询数据库，但不会告诉它查询后如何分析数据、如何组织报告------这是 Skill 的职责。Google Drive 插件同时包含 MCP 和 Skill，正好说明了两者互补而非替代。

误区三：插件比 MCP 或 Skill 更"高级"

不是。插件只是组合形态，不是更高级的能力。一个精心编写的 Skill 可能比一个粗糙的插件更有价值。选择的标准不是"哪个更高级"，而是"我需要原子能力还是完整方案"。如果你只需要一个代码审查流程，写一个 Skill 比装一个完整的 DevOps 插件更合适。

误区四：Skill 太简单，不够用

Skill 的简单恰恰是它的优势。零依赖、纯文本、人类可读------这意味着任何人都能参与编写和审查，不需要开发环境。对于编码方法论、审查流程、文档规范这类"知识型"需求，Skill 是最轻量的方案。AWS Core 插件里有 24 个 Skill，每个都很"简单"，但组合起来就是完整的 AWS 开发最佳实践。

总结

Skill、MCP 服务和插件代表了扩展 Agent 能力的三个层次。回到做饭的比喻：Skill 是菜谱，教你怎么做一道菜；MCP 是供应链和设备，让你能拿到食材、用上烤箱；插件则是预配好的料理包，把菜谱和食材打包好，拿到就能下锅。选择的标准很清晰：需要改变做法时写 Skill，需要接入外部能力时开发 MCP 服务，需要把多个 Skill 和 MCP 按领域最佳实践组织成分发包时做成插件。大多数实际项目中，Skill 和 MCP 作为原子能力被独立开发和复用，插件作为组合形态负责最终的交付体验。理解这个层次关系，才能设计出既灵活又可交付的 Agent 能力体系。