最近身边不止一个人问我同一个问题给 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统一“能连什么”的标准协议MCPModel 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 每次都靠命令行敲脚本来看状态那样用户根本没法用。我一线的体感是很多人把插件这个概念泛化了把所有扩展都叫插件。但真正做架构的时候插件是“住在某个应用里”的那一层它负责跟宿主打交道而不是负责教模型怎么做业务。为了帮助你快速建立区分我把三者做了一个对比表格平时做方案评审时可以直接拿过来用对比维度SkillMCP插件扩展层级模型智能层工具连接层宿主应用层核心执行者大模型推理MCP Server宿主运行时 本地代码解决的关键问题告诉模型怎么做让模型能连到什么Agent 住在哪、怎么被使用典型形式SKILL.md 脚本 / 结构化提示词Tools / Resources / Prompts 服务应用扩展包、UI 组件、事件钩子典型场景工作流编排、行业方法论沉淀数据库、浏览器、设计软件接口IDE 面板、浏览器扩展、桌面端入口是否需要独立服务不需要需要 Server 进程依赖宿主应用变更成本改提示词和文档即可改协议实现后重新部署改代码并重新发布扩展包所以结论很直接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 一次完整执行里三层是怎么协作的为了更直观我按时间线描述一次实际运行过程用户点击插件面板的“一键启动”按钮插件调用 Agent 运行时加载“热点分析”SkillAgent 按 Skill 里写好的步骤调用搜索信息 MCP Server 的search工具MCP Server 返回热榜数据Agent 把候选选题写成一个 Markdown 文件存到本地工作区插件面板状态变为“写作中”Agent 继续加载“文章写作”Skill生成草稿再把草稿交给“发布前审核”Skill审核通过后Agent 调用平台发布 MCP Server 的create_draft工具把文章写入草稿箱插件检测到流程结束拉取工具调用日志并展示在面板里。这个过程中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 我整理的五问快速判断表场景推荐优先层级理由想让 Agent 学会公司内部标准流程Skill流程是方法论可跨平台复用想让 Agent 读取数据库并生成报表MCP数据库接口是确定性能力想让 Agent 操作 IDE 当前打开的文件插件依赖宿主上下文和事件想让 Agent 按平台调性写不同文案Skill核心是提示工程和示例想让 Agent 调用某个未接入的 SaaS APIMCP标准化工具连接最合适这张表不是绝对的但在这个项目启动阶段可以帮你快速定位绝大多数需求。记住一个原则优先想清楚“这个需求到底卡在哪一层”再选技术方案而不是反过来套概念。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 的能力扩展才不会变成一团乱麻。 
长河君 · 2026/10/26 9:58:59 · 阅读 1.2k 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统一“能连什么”的标准协议MCPModel 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 每次都靠命令行敲脚本来看状态那样用户根本没法用。我一线的体感是很多人把插件这个概念泛化了把所有扩展都叫插件。但真正做架构的时候插件是“住在某个应用里”的那一层它负责跟宿主打交道而不是负责教模型怎么做业务。为了帮助你快速建立区分我把三者做了一个对比表格平时做方案评审时可以直接拿过来用对比维度SkillMCP插件扩展层级模型智能层工具连接层宿主应用层核心执行者大模型推理MCP Server宿主运行时 本地代码解决的关键问题告诉模型怎么做让模型能连到什么Agent 住在哪、怎么被使用典型形式SKILL.md 脚本 / 结构化提示词Tools / Resources / Prompts 服务应用扩展包、UI 组件、事件钩子典型场景工作流编排、行业方法论沉淀数据库、浏览器、设计软件接口IDE 面板、浏览器扩展、桌面端入口是否需要独立服务不需要需要 Server 进程依赖宿主应用变更成本改提示词和文档即可改协议实现后重新部署改代码并重新发布扩展包所以结论很直接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 一次完整执行里三层是怎么协作的为了更直观我按时间线描述一次实际运行过程用户点击插件面板的“一键启动”按钮插件调用 Agent 运行时加载“热点分析”SkillAgent 按 Skill 里写好的步骤调用搜索信息 MCP Server 的search工具MCP Server 返回热榜数据Agent 把候选选题写成一个 Markdown 文件存到本地工作区插件面板状态变为“写作中”Agent 继续加载“文章写作”Skill生成草稿再把草稿交给“发布前审核”Skill审核通过后Agent 调用平台发布 MCP Server 的create_draft工具把文章写入草稿箱插件检测到流程结束拉取工具调用日志并展示在面板里。这个过程中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 我整理的五问快速判断表场景推荐优先层级理由想让 Agent 学会公司内部标准流程Skill流程是方法论可跨平台复用想让 Agent 读取数据库并生成报表MCP数据库接口是确定性能力想让 Agent 操作 IDE 当前打开的文件插件依赖宿主上下文和事件想让 Agent 按平台调性写不同文案Skill核心是提示工程和示例想让 Agent 调用某个未接入的 SaaS APIMCP标准化工具连接最合适这张表不是绝对的但在这个项目启动阶段可以帮你快速定位绝大多数需求。记住一个原则优先想清楚“这个需求到底卡在哪一层”再选技术方案而不是反过来套概念。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 的能力扩展才不会变成一团乱麻。