主题
10.1 Plugin 与 Marketplace
Plugin 把 MCP、Skills、Agents、Hooks 打包成一个可安装、可分发的单元。
读完你能做什么：理解插件结构，安装插件，并把团队的能力打包成私有插件分发。
一、Plugin 是什么
Plugin = 一组扩展能力的打包分发单元。 一个插件可以包含：
text
Plugin
├── Skills（技能）
├── MCP servers（连接器）
├── Agents（子代理）
├── Hooks（钩子）
└── Commands（命令）安装一个 Plugin，等于一次性获得这一整套为某个场景/角色配好的能力。
1.1 为什么需要 Plugin
text
不用 Plugin：
装技能 A → 配 MCP B → 建子代理 C → 设 hook D...
每个人都要重复一遍，容易配错
用 Plugin：
claude plugin install team-toolkit@company
一条命令，整套能力到位二、安装插件
bash
# 从 marketplace 安装
claude plugin install <name>@<marketplace>
# 例子
claude plugin install code-review@claude-plugins-official管理：
bash
claude plugin # 插件管理入口（别名 claude plugins）临时加载（不永久安装）：
bash
claude --plugin-dir ./my-plugin # 从目录加载
claude --plugin-dir ./my-plugin.zip # 从 zip 加载
claude --plugin-url https://example.com/plugin.zip # 从 URL 加载三、Marketplace（插件市场）
Marketplace 是插件的分发源。可以是：
| 类型 | 说明 |
|---|---|
| 官方市场 | Anthropic 维护的官方插件 |
| 社区市场 | 第三方 |
| 私有市场 | 你们团队/公司自己的插件源 |
私有市场是团队工程化的关键 —— 它让你把公司内部的标准能力包集中分发。
四、Plugin 的结构
一个 Plugin 本质是一个特定结构的目录：
text
my-plugin/
├── plugin.json # 插件元信息（名字、版本、描述）
├── skills/ # 技能
│ └── release-check/
│ └── SKILL.md
├── agents/ # 子代理
│ └── reviewer.md
├── hooks/
│ └── hooks.json # 钩子配置
├── commands/ # 命令
└── .mcp.json # MCP server 配置plugin.json 声明插件的基本信息，其余目录就是你已经熟悉的那些扩展机制 —— Plugin 只是把它们打包在一起。
五、插件里的组件如何命名
插件提供的组件会带插件作用域前缀，避免冲突：
text
普通技能： /release-check
插件里的技能： /my-plugin:release-check
插件里的子代理： my-plugin:reviewer这个 : 分隔的命名让不同插件可以有同名组件而不冲突。（这也是为什么技能/代理的 name 字段不能含 : —— 它保留给插件作用域。）
六、打包一个团队插件
假设你们团队积累了一套标准：release 检查技能、代码审查子代理、格式化 hook、内部系统的 MCP 连接器。把它们打包：
6.1 组织目录
text
company-toolkit/
├── plugin.json
├── skills/
│ ├── release-check/SKILL.md
│ ├── api-design/SKILL.md
│ └── postmortem/SKILL.md
├── agents/
│ └── security-reviewer.md
├── hooks/
│ └── hooks.json # 自动格式化、测试门禁
└── .mcp.json # 内部 GitHub、数据库连接器6.2 plugin.json
json
{
"name": "company-toolkit",
"version": "1.0.0",
"description": "公司标准开发工具包：release 流程、API 规范、安全审查、内部系统接入"
}（字段以官方 plugins-reference 为准。）
6.3 分发
- 通过私有 marketplace 发布
- 或直接分发目录/zip，团队用
--plugin-dir加载
团队成员安装后，立刻拥有全套标准能力，无需各自配置。
七、Plugin 在 CoWork 里
CoWork 也支持 Plugin。CoWork 用户可以：
- 从市场安装匹配自己角色的插件包
- 获得为特定工作（数据分析、文档处理等）配好的能力
见 09.3。
八、从个人到团队的演进路径
Plugin 是这条演进路径的终点：
text
个人经验
↓ 固化
Skill / Hook / 子代理（个人用）
↓ 提交 git
项目共享（团队在这个项目里共享）
↓ 打包
Plugin（跨项目、跨团队分发）
↓ 发布
私有 Marketplace（全公司标准）一套好的工作法，沿着这条路径，从"你一个人知道"变成"全公司的标准配置"。
九、企业级管控插件
组织可以通过管理设置强制启用某些插件，确保全员使用经过审核的能力包：
text
managed settings 的 enabledPlugins
→ 强制下发插件
→ 个人无法移除被强制启用的插件里的 hook 甚至可以豁免"只允许管理员 hook"的限制 —— 让管理员能通过组织市场分发经过审核的 hook。见 10.3 企业级管控。
十、实操建议
| 建议 | 理由 |
|---|---|
| 先在项目里验证组件，再打包插件 | 打包前确保每个技能/hook 真的好用 |
| 一个插件聚焦一个主题 | "前端工具包""数据分析包"，而非大杂烩 |
| 版本化管理 | plugin.json 的 version，便于团队升级 |
| 写清 description | 让人知道这个插件解决什么问题 |
| 私有系统的连接器放插件 | 团队一次配好内部系统接入 |