1. 先说结论三个概念根本不是选一个的关系最近在各个技术群里关于 AI Agent 能力扩展的讨论明显变多了。大致是这么个画风有人发帖问我想给我的 Agent 加个搜索能力到底是用 Skill 还是配 MCP 还是写插件底下吵成一团。还有人把 Skill 编码编号成 247、193 之类的像追星一样囤积各种技能包另一拨人天天研究 MCP 协议翻来覆去追问mcp 是软件协议还是硬件协议还有一波人在折腾 IDE 插件、Figma 插件认为把 Agent 塞进已有的软件生态才叫真本事。热闹是热闹但大多数讨论从一开始就跑偏了——大家都在纠结三选一可这三样东西压根就不在一个维度上。先说我的结论后面慢慢拆Skill、MCP 和插件分别是 Agent 能力扩展在不同层面上的三种实现方式它们解决的是不同性质的问题正常项目里往往会同时用到。如果非要用一句话概括Skill 是教 Agent 怎么做事MCP 是让 Agent 能接到外部工具和数据而插件是把 Agent 嵌进某个宿主应用的内部生态。一个是方法层面一个是连接层面一个是集成层面。你不可能只用其中一种就覆盖所有扩展需求也不可能说某种方案取代另一种。那为什么会有三选一的错觉我观察下来主要是因为很多教程喜欢拿某一个具体的场景来举例。比如讲 Claude 的 Agent Skills 就用 markdown 写提示词讲 MCP 就拿 GitHub、数据库连接做演示讲插件就拿 VSCode、Chrome 扩展说事。三个场景都用了给 Agent 加能力这个动作但背后的技术栈完全不同读者就会误以为这是三条互相排斥的路线。再加上各平台宣传口径不一致有的叫技能有的叫插件有的叫工具调用function calling概念混在一起不踩坑才怪。这篇文章我就想把三者的边界彻底捋清楚然后给出一个真实项目里可落地的选型和协作思路。适合正在搭 Agent 应用、被各种名词绕晕的开发者也适合已经在用某一种方案、想搞清楚另外两个到底是不是必选项的人。2. Skill 没那么神秘本质是给模型的一套操作手册2.1 Skill 在不同平台里的三种长相Skill 这个概念在不同平台落地的时候长得完全不一样这是它容易被误解的根源。先说 Anthropic 这边带火的 Agent Skills。它的形态其实是一组文件一个 SKILL.md 描述文件加上若干参考示例和资源文件全部放进.claude/skills之类的目录里。模型在运行时会读取这些内容按照里面写的步骤去完成任务。它本质上就是精心组织过的提示词和示范用例的集合不涉及任何网络请求也不依赖某个服务端框架。再比如说 OpenAI 那边的自定义 GPTs它的Actions其实也是 Skill 的一种形态——只不过是把工具的 OpenAPI 描述和调用说明绑定在了一起让模型知道这个工具能干什么、参数填什么、什么时候该调它。还有国内平台像扣子Coze的技能、豆包的技能等更是直接做成了一站式的技能编辑器你不需要写代码在里面配置提示词、勾选需要的工具一个技能就算建好了。最近社区里流行的skill 编码 247狗头军师 skill这类说法就是在这种生态下诞生的亚文化——因为生产一个技能的门槛太低大家开始像收集周边一样囤技能包。尽管形态各异它们的本质是一样的Skill 是一组任务级的指导材料作用是让模型在面对特定任务时知道该用什么样的策略、分几步走、调用哪些现成能力。2.2 为什么 Skill 注定是最轻量的一层Skill 和另外两个方案最大的区别在于它不改变 Agent 的运行时边界只是在提示层面注入知识和流程。打个比方。MCP 和插件解决的是手脚够不够长的问题Skill 解决的是脑子转得够不够清楚的问题。你要让一个 Agent 帮你写一份行业分析报告就算你的 Agent 已经接入了搜索 API、数据库、各种工具它也可能不知道一份好报告应该包含哪几个章节、数据应该从哪里找、怎么组织语言逻辑。这时候 Skill 上场它把这些隐性经验显式地写成一份操作手册塞给模型模型照着手册来完成整个任务。正因为 Skill 只是文本层面的东西所以它的生产成本极低。一个稍微懂点提示词的人花十几分钟就能写出一份像模像样的 Skill。而且它不需要单独部署服务不需要考虑鉴权、网络、协议版本改动也只需要改文件内容就行。这就是为什么很多项目第一步选择 Skill 扩展——它廉价、灵活、迭代快。但也恰恰因为太轻它有个先天短板无法完成任何真实的连接动作。Skill 写得再详细模型也没办法凭空调起你本地的数据库更没办法操作一个外部 Web 服务。那些真正需要数据流通的操作必须落到另外两层去解决。2.3 别把所有东西都往 Skill 里塞我见过一类典型误区把业务逻辑全写进 Skill 里。比如有人想把复杂的权限判断、多分支流程控制都塞进 SKILL.md让模型自己去理解并且严格执行。结果就是提示词越写越长最后两万多个 token 全是规则文本模型反而抓不住重点执行效果一塌糊涂。Skill 的正确使用姿势是克制。它应该描述做什么、按什么顺序做、有哪些质量要求而不是把程序该干的活全给它。如果你发现某个 Skill 里需要写大量分支条件、状态判断那多半该把这块逻辑下沉到代码层或者工具层做成一个真正的工具函数、MCP Server 或插件再由 Skill 去调用它。这个边界想清楚后面三个方案怎么配合就顺了。3. MCP把接入这件事从代码变成了协议3.1 先回答那个热搜问题MCP 到底是软件协议还是硬件协议mcp 是软件协议 硬件协议那个概念叫什么来着——这个热搜词我看了都有点哭笑不得。MCP 是软件层面的通信协议全称 Model Context Protocol模型上下文协议。它定义的是大模型应用和外部工具/数据源之间怎么对话、怎么请求、怎么返回跟硬件一点关系都没有。但那个问题的潜台词其实很有意思写协议的人心里会把它类比成什么最准确的说法是MCP 就像软件世界的USB-C 接口。USB-C 定义了一套统一的物理接口标准鼠标、键盘、显示器、移动硬盘只要照着这个标准做插上就能用。MCP 做的就是这件事——它定义一个标准的工具接入接口任何工具服务商只要照着 MCP 协议暴露自己的能力任何大模型应用只要实现了 MCP 客户端就能直接对接不再需要为每家服务商写一套定制的集成代码。在 MCP 出现之前每接一个新数据源、新工具你都得写胶水代码封装 API、处理鉴权、把返回数据转换成模型能理解的格式。工具一多整个项目到处都是自研的Adapter。MCP 的意思就是这套东西太重复了不如统一成一个协议。3.2 Host、Client、Server 三方是怎么协作的MCP 的架构里有三个角色很多人第一次看容易绕晕Host宿主进程通常就是你的 Agent 应用本身负责加载配置、管理会话、决定要不要调用工具。ClientHost 内部的 MCP 客户端组件负责跟远程的 MCP Server 建立连接、发送请求。Server暴露了特定能力的服务端进程可能在本机也可能在远程通过协议向外提供工具工具列表和执行接口。实际跑起来大概是这样的流程Agent 启动时Host 按照配置文件拉起一组 MCP Client每个 Client 连到一个 MCP ServerClient 首先向 Server 拉取工具清单然后把这份清单交给模型让模型知道当前可用的工具列表模型在生成的推理过程中决定调用某个工具时Host 把带参数的请求通过 Client 发给 Server执行完之后结果再被送回到模型那里继续推理。这个流程你不需要完全记住但要抓住一个关键点MCP 真正解决的是连接这个环节的标准化问题而不是能力本身。它不帮你写业务逻辑也不帮你想任务怎么拆分它只是高效地把 Agent 和外部能力联通。也正因如此你会看到 MCP 的生态迅速渗透到各种软件里。最近连游戏引擎都开始聊Unreal 5.8 mcp还有人把图数据库的 MCP Server 接到 Agent 上做知识图谱查询。像 RuoYi-Vue-Pro 这种传统后台管理框架社区里都有人做了合并 MCP 功能让 Agent 能直接查业务库。3.3 MCP 与 Skill 在运行链路里怎么分工这里必须强调一个经常被忽略的点MCP 和 Skill 不是替代关系它们在运行链路的不同位置工作。我拿让 Agent 查数据库并生成报表来举例。如果没有 MCP你得把数据库连接信息、SQL 写法、返回格式全部写进提示词里模型每次要靠猜去生成可执行的查询又慢又不靠谱。有了 MCP 之后Agent 直接拿到一个query_database工具它知道参数有哪些、返回长什么样查询成功率大幅提升。但问题是模型可能不知道怎么组织一次完整的报表任务——是先查总览数据还是先过滤异常值报表里应该包含哪些维度的对比这种做事方法层面的东西MCP 不负责。你需要的是一个写好的报表生成 Skill告诉模型任务拆几个阶段、每阶段调哪些 MCP 工具、结果按什么格式输出。简单说MCP 提供手Skill 提供脑图。手用来够东西脑图用来指挥手按正确顺序够东西。4. 插件是宿主生态的内挂它的价值被低估了4.1 插件与 MCP Server 的边界在哪里插件这个概念大家太熟了VSCode 插件、Chrome 插件、Figma 插件、WebStorm 插件甚至还在热搜里看到figma 汉化插件musicfree 插件dsh 插件这种日常向的讨论。在 AI Agent 语境下插件通常指的是在某个宿主应用内部通过宿主提供的 API 扩展宿主功能的模块。那它和 MCP Server 有什么区别举个例子你就明白了。假设你想让 Agent 操作 IDE 里的代码。你可以写一个独立的 MCP Server它监听文件变化、执行命令行然后 Agent 通过 MCP 协议调用它你也可以直接写一个 IDE 插件注册成 IDE 的扩展点在 IDE 的 UI 上增加一个面板直接在面板里跑 Agent 对话流。两者的核心差异在于集成深度和运行边界。MCP Server 是独立于宿主应用之外的进程它跟宿主只通过标准协议打交道优点是跨平台、跨应用通用插件则必须在宿主进程内运行能直接调用宿主的内部 API操作 UI、监听事件能做到非常深度的融合缺点是跟宿主强耦合换一个宿主就得重新写一遍。很多人以为有了 MCP 就不需要插件了这是第二个误区。MCP 再通用也无法直接替你做 IDE 里的语法高亮联动、自动补全触发、菜单注册这类事情——那些必须依赖宿主自身的扩展机制。4.2 从 IDE 到游戏引擎为什么生态里到处都有插件插件机制的适用范围比你想的还要广。最近我注意到几个典型案例VSCode/WebStorm 插件把 Agent 直接嵌入编辑器写代码时旁边就是一个 Agent 对话框选中代码右键发给 Agent 重构。这种体验 MCP 很难替代因为它依赖的就是 IDE 自身的交互事件系统。Figma 插件设计师想要 AI 辅助排版直接在 Figma 里跑一个插件插件调 Agent 的 API 完成自动命名、批量改样式、生成设计规范。你很难把这套体验用纯 MCP 复现因为插件可以直接遍历画布上的节点。Unreal 引擎 5.8 的 MCP 插件这个品类比较有意思它其实是插件MCP结合的产物——用插件形式把 MCP Server 塞进引擎编辑器Agent 通过 MCP 协议才能在引擎里执行各种操作。如果只有 MCP 没有插件Agent 根本无法触达引擎内部的编辑器上下文。这里我额外提一句热搜里idea 插件开发这个词条。很多人想学插件开发是冲着给 AI 做一个入口去的这个方向没问题但务必想清楚一件事插件的价值是让 Agent 参与宿主应用的原有工作流而不是在宿主里跑一个独立的 Agent 壳子。如果只是把 Chat 对话框嵌进去那其实用浏览器开个网页也没什么区别。真正有价值的是把宿主的数据对象、事件钩子、操作命令开放给 Agent让它有点像一个会使用该软件的实习生一样干活。4.3 插件适合什么场景从我接触过的项目来看插件最不可替代的场景有这几类第一类是高频交互场景。用户在 IDE/Figma/浏览器里干活顺手就要用到 Agent你不能要求用户切到另一个应用去对话。嵌入式的入口节省了上下文切换成本体验天差地别。第二类是需要深度操作宿主对象的场景。比如批量重构代码、批量整理设计稿图层、自动管理浏览器标签页这些操作如果不是以插件身份去调用宿主 API光是权限和安全模型就能让你痛不欲生。第三类是把 Agent 能力打包给非技术用户。很多做内部工具的企业最后都会选择把 AI 能力做成 Chrome 插件或者企业微信内置应用因为终端用户不会配 MCP Server也不习惯命令行。插件是离用户最近的形态。5. 真实项目里怎么搭一个三层扩展的参考架构5.1 选型原则先定边界再选方案我自己在项目里做扩展设计时会先问三个问题这个能力是教模型该怎么做还是让模型能碰到某个东西被扩展的对象是通用能力比如查天气、调数据库、访问 GitHub还是某个特定应用内的深层操作比如操作 Figma 节点、在 IDE 里改文件、操作浏览器标签用户是在一个宿主软件里使用 Agent还是在独立的 Agent 界面里使用回答了这三个问题答案基本就出来了如果你的目标是教会模型高效完成某类任务用Skill。如果目标是让 Agent 稳定地对接一个或多个外部服务而且这些服务本身是通用的、需要在多种 Agent 应用里共用优先做MCP Server。如果目标是让 Agent 深度融入某个已有的软件工作流而且你愿意为该宿主单独维护代码那就做插件。注意这三个问题的答案完全可以同时成立所以一个成熟项目里三者并存非常正常。5.2 一个可以抄作业的实际架构我拿一个实际做过的项目来拆解。当时我们给一个 Django 项目搭建内部运营分析 Agent需求是运营人员在网页对话框里提问Agent 能查业务库、能生成分析报告、能操作后台管理界面自动导出报表。整体架构分三层Skill 层写了三份技能文件——业务指标分析 Skill负责告诉模型常见的指标口径GMV、转化率、复购率怎么算、报告该分哪些板块、每个板块的数据从哪些工具取周报生成 Skill负责规定周报模板和语气风格异常排查 Skill负责列出当数据异常时按什么顺序检查。这一层全部是 Markdown 文档迭代太快了运营觉得报告重点不对我改一下文档就上线。MCP 层写了一个业务数据库 MCP Server对外暴露query_orders、query_users、query_inventory等几个工具另外接了一个现有的向量数据库 MCP Server 用于知识库检索。Agent 通过 MCP 协议跟这些服务通信。最直接的收益是模型再也不用靠提示词去猜 SQL 怎么写工具参数和返回 Schema 都是现成的准确率提升非常明显。插件层做了一个后台管理页面的浏览器插件控件运营在后台页面里直接选中一段数据或者报表右键唤起 Agent 进行解释、生成后续分析建议。这一步跟 MCP 完全不冲突它专注的是浏览器页面内的交互体验Agent 在后端还是走 MCP 去取数但入口和上下文是通过插件注入的。这套架构跑了一段时间我的体会是三层各自的演进节奏完全不一样这也是为什么把它们拆开维护反而是种解放。Skill 每周都可能改一次MCP Server 一个季度可能才增加一两个工具插件则是跟着后台系统的版本走。如果当初图省事把三者揉成一个超级工具层改一次就要牵动全局测试成本和风险都会成倍上涨。5.3 三者的维护成本对比很多人在选型时其实最关心的还是成本我直接放一个根据实际经验做的对比维度SkillMCP Server插件开发门槛极低会写提示词就能做中需要理解协议和 Server 开发高需要熟悉宿主 API 生态迭代效率改文件即可分钟级需要改代码、重新部署需要改代码、构建、发版通用性单一 Agent 内生效跨 Agent、跨应用通用仅宿主内生效部署依赖无需要维护 Server 进程/网络/鉴权需要跟着宿主版本走稳定性风险低内容是静态的中网络抖动、鉴权过期、版本兼容高宿主升级可能破坏插件能接入外部数据否纯提示层面是核心价值视宿主 API 能力而定这个表如果你现在记不住就记住一句话越轻量的越灵活越通用的越复杂越深度的越依赖宿主。排列组合下来正好是三个互补的生态位。6. 落地时最容易踩的四个坑6.1 坑一Skill 写太多导致上下文爆炸前面说过 Skill 很轻所以很多人会忍不住写很多。我一个朋友的项目里挂了三四十个 Skill每个都是几千字的详细手册。结果模型每次都要在大脑上下文窗口里把这些内容全读一遍还没开始干活上下文就占掉一大半回答质量肉眼可见地下降成本也直线上升。解决办法是分层加载。别把所有 Skill 一股脑全部塞给模型只把当前会话必需的 Skill 注入。现在不少框架已经支持按需加载先让模型看目录清单判断当前任务需要哪几个技能再动态读取对应的 Skill 正文。有点像你读书先看目录再翻章节而不是整本书同时摊开在面前。6.2 坑二MCP Server 的鉴权和稳定性能让人崩溃MCP 协议本身不复杂但真实世界里鉴权才是大头。热搜里那个codex 接入 figma mcp 怎么授权就是典型问题——你的 Agent 要远程调 Figma 的接口Figma 需要 OAuth 授权MCP Server 侧怎么保存 Token、怎么刷新、怎么在多用户之间隔离这些都是工程细节处理不好跑着跑着就 401。我的建议是启用 MCP 之前先把两类情况想清楚本机运行的单用户模式可以直接用本地环境变量存 Token简单粗暴但只要能预先想到会部署到服务器、多用户共用就必须做独立的凭证管理用密钥存储服务统一管理并给每个用户单独维护授权上下文。别图省事把 Token 写死在配置里上线必炸。还有一个无关鉴权但是同样高频的问题MCP Server 进程莫名挂掉。尤其本机跑的 stdio 模式Agent 一断连 Server 就死。生产环境尽量用 streamable HTTP 模式部署成独立服务配合健康检查和自动重启不然你会被Agent 今天怎么又连不上工具了这种问题烦死。6.3 坑三插件与 Agent 框架的版本地狱插件要和宿主软件深度绑定而宿主软件的版本更新你控制不了。VSCode 一个季度更新一个大版本Figma 经常静默改 APIChrome 就更不用说了。你一个月前写好的插件下个月可能就因为宿主调整了某个内部接口而失灵。做插件开发一定要有顺风车心态宿主更新了你跟着改别指望宿主为你做兼容。项目里凡是涉及插件的模块我都建议做两层隔离一是插件壳子和业务逻辑层分开业务逻辑尽量只依赖稳定的 API宿主相关的调用集中在壳子的薄薄一层二是做好自动化冒烟测试每次宿主升级后第一时间跑一遍核心链路别等用户投诉了才发现坏了。6.4 坑四把扩展能力和并发能力混为一谈ai agent 怎么扛并发这类热搜词我没法忽视。很多人以为给 Agent 多挂几个 Skill、多接几个 MCP Server 就等于能力变强了然后就能扛住高并发。这是完全跑偏了。扩展能力解决的是能做什么并发能力解决的是多少人同时用都不卡两个话题几乎不相关。你的 Agent 要扛并发该考虑的是推理服务本身的伸缩性、任务队列、缓存层、请求限流这些基础设施层面的东西而不是在 Skill 列表里多加两个技能包。甚至可以说Skill 和 MCP 接得越多如果中间任何一环不稳定并发压力下反而更容易出故障。扩展能力是功能堆叠并发能力是工程架构别用功能堆叠去冒充架构优化。最后再补充一句自己的体会在真实项目里我几乎没见过哪套 Agent 应用只用了某一种扩展方式就能活得很舒服的。Skill 负责教会模型干活MCP 负责把外部世界接进来插件负责让 Agent 融进用户原有的工作流——它们是在中文互联网的讨论里被对立起来但在真实系统里从来都是并肩作战的。你唯一需要做的就是根据你的场景给它们各自分好工然后控制好维护边界。