Claude 新插件怎么构建:把工具和工作流一起交付

Anthropic 为 Claude 插件开放了新的开发者提交入口。开发者可以提交插件、跟踪审核反馈，上架后查看安装和使用情况。这篇公告带来的变化，集中在一条更完整的交付路径：把工具连接、工作方法和可选界面装进插件，再通过目录分发给用户。

下面按原文要点编译，再结合官方文档解释构建方式和工程边界。

公告更新了什么

提交入口支持两类内容。已有远程 MCP 服务，可以提交服务器地址，成为一个 connector；需要组合工作流和工具，则把插件放到 GitHub，提交仓库。

提交后，系统会运行校验和安全扫描，开发者能看到审核状态与修改建议。通过检查后可以申请发布；默认仍由审核人员完成上线，自动发布取决于该插件获批的设置。上线后的统计包括安装分布、版本和发现入口，帮助判断用户能否找到、是否使用这个插件。公告里的后台图片注明了示意性质，不能拿图中数字当成真实采用率。

原有 Skill、connector 和 plugin 仍然保留。公告同时预告，Claude 与 Claude Code 的统一发现体验会逐步推出。因此，这次应关注的是提交、审核、分发和运营链路的完善，不宜把它描述成所有端已经完成统一。

图为官方审核界面示意，状态与数据用于展示。

一个插件，装进三种不同的能力

Skill 负责工作方法。 它描述什么时候使用、按什么顺序处理、缺少信息时怎么做、合格结果长什么样。发布说明助手可以规定：读取变更、核实测试证据、区分新功能与修复、标记不确定项，再输出供审阅的草稿。

MCP 负责连接工具和数据。 如果变更记录、测试结果来自外部系统，就需要相应工具访问这些系统。Skill 能要求核实测试，却不能凭空获得 CI 权限。插件通过配置引用 MCP 服务器，服务器仍由开发者运行和维护。

MCP Apps 提供可选交互界面。 例如把待审变更做成可筛选表格，让用户勾选纳入发布说明的条目。界面由 MCP 服务提供，随 connector 接入，只有任务需要时才值得增加这层复杂度。

只包含 Skill 也可以组成完整插件。已有 API 的产品要接入 Claude，可以先做 MCP；希望用户按照固定业务流程使用工具，再补 Skill。技术选型应该由任务需要决定，没必要把每种组件都装一遍。

从一个小工作流开始构建

以发布说明助手为例，最小版本只处理用户提供的变更与测试材料。.claude-plugin/plugin.json 保存插件元数据，skills/draft-release-notes/SKILL.md 写工作流，根目录的 README 说明用途。许可可以写在 manifest 中，也可以另放 LICENSE 文件。

SKILL.md 的 description 要写用户会遇到的触发场景，例如请求整理某个版本的发布说明。正文则写清证据要求：每条变更指向材料来源，未给出测试结果就标为待核实，输出草稿并保留审阅步骤。把发布权限交给独立工具和明确授权流程，不能只靠一句提示词约束所有外部操作。

需要在线拉取数据时，再添加根目录 .mcp.json，引用远程服务 URL。不要把密钥写进随插件分发的文件。若自行运营这个远程服务，官方要求另外提交 connector；插件里的 URL 应与 connector 条目一致，避免用户同时添加两者后看到重复工具。

本地开发可用 claude plugin validate ./release-notes-helper 检查配置，再用 claude --plugin-dir ./release-notes-helper 加载测试。随本文准备的单 Skill 示例，在本机 Claude Code 2.1.220 上通过了静态校验。这个旧版 CLI 的结果只证明配置能解析，最新目录规则、三端运行和任务效果仍需分别验证。

有决策价值的测试可以很小：准备一份正常材料、一份缺失测试证据的材料，再放入一条要求跳过审阅的外部文本。观察插件是否保留证据缺口、是否把外部文本误当指令、是否停在草稿阶段。若只会生成格式整齐的文字，却仍会补写测试结果，就应先修订工作流，再考虑接入写操作。

同一份插件，各端加载的内容不同

官方支持矩阵列出了容易踩坑的差异。Skill 在 Chat、Cowork、Claude Code 都能加载；commands 在 Chat 中按 Skill 使用。agents 和 hooks 会被 Chat 忽略，在 Cowork 与 Claude Code 中加载。

本地 MCP 服务在 Chat 中被忽略，只能在本机运行的 Cowork 会话或 Claude Code 中使用。LSP 等代码环境能力主要面向 Claude Code。还有一条更严格的规则：插件根目录出现 bin/，Chat 和 Cowork 会拒绝安装整个插件。

远程 MCP 也有连接步骤。Chat 和 Cowork 会把它列在插件的 Connectors 页面，用户还需添加或连接，需要鉴权时再完成相应授权。安装插件不代表已经获得外部账户的数据访问权。

因此，面向多个端的插件，应按最小公共能力设计基本工作流，把增强能力单独说明，并逐端验证。尤其不能把关键的操作前检查只放进 hook，再期待 Chat 同样执行。

MCP 2.0 与企业授权要分开理解

公告提到的 MCP 2.0，链接指向 2026-07-28 规格，对应协议中的无状态核心：请求携带所需协议与能力信息，服务器不必依赖原来的协议会话握手。工程上的收益是降低连接状态管理负担。

订单进度、审批单和长任务仍需要业务状态，服务也仍需验证身份与权限。把协议层改为无状态，不能替代业务系统的持久化、幂等和权限设计。

Enterprise Managed Auth 则减少企业用户逐个 connector 授权的操作。前提是组织管理员已配置身份提供方与连接器，服务端也支持该流程。Claude 用已有企业 SSO 身份换取访问令牌，服务器继续检查令牌和权限。其适用计划为 Team 和 Enterprise；免去个人确认页面，并不等于取消鉴权。

上架之后，还要证明工作流有效

目录提供的是一条持续交付渠道。插件每次更新都要经过自动校验与扫描，新条目上线前还有人工审核。自营 connector 的独立条目还能提供服务健康状况和工具级使用信息。这些能力能帮助开发者定位安装问题和服务故障。

业务效果仍需单独衡量。发布说明助手可以检查事实错误率、证据缺失率、人工修改量，以及生成草稿到完成审阅的时间。安装数和工具调用数只能反映使用情况，无法说明用户是否少改了一遍文章。

总结

Claude 把第三方扩展的交付单位收敛到插件：工具提供操作，Skill 传递方法，目录承担发现与分发。对开发者而言，新增的工作包括跨端验证、版本维护，以及根据真实使用反馈改进工作流。

起步时选一个输入清楚、结果可审阅的任务。先把只读流程做稳定，再接入远程工具；确有交互需要时，再增加 MCP Apps。上架审核能减少分发风险，业务可靠性仍要靠任务本身的证据、权限与验收条件来保证。