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

1. 先把概念掰开揉碎：Skill、MCP、插件到底各管什么

1.1 三个词被混用，是绝大多数人踩的第一个坑

我接触 AI Agent 这一摊子事大概两年多，从最早的纯 Prompt 编排，到后来接工具调用，再到现在的 Skill、MCP、插件满天飞，最大的感受就是：这三个词被严重混用了。你去搜"AI Agent 能力扩展"，十篇文章里有八篇把 Skill、MCP、插件当成同一层的东西在讲，然后告诉你"选一个就行"。这个说法从根上就是错的。

先把它们各自的定位说清楚。Skill，本质是"能力封装"，它描述的是一段可复用的、面向某个具体任务的执行逻辑。比如"把一段中文翻译成英文并保持术语一致"、"从一份 PDF 里抽取表格并转成 CSV"，这些都可以是一个 Skill。Skill 关注的是做什么、怎么做，它可以是纯提示词，也可以带脚本、带工具调用，甚至带一套固定的工作流。

MCP，全称 Model Context Protocol，它解决的是连接问题。你可以把它理解成 AI Agent 和外部世界之间的"标准插座"。以前每接一个数据源、每接一个工具，都要写一套专属的适配代码，接十个工具写十套，维护起来要命。MCP 做的事情就是把这些连接抽象成统一协议，Agent 只要会说 MCP，就能跟所有支持 MCP 的服务对话。它关注的是怎么连、连什么。

插件，这个词最泛。在 IDE 里它是扩展功能，在浏览器里它是加装模块，在 Agent 语境下，插件通常指的是宿主平台提供的扩展机制。比如某个 Agent 平台允许你上传一个插件包，平台负责加载、调度、权限管理，你只负责写业务逻辑。插件关注的是挂在哪、谁来管。

所以你看，这三者根本不在一个维度上。Skill 是能力层，MCP 是连接层，插件是宿主扩展层。把它们放在一起"三选一"，就像问"做饭、买菜、厨房你选哪个"一样荒谬。

1.2 用一个生活场景把三者关系讲透

我习惯用一个类比：把 AI Agent 想象成一家餐厅。

Skill 就是菜谱。宫保鸡丁怎么做、火候多大、放多少糖，这是菜谱管的事。菜谱可以写在纸上（纯提示词），也可以配好半成品（带脚本），核心是"这道菜怎么做出来"。

MCP 就是供应链标准。餐厅要进货，以前每个供应商一套对接方式，蔬菜一个电话、海鲜一个微信、调料一个传真，乱成一锅粥。MCP 相当于定了一套统一的采购单格式，所有供应商都按这个格式来，餐厅后厨只要认这个格式就行。它不关心你买的是白菜还是龙虾，只关心"怎么把货送进来"。

插件就是厨房设备。烤箱、蒸箱、料理机，这些是挂在厨房里的硬件。设备本身不决定你做什么菜，但它决定了你能不能用某种方式做菜。插件由平台（厨房）提供安装位，你装上去，平台负责供电、维护、安全。

一家好餐厅，菜谱、供应链、设备缺一不可。你不会说"我只要菜谱不要供应链"，也不会说"我只要设备不要菜谱"。AI Agent 的能力扩展也是这个道理。

1.3 为什么现在突然都在聊这三个词

说白了，是因为 Agent 从"玩具"走向"干活"了。早期大家玩 Agent，就是让它写写文案、答答题，纯提示词就够了。现在要让它真的去操作数据库、去调 API、去处理文件、去跑长流程任务，光靠提示词根本撑不住。

这时候问题就暴露了：能力怎么复用？连接怎么标准化？扩展怎么管理？三个问题对应三个答案，Skill、MCP、插件各自解决一块。它们不是竞争关系，是协作关系。我见过太多团队，一开始只做 Skill，做到几十个之后发现连接层乱成一团；也有团队一上来猛搞 MCP，结果发现没有好的 Skill 封装，Agent 还是不知道该干什么。

提示：如果你现在还在纠结"到底选哪个"，说明你还没搞清楚自己的瓶颈在哪。先问自己：是 Agent 不会做事（缺 Skill），还是 Agent 连不上东西（缺 MCP），还是扩展没法管理（缺插件机制）。

2. 核心机制拆解：三者各自的技术底座

2.1 Skill 的本质是"可复用的任务契约"

很多人以为 Skill 就是一段提示词，这是最浅的理解。真正工程化的 Skill，核心是一份任务契约：输入是什么、输出是什么、中间需要哪些工具、失败怎么处理、边界在哪。

我拿一个实际例子说。假设你要做一个"从会议录音生成结构化纪要"的 Skill。表面看就是"把录音转文字再总结"，但拆开看：

• 输入契约：音频文件路径、语言、是否需要区分说话人
• 处理链路：语音转文字 → 分段 → 说话人识别 → 要点抽取 → 待办事项提取 → 格式化输出
• 工具依赖：语音识别工具、文本分段工具、LLM 总结
• 输出契约：Markdown 格式的纪要，包含议题、结论、待办三块
• 失败处理：音频太长怎么办、识别置信度低怎么办、没有待办怎么办

你看，这已经不是一个提示词能搞定的了。它是一套有明确边界的执行逻辑。Skill 的价值就在于：把这种逻辑固化下来，下次遇到同类任务直接调用，不用重新设计。

Skill 的粒度也很讲究。太粗，一个 Skill 干十件事，复用性差；太细，一个 Skill 只干一件事，组合起来又太碎。我的经验是，一个 Skill 对应一个"人类会单独交代的任务"。你会单独跟助理说"帮我整理会议纪要"，不会说"帮我做会议纪要的第一步"，所以 Skill 就按这个粒度切。

2.2 MCP 解决的是"连接爆炸"问题

MCP 出现的背景，是工具接入的 N×M 难题。假设你有 N 个 Agent，M 个外部工具，传统做法是每个 Agent 对每个工具都要写适配，总共 N×M 套代码。工具一升级，所有适配全要改。

MCP 的思路是引入一个中间层：工具方实现 MCP Server，Agent 方实现 MCP Client，双方都认这套协议。这样 N 个 Agent 和 M 个工具之间，只需要 N+M 套实现。这就是典型的协议标准化带来的复杂度降维。

MCP 的核心概念有几个，我按重要性排：

• Resources（资源）：Agent 可以读取的数据，比如文件、数据库记录、API 返回
• Tools（工具）：Agent 可以调用的动作，比如发邮件、写文件、查天气
• Prompts（提示模板）：预定义的提示词模板，方便复用
• Sampling（采样）：Server 反过来请求 Client 的 LLM 做推理，这个比较进阶

实际用起来，最常打交道的是 Tools 和 Resources。Tools 是"能做什么"，Resources 是"能看什么"。一个设计良好的 MCP Server，会把这两块分得很清楚。

MCP 的传输方式也值得说一句。常见的有标准输入输出（stdio）和基于 HTTP 的传输。stdio 适合本地进程，简单直接；HTTP 适合远程服务，能跨网络。选哪种取决于你的工具部署在哪。本地文件操作类工具用 stdio 就很顺，云端 API 类工具用 HTTP 更合适。

2.3 插件机制是"宿主给的扩展位"

插件这个词之所以让人困惑，是因为它太依赖宿主。同一个功能，在 A 平台叫插件，在 B 平台可能叫扩展、叫模块、叫 App。但本质都一样：宿主平台开放一个扩展点，你按它的规范填进去，平台负责加载和运行。

插件机制的关键在于生命周期管理和权限边界。平台要管插件的安装、启用、禁用、卸载、升级，还要管插件能访问什么资源、能调用什么接口。这些是 Skill 和 MCP 不管的。

举个具体场景。你在某个 IDE 里装一个 AI 辅助编码的插件，这个插件可能内部用了 Skill（比如"生成单元测试"这个能力），也可能通过 MCP 连了外部服务（比如连了代码仓库）。但对你来说，你只是"装了个插件"。插件是用户视角的封装，Skill 和 MCP 是它内部的实现手段。

所以三者的关系可以这样理解：插件是外壳，Skill 是内核能力，MCP 是连接管道。一个成熟的 Agent 扩展体系，往往是插件里打包了若干 Skill，这些 Skill 又通过 MCP 去连外部资源。

2.4 三者对比：一张表看清边界

这张表我建议你存下来。每次纠结"这个需求该用哪个"的时候，对着表看一眼，基本就清楚了。

3. 实操：怎么把三者串起来用

3.1 一个真实场景的完整拆解

我拿一个我自己做过的项目说：让 Agent 自动处理客户邮件并归档。需求听起来简单，但拆开看，三个东西全用上了。

先看任务流：Agent 要读邮箱 → 判断邮件类型 → 提取关键信息 → 生成回复草稿 → 归档到对应文件夹 → 记录到表格。

Skill 层，我定义了三个：

• classify_email：判断邮件是咨询、投诉、合作还是垃圾邮件
• extract_info：从邮件正文提取客户名、需求、紧急程度
• draft_reply：根据类型和信息生成回复草稿

MCP 层，我接了两个 Server：

• 邮箱 MCP Server：提供读邮件、发邮件、移动邮件的 Tools
• 表格 MCP Server：提供写记录、查记录的 Tools

插件层，我把上面这些打包成一个插件，装在我的 Agent 平台上，配好权限（只能访问指定邮箱和指定表格），设好触发条件（新邮件到达时触发）。

这样一套下来，整个流程就跑通了。关键在于：Skill 负责"想清楚做什么"，MCP 负责"够得着外部"，插件负责"装得进去、管得住"。

3.2 Skill 的编写要点：契约先行

写 Skill 最容易犯的错，是上来就写提示词。我的做法是先写契约，再写实现。

契约包含四块：

1. 输入定义：字段名、类型、是否必填、取值范围
2. 输出定义：字段名、类型、格式要求
3. 前置条件：调用这个 Skill 需要什么已经就绪
4. 后置保证：调用成功后能保证什么

拿extract_info举例：

name: extract_info description: 从客户邮件正文提取结构化信息 input: email_body: type: string required: true description: 邮件正文纯文本 output: customer_name: type: string description: 客户名称，未识别则为空 demand: type: string description: 客户核心需求摘要，50字以内 urgency: type: enum values: [high, medium, low] preconditions: - 邮件正文已去除签名和引用 postconditions: - 输出字段全部存在 - urgency 必为三个枚举值之一

契约写清楚了，实现反而简单。提示词就围绕"怎么从正文里稳定抽出这三个字段"来写，测试用例也照着契约来设计。

提示：Skill 的 description 字段极其重要，Agent 是靠它来决定"什么时候该调用这个 Skill"的。description 写得太泛，Agent 会乱调；写得太窄，该调的时候不调。我的经验是 description 里要包含"触发场景"和"不适用场景"两部分。

3.3 MCP 接入的实操步骤

接一个 MCP Server，标准流程大概是这样：

1. 确认 Server 类型：是本地进程（stdio）还是远程服务（HTTP）
2. 配置连接信息：本地的话配命令和参数，远程的话配地址和认证
3. 声明能力：告诉 Client 这个 Server 提供哪些 Tools 和 Resources
4. 测试连通：先手动调一个最简单的 Tool，确认链路通
5. 接入 Agent：把 Server 注册到 Agent 的工具列表里

配置文件通常长这样（以常见的 JSON 配置为例）：

{ "mcpServers": { "email": { "command": "node", "args": ["/path/to/email-server.js"], "env": { "EMAIL_HOST": "imap.example.com", "EMAIL_USER": "agent@example.com" } }, "spreadsheet": { "url": "https://api.example.com/mcp", "headers": { "Authorization": "Bearer YOUR_TOKEN" } } } }

这里有几个坑我踩过：

• 环境变量别硬编码在配置里，尤其是密码和 token，用平台提供的密钥管理
• stdio 类型的 Server 要注意进程生命周期，Agent 退出时 Server 要能正常关闭，否则会留僵尸进程
• 远程 Server 要设超时，网络抖动时不能让 Agent 一直卡着

3.4 插件打包：把散件组装成产品

当你有一堆 Skill 和 MCP 之后，插件就是最后的封装。插件要解决的是交付问题：怎么让别人一键装上、怎么控制权限、怎么升级。

一个插件包通常包含：

• 清单文件：声明插件名、版本、依赖、权限
• Skill 定义：打包进去的 Skill
• MCP 配置：需要连接的 Server
• 资源文件：提示词模板、配置模板、图标等
• 入口逻辑：插件加载时执行什么

清单文件是核心，它决定了插件能干什么、不能干什么。权限声明要最小化，只申请真正需要的。我见过一个插件申请了全盘文件读写权限，就为了读一个配置文件，这种在审核时会被打回，用户也不敢装。

4. 常见误区与排查实录

4.1 误区一：以为 Skill 越多越好

新手最容易犯的错，是疯狂堆 Skill。看到什么任务都想封装成一个 Skill，结果 Agent 面对几百个 Skill，选择困难，调用准确率暴跌。

我的经验是，Skill 数量控制在 20 到 50 个之间比较健康。超过这个数，就要考虑分层：把细粒度的 Skill 组合成粗粒度的 Skill，或者用路由机制先分类再选具体 Skill。

判断一个 Skill 该不该独立，问三个问题：它会被单独调用吗？它有独立的输入输出契约吗？它的失败会影响其他 Skill 吗？三个都是"是"，才值得独立。

4.2 误区二：MCP 接得越多越强

MCP 接多了，问题也很明显：上下文爆炸。每个 MCP Server 都会往 Agent 的上下文里塞工具描述，接十个 Server，光工具描述就占掉大量 token，真正干活的空间被挤压。

解决办法是按需加载。不是所有 Server 都要常驻，可以按任务类型动态挂载。比如处理邮件的任务，只挂邮箱 Server；处理数据的任务，只挂数据库 Server。这样上下文干净，Agent 决策也准。

4.3 误区三：插件装完就不管了

插件是有生命周期的。版本升级、依赖变更、权限调整，都需要管理。我见过团队装了几十个插件，半年后没人记得哪个是干嘛的，哪个还在用，哪个有安全风险。

建议建一个插件台账，记录：插件名、用途、负责人、版本、上次更新时间、依赖的 MCP。定期清理不用的，及时升级有安全更新的。

4.4 常见问题速查表

4.5 几个我踩过的具体坑

坑一：Skill 的 description 写成了功能说明。我一开始写"这个 Skill 用于提取信息"，结果 Agent 根本不知道什么时候该用。后来改成"当需要从客户邮件中提取客户名、需求和紧急程度时使用，不适用于内部邮件"，调用准确率立刻上来了。

坑二：MCP Server 没做错误隔离。有个 Server 挂了，导致整个 Agent 卡死。后来给每个 Server 加了独立的超时和降级逻辑，一个挂了不影响其他。

坑三：插件权限给太大。早期图省事，插件申请了全权限，结果一次误操作删了重要文件。后来严格按最小权限原则，每个插件只给必需的权限。

坑四：Skill 和 MCP 职责混淆。我一度把"读文件"这种操作也封装成 Skill，其实这应该是 MCP 的 Tool。Skill 应该关注"读文件之后干什么"，而不是"怎么读文件"。

5. 架构选型：不同阶段该怎么配

5.1 起步阶段：Skill 优先

如果你刚开始做 Agent，任务比较单一，我的建议是先把 Skill 做扎实。这个阶段不需要复杂的 MCP 和插件，把核心任务的执行逻辑封装好，让 Agent 能稳定完成主要工作。

这个阶段的重点是打磨 Skill 的质量：契约清晰、边界明确、失败可处理。别急着铺开，先把一两个核心 Skill 做到 90 分以上。

5.2 成长阶段：引入 MCP

当你的 Agent 需要连接的外部资源超过三五个，就该考虑 MCP 了。这个阶段的标志是：你开始为每个新工具写重复的适配代码。这就是连接爆炸的前兆。

引入 MCP 的节奏，是先接一两个关键 Server，跑通链路，验证稳定性，再逐步扩展。别一次性全接，容易失控。

5.3 成熟阶段：插件化交付

当你的 Agent 能力要交付给其他人用，或者要在多个环境部署，插件化就是必然。这个阶段要解决的是标准化交付：一键安装、权限可控、版本可管。

插件化不是技术问题，是工程问题。它要求你把前面做的 Skill 和 MCP 整理成规范的包，配好清单和权限，做好版本管理。

5.4 三个阶段的能力对照

这张表不是硬性标准，是参考。核心是按需演进，别为了用而用。

6. 我个人的一些实战体会

6.1 别被概念绑架，回到问题本身

Skill、MCP、插件这些词，本质是解决问题的工具，不是目的。我见过太多团队，为了"用上 MCP"而强行接 MCP，结果本来一个函数调用能解决的事，绕了一大圈。

正确的思路是：先明确问题是什么，再看哪个工具合适。问题是"任务逻辑要复用"，就用 Skill；问题是"连接要标准化"，就用 MCP；问题是"扩展要管理"，就用插件。问题驱动，而不是概念驱动。

6.2 三者协同的关键是"边界清晰"

三者能协同好的前提，是各自边界清晰。Skill 不越界去管连接，MCP 不越界去管任务逻辑，插件不越界去管具体实现。边界一乱，维护成本就指数级上升。

我判断边界是否清晰，有个简单方法：看改动的影响范围。改一个 Skill，只影响这个任务；改一个 MCP 配置，只影响连接；改一个插件，只影响这个功能包。如果改一处要动全身，说明边界没划好。

6.3 从小处着手，别一上来就搞大架构

我见过最典型的失败案例，是一个团队一上来就设计了一套"Skill + MCP + 插件"的完整架构，画了十几张图，结果三个月没跑通一个完整任务。

我的建议是从一个小任务开始，先做一个 Skill，跑通；再加一个 MCP，跑通；最后打包成插件，跑通。每一步都验证，每一步都可用。架构是长出来的，不是设计出来的。

6.4 最后分享一个实用技巧

如果你不确定一个需求该用 Skill 还是 MCP，问自己一句话："这是在描述'做什么'，还是在描述'连什么'？"

"从邮件提取信息"是做什么，是 Skill。"读取邮箱里的邮件"是连什么，是 MCP。这个判断方法我用了一年多，基本没出过错。

再补一句，Skill 和 MCP 的划分不是绝对的，有些场景下会有重叠。这时候看复用维度：如果这个能力会被多个任务复用，倾向 MCP；如果只服务于特定任务，倾向 Skill。复用维度是最终裁判。