企业官网建设流程全解析

Claude 插件目录开放了：MCP 连接器与 Agent Skills 怎么打包上架

原文：Claude Blog - 《Build plugins for Claude》（https://claude.com/blog/build-plugins-for-claude）

Anthropic 在 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 计划下。官方给了两条路径：

1. 单一 MCP 连接器：直接指向你自己的远程 MCP 服务器。
2. 插件包：把 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 特性与扩展在路上，细节以官方文档为准。

五、上架之后能看到什么数据

插件上线后，官方提供两类数据：

1. 使用分析：按产品入口和版本看安装量，用来决定先修什么、先做什么。
2. 发现端指标：列表页浏览量和用户搜索词，用来优化曝光。

"按版本看安装量"这条对做插件的人特别有用——一次改动到底是修好了还是改坏了，可以直接从版本维度的安装曲线里读出来，不必等用户来报障。

六、一个最小的远程 MCP 服务示意

官方博客没有给出插件的目录结构与配置文件，构建细节要看文档（https://claude.com/docs/build/overview ，具体字段与版本以官方文档为准）。下面这段是我自己写的示意代码，不是官方示例，只用来表达"无状态远程服务"这个思路：

# 示意代码，非官方示例：一个无状态远程 MCP 服务fromfastapiimportFastAPI,Request app=FastAPI()SIGNS={"sunny":"晴","rain":"雨","snow":"雪"}@app.post("/mcp")asyncdefhandle(req:Request):# 每次请求自带完整信息，服务端不保留会话状态payload=awaitreq.json()method=payload.get("method")ifmethod=="tools/list":# 声明本服务暴露的工具return{"tools":[{"name":"weather_code","description":"把天气码翻译成中文"}]}ifmethod=="tools/call":# 参数只从本次请求取，纯函数式处理，无跨请求共享状态code=payload["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 开发者的三点启发

1. 扩展体系正在收拢成两层：连接器管能力接入，技能管流程编排。做 Agent 应用时，把"能做什么"和"该怎么做"分开存放，复用性会比全塞进一个大 prompt 高得多。
2. 打包与分发被拆成三步——提交自动扫、人工审、自主发布。这是一种可控的生态准入模型，如果你在做企业内部的能力市场，这套流程可以直接借鉴。
3. 无状态化不是实现细节，而是部署前提。状态挂在服务端连接里，就注定难以多副本扩容；MCP 2.0 把这条线划出来，值得在动手写第一个远程服务时就定好。