Claude Plugins Directory 开放，扩展成为 Anthropic 的分发层
Anthropic 于 2026 年 9 月 25 日向第三方开放 Claude plugins directory 提交，为开发者提供了进入其扩展市场的审核通道。这一变化意义重大：plugins 不再只是 Claude 功能之外的可选封装。Anthropic 现在将其定义为开发者应如何为 Claude 打包外部能力的主要方式。
一个 plugin 可以包含一个 Model Context Protocol connector、一个或多个 Agent Skills，或两者兼具。MCP 让 Claude 能够访问外部工具和数据，而 Skill 则提供可复用的指令、脚本和支持资源。将二者结合，开发者便可把访问能力与操作知识作为一个可安装产品一同分发。
这一打包决策让 Anthropic 直接与 ChatGPT 所采用的 app 模式展开竞争。两家公司如今都希望第三方开发者基于 MCP 构建产品、通过平台审核，并借助可搜索的目录触达用户。因此，真正重要的竞争并非 Claude 与某个单独集成之间的较量，而是 Claude 的捆绑 plugin 模式与传统对话式 app store 之间的竞争。
Anthropic 的 plugin announcement 为开发者提供了提交、审核追踪、上线控制和使用分析门户。它还开始整合此前作为独立构件存在的多种扩展形式。
Claude plugins directory 有望让复杂的 agent 工作流更易于安装和发现。但这也将更多责任集中到 Anthropic 的审核流程、排序系统、权限控制，以及对获批后仍可能发生变化的软件的处理机制上。
Claude Plugins Directory 现已具备提交流程
最直接的变化在于运营层面：外部开发者现在可以提交 plugin、跟进审核进度，并在获批后发布。
提交门户面向使用付费 Claude 计划的开发者开放。Anthropic 提供两种提交路径，反映了开发者目前扩展 Claude 的不同方式。
第一种路径适用于单个远程 MCP connector。开发者提供 MCP server 的地址，该服务器通过协议暴露工具或数据。这一途径适合主要需要 Claude 搜索记录、调用 API 或执行明确操作的服务。
第二种路径适用于托管在 GitHub repository 中的 plugin bundle。该 bundle 可以将 MCP servers 与 Agent Skills 结合。在 Claude Code 中，它还可以包含 language server integrations、commands、hooks 和 specialized agents。
这一区别很重要。connector 告诉 Claude 可以访问哪个外部系统；Skill 则告诉 Claude 应如何处理特定任务。plugin 可以同时打包这两部分，使用户无需从不同组件中自行拼装工作流。
以一个用于处理生产事故的开发者工具为例。它的 connector 可能用于获取告警、日志和 issue records；其 Skills 则可定义调查顺序、所需证据以及最终事故报告的格式。这样一来，plugin 便可将连接能力和操作流程一同分发。
Anthropic 表示，每项提交都会接受自动验证和安全扫描。开发者可以查看审核状态、检查扫描结果，并回应建议修改。获批并不意味着必须立即发布，因为开发者仍保留对发布时间的控制权。
这种最终控制将审核与上线区分开来。团队可以等待后端、支持材料或公告准备就绪后，再将已获批的 plugin 公开；也可以让目录发布与既有产品部署协调进行。
发布后，门户会按 Claude 使用界面和 plugin 版本报告安装量，也会显示 listing 浏览量以及将用户带到该 plugin 的搜索词。这些指标应能帮助开发者区分发现问题与激活问题。
一个获得较多浏览却安装量很低的 listing，可能存在定位薄弱、权限不清晰或感知价值有限的问题。一个在 Claude Code 中采用率很高、但在其他场景中使用较少的 plugin，可能需要为普通 Claude 用户提供不同的 Skills 或文档。
目录本身仍将 Skills、connectors 和 plugins 作为清晰可辨的分类呈现。现有条目无需立即调整。Anthropic 表示，开发者最终将能够把 connector listings 转换为 plugins，而当前目录项目在过渡期间仍可保留。
这是一种没有突然迁移截止日期的整合方式。Anthropic 可以将 plugins 确立为首选格式，同时保留现有集成及其背后的已安装用户基础。
这一策略也与更广泛的 Claude Marketplace 同步推出，后者列出了超过 2,000 个 plugins 和 connectors。提交门户使该目录从一个精选目的地转变为更具结构化的开发者渠道。
Anthropic 为何现在要将工具与指令打包
Plugins 解决了一个分发问题，而 MCP connectors 和 prompt packages 单独都难以很好地解决这一问题。
MCP 标准化了 AI 应用与外部服务之间的交互。server 可以以 MCP-compatible client 能够理解的形式声明工具、资源和相关能力。这减少了开发者为每种 AI 产品设计不同集成协议的需求。
该协议也变得更易于大规模运行。2026 年 7 月的 MCP specification 引入了无状态核心、可缓存列表、基于 header 的路由、授权变更和正式的扩展框架。无状态核心使请求能够抵达普通 server instances，而不必依赖持久的传输会话。
这些变化使 MCP 成为托管商业集成的更坚实基础。不过，它们并不能告诉 Claude 某个组织希望如何执行任务。可用工具列表并不等同于操作流程。
Agent Skills 覆盖了第二层。Anthropic 将 Skill 定义为包含指令、脚本和资源的文件夹，Claude 会在相关情况下加载它。其 Agent Skills model 允许开发者编码专门工作流，而无需在每次对话中放入所有指令。
这形成了自然的分工。MCP 负责访问和操作，Skills 负责流程及任务特定上下文，Plugins 则将这些层打包用于安装和分发。
这一时机也反映出 agent 产品正超越简单问答。当助手能够检索私有记录、运行代码、生成文件或更改外部系统时，成功使用不只取决于模型质量。周边工作流决定了模型能够看到什么、可以做什么，以及其表现的一致性。
此前，开发者必须通过不同渠道分发这些部分。一个 repository 可能包含 MCP server，另一个可能包含 prompts、scripts 或 Claude Code commands。安装说明通常要求用户编辑配置文件，并理解各组件如何协同工作。
plugin 将这些碎片整合为可识别的产品单元。这让开发者拥有一个 listing、一个版本化 package 和一个 adoption funnel；也让用户面对一个更简单的决策：是否安装一个为特定工作而设计的 package。
对于企业买家而言，打包也让治理变得更清晰。管理员可以评估一个具名 package、审查其源代码和能力，并决定哪些人应获得它。Anthropic 的组织控制功能可使某个 plugin 可用、默认安装，或要求指定用户必须安装。
package 还可以跨 Claude 使用界面流转。根据 Anthropic 的目录指南，当使用同一账户时，已安装的 Skills 可在 Claude chat、Cowork 和 Claude Code 中使用。这种覆盖范围使 plugin 比仅绑定于单一界面的狭窄集成更有价值。
这种跨界面承诺仍存在条件限制。围绕本地 hooks 或开发 commands 设计的 plugin，无法在浏览器对话中提供相同体验。开发者仍需识别各个界面支持哪些能力，并设计适当的降级方案。
即便如此，Anthropic 正在将 plugins 确立为发现、审核、分析和组织分发所围绕的单位。MCP 和 Skills 仍是底层组件，但目录赋予了这一 bundle 商业和运营层面的可见性。
将 Claude Plugins 与 Connectors 对比是错误的竞争框架
核心竞争并非 Claude plugins 对 connectors，因为 Anthropic 希望 connectors 成为 plugins 中的组成部分。
当访问能力本身就是完整产品时，connector 仍然很有用。数据库搜索服务、文档检索 endpoint 或定义范围狭窄的 API，可能不需要额外指令。因此，Anthropic 仍通过新门户接受单个远程 MCP server。
当集成需要一个流程、政策或专门输出时，plugin 的价值会更高。开发者可以将工具与 Skills 配对，说明何时使用这些工具，以及如何将其结果转化为完成的工作。
这意味着，Claude plugins 与 connectors 的区别主要在于打包深度。connector 暴露一种能力；plugin 则可将一个或多个能力转化为拥有自身指令和支持资产的工作流。
更具影响力的比较对象是 ChatGPT 的 app 分发模式。OpenAI 于 2025 年 12 月开始接受第三方 app 提交，并将获批产品纳入可搜索目录。其提交流程同样要求开发者提供 MCP connectivity details、测试说明、目录元数据和市场可用性信息。
OpenAI 的 app submission model 强调能够检索上下文、执行操作并呈现交互式界面的对话体验。Apps 可以通过名称调用、从工具菜单选择，或通过推荐浮现。
Anthropic 正从不同的起点切入同一机会。其 bundle 可以将远程工具与流程知识结合，而 Claude Code plugins 还可以进一步扩展至 commands、hooks、agents 和开发基础设施。
不过，这两种模式的技术共同点比其名称所暗示的更多。两者都将 MCP 视为重要的连接层，都审核公开提交内容，也都提供目录，而分发在一定程度上取决于搜索、排序和平台推荐。
这种共享基础降低了一些开发成本。公司可以通过 MCP 暴露核心能力，再围绕它构建平台特定的打包方式。但这并不能消除适配工作，因为每个宿主平台都有不同的界面、政策、审核标准和支持的扩展。
战略问题在于，哪个平台能为开发者提供从可用集成到重复使用的最佳路径。原始受众规模固然重要，但发现质量、分析能力、跨界面可用性、企业部署能力，以及所需平台特定工作的数量同样重要。
Anthropic 的门户直接回应了其中若干因素。搜索查询分析可以让开发者了解用户如何描述问题。按版本划分的安装数据可以揭示一次更新是否改善了采用率。审核反馈则能在发布前暴露合规问题。
但分析数据本身无法创造需求。一个包含数千条目 的目录可能变得难以浏览，尤其是在多个插件都声称能解决同一工作流时。即使没有正式的付费体系，搜索排名和编辑推荐也会成为产品经济的一部分。
开发者还需要决定在多大程度上押注于平台专属的 Skill。详尽的 Claude 指令可以改善 Anthropic 产品内的体验，但如果另一个托管平台对工作流指引的理解不同，也可能增加维护负担。
对用户而言，胜出的模式将是既能减少配置、又不会掩盖重要选择的模式。只有当人们能够理解其权限、数据流、维护状态和支持环境时，一键式软件包才真正有用。
知识工作者或许会通过日常任务而非目录品牌感受到这场竞争。一个研究插件可能会收集源材料、执行验证流程，并生成结构化简报。这类 AI workflow 在工具与操作指引一并交付时会更有价值。
Anthropic 正在押注：这种捆绑包是智能体软件的正确基本单元。OpenAI 则押注于以应用为中心的体验能够原生融入对话。两种路径都将分发与信任转化为平台功能，而不是完全留给 GitHub 仓库和手动配置。
Claude Plugins 的工作方式带来了更棘手的信任问题
经过审核的目录能降低不确定性，但无法让每一个插件永久安全。
Anthropic 的自动验证和安全扫描是有用的第一道防线。其目录政策还要求具备隐私保护、适当的数据收集方式、遵守使用规则，并与其他已列出的服务器保持兼容。条目发布后，审核仍可继续进行。
然而，插件并非静态文档。它可能将 Claude 连接至实时服务、包含可执行组件，或依赖后续会更新的代码。因此，提交时观察到的安全属性可能发生变化。
远程 MCP 服务器构成了特殊挑战。运营方可以在不要求用户重新安装任何内容的情况下改变服务器行为。审核期间看似无害的工具响应，并不能保证未来响应仍然无害。
Anthropic 在自身的智能体隔离分析中承认了这一区别。本地工具可以被检查并固定到已知版本。远程工具则可能在用户最初作出信任决定后发生变化，因此 Anthropic 建议将已审核目录之外的资源视为不受信任。
目录收录通过初始和持续审核改善了这一状况，但并不会将远程服务变成不可变的软件。Anthropic 的条款保留了因安全问题、投诉、政策违规或其他原因移除 MCP 服务器的权利。
第二类风险来自提示词注入，即不受信任的内容包含意图重定向智能体的指令。一个获取网页、消息、工单或文档的插件，可能会将敌对文本带入 Claude 的工作上下文。
传统依赖项检查无法完全解决这一问题。服务器可能运行真实、经过签名的代码，却仍然返回旨在操纵智能体的内容。有害指令可能通过文档而非可执行文件本身传入。
将 Skills 与连接器打包在一起，也增加了一个审核维度。指令决定 Claude 应在何时使用工具、应信任哪些证据，以及应如何处理冲突。设计不佳的指引即使不包含明显恶意代码，也可能导致不安全行为。
Claude Code 插件可能带来更广泛的后果。Hooks、命令、智能体和本地 MCP 服务器可能会与源文件、Shell 命令、凭据或部署系统交互。实际风险取决于权限以及插件运行的环境。
因此，企业需要的不只是一个批准徽章。管理员应审查所请求的能力、认证路径、数据保留政策、更新行为，以及本地和远程组件之间的差异。在授予生产系统访问权限前，他们还应先使用非敏感数据测试新插件。
开发者也面临相关的信息披露问题。一份清晰的条目说明应解释哪些信息会离开 Claude、插件能够执行哪些操作，以及远程服务是否可以独立于已安装软件包自行变更。当权限或依赖项发生变化时，版本说明也很重要。
门户的版本分析可能会鼓励定期更新，但频繁发布会带来审核压力。Anthropic 尚未公开详述每一项重新审核的门槛、每一个排名信号，或变更后的远程服务能够多快被重新评估。
Anthropic 决定将插件设为主要第三方格式，也存在治理层面的张力。统一的软件包简化了分发，但也让平台对可见性和持续访问拥有更大影响力。开发者必须遵守可能不断演变的政策，而 Anthropic 则控制目录位置和移除决策。
这种安排在软件市场中很常见。智能体插件提高了风险，因为它们可以在一个软件包内结合外部数据、程序性指令和具有后果的操作。审核不仅必须评估软件是否能运行，还要评估它在不确定输入下如何引导模型。
用户应将批准理解为一种风险降低措施，而不是永久保证。最有力的信号将是 Anthropic 是否能够将自动扫描与持续监控、透明披露、快速事件处理，以及将每个插件权限保持在狭窄范围内的控制措施结合起来。
该目录给开发者与企业买家带来压力
Anthropic 的决定迫使插件开发者将发现、治理和维护视为产品要求。
对独立开发者而言，门户为他们提供了一条可信的用户触达路径，触及那些绝不会手动安装仓库的用户。这种分发能力可能会奖励那些以极少设置完成完整任务、且设计聚焦的插件。
它也提高了准入标准。一个公开插件如今需要的不只是可用代码，还需要连贯的条目说明、明确的权限边界、可靠的托管、可供审核的仓库、版本纪律，以及足以支撑真实世界使用的支持能力。
门户的搜索分析将使命名和定位变得可衡量。开发者可以了解哪些搜索带来条目访问量，再调整描述或优先补足缺失能力。按产品界面划分的安装数据可指导平台专属开发。
这些信号可能催生更好的产品，但也可能有利于那些有时间优化目录表现的团队。较小的开发者可能会发现，自己正与成熟的软件供应商竞争；后者已有知名品牌、成熟的认证系统和专职合规人员。
企业买家面临不同的决策。他们可以使用公开目录中的插件、分发内部软件包，或结合两种方式。公开条目降低了采购和筛选成本，而内部插件则可以编码公司特有流程并连接私有系统。
Anthropic 的组织控制功能允许管理员管理发布和安装。企业可以将某个插件设为可选、默认安装或强制安装。这有助于标准化工作流，尤其是在某个 Skill 包含经批准的操作指引时。
强制部署需要谨慎处理。Anthropic 指出，某些 Claude Code 组件会在用户的计算机上运行。带有本地 Hooks 或工具访问权限的强制插件，可能会以员工无法自行禁用的方式影响开发环境。
安全团队将需要一份涵盖来源、版本、能力、受众和近期使用情况的清单。他们还需要针对从公开目录下架的插件、行为发生变化的服务器，以及维护者停止发布更新的软件包制定响应流程。
软件供应商如今必须决定，Claude 是否值得拥有自己的打包工作流。一个基础 MCP 端点可以触达多个兼容客户端，但 Claude 专属的 Skill 能够提升任务质量和目录定位。代价则是又一个需要维护的产品界面。
最成功的开发者很可能会保持其核心服务的可移植性，同时为每个托管平台调整体验。MCP 可以提供对工具的共享访问。平台专属的指令、界面和治理元数据则可以置于这一共同层之上。
这种方式避免将可移植性等同于一致性。服务器可以向 Claude 和 ChatGPT 暴露相同的底层能力，而每个平台对发现、推荐、权限和用户交互的处理方式不同。
Anthropic 必须让这项额外工作物有所值。目录需要带来高质量安装，而不只是被动浏览。审核时间必须保持可预测。分析数据必须足够准确，能够指导决策。跨界面行为必须易于理解。
公司还必须防止低质量提交淹没发现体验。自动验证可以捕捉格式问题和已知安全问题，但无法判断十个几乎相同的插件是否提供了不同价值。
随着提交量增长，策展将变得更困难。如果搜索偏向既有参与者，新开发者可能难以获得关注；如果推荐偏向新颖性，用户则可能遇到不稳定的产品。Anthropic 将需要取得平衡：奖励质量，同时避免目录固化在最早的一批条目周围。
对买家而言，重要指标不是可用插件的数量，而是安装后仍然可靠、透明且有用的插件数量。庞大的目录带来选择空间，但活跃使用和留存情况才能揭示打包是否真正改善了实际工作。
Claude Plugins Directory 接下来会如何发展
三个信号将决定插件能否成为 Claude 真正的扩展层，而不只是另一份集成目录。
第一个信号，是现有连接器转化为更丰富插件捆绑包的情况。Anthropic 表示，开发者最终将能够把连接器条目转化为插件。持续出现的转换浪潮将表明，开发者认为将 Skills 和工作流资产附加到 MCP 访问上具有价值。
这些转换的质量比原始数量更重要。仅仅将现有连接器包装进一个新清单，意义不大。插件应当减少设置、编码有用流程，或创造连接器本身无法交付的一致结果。
如果成熟的连接器提供商投资于这些更丰富的软件包，Anthropic 的捆绑策略就会获得支持。如果大多数条目仍然只有连接器，插件可能主要只是一种新的目录标签。
第二个信号，是单一发现体验是否真正横跨 Claude 和 Claude Code。Anthropic 表示，统一体验将在未来数周内陆续覆盖两款产品。用户应能在安装前了解插件适用于何处。
一个令人信服的推出应在各个界面提供一致的身份、版本信息、权限和状态，也应明确展示界面专属能力。面向开发者的 Hook 不应看起来与浏览器兼容的 Skill 等同。
跨界面留存尤其值得关注。如果用户通过某个 Claude 产品安装一个软件包，并持续在其他产品中使用它，那么插件就实现了独立连接器难以提供的能力。
第三个信号是 Anthropic 如何处理首起可见的安全或质量事故。庞大的第三方生态最终难免会出现存在漏洞的软件包、遭入侵的服务器、误导性的元数据，或行为与审核版本不同的更新。
其应对方式将检验持续监控、开发者沟通、用户通知和下架流程。快速遏制将巩固目录的信任模型；缓慢或不透明的回应则会削弱审核的价值。
竞争对手的反应同样值得关注，但这属于辅助证据，而非核心检验。OpenAI 已经拥有基于 MCP 的目录和提交流程。两家公司都会继续增加发布工具、界面、分析功能和企业控制能力。
Anthropic 的独特主张在于插件捆绑包本身。它希望第三方将访问能力、专业知识和工作流行为打包成一个可安装单元，并可在各类 Claude 产品间运行。
这是一个可信的方向，因为智能体同时需要工具和指令。但这并不天然构成持久优势。开放标准使核心连接具备可移植性，而审核质量和产品分发仍由各个平台掌控。
开发者应从一项边界明确的任务开始，只暴露最低限度的必要工具，并记录每一项重要权限。他们还应测试：当检索到的内容包含误导性指令，或远程依赖发生故障时，软件包会如何表现。
企业团队应将插件视为活跃的软件依赖，而非装饰性的提示词包。这意味着要审核更新、限制权限、监控使用情况，并维护下架方案。
对个人用户而言，实际问题更简单：安装的软件包是否能以更少的配置和更清晰的控制，可靠地完成一项真实工作流？未来几个月可关注连接器转化、真正的跨产品使用，以及透明的事故处理。这些结果将表明 Claude 插件目录是否已成为 Anthropic 持久的第三方平台。
