Claude 插件目录开放了MCP 连接器与 Agent Skills 怎么打包上架原文Claude Blog - 《Build plugins for Claude》https://claude.com/blog/build-plugins-for-claudeAnthropic 在 2026 年 9 月 25 日宣布Plugins 成为为 Claude 构建第三方扩展的主要方式一个插件可以打包 MCP 连接器、Agent Skills或者两者兼有通过新的目录提交门户审核后上架 Claude 目录。对做 Agent 应用的人来说这件事的分量在于——把外部能力接进模型正在从各家自建私有集成走向有统一打包格式和分发渠道的生态。这篇把插件的组成、两条提交路径、审核链路和上架后的数据面拆开讲清楚。一、插件到底打包了什么官方定义很直接插件打包 MCP 连接器、Agent Skills 或两者是构建 Claude 第三方扩展的主要方式。这句话里其实有三层信息。第一层是 MCP 连接器MCP connector它指向一个远程 MCP 服务器负责把外部系统暴露成模型可调用的能力。第二层是 Agent Skills也就是把某类任务的流程、知识与脚本封装成可复用的技能。第三层是两者的组合连接器回答能调用什么技能回答该怎么用合起来才是一个完整工作流。在 Claude Code 场景里插件还能带上 LSP、commands、hooks 和 agents。也就是说同一种打包格式在不同产品外壳里承载的能力面并不一样——对话场景偏连接器与技能编码场景则要覆盖编辑器语言服务、命令、钩子和子智能体。二、两条提交路径目录提交门户对开发者开放入口是 https://claude.ai/directory/manage/new 账户需在付费 Claude 计划下。官方给了两条路径单一 MCP 连接器直接指向你自己的远程 MCP 服务器。插件包把 MCP 服务器和技能组合起来托管到 GitHub 并提交仓库地址在 Claude Code 中还可以包含 LSP、commands、hooks、agents。这两条路径对应两种成熟度。如果你只是想把已有服务接进 Claude提交一个连接器就够如果你希望用户一次性拿到能力 流程那就得走插件包。官方同时说明了向后兼容已有的 skill、connector 或插件都不需要做任何改动未来还可以把连接器上架项升级成插件。三、上架链路先自动扫再人工审最后自己按发布键提交之后的流程分三步官方描述得比较清楚。一是自动校验与安全扫描。提交即触发检查与安全扫描让问题尽早暴露避免拖到人工审核阶段才被打回。二是审核状态与反馈。开发者能在门户里看到插件处在审核流程的哪一步、安全扫描的结果以及官方建议修改的地方。三是自主发布。审核通过后由开发者决定什么时候在 Claude 中正式发布——审核通过不等于自动上线。这个设计值得留意发布时机交回开发者手里意味着可以等文档、版本、客户通知都准备好再对外放出而不是审核一过就被推着上线。四、MCP 2.0 与两个扩展官方声明 Claude 支持最新的 MCP 规范通常被称作 MCP 2.0其中一个关键变化是 stateless core无状态核心规范链接指向 2026-07-28 这个版本日期。无状态核心影响的是服务端设计会话状态不再必须挂在服务端连接上这对多副本部署、水平扩容和故障恢复都更友好。如果你在写远程 MCP 服务器这一点直接决定了状态该放在哪里。配套的两个扩展是 MCP Apps聊天内的交互式 UI和 Enterprise Managed Auth面向企业用户的零接触 OAuth。官方表示还有更多 MCP 特性与扩展在路上细节以官方文档为准。五、上架之后能看到什么数据插件上线后官方提供两类数据使用分析按产品入口和版本看安装量用来决定先修什么、先做什么。发现端指标列表页浏览量和用户搜索词用来优化曝光。按版本看安装量这条对做插件的人特别有用——一次改动到底是修好了还是改坏了可以直接从版本维度的安装曲线里读出来不必等用户来报障。六、一个最小的远程 MCP 服务示意官方博客没有给出插件的目录结构与配置文件构建细节要看文档https://claude.com/docs/build/overview 具体字段与版本以官方文档为准。下面这段是我自己写的示意代码不是官方示例只用来表达无状态远程服务这个思路# 示意代码非官方示例一个无状态远程 MCP 服务fromfastapiimportFastAPI,Request appFastAPI()SIGNS{sunny:晴,rain:雨,snow:雪}app.post(/mcp)asyncdefhandle(req:Request):# 每次请求自带完整信息服务端不保留会话状态payloadawaitreq.json()methodpayload.get(method)ifmethodtools/list:# 声明本服务暴露的工具return{tools:[{name:weather_code,description:把天气码翻译成中文}]}ifmethodtools/call:# 参数只从本次请求取纯函数式处理无跨请求共享状态codepayload[params][arguments][code]return{content:[{type:text,text:SIGNS.get(code,未知)}]}return{error:{code:-32601,message:method not found}}调用链是这样走的客户端把 tools/list 发到 /mcp拿到工具声明模型决定调用后再发 tools/call服务端从 params.arguments 里取出 code查表返回文本内容。整条链路没有任何服务端会话任何一个副本都能处理任意一次请求——这正是无状态核心想换来的东西。真实协议的方法名、字段名与错误码请以 MCP 官方规范为准。七、对 Agent 开发者的三点启发扩展体系正在收拢成两层连接器管能力接入技能管流程编排。做 Agent 应用时把能做什么和该怎么做分开存放复用性会比全塞进一个大 prompt 高得多。打包与分发被拆成三步——提交自动扫、人工审、自主发布。这是一种可控的生态准入模型如果你在做企业内部的能力市场这套流程可以直接借鉴。无状态化不是实现细节而是部署前提。状态挂在服务端连接里就注定难以多副本扩容MCP 2.0 把这条线划出来值得在动手写第一个远程服务时就定好。