Anthropic 把插件商店开源了,Claude Code 的玩法要变了

24900 颗星,680 个 issue,这不是某个社区项目,是 Anthropic 亲自下场做的插件目录。

/ / /

一句话说清楚这是什么

上周三下午我在刷 GitHub Trending,看到一个 repo 一天涨了 2556 颗星。点进去一看——anthropics/claude-plugins-official。Anthropic 官方维护的 Claude Code 插件目录。

讲真,我之前一直觉得 Claude Code 的插件系统挺散的,社区零零散散有人写,但没个统一的入口。现在 Anthropic 自己做了这么一个"官方商店",把 internal 和 external 插件放到同一个 repo 里管理,意思很明确:Claude Code 的插件体系,我们要亲自定标准了。

Claude Code 插件目录整体架构

/ / /

两种插件,两条管线

整个 repo 的目录结构其实挺简单的:

claude-plugins-official/
├── plugins/           # Anthropic 内部团队维护
├── external_plugins/  # 社区和合作伙伴提交
├── .github/           # CI/CD
└── README.md

plugins/ 下面是 Anthropic 自己的人写的,质量有保证(理论上)。external_plugins/ 是外部开发者提交的,要过审。

安装方式有两种:

# 方式一: 命令行直装
/plugin install superpowers@claude-plugins-official

# 方式二: Discover UI 里浏览
/plugin > Discover

我试了一下,第一种方式大概 3 秒就装完。第二种有个可视化列表,适合不知道要装啥的人慢慢翻。

插件安装流程对比

/ / /

一个插件长什么样

每个插件必须遵守一套标准结构:

my-plugin/
├── .claude-plugin/
│   └── plugin.json    # 元数据(必须有)
├── .mcp.json          # MCP 服务器配置(可选)
├── commands/          # 斜杠命令(可选)
├── agents/            # Agent 定义(可选)
├── skills/            # Skill 模块(可选)
└── README.md

plugin.json 是核心——名字、版本、描述、权限声明全在这。.mcp.json 用于接外部工具(比如你想让插件调 Figma API 或者数据库)。commands/、agents/、skills/ 三个目录分别对应三种扩展能力。

这个结构设计得...怎么说,够用但不花哨。没有搞什么复杂的 manifest schema 或者 capability negotiation 协议。一个 JSON 加几个目录,结束。

插件标准结构拆解

/ / /

语言组成透露了什么

我翻了一下 repo 的语言统计:

-Python 31.6%
-TypeScript 28.9%
-HTML 19.5%
-Shell 13.0%
-JavaScript 7.0%

Python 和 TypeScript 几乎五五开,这说明 Anthropic 内部写插件时两种语言都在用。HTML 占将近 20%,我猜大部分是 skill 模板和文档渲染用的。Shell 13% 不少了——大概是各种安装脚本和 CI 流程。

扯远了,回到主题。

语言占比分布图

/ / /

680 个 issue 意味着什么

截至今天,这个 repo 有 680 个 open issue。说实话,对一个 405 次 commit 的项目来说,这个 issue 数有点夸张。

我翻了几页,大致分三类:

[01]功能请求——"能不能支持 xxx"(占大头)
[02]插件提交申请——外部开发者想把自己的插件加进目录
[03]Bug 报告——安装失败、权限冲突之类的

第二类最有意思。想进 external_plugins/ 目录,开发者需要填一个 submission form,然后等审核。目前审核速度嘛——10 个 open PR,你品。

这意味着如果你今天提交一个插件,可能要等一段时间才能进目录。Anthropic 的审核团队显然还没跟上社区的热情。

Issue 分类统计

/ / /

安全问题不能忽略

README 里有一段红色警告(大意):

安装前请确认你信任这个插件。Anthropic 不控制插件里的 MCP 服务器、文件或其他软件,也不能保证它们会按预期工作。

这段话很诚实。翻译成人话就是:我们只管目录,插件本身出了事你自己担着。

这和 VS Code Extension Marketplace 的模式类似——平台提供分发渠道和基本审核,但不做沙箱隔离。一个恶意插件理论上可以读你本地文件、调你的 MCP 服务器、甚至改你的代码。

我个人的建议:

-只装 plugins/ 下 Anthropic 官方维护的
-external_plugins/ 的,先去看源码
-留意插件更新——初始版本安全不代表后续版本也安全

插件安全模型示意

/ / /

和 VS Code / Cursor 插件体系的对比

我一直在想这个问题:Claude Code 的插件系统和 VS Code 的 Extension 有什么本质区别?

答案是——运行时不同。VS Code Extension 跑在编辑器进程里,有明确的 API boundary。Claude Code Plugin 跑在 Agent 的上下文里,能直接影响 Agent 的行为、工具调用、甚至决策逻辑。

这意味着 Claude Code 插件的"能力上限"远高于传统编辑器插件。一个 VS Code Extension 最多给你加个 linter 或者改改 UI。一个 Claude Code Plugin 可以:

-注入新的 slash command,改变你的工作流
-定义 Agent 行为,让 Claude 用特定方式处理任务
-通过 MCP 接入任意外部服务
-添加 Skill 模块,扩展 Claude 的知识和能力

能力越大,信任成本越高。这也是为什么 Anthropic 要搞官方目录——至少给一个"这些我们看过了"的信号。

Claude Code vs VS Code 插件能力对比

/ / /

对开发者意味着什么

如果你在写 Claude Code 插件,现在有两个选择:

路线 A:进官方目录。好处是曝光量大(24900 星的 repo 首页展示),坏处是要过审、受约束。

路线 B:独立分发。用户直接 git clone 或者你自己建 repo,/plugin install 指向你的地址。自由,但没有官方背书。

我的判断:对于工具类插件(linter、formatter、CI helper),走官方目录更合适。对于深度定制类插件(特定团队工作流、内部系统集成),独立分发更灵活。

/ / /

我还没想明白的事

有几个问题我暂时没找到答案:

[01]插件之间的依赖怎么处理? 比如 A 插件依赖 B 插件,目前没看到 dependency 声明机制
[02]版本锁定呢? @claude-plugins-official 这个后缀指向的是 main 分支还是 tag?
[03]插件和 Claude Code 版本的兼容性谁来管?

这些问题现在可能还不急,但如果插件市场真的起来了(看这个星数增速,大概率会),迟早要面对。

/ / /

回头看,Anthropic 做这件事的时机选得不错。Claude Code 的用户基数到了,社区插件开始零散出现,这时候官方下场定标准、建目录,比等社区野蛮生长后再收编要省事得多。

讲真,405 次 commit,680 个 issue,10 个待审 PR——这个项目还很早期。但方向对了。AI coding agent 的插件市场,可能是未来两年最值得关注的基础设施之一。

我先去翻翻 external_plugins/ 里有没有什么好玩的。