Claude Code Plugin 到底是什么？别再和 MCP、Hook、Subagent、Skill 混着用了

最近如果你在看 Claude Code 的资料，大概率会被几个词绕晕：

plugin、MCP、hook、subagent、skill。

它们看起来都像“扩展能力”。所以很容易被当成一回事。

结果就是：

装了个 plugin，就以为自己“接好了 MCP”
看到 skills，又觉得它就是另一种 plugin
一说 Claude Code plugin，脑子里先蹦出来 VS Code 插件

这几个词确实都相关。但真不是一层。

先把判断放这儿，后面再慢慢拆：

Plugin 更像打包和分发层。MCP 负责连接。Hook 负责在流程里插动作。Subagent 负责分工。Skill 负责把一类事情做稳。

这个判断放到 2025 年上半年，还不一定非讲不可。但放到现在，不讲清楚就很容易一直用旧地图看新东西。

原因很简单。

Anthropic 是在 2025 年 10 月 9 日 才正式把 Claude Code Plugins 作为公开 beta 推出来的。紧接着 2025 年 10 月 16 日 又发布了 Agent Skills。

也就是说，今天再聊 Claude Code 的扩展体系，已经不能只沿用早期那套“有 MCP、有 hook、有 subagent” 的理解了。

先把大背景讲清楚：为什么现在必须重新理解 Plugin

如果你是早一点开始关注 Claude Code 的，你脑子里的版本大概是这样的：

它能跑命令
它能读写文件
它能接 MCP
它有 hook
它能配 subagent

这个理解没错。

问题是，它更像“零散能力清单”，还不是一套好安装、好分发、好共享的体系。

你自己在本机上慢慢配，当然能用。可一旦你想把一整套工作流给团队复用，或者想让开源项目把推荐用法直接发给用户，马上就会碰到几个很实际的问题：

怎么统一安装
怎么统一开关
怎么统一分发
怎么通过 marketplace 发现和复用

这时候，只靠 MCP 或 hook 就不够了。

不是它们没用。而是它们更像零件，还不是安装单位。

Anthropic 在 2025-10-09 发布 Plugins 时，定义给得很直接：

Claude Code plugins 是一组可以一键安装的自定义集合，里面可以打包：

slash commands
subagents
MCP servers
hooks

看到这里，其实就差不多能对上了。

Plugin 不是这些能力里的某一个。它更像一个外壳，把这些能力装进去，然后让你能安装、共享、开关和分发。

这就是它最重要的定位。

Plugin 到底是什么

如果只用一句话讲，我会这么说：

Plugin 是 Claude Code 的扩展打包机制。

它不直接回答“怎么接外部工具”，也不直接回答“这类任务该怎么做更稳”。它回答的是另一件事：

你已经配好的那套能力，怎么变成一个别人也能装的东西。

这个单元里可以装很多东西。

比如一个团队内部的 code review plugin，完全可能同时包含：

一个 slash command，用来触发常规审查流程
一个 hook，在提交前自动做检查
一个 MCP server，用来连内部工单系统
一个 subagent，专门负责安全审查

这四样东西以前你也能单独配。

但现在你可以把它们打成一个 plugin，直接给团队装。

这一步很关键。

因为它把“我自己电脑上调顺的一套东西”，变成了“团队可以一起装的一套东西”。

这两个阶段，看起来只差一步。实际差得很大。

Plugin 不是 MCP 的新名字

这里最容易讲歪。

我的判断很简单：

MCP 是连接协议。Plugin 是封装单位。

两者有关，但不是一回事。

MCP 管的是“怎么连”。

Claude Code 要接到外部系统，靠的是这一层。

比如：

GitHub
Jira
Figma
数据库
内部 API
日志和监控平台

如果没有 MCP，Claude Code 很多时候只能在本地文件和命令行里工作。

有了 MCP，它才能把外部世界的工具、数据、资源，以统一方式拿进来。

所以 MCP 干的是连接。 Plugin 干的是打包和分发。

两者最常见的关系是：

你先用 MCP 把能力接进来
再用 Plugin 把这套能力打包给别人安装

你可以把它理解成：

MCP 更像插座。Plugin 更像插线板外加一个包装盒。

前者负责接上能力。后者负责把这堆能力整理好，再发出去。

Hook 也不是 Plugin

Hook 很容易被说轻了。

很多人一看到 hook，就顺手把它归到“小脚本”里。这么讲不太准。

在 Claude Code 里，hook 更像是：

在 Agent 工作流关键节点插进去的一段自动化逻辑。

比如：

某个工具调用前先检查风险
某个动作结束后补日志
某类任务执行前先做格式校验
某个阶段结束后发通知

它更关心的是时机。

什么时候拦一下。什么时候补一步。什么时候顺手做个检查。

所以 hook 的重点不是连接，也不是分发。而是工作流里的拦截、补充和约束。

那它和 plugin 怎么搭在一起看？

Hook 可以被装进 plugin。

说白了，hook 是零件，plugin 是包。

Subagent 负责“谁来干这件事”

再说 subagent。

Claude Code 很强的一点，是它不只是会回答。它会分工。

你可以把不同任务交给不同角色：

一个代理负责前端
一个代理负责后端
一个代理负责测试
一个代理负责排查日志

subagent 处理的是另一类问题：

这件事该交给谁来干更合适。

如果你把 Claude Code 想成一个团队，subagent 就是里面的专职角色。

那它和 plugin 的关系呢？

结论也一样。

Subagent 不是 plugin 的替代品。它只是 plugin 里可以打包的一部分。

你完全可以做一个 plugin，里面就打包几个专门角色：

reviewer
security-auditor
debugger
release-manager

装完 plugin，这些角色就一起到位了。

所以 subagent 管分工。 plugin 管统一安装。

Skill 最容易和 Plugin 混

这一块最容易混。

因为它看起来确实很像同一类东西。

Anthropic 在 2025 年 10 月 16 日 发布 Agent Skills 时，把 skill 定义成一组由文件夹组织起来的 instructions、scripts、resources。

这个定义至少说明了一点：

Skill 更像“能力内容”。

它是在教 agent 某件事该怎么做。

比如：

怎么处理 PDF
怎么按品牌规范写内容
怎么完成某类固定流程
怎么调用一些脚本完成特定任务

如果说 MCP 是把外部世界接进来，Hook 是在流程里插动作，Subagent 是给任务分工，那 Skill 更像是在给 agent 一套“上岗资料”。

它不是单个工具。也不只是单条命令。

它更像一套做事方法，目的是让同类任务别每次都靠临场发挥。

这里最容易出现的误解是：

“既然 skill 也是一组文件和脚本，那它不就是 plugin 吗？”

不是。

我更认可的理解是：

Skill 是能力内容。Plugin 是分发容器。

这两个概念可以配合，但不该混写成一个。

从 Anthropic 的 Skills 公告和 anthropics/skills 仓库一起看，更容易理解这层关系。

更稳妥的说法是：

skill 更接近能力内容本身
plugin 和 marketplace 更接近安装与分发入口

所以在 Claude Code 这套语境里，你可以把它们理解成配合关系。

但不要反过来说：

Plugin 就等于 Skill。

这会把层次讲乱。

用一个真实场景拆开看，你就不会再混了

假设你们团队想做一套“PR 审查增强环境”。

很多人第一反应是：

“那我是不是应该先写个 MCP？”

先别急着下结论。

你得先看，缺的到底是哪一层。

如果你缺的是接入外部系统

比如你要：

读 GitHub PR
查内部规范库
连缺陷系统

那你先缺的是 MCP。

因为这就是接入问题。

如果你缺的是自动卡点

比如你要：

提交前自动检查风险命令
审查结束后自动发通知
工具调用前后自动补日志

那你先缺的是 hook。

因为这就是流程插入问题。

如果你缺的是专门角色

比如你想把安全审查、性能审查、测试补全拆给不同代理。

那你先缺的是 subagent。

因为这就是任务分工问题。

如果你缺的是稳定做事的方法

比如你希望 agent 审 PR 时总是按固定规范来：

先看功能正确性
再看安全风险
最后按团队格式输出结论

那你先缺的是 skill。

因为这就是能力复用问题。

那 Plugin 在哪一层

Plugin 不直接替你把这些事做掉。

它干的是更偏工程化的活：

把前面这些零件收起来，打成一个可以安装的包。

比如最终你们团队可能得到的是这样一个 plugin：

review-pr slash command
GitHub MCP server
security-reviewer subagent
审查前后自动执行的 hooks
一套 PR review skills

然后新人进组，只要装这个 plugin，就拥有同一套工作环境。

这就是 Plugin 真正值钱的地方。

它不是替代前面几层。它是把前面几层组织起来。

为什么 Plugin 对 Claude Code 很重要

如果只从单点功能看，plugin 好像也没多夸张。

因为你会觉得：

“这些能力以前不是也有吗？”

对。

以前很多能力就有。

但 Plugin 带来的变化，本来就不在单点功能。它的变化在工程化程度。

我认为它至少带来了 3 个变化。

1. 从零散扩展点，变成统一安装单位

以前你得一项一项教：

这个命令怎么加
那个 hook 放哪
子代理怎么配
哪些配置别漏

现在很多时候只要一句：

“装这个 plugin。”

这对团队推广很重要。

2. 从个人玩法，变成团队分发

一个人把 Claude Code 调顺，不算太难。

难的是十个人都装完以后，行为还能尽量一致。

Plugin 正是在解决这个问题。

3. 从“可定制”，走向“有生态”

有了 marketplace，Claude Code 的扩展能力才开始真的有点“生态”的样子。

你可以发现、安装、共享、维护。

这和“文档里说你可以自定义”不是一回事。

前者开始有生态。后者只是告诉你这里能改。

最后给一个判断框架

如果你后面再遇到 Claude Code 的扩展问题，可以先这样判断：

你要连外部工具

先看 MCP。

你要在流程节点插自动化逻辑

先看 hook。

你要给不同任务配专门角色

先看 subagent。

你要把一套做事方法沉淀下来

先看 skill。

你要把上面这些东西统一安装、共享、分发

这时候再看 plugin。

这个顺序挺重要的。

因为 Plugin 很像“总入口”，但它其实不是起点。

它更像收口层。

前面每一层先想清楚。后面的打包和分发才有意义。

我现在对 Claude Code Plugin 的看法也很简单。

它最重要的地方，不是又多了一个新名词。

而是 Claude Code 终于从“你可以自己配很多东西”，往“这些东西可以变成团队级、社区级的可分发能力”迈了一步。

这一步一旦成立，Claude Code 讲的就不只是 agent 能力。还开始讲生态能力了。

这才是 Plugin 真正值得写的地方。

参考资料

Anthropic 官方公告：Claude Code Plugins，2025-10-09
Anthropic 官方公告：Introducing Agent Skills，2025-10-16
Claude Code 官方文档：Overview
Claude Code 官方文档：MCP
Claude Code 官方文档：Setup / Slash Commands
Anthropic GitHub：anthropics/skills