插件系统：安装、开发与团队分发

插件是扩展的"打包格式"

前面几章讲的 skills、子代理、hooks、MCP 服务器，都是散装扩展——各自独立配置。插件（plugin）把这几样打成一个包：一个插件可以同时带技能、子代理、hooks 和 MCP 服务器，装一个插件等于一次接入全家桶。比如官方的 commit-commands 插件，装上就有提交、推送、开 PR 的一组命令。

打比方：散装扩展是菜市场买菜自己配菜，插件是预制菜——开袋即热，配方统一，还便于分享。对"把团队工作流标准化"这个需求来说，插件是目前 Claude Code 里最正式的载体。

安装：面板流与命令流

面板流（推荐新人）：会话里跑 /plugin（不带参数），打开面板后默认在 Discover 标签，列出你所有市场源里的插件，可搜索、可看详情。详情页会告诉你这个插件会安装什么（命令、代理、技能、hooks、MCP 服务器）——装之前看一眼是个好习惯，因为插件可以带 hooks 和 MCP 服务器，属于"会执行代码"的东西。

或者一步到位：

/plugin install commit-commands@claude-plugins-official

命令流（不进会话、写进脚本）：

# 默认装到 user 作用域
claude plugin install formatter@your-org

# 指定作用域
claude plugin install formatter@your-org --scope project
claude plugin install deploy-helper --marketplace your-org/plugins  # 市场+插件一步装

安装完成后按提示操作即可：有的提示 Plugin is now active.（立即可用）；有的要跑 /reload-plugins（热加载，不重启会话）；带 MCP 服务器的可能要先进 Configure 配参数。

三个安装作用域

project 作用域有个容易困惑的点：提交进共享设置的只是"启用声明"，同事机器上不会自动下载插件本体——每人还要跑一次 claude plugin install <名>@<市场> --scope project。同一插件多层设置时，local 压 project，project 压 user，规则与 settings 一致。

市场源：插件从哪来

市场（marketplace）是插件的目录清单。官方市场 claude-plugins-official 首次开交互会话时自动注册，能装 /plugin install <名>@claude-plugins-official 就直接装。别人的市场要先添加：

/plugin marketplace add owner/repo                 # GitHub 仓库
/plugin marketplace add your-org/plugins#v1.2.0    # 钉在某个 tag
/plugin marketplace add ./my-marketplace           # 本地目录（开发用）
/plugin marketplace add https://example.com/marketplace.json  # 托管清单

管理面板的 Marketplaces 标签能看、能更新、能开关自动更新（官方市场默认自动更新，社区市场默认不更新）。移除市场会连带卸载从它装的所有插件，面板会先列出清单让你确认——删源前看一眼。

卸载、依赖与同步

管理插件还有几个边角知识，遇到时少走弯路。卸载项目启用的插件会触发二选一：按 y 只对"我"禁用（写进你的 local 设置，插件对项目仍在），按 u 对所有人卸载（从共享设置移除）——手滑前看清提示。带依赖的插件：安装/禁用/卸载时会联动处理声明的依赖插件；自动装上的依赖用 claude plugin prune 清理。claude.ai 账号同步的插件：你在 claude.ai 上启用的插件会以 <名>@synced 的形式出现在终端会话里（v2.1.273+），管理和删除在 claude.ai 侧做，本地 /plugin 只能开关。

成本可视化：claude plugin details <名> 输出这个插件的 always-on token 开销和各组件占比；官方市场里的插件在详情页直接给"每轮开销"和"调用时开销"两个估算值。装插件和装 npm 包一样要有依赖洁癖——每个 always-on 的插件都在给你的每个会话加税。

开发一个自己的插件

插件目录结构固定，最小可用版长这样：

my-plugin/
├── .claude-plugin/
│   └── plugin.json     # 清单（可选，缺了就按目录结构自动发现）
├── skills/
│   └── my-skill/
│       └── SKILL.md    # 技能，调用时是 /my-plugin:my-skill
├── agents/
│   └── specialist.md   # 子代理
├── hooks/
│   └── hooks.json      # 事件钩子
└── .mcp.json           # 插件自带的 MCP 服务器

开发时不想来回装卸？用 --plugin-dir 启动加载本地目录，单会话生效，改完重开就行。注意一个安全限制：插件里的子代理不支持 hooks、mcpServers、permissionMode 字段——这些要么放插件的 hooks/hooks.json 和 .mcp.json（对插件全局生效），要么让用户拷贝到自己的 agents 目录。

团队分发：三条路选一条

路线一：内部市场仓库。建一个 git 仓库放 marketplace.json 和若干插件，团队每人 /plugin marketplace add 你的组织/插件仓库 一次，之后靠面板安装更新。适合十人以内、插件增长不快的团队。

路线二：项目共享启用。把团队必备插件写进项目 .claude/settings.json 的 enabledPlugins 提交，配合入职文档让大家装齐。声明跟着仓库走，人是各自装。

路线三：组织管理下发。管理员通过 managed settings 直接给全员预装/强制插件，成员无感同步。适合有合规要求的大团队。

插件与散装扩展怎么选

最后把决策框架补全。什么时候用散装（各自放 skills/agents/hooks 目录），什么时候打包成插件？

插件还有个隐藏福利：版本化。散装扩展改了就是改了，插件走市场的 tag 可以钉版本（#v1.2.0），回滚有据可查——对"团队工具链要稳定"的诉求，这是散装方式给不了的。

日常维护还有两个贴心工具：/plugin 面板的 Installed 标签会标出"Not used recently"的插件（附上次使用时间）；claude plugin details <名> 能看到插件的 always-on token 开销——插件不是免费的，每条描述都进上下文，季度清理一次是好习惯。

安全红线重申：装第三方插件等于让它在你机器上跑代码（hooks 和 MCP 服务器），来源不明的市场先审后装，官方插件文档有完整的信任审查清单。

本章由 WorkBuddy 原创整理，事实性内容参考 Claude Code 官方文档。