Agent 能力扩展：Skill、MCP 与插件如何共存与协同

最近身边不止一个人问我同一个问题：给 Agent 扩展能力，到底该选 Skill、MCP 还是插件？问的人多了，我发现大家默认这三样是互斥方案，选了一个就得放弃另外两个。我的回答是：这个问法本身就是错的。Skill、MCP、插件根本不是同一个层面的东西，没有谁替代谁的关系，它们要解决的是三个完全不同的问题。

如果你试着把所有 Agent 相关的能力扩展方式都叫成“插件”，你会发现等到要落地的时候根本说不清楚：到底是在教模型做事，还是在帮模型连工具，还是在给宿主应用加一个入口？这三件事混在一起，架构就糊了。这篇文章就把它们拆开讲清楚，并且用我实际搭过的一个内容发布 Agent 作为例子，说明它们是怎么同时存在的。适合正在搭 Agent、做技术选型、或者被各种新概念绕晕的人参考。

1. 三选一是个伪命题：先搞清楚三者到底在解决什么问题

1.1 大部分技术选型争论，其实是在不同抽象层上吵

我先说一个判断：Skill、MCP、插件这三个词，经常被放在同一个句子里比较，本身就是技术社区里最典型的“抽象层级错位”。类比一下，你问“炒菜应该用锅、煤气灶还是菜谱？”这个问题没法回答，因为菜谱管的是怎么做，锅管的是用什么加热，煤气灶管的是热源从哪来。Agent 的能力扩展也是一样的道理。

Skill 管的是“模型知道该怎么做”，MCP 管的是“模型能连接到什么外部能力”，插件管的是“Agent 在哪个宿主环境里被使用、以什么形式呈现”。这是三个不同的问题，答案也应该是三个一起给，而不是挑一个。

很多人在 Agent 项目启动时先开会讨论“我们到底是走 Skill 路线还是 MCP 路线”，这个会一般开到最后结论都是“都要”。真正该讨论的是：当前这个具体需求，主要卡在“不会做”“连不上”还是“交互入口不舒服”上。

1.2 Skill：教 Agent“怎么做”的可复用能力包

先讲最近的爆款概念 Skill。广义上，Skill 是任何可复用的“做事方法”封装：如何拆解任务、按什么顺序执行、什么情况下用什么工具、输出长什么样。狭义上，在 Claude Code、Codex 这类编码 Agent 的生态里，Skill 通常表现为一个目录，里面放了一个SKILL.md描述文件，再加上若干辅助脚本、参考文档、示例输出。

以 Claude Code 的 skills 机制为例，一个 Skill 目录至少包含：

• 技能名称和名称空间；
• 触发条件的明确描述（什么时候该调用这个 Skill）；
• 完整的工作流步骤；
• 输入参数和输出结构的定义；
• 一个或多个示例，让模型知道“做到什么程度算完成”。

为什么需要这么正式？因为 Skill 本质上是把“行业经验”转化成“模型能稳定执行的流程”。比如你写一个 GIS 空间分析 Skill，不是告诉模型“你会做空间分析就行了”，而是要把“加载数据→重投影→缓冲区分析→制图→输出报告”这个流程固定下来，连每一步用什么参数、中间结果放在哪里都要写清楚。

类似的还有“论文写作 Skill”“测试用例生成 Skill”“内容选题 Skill”，本质上都是把领域方法论塞进模型的工作记忆里。它最大的特点是：不需要额外的服务进程，不依赖特定宿主，只要你把 Skill 文件放在模型能读到的地方，模型就能按这套 SOP 走。

1.3 MCP：统一“能连什么”的标准协议

MCP（Model Context Protocol）解决的是另一个问题：模型怎么稳定、标准地调用外部工具和数据源。

在 MCP 出现之前，每个 AI 应用想接一个数据库或者一个搜索服务，都要专门写一套 API 适配代码。你接了一个搜索服务，换一个 Agent 框架又要重新写一遍。MCP 做的事情就是把这个“适配层”标准化了：它基于 JSON-RPC 2.0 消息格式，把模型和外部工具之间的对话方式统一起来，整个架构分成 Host（宿主）、Client（宿主内部的连接器）、Server（提供工具/资源/提示的服务端）三层。

MCP Server 对外暴露三类核心原语：

• tools：可被模型调用的外部动作，比如“搜索网页”“查询数据库”“发送文件”；
• resources：可被模型读取的外部数据，比如某个仓库的文档、某张表的内容；
• prompts：预先编排好的提示模板，可以理解为 Server 端提供的 Skill 片段。

把这三样统一之后，模型只要会“说 MCP 这一种语言”，就能调用所有支持 MCP 的软件能力。这也是为什么连 Unreal Engine 5.8、Altium Designer 这种专业设计软件都开始做 MCP 接入——做一个 MCP Server，就等于让所有主流 Agent 都能直接操作这个软件。

MCP 的定位非常清楚：它管的是“模型的手能伸到哪里”，是连接层，不是智能层。

1.4 插件：绑定“在哪运行”的宿主集成器

插件是这三个概念里最传统的，它的本质是“宿主应用的扩展单元”。浏览器有浏览器插件，IDE 有 IDE 插件，内容平台有平台插件。插件可以拥有自己的界面、监听宿主事件、读取宿主数据、调用宿主 API，它跟模型的理解能力没有直接关系，就算没有大模型，插件也照样能运行。

在 Agent 场景里，插件负责的是“入口、展示、权限、和宿主系统的交互”。举个例子，你在 VS Code 或者 IntelliJ IDEA 里开发一个 Agent 管理面板，左侧树形列表展示任务状态，底部窗口输出日志，点一个按钮触发任务流水线——这部分功能做成插件是最合适的，因为它要用到 IDE 的 UI 系统和事件机制。你总不能让 Agent 每次都靠命令行敲脚本来看状态，那样用户根本没法用。

我一线的体感是：很多人把插件这个概念泛化了，把所有扩展都叫插件。但真正做架构的时候，插件是“住在某个应用里”的那一层，它负责跟宿主打交道，而不是负责教模型怎么做业务。

为了帮助你快速建立区分，我把三者做了一个对比表格，平时做方案评审时可以直接拿过来用：

所以结论很直接：Skill 告诉你“怎么想”，MCP 帮你“够得着”，插件给你“住得下”。三件事不是竞争关系，是互补关系。

2. 一次完整 Agent 项目里，三者是如何同时上场的

讲概念容易，放到项目里就容易糊涂。我拿一个真实做过的项目举例：搭一个内容发布 Agent，需求是“搜集热点 → 生成文章 → 审核 → 发布 → 备份数据”，最后要在一个可视化面板里一键启动整条流水线。

这个项目刚好三层都用上了，而且缺一层架构都不完整。

2.1 Skill 层：把内容生产的流程固化成技能

我首先定义了几个 Skill 文件，放在一个skills/目录下。第一个叫“热点分析”Skill，它的职责是告诉模型：拿到热榜数据之后，先按平台调性筛选出三个潜在选题，每个选题注明依据和参考语料，而不是直接开始写文章。第二个叫“文章写作”Skill，规定的步骤是：读取选题表里的输入字段（调性、目标用户、字数、标题要求），先搭提纲，再写正文，最后做 SEO 关键词检查。第三个叫“发布前审核”Skill，这个 Skill 会要求模型在调用发布工具之前，先检查文章里有没有敏感词、链接是否有效、排版是否符合平台规范。

每个 Skill 的SKILL.md大致长这样：

--- name: article-review description: 发布前对文章进行敏感词、格式、链接检查 when_to_use: 当一篇文章准备发布或保存草稿时 version: 1.0.0 --- # 输出要求 1. 输入：草稿正文的完整内容。 2. 第一步：扫描敏感词列表，输出命中项。 3. 第二步：检查 Markdown 标题层级是否跳到二级以上。 4. 第三步：对所有外链做可达性判断并标记可疑链接。 5. 输出：结构化审核报告，包含“通过/不通过/需修改”三个字段。

写 Skill 的时候有个很关键的认知：模型不会因为你写了一句“请审核文章”就真正按流程来。Skill 的价值在于把流程步骤写死，让模型的每一次调用都有边界。哪怕这个边界只是几段自然语言，也比让模型自由发挥稳定得多。

2.2 MCP 层：让 Agent 真正拿到外部数据并执行动作

光有 Skill 还不够，因为模型本身没有热榜数据，也没有发布能力。这时候 MCP 上场了。

我为这个项目起了三个 MCP Server：

• 搜索信息 MCP Server：封装一个搜索引擎 API，接收search(query, count)工具，返回结构化搜索结果；
• 内容库 MCP Server：封装草稿箱数据库，暴露save_draft(document, tags)和fetch_drafts(status)两个工具；
• 平台发布 MCP Server：对接分发平台的草稿接口，暴露create_draft(article, platform)和publish(id)。

有了这三个 Server，模型就能在运行时“即插即用”地访问外部系统。更关键的是，MCP 把“接口适配”和“业务逻辑”分开了。今天我如果想把搜索引擎换成另一个服务，只需要改 MCP Server 内部的 HTTP 调用逻辑，Agent 端的 Skill 完全不用动。

MCP Server 的配置就是一份 JSON 清单，标明哪些工具暴露给客户端：

{ "mcpServers": { "content-store": { "command": "node", "args": ["/path/to/content-store-server.js"], "env": {"DB_URL": "postgres://..."} }, "publisher": { "command": "python", "args": ["/path/to/publisher_server.py"], "env": {"PLATFORM_TOKEN": "${PLATFORM_TOKEN}"} } } }

这段配置的价值在于：你把“能连什么”显式地声明在环境里，Skill 只需要知道“有 content-store 这个工具可以用”即可。工具解耦靠的就是这一层。

2.3 插件层：把整条流水线变成用户可操作的面板

最后，用户在真实工作环境里不可能每次都用命令行去触发 Agent。我在宿主应用（这里是一个 IDE 环境）里写了一个插件，功能包括：

• 侧边栏里显示当前流水线状态：正在选题 / 写作中 / 等待审核 / 已发布；
• 提供一个“一键启动”按钮，触发整条流水线；
• 在底部输出面板显示每一步的工具调用日志；
• 把漏水状态存到插件自己的存储里，支持任务历史回看。

插件在这里没有做任何业务判断，它只是负责“把任务交给 Agent 的 Skill 机制，把结果显示在界面上”。为了让插件和 Agent 通信，插件里只需要一个调用入口函数，大致是：

async function startPipeline() { const taskId = generateTaskId(); log(`[pipeline] start task ${taskId}`); await agent.run("hotspot-analysis", { platform: "xiaohongshu" }); const draft = await agent.run("article-writing", { taskId }); const review = await agent.run("article-review", { draft }); if (review.passed) { await agent.run("publish", { draftId: draft.id }); } updatePanel(taskId, "done"); }

看出来了吗？这个插件本身就是“胶水”，它把 Skill 定义好的流程编排成一个完整的用户业务动作，但流程内容本身全部在 Skill 层。三层各司其职，整条流水线才能闭环。

2.4 一次完整执行里，三层是怎么协作的

为了更直观，我按时间线描述一次实际运行过程：

1. 用户点击插件面板的“一键启动”按钮；
2. 插件调用 Agent 运行时，加载“热点分析”Skill；
3. Agent 按 Skill 里写好的步骤，调用搜索信息 MCP Server 的search工具；
4. MCP Server 返回热榜数据，Agent 把候选选题写成一个 Markdown 文件存到本地工作区；
5. 插件面板状态变为“写作中”；
6. Agent 继续加载“文章写作”Skill，生成草稿，再把草稿交给“发布前审核”Skill；
7. 审核通过后，Agent 调用平台发布 MCP Server 的create_draft工具把文章写入草稿箱；
8. 插件检测到流程结束，拉取工具调用日志并展示在面板里。

这个过程中，Skill 管着第 3、6、7 步“该做什么、按什么顺序”，MCP 管着第 3、7 步“数据从哪取、东西往哪发”，插件管着第 1、5、8 步“用户怎么触发、怎么看到结果”。如果你把其中任何一层去掉，整个闭环都会断掉：没有 Skill，模型不知道该按什么流程做；没有 MCP，模型没有数据和动作来源；没有插件，用户压根没法用。

3. 先选 Skill 还是先选 MCP：按能力边界做判断，而不是按流行度

我在做技术咨询的时候，经常被问到“新功能到底做成 Skill 还是 MCP”。这个问题本身是合理的，因为二者虽然不互斥，但确实存在一个“是谁的主场”的判断。我的经验是不要看哪个概念火，要看你要扩展的这个能力本身属于什么类型。

3.1 判定一：能力是否需要跨平台复用

如果你的能力封装是“方法论层面的”，换到任何 Agent 平台都应该能用，那首选 Skill。

典型例子是“GIS 空间分析 Skill”“论文写作 Skill”“复盘总结 Skill”。这些能力不绑定某个特定的软件接口，它依赖的是模型的推理。只要你把步骤、检查项、示例写清楚，拿到 Codex、Claude Code、豆包或者其他任何支持 Skill 的 Agent 里都能跑。做成 Skill 的迁移成本几乎为零。

反过来，如果这个能力离不开某个平台的专属 API，比如你的编辑器插件要监听文件的保存事件、读取当前打开的文件路径，那它天然就是插件层的东西。

3.2 判定二：交互是依赖提示工程还是有明确 API

这是最核心的一条判断标准。如果功能的核心是“让模型更聪明地完成编排、推理、质量检查”，那这是 Skill 的活；如果功能的核心是“稳定地调用某个外部服务的确定接口”，那这是 MCP 的活。

举个例子：“浏览网页内容并提取摘要”这个问题，很多人一开始会尝试用提示词让模型“自己从网上摘录”，结果模型经常编造链接。正确做法是把抓取网页逻辑写成一个 MCP Server 工具，返回干净的文本给模型，模型拿到文本后按 Skill 里规定的摘要模板输出。前一半是 MCP，后一半是 Skill。

再比如“用心理学模型分析用户画像”，这个分析框架完全是提示工程层面的，做成 Skill 就足够，不需要新建一个服务。

3.3 判定三：有没有现成的协议生态可用

在做工具连接之前，先搜一下这个外部系统是否已经有人写好 MCP Server。现在主流软件生态的适配速度非常快，像 Unreal Engine、Altium Designer、各种数据库、浏览器组件，都能找到现成的 MCP 接入方式。有就用，别自己造一个私有协议。

如果你要连接的系统没有现成 MCP Server，但是 API 文档齐全，自建一个 MCP Server 也不难。MCP Server 本质上就是一个轻量级 JSON-RPC 服务，包裹一层鉴权和参数映射就行。不要为了省事把业务逻辑全塞进去，这个坑后面专门说。

3.4 判定四：是否需要宿主的 GUI、事件、权限

需要界面或者需要跟宿主深度交互，就必须做插件。模型再聪明也没法长出侧边栏，也没法监听快捷键。Agent 的使用体验最终是由插件这一层决定的。

我见过一些团队试图把插件里的 UI 用自然语言描述给模型，让模型去生成一个 HTML 页面来代替。对原型验证可行，但对正式产品来说体验差距太大。原生插件的响应速度、系统集成度、离线能力，都是临时方案比不了的。

3.5 我整理的五问快速判断表

这张表不是绝对的，但在这个项目启动阶段可以帮你快速定位绝大多数需求。记住一个原则：优先想清楚“这个需求到底卡在哪一层”，再选技术方案，而不是反过来套概念。

4. 被卡住最多的三个误区：不是工具不行，是用法错了

真正实际操作后你会发现，概念搞清楚了只是第一步，落地时还有三个特别典型的坑。我基本都踩过，下面逐个说。

4.1 误区一：把 Skill 写成“一句话提示词”

我见过很多团队的 Skill 目录长这样：

# 写作助手 你是专业的内容创作者，请在接到任务后写一篇高质量的文章。

这不是 Skill，这是一个没有边界的提示词。模型拿到它之后，根本不知道什么叫“高质量”、写作步骤是什么、输出结构长什么样、需要检查哪些点。结果就是每次输出随机性极高，质量完全不可控。

真正的 Skill 应该像一份“可执行的岗位说明书”。我在文章写作 Skill 里会写清楚：

• 输入格式：选题、目标平台、目标字数、语气偏好；
• 执行步骤：先搭建提纲 → 再按提纲分段写作 → 插入链接和引用 → 最后做 SEO 关键词覆盖检查；
• 输出格式：Markdown 标题层级、每个段落的核心论点、末尾风险提示。
• 至少附上两个完整示例，一个是“合格输出”，一个是“不合格输出”。

经验是：Skill 越像一份能让新员工照着干活的标准作业程序，效果越好。别嫌写得长，写 Skill 本身就是在做知识工程。

4.2 误区二：让 MCP Server 承载业务逻辑，做成了万能服务

MCP 的定位是“连接标准”，不是“业务后端”。但很多人很容易写偏：把几十个工具、各种业务规则、状态管理全部塞进一个 MCP Server，甚至还在 Server 内部维护对话状态。结果就是模型调用工具链的时候非常笨重——为了完成一个简单的动作，连续调用了七八个工具，上下文被撑爆，还容易出错。

MCP Server 的正确姿势是“原子化的工具集合”：每个工具只做一件确定的事，无状态，输入输出都是标准 JSON。业务逻辑、步骤编排、决策判断，都应该放在 Skill 层靠模型的推理来组合。

举例来说：

• 正确的做法：MCP Server 暴露query_candidates(keyword)，Skill 层决定先查 5 个关键词再合并结果；
• 错误的做法：MCP Server 暴露suggest_best_topics()，内部已经写死了选题逻辑，模型只是按按钮。

后者看起来方便，实际上把本该支持灵活编排的智能层变成了硬编码，换个场景整个工具就没法复用。

4.3 误区三：插件里套 Skill，适配层越写越复杂

第三个坑反过来，有人把所有逻辑都塞进插件代码里。插件里不仅写 UI，还写“热点分析”的流程、文章写作的提示词、发布审核的规则。看起来也是三层都齐了，但实际上把 Skill 该干的活全硬编码到了宿主应用里。

这样做带来的问题非常直接：想调整写作风格，必须改插件代码、打新包、发新版本；而用 Skill 的话，只需要改一个 Markdown 文件，Agent 下次运行时自动生效。而且硬编码在插件里的逻辑没法跨平台复用，换一个宿主环境全部重写。

每次有团队抱怨“我们插件越维护越重”，一查基本都是这个问题。正确的分工是：插件只管宿主的壳，代码里不要出现任何业务提示词和业务上下文，所有业务规则都应该放在 Skill 或 MCP Server 里。这样插件的代码量能砍掉一大半，后续的迭代速度也会明显快起来。

4.4 这三个坑背后的共同根源

把这几个误区放在一起看，你会发现它们都是同一件事：把三层机制混着用了。Skill、MCP、插件各自有明确的职责边界，你在某一层里做了不该它负责的事，架构就会变糊。

我给自己定了一个检查原则：每次新增加一个扩展能力时，先问它属于哪层，如果说不清楚就暂缓设计。如果说着说着发现同一件事既要写 Skill 又要在插件里改逻辑，那就是职责重叠了，必须削掉一边。

5. 我自己整理的三层能力扩展落地清单和顺序

最后给一份可以直接照着执行的落地清单。这套顺序是我做了十几个 Agent 扩展项目后沉淀出来的，能避免绝大部分返工。

5.1 从最小闭环开始：先写 Skill，再接 MCP，最后才是插件

很多人搭 Agent 时喜欢先把所有基础设施配好，再开始做功能。我的建议反过来。

第一步，先把最痛的单点任务做成一个 Skill，用最笨的方式在命令行里跑通。比如你的痛点是“文章发布前总忘检查敏感词”，那就先写出一个能用的审核 Skill。哪怕这时候还要手动复制文本进去，都没关系，先把质量和流程折腾对。

第二步，接入 MCP。把外部数据的获取动作，比如“读取内容库”“调用搜索接口”，暴露成 MCP 工具。然后回头修改 Skill，让模型在对应步骤里去调用工具。这一步的目的不是炫技，而是把原来手工搬运数据的动作自动化。

第三步，再考虑插件。当整个流程在命令行里稳定跑通之后，再去做界面、入口、状态展示。否则你插件做得再漂亮，底层的流程没有闭环，用户用一次就会失去信任。

这个顺序很重要，因为流程没稳定之前做 UI 是最容易返工的。

5.2 命名、版本与依赖管理：扩展多了以后系统会教你做人

等你的 Skill 和 MCP Server 数量多起来，管理就成了新问题。我现在会强制自己遵守几个约定：

第一，Skill 目录用“业务域名反序 + 技能名”的命名规范，比如com.company.marketing.hotspot-analysis，这样多个团队协作时不会撞名，也方便按业务域归档。

第二，每个 SKILL.md 文件头部写版本号、作者、最后修改时间。Skill 本质上是知识资产，必须像代码一样可回溯。我见过有人改了一版 Skill 后模型行为大变，却完全不知道改了哪个文件的案例。

第三，MCP Server 的配置里，环境变量和工具列表要单独维护一份 Markdown 文档。工具改名、删除都要同步更新文档，否则团队里其他人接入时只能靠猜。

第四，插件的发布包遵循宿主应用的标准格式，同时把版本号和 Skill 需求版本号关联起来。插件下层依赖的 Skill 版本升级时，插件要检测到并给出明确提示，而不是静默失效。

5.3 测试与回滚：Agent 能力扩展最容易忽略的部分

很多人以为 Agent 扩展不需要测试，跑通一次就算完。那是把“碰巧成功”当成了“稳定可用”。

我在日常工作中至少会做三层测试：

Skill 层，准备“输入输出样例集”。每个主流程至少 5 组输入样例，每组注明期望的输出结构。每次修改 Skill 后，用这组样例跑一遍回归，看有没有偏离预期。

MCP 层，先做 dry-run。实际调用外部服务前，用模拟数据启动 Server，验证工具的参数校验、鉴权和错误返回。外网服务不稳定是常态，所以还必须为超时、限流、断连设计明确的报错返回，别让模型蒙在鼓里。

插件层，加一个 feature flag。新功能先灰度到内部用户，收集日志再全量开放。一旦出现异常，可以秒级关闭功能而不影响 Agent 主流程。

另外一项很实用的做法是，把 Agent 每次执行的工具调用链日志保存下来。出问题时第一件事不是猜模型为什么答错，而是翻日志看它在第几步开始偏离 Skill 的定义；是调用了不存在的工具，还是中间跳过了某个检查步骤。有了完整日志，你才能区分到底是 Skill 写得不清楚、MCP 工具返回格式有问题，还是插件入口传参传错了。

5.4 我的个人体会

如果你也正在给 Agent 做能力扩展，我建议你把三张图纸同时铺开：一张画模型怎么“做成事”的技能栈，一张画外部世界连接方式的协议表，一张画宿主环境交互的界面层。先别急着自己三选一，先各归其位。

等三层都摆清楚了，你会发现大部分纠结早就消失了。真正难的不是选型，而是把一个流程里的“知道怎么做”“能连接到什么”“在哪跑起来”拆开想明白。每层做好每层的事，Agent 的能力扩展才不会变成一团乱麻。