1. 先把概念掰开：Skill、MCP、插件到底各管哪一段

很多人第一次接触 AI Agent 扩展能力时，脑子里会自动蹦出一个选择题：我到底该用 Skill、MCP 还是插件？这个问法本身就有点问题，因为它默认了三者是互斥的替代关系。实际做过几个 Agent 项目之后你会发现，它们压根不在同一个层面上竞争，更像是"大脑里的操作手册""对外接线的标准插座"和"装进宿主程序里的功能模块"这三件事。

先把最容易被混淆的三个词用生活化的方式说清楚。

Skill（技能），本质是一段写给模型看的"操作说明书 + 执行脚本"。它通常包含一个描述文件（说明这个技能什么时候用、输入输出是什么）加上可选的脚本或提示词模板。模型读到这个描述后，知道"遇到这类任务时该调用这个技能"。它解决的是"模型知道怎么做某件事"的问题，偏认知层。

MCP（Model Context Protocol），是一套让模型和外部工具、数据源对话的协议标准。你可以把它理解成 USB-C 接口：只要对方实现了这个协议，模型就能用统一的方式去调用它，不用为每个工具单独写适配代码。它解决的是"模型怎么稳定地够到外部世界"的问题，偏连接层。

插件（Plugin），是宿主应用（比如 IDE、浏览器、办公软件）提供的扩展机制。它跑在宿主进程里，能拿到宿主的 API、UI 插槽、生命周期钩子。它解决的是"这个功能怎么嵌进某个具体软件里"的问题，偏宿主集成层。

把这三者放在一张表里对比，关系会清楚很多：

看这张表就能明白，为什么说"三选一"是个伪命题。一个完整的 Agent 能力扩展方案，往往是三层同时存在：用 Skill 告诉模型任务该怎么拆、用 MCP 把外部工具接进来、用插件把整个能力塞进用户日常用的软件里。它们不是竞争对手，是流水线上的不同工位。

我见过不少团队在选型阶段卡住，就是因为把这三者当成了同一维度的选项，结果要么用插件硬扛本该由 Skill 处理的编排逻辑，要么用 Skill 去模拟本该由 MCP 承担的稳定连接，最后都做得很别扭。下面几节我会把每一层的真实边界、常见误区和落地细节拆开讲。

2. Skill 的真实定位：它不是"功能"，是"给模型的作业指导书"

2.1 为什么 Skill 常被误解成插件

Skill 这个词太容易让人联想到"装上去就多一个功能"，于是很多人下意识把它和插件划等号。但如果你真的写过 Skill，会发现它更像一份写给新员工的 SOP：里面写清楚这个任务的目标、可用工具、执行步骤、边界条件、输出格式。模型读完这份 SOP，才知道在什么场景下该做什么。

举个具体例子。假设你要让 Agent 处理"把一份会议纪要整理成待办清单"这件事。用 Skill 的写法，你会写一个描述文件，说明触发条件是"输入包含会议记录文本、用户要求提取行动项"，然后给出处理步骤：先识别发言人、再抽取含动作动词的句子、再归一化负责人和时间、最后按优先级排序输出。模型拿到这份指导，就能稳定地完成任务，而不需要你为它写一个专门的函数。

这就是 Skill 的核心价值：它把"怎么做"这件事从模型权重里外化成了可读、可改、可版本管理的文本。你改一行描述，模型的行为就可能变化，不用重新训练。

2.2 Skill 的组成结构与编写要点

一个能用的 Skill，通常包含这几块内容：

• 元信息：名称、版本、适用场景的一句话描述。这部分决定模型能不能在正确时机想起它。
• 触发条件：什么输入、什么意图下应该启用。写得太宽会误触发，写得太窄会漏触发。
• 执行步骤：分步骤的操作指引，可以引用外部工具或脚本。
• 输入输出约定：参数格式、返回结构，方便和其他环节对接。
• 边界与异常：遇到什么情况该放弃、该追问、该降级处理。

编写时最容易踩的坑是"描述写得像需求文档而不是操作指引"。需求文档写"要准确提取信息"，操作指引要写"逐句扫描，遇到含'负责''跟进''完成'等动词的句子标记为候选"。模型需要的是可执行的动作，不是抽象的目标。

提示：Skill 的描述文件里，动词比形容词重要得多。"准确""高效"这类词对模型几乎没有约束力，"逐行扫描""按字段拆分""若为空则跳过"这类动作描述才真正影响输出。

2.3 Skill 的可迁移性：为什么它比插件更"轻"

Skill 最大的优势是轻和可迁移。同一份 Skill 描述，理论上可以喂给不同的模型、跑在不同的平台上，只要对方支持读取这类描述。它不依赖某个宿主的 API，也不绑定某个运行时。这意味着你积累的 Skill 库是一种可以跨项目复用的资产。

但轻也有代价。Skill 本身不提供执行能力，它只是"告诉模型怎么做"。真正干活还得靠模型自身能力或者外部工具。所以 Skill 必须和 MCP 或插件配合，才能形成完整闭环。单独一个 Skill，就像一份没有工具的工具使用手册，模型看懂了也未必做得到。

我个人的经验是：把稳定的、跨项目通用的流程沉淀成 Skill，把易变的、依赖具体环境的操作交给 MCP 或插件。这样 Skill 库不会因为环境变化而频繁失效，维护成本低很多。

3. MCP 解决的是"够得着"的问题，不是"会不会"的问题

3.1 MCP 出现的背景：工具接入的碎片化

在 MCP 之前，让模型调用外部工具是一件很痛苦的事。每个工具都有自己的调用方式：有的要写 HTTP 请求，有的要调 SDK，有的要起本地进程。模型每接一个新工具，就得为它单独写适配层。工具一多，适配代码就爆炸，而且每个模型的接入方式还不一样。

MCP 的思路是把这件事标准化。它定义了一套协议，工具方只要实现服务端，模型方只要实现客户端，双方就能用统一的方式对话。工具的描述、参数、返回值都有固定格式，模型不需要为每个工具写定制代码。

这就像早年每个电器都有自己的充电口，出门要带一堆线；后来统一成一种接口，一根线走天下。MCP 就是 AI 工具接入领域的那个统一接口。

3.2 MCP 的工作机制拆解

MCP 的交互大致分几个环节：

1. 能力发现：客户端连接服务端后，先问"你有哪些工具、资源、提示模板"。服务端返回一份清单。
2. 能力描述：每个工具附带名称、用途、参数 schema。模型据此判断该不该调用。
3. 调用请求：模型决定调用某个工具，客户端按协议格式发出请求。
4. 结果返回：服务端执行后返回结构化结果，客户端再喂回模型。

这套机制的关键在于描述和调用分离。模型先看到描述，再决定调用，而不是硬编码调用逻辑。这让模型能动态发现新工具，不用重新训练或改代码。

实际落地时，MCP 服务端可以是本地进程，也可以是远程服务。本地进程适合访问本机资源（文件、数据库、本地应用），远程服务适合访问云端能力。选择哪种，取决于你要接的东西在哪。

3.3 MCP 落地时的常见坑

MCP 听起来很美，但真接起来有几个坑必须提前知道。

第一个坑是工具描述写得太烂。MCP 服务端返回的工具描述，直接决定模型会不会正确调用。如果描述写得含糊，模型要么不调用，要么乱调用。描述里要写清楚"这个工具做什么、什么时候用、参数含义、返回什么"，和写 Skill 描述一样，动词优先。

第二个坑是权限和授权。远程 MCP 服务通常需要授权，客户端要处理 token 获取、刷新、失效重试。这块如果没做好，会出现"模型明明该调用工具却报错"的情况，排查起来很费劲。

第三个坑是流式输出与文件落盘。有些场景下工具返回的内容很大，需要流式写文件而不是一次性塞回模型上下文。这时候客户端要支持流式处理，否则上下文会被撑爆。

第四个坑是工具数量膨胀。接了几十个工具之后，模型的选择难度上升，误调用率也会上升。这时候需要做工具分组、按场景动态加载，而不是一股脑全塞给模型。

注意：MCP 不是"接了就能用"。工具描述质量、授权链路、上下文管理这三件事，任何一件没做好，都会让 MCP 的实际效果大打折扣。

3.4 MCP 和 Skill 的配合方式

MCP 负责"够得着"，Skill 负责"知道怎么用"。两者配合的典型模式是：Skill 描述里写明"本任务需要调用 X 工具，调用时参数这样填，返回结果这样处理"，MCP 负责把 X 工具真正接进来。

这样分工的好处是，工具换了（比如从 A 数据库换成 B 数据库），只要 MCP 层换实现，Skill 描述基本不用动。反过来，流程变了，改 Skill 描述即可，MCP 层不受影响。两层解耦，维护起来清爽很多。

4. 插件的位置：它管的是"嵌进宿主"，不是"模型能力"

4.1 插件和 MCP/Skill 的本质区别

插件跑在宿主应用里，能拿到宿主提供的 API、UI 插槽、事件钩子。它的核心价值是把能力嵌进用户已经在用的软件，而不是给模型增加能力。

举个例子。你想让 Agent 帮你在 IDE 里改代码。模型本身能生成代码，但它没法直接操作 IDE 的编辑器、文件树、终端。这时候就需要一个 IDE 插件，它监听用户操作、调用 IDE API、把结果反馈给模型。插件在这里扮演的是"手和脚"，模型是"大脑"。

所以插件和 MCP、Skill 不在一个层面。MCP 和 Skill 关注的是模型侧的能力扩展，插件关注的是宿主侧的集成。一个 Agent 方案可以没有插件（纯命令行或网页交互），也可以没有 MCP（只用模型自身能力），但只要有宿主集成需求，插件就绕不开。

4.2 插件开发的现实约束

插件开发有几个绕不开的现实约束，提前知道能省很多时间。

约束一是宿主 API 的稳定性。宿主应用的扩展 API 经常变，尤其是版本迭代快的软件。今天能用的接口，下个版本可能就废弃了。所以插件代码要做好版本适配，关键路径加兼容分支。

约束二是审核与分发。很多宿主对插件有审核机制，涉及权限、隐私、安全的插件审核更严。开发前先看清楚宿主的插件规范，别做完才发现过不了审。

约束三是性能与资源占用。插件跑在宿主进程里，占用的是宿主资源。如果插件做重计算或频繁 IO，会拖慢宿主，用户体验直接受影响。重活尽量放到外部进程，插件只做轻量的桥接。

约束四是调试困难。插件运行在宿主环境里，调试不像独立程序那么方便。要善用宿主的日志系统、开发者工具，必要时加详细的埋点。

4.3 什么时候该做插件，什么时候不该

不是所有需求都值得做成插件。判断标准很简单：这个能力是否必须嵌在某个具体宿主里，且用户是否高频在该宿主中使用它。

如果答案是肯定的，做插件值得。比如"在 IDE 里直接调用 Agent 改代码""在浏览器里一键抓取页面内容喂给 Agent"，这些场景用户就在宿主里，插件能大幅降低使用门槛。

如果答案是否定的，比如"批量处理本地文件""定时跑数据同步"，这些用命令行工具或后台服务就够了，硬做成插件反而增加复杂度。

我见过一些团队，为了"看起来完整"硬把本该是后台服务的功能塞进插件，结果插件又重又难维护，用户还得先打开宿主才能用。这是典型的为了形式牺牲实用。

5. 三层如何协同：一个完整 Agent 扩展方案的搭建思路

5.1 从任务出发反推分层

搭建方案时，不要先想"我要用哪层"，而要先想"这个任务需要什么"。把任务拆成几个问题：

• 模型需要知道"怎么做"吗？需要，就写 Skill。
• 模型需要够到外部工具或数据吗？需要，就上 MCP。
• 用户需要在某个软件里直接用吗？需要，就做插件。

这三个问题可以同时为"是"，那就三层都上。也可以只有一个为"是"，那就只做一层。分层是为了解决问题，不是为了凑齐。

5.2 一个具体场景的分层拆解

假设你要做一个"帮用户在本地代码库里定位并修复 bug"的 Agent。拆解一下：

• Skill 层：写一份"bug 定位与修复"的技能描述，说明流程——先读报错、再定位相关文件、再分析根因、再生成补丁、再验证。这份描述让模型知道任务该怎么推进。
• MCP 层：接一个文件系统 MCP 服务，让模型能读文件、写文件、跑测试命令。再接一个代码检索 MCP 服务，让模型能快速找到相关代码。
• 插件层：做一个 IDE 插件，让用户在编辑器里选中报错信息就能唤起 Agent，修复结果直接以 diff 形式展示在编辑器里。

三层各司其职：Skill 管流程，MCP 管能力，插件管入口。缺任何一层，体验都会打折。没有 Skill，模型流程混乱；没有 MCP，模型够不到代码库；没有插件，用户得切到别的地方操作。

5.3 分层带来的维护优势

分层最大的好处是变更隔离。流程变了改 Skill，工具换了改 MCP，宿主升级了改插件，互不影响。如果一开始就把所有逻辑揉在一起，任何一处变化都要动全身，维护成本会指数级上升。

我自己的项目里，Skill 描述是迭代最频繁的，因为流程优化最常发生；MCP 层相对稳定，工具接好之后很少动；插件层跟着宿主版本走，宿主升级时才需要适配。这种节奏下，每层的变更频率不同，分层让它们各自演进，不会互相拖累。

6. 选型与落地中的经验教训

6.1 别在选型阶段纠结"三选一"

回到标题那句话：Skill、MCP 和插件不是三选一。选型阶段真正该问的不是"选哪个"，而是"这个任务需要哪几层"。把任务拆清楚，答案自然浮现。纠结三选一，本质是没把任务拆明白。

6.2 先跑通最小闭环，再补层

新手常犯的错是一上来就想把三层都搭齐，结果每层都半成品，整体跑不通。正确做法是先跑通最小闭环：比如先用 Skill + 模型自身能力跑通流程，再逐步接 MCP 补外部能力，最后做插件补宿主入口。每加一层，闭环都保持可用，这样问题容易定位，进度也可控。

6.3 描述质量决定上限

无论是 Skill 描述还是 MCP 工具描述，质量直接决定 Agent 的表现上限。模型再强，描述写得烂，它也做不对。花在打磨描述上的时间，回报率远高于换模型或加工具。这一点我在多个项目里反复验证过。

6.4 上下文管理是隐形瓶颈

三层协同之后，上下文里会塞进 Skill 描述、工具清单、调用结果、历史对话。如果不做管理，上下文很快被撑爆，模型表现断崖式下降。常见做法是按需加载 Skill、动态筛选工具、对长结果做摘要或落盘。这块不做，前面三层搭得再好也白搭。

这张表里的每一条，都是我在实际项目里踩过或见别人踩过的。它们的共同点是：问题不在模型能力，而在分层没做好、描述没写清、上下文没管住。

7. 我对这套分层思路的个人体会

做了几个 Agent 项目之后，我越来越觉得 Skill、MCP、插件这套分层，本质上是在回答"能力从哪来、怎么接、给谁用"这三个问题。Skill 回答"怎么做"，MCP 回答"够得着"，插件回答"嵌得进"。三者不是竞争关系，是协作关系。

真正难的从来不是选哪层，而是把每层的边界划清楚，让它们各司其职又顺畅衔接。边界划清了，扩展能力就是搭积木；边界糊了，再强的模型也救不回来。如果你正在做 Agent 扩展，建议先把任务拆成那三个问题，答案会比你想象的清楚得多。