Claude 开放插件提交:开发者能上架了,但跨端能力仍有边界

9月25日，Anthropic 给想进入 Claude 插件目录的开发者开了一个提交门户。

这件事听着像多了个上传页面，但我更关心页面后面的几个问题。到底能交什么？交上去之后谁来检查？等用户在手机上、桌面上、Claude Code 里找到同一个插件，它们干的事一样吗？

尤其是最后一个问题，挺容易让人想当然。

先说入口。Anthropic 目前允许 Pro、Max、Team 和 Enterprise 计划的开发者提交。Team 和 Enterprise 账户还要看提交者有没有相应的角色权限。所以，如果你用的是免费账户，不能把这次开放理解成自己也拿到了提交资格。

能提交的东西，官方给了两条路。

一条是单独的远程 MCP 连接器。你提供服务器 URL，让 Claude 通过它连接外部服务或能力。这条路不要求你准备 GitHub 仓库。

另一条是插件包。它托管在 GitHub 仓库里，可以把 MCP 连接器、Agent Skills，或者两者一起打包。仓库在目录条目正式上线前必须公开。如果面向 Claude Code，插件还可以包含 LSP、命令、钩子和代理等组件。

乍看都叫插件，其实交付物不太一样。你只是要让 Claude 连上一个远程 MCP 服务，单独提交连接器就行。你想把技能和其他组件组织成一个完整的扩展，再考虑插件包。

但这里有个容易漏掉的小口子。如果插件包引用了你自己运营的远程 MCP 服务器，官方文档要求把这个服务器也作为连接器单独提交。不是把地址塞进插件包，事情就算办完了。

我觉得这条规则很能说明目录的思路。目录收的不是一个随便起名的压缩包，里面不同的能力有自己的身份，也有自己的提交要求。开发者在动手前，最好先把插件包和远程服务的关系画清楚，免得做到一半才发现还欠一个连接器条目。

提交之后呢？

官方公告说，门户会做自动校验和安全扫描，也会展示审核状态、反馈以及建议修改项。插件包的每个版本都会经过自动校验和安全扫描。新目录条目正式上线前，还有人工审核。

这几个环节别混成一次「上传成功」。自动检查过了，不等于新条目已经过了人工审核。页面给出建议修改项，也不等于开发者改完马上就能上线。官方没有承诺固定的审核用时，谁也没法据此给自己的发布日期倒排一个稳稳的日程。

不过有一点我挺喜欢。获批之后，何时发布由开发者决定。对于需要配合产品更新、文档说明或者服务端准备的人，这个决定权很实际。至少从官方描述看，提交、获批、发布是分开的动作，不必把拿到批准的那一刻当成唯一的发布窗口。

发布以后，门户还会提供使用分析，包括按产品界面和版本统计的安装量，以及目录展示、搜索发现的数据。这些数字能帮开发者观察插件有没有被看见、在哪里被安装。至于安装之后有没有形成稳定使用、能不能带来收入，Research Pack 里没有独立数据，我也不想替这些数字脑补一个成功故事。

说到被看见，就得聊这次最容易产生误会的地方。

官方说，目录条目可以在 Claude 网页、桌面、移动端以及 Cowork 被发现，用户添加的插件也可以进入自己的 Claude Code 会话。Anthropic 还表示，未来数周会逐步推出覆盖 Claude 与 Claude Code 的统一发现体验。

注意，是未来数周逐步推出。现在不能把它写成已经全面完成。

更关键的是，「找得到」和「能运行里面的每个组件」，根本是两回事。把插件想成一个装了不同零件的工具箱也许更好理解。工具箱可以被带到不同地方，至于箱子里的每件工具能不能拿出来用，要看那个地方有没有对应的工作台。

官方的跨平台能力表就把这条边界写得很清楚。Skills 在聊天、Cowork 和 Claude Code 中都可以加载。对主要提供技能的开发者来说，这确实是一个覆盖面相当广的组件。

再看 Agents，到了聊天里会被忽略，在 Cowork 和 Claude Code 中才会加载。如果你的插件很依赖代理来完成一段工作流，读者在聊天界面添加了它，也不能据此期待那段代理逻辑原样出现。

Hooks 也是类似的提醒。官方表格显示，它们在聊天中会被忽略。本地 MCP 服务器在聊天中同样会被忽略。至于远程 MCP 连接器，表格给出的也是各客户端不同的连接或加载方式，不能简单用一个「全端支持」概括。

这块说真的，有点绕。但绕的原因不是文档故弄玄虚，而是插件里装的东西本来就不止一种。技能、代理、钩子、MCP 连接器，名字挨在一起，承担的工作却不同。目录能让它们以一个条目被发现，不会自动抹平客户端之间的能力差异。

你想想看，如果开发者在介绍页上写「一个插件覆盖 Claude 全平台」，用户大概会怎样理解？很多人会以为自己在网页聊天里点了添加，就能得到和 Claude Code 里相同的流程。等到代理和钩子没有出现，问题可能并不在安装，而在产品本身就没有加载那些组件。

所以我会更愿意看到一种诚实的写法，明确告诉用户这个插件在哪些地方能被发现，核心功能靠什么组件实现，以及每个客户端实际能用到哪一部分。这个建议是我根据官方能力表做的编辑判断，不是 Anthropic 公布的一条额外审核规则。

反过来说，我也理解开发者为什么会想强调覆盖面。做一个扩展，当然希望尽可能多的人找到它。目录展示和搜索发现数据，听起来也确实让分发这件事变得更可观察。可要是用同一个名称承诺完全相同的体验，后面解释差异的成本，最后还是会落回自己身上。

这件事让我想到一个挺朴素的区别。过去聊扩展，大家很容易把「上架」当成终点，仿佛进入目录，用户自然就会来，功能自然就会跑起来。现在看 Claude 这套规则，上架更像拿到一个公开入口。入口后面还有组件怎么组合、服务怎么单独提交、版本怎么检查、不同客户端怎么承接。每一层都要开发者自己想明白。

坦率地讲，我也还不知道这套目录最终会有多热闹。Anthropic 给了提交和审核规则，也给了发布后可看的数据类型，但目前没有独立数字能证明生态规模、审核通过率或开发者收益。对这些问题，现在下判断太早。

真正值得继续盯的，是统一发现体验逐步推出之后，用户在 Claude 和 Claude Code 之间找插件会不会更顺，开发者会不会真的愿意按这些规则持续更新，以及审核反馈能否跟上提交量。眼下能确认的变化更具体，也更有用。

入口开了，路怎么走，官方已经画出了一部分。

至于一个插件能走到哪儿，别只看它出现在几个目录里。打开工具箱，看看每个客户端究竟能拿起哪件工具。