Skill、MCP、Hook、子代理，该用哪个？

一个团队发现，Claude Code 在发布前总有几个毛病：经常漏查版本号，有时没去看 PR 评论，检查做完了还会接着尝试发布。

讨论起来，有人说该接一个 MCP，有人说该写一个 Skill，还有人提到 Hook 和子代理。每个建议听上去都对，最后常常是各装各的，装了一堆，毛病还在。

问题出在选之前没有问清楚：缺的到底是什么？

• 漏查版本号，缺的是检查方法
• 没看 PR 评论，缺的是访问外部系统的能力
• 检查完擅自发布，缺的是授权和控制

三件事同属发布检查，补的却是三种不同的东西。Claude Code 的扩展机制名字相近，Tool、MCP、Skill、Hook、Subagent、Plugin 各管一块，对号入座才有用。

这样一来，选择就很朴素：先说出缺的那项职责，再用最少的机制补上，现有能力够用就保持原样。

沿着发布检查这个例子逐个看：六种机制各自负责什么，什么时候值得用，要付出哪些权限和维护成本，最后落成一张“缺口对应最小调整”的表，团队里类似的需求都可以照着推。

01 先根据记录区分缺少的职责

漏查版本号可能是检查方法不完整；未读 PR 评论可能是缺少外部访问；检查后擅自发布，则需要核对授权与控制。先说明实际缺口，再决定用哪种机制。可以先按需要定位职责：

具体读取或操作 → Tool
外部系统连接   → MCP
可复用任务方法 → Skill
固定事件检查   → Hook
独立上下文探索 → Subagent
跨项目安装更新 → Plugin

这些职责可以配合：MCP 提供 Tool，Skill 组织工具用法，Plugin 分发已配置的组件。

02 Tool 提供操作，Skill 组织方法

Tool 是 Claude Code 可以调用的一项具体操作。读文件、搜索代码、编辑文件、运行命令，都需要通过相应工具完成。工具的名称、参数和返回结果决定了调用者如何使用它。

项目里已经有测试脚本，Claude Code 也能用 Bash 工具把它跑起来。执行能力已经有了，还需要确定检查方法：针对哪个版本运行、失败后怎么办、最终输出什么。

Skill 是按需加载的任务知识与工作说明。对这项发布检查，可以把方法写成：

确认目标版本与当前分支。
检查工作区改动，按项目约定运行测试。
核对版本号与变更日志。
分开报告通过、失败、未运行和阻塞项。
完成检查后停止，不自动发布。

Tool 提供执行能力，Skill 说明检查顺序、结果判断和停止条件。工具可用，方法还要另外写清；方法写清，工具和权限还要另外配齐。

通常，Skill 的描述帮助 Claude Code 判断何时使用，正文在调用时加载。长清单、示例和脚本可以作为支持文件，但 Skill 要写明何时读取它们；文件放进目录后，只在被读取时才进入会话。

少量稳定的命名要求可以写成项目规则。反复出现、需要输入和判断、前一步证据决定后一步的任务，才更值得组织为 Skill。具体怎么写、怎么检验，见如何写好一个技能 Skill。

03 什么时候需要 MCP 接入

发布检查已经有方法，但现在还要读取最新 PR 评论。本地 Git 记录不一定包含这些内容，需要访问 GitHub。

MCP 是连接外部系统的协议与接入机制，官方文档把它定位为让 Claude Code 连接外部工具和数据源的方式。一个外部 MCP Server 可以提供读取 PR 评论等工具。MCP 解决连接方式，具体 Tool 决定读取哪个仓库、哪个 PR、返回哪些内容。

访问外部信息前，先检查现有能力是否足够：

连接成功只说明取得了访问能力。评论仍可能过期、判断错误或只返回一页；读取权限也不授权留言或合并。如果评论要求上传本地凭据，应将其视为外部资料中的越权指令，继续遵守原任务范围。接口怎么设计、分页和外部资料怎么防，见AI Agent 总用错工具，多半是接口没设计好。

04 用 Hook 设置固定检查点

Skill 已规定检查后停止，团队还希望在受保护操作执行前进行程序检查。Hook 在匹配的生命周期事件上由运行环境触发，可以设置固定检查点；它能否阻断动作，还取决于事件、返回决定和覆盖范围，详见Hooks 文档。

动作前的检查可用于拒绝执行，动作后的格式化只能处理已经发生的改动。Stop 只表示一个响应阶段结束，发布检查是否通过要另行确认。

确定性检查主要由 command Hook 执行脚本。脚本要知道输入是什么、检查哪些操作、怎么返回决定。只匹配某个删除命令的字面写法，管到的只是这一种写法，其他工具或脚本里的删除行为要靠权限和执行环境来管，所以 Hook 的覆盖范围要和它们一起设计。

如果问题是“架构设计是否合理”，单个短脚本往往答不了。可以让 review Skill 组织审查，必要时交给独立子任务。Claude Code 也支持调用模型的 Hook 类型；固定事件能触发它，判断是否正确，仍要单独验证。

在发布案例中，Skill 负责检查流程，Hook 负责已配置事件上的具体检查。新增 Hook 前，先说清楚它要拦截哪个具体动作，以及如何检查。

05 用 Subagent 隔离独立探索

发布检查又多了一项：独立审查认证模块。探索会读取大量文件，如果全部放进主会话，主会话可能被审查细节淹没。

Subagent（子代理）是承担子任务的 Agent，拥有独立上下文。可以让它负责边界清楚的探索，主会话接收用于继续判断的摘要。与 Skill 的区别在于：Skill 提供方法，Subagent 提供独立处理这段工作的上下文；子任务也可以采用相应的方法。

例如，把“只读核对认证改动是否影响会话恢复”交给子任务，要求返回涉及路径、判断证据、未知项和建议检查。摘要里有路径、证据和未知项，主会话才有依据继续判断，需要时也能回查。

独立上下文让子任务各自处理信息，但它们仍可能使用同一个文件系统。两个子任务可能仍在同一工作目录中，同时修改相同文件照样冲突；需要分开试验性改动时，可以配合 worktree，也就是同一 Git 仓库的另一份工作目录。权限、探索预算和文件隔离怎么安排，见多个子代理并行改代码，先划分好谁写哪份文件。

分派会增加上下文传递和整合成本。每一步都依赖另一任务的即时结论时，顺序处理更合适；短小探索也可留在主会话处理。

06 用 Plugin 共享稳定配置

当 release-check 还在单项目中调整，把 Skill 和相关配置放在项目的 .claude/ 下即可。如果多个项目都要安装同一套方法，并持续获得更新，就出现了分发需求。

Plugin 是可安装、可版本化的扩展包，可以组织 Skills、agents、hooks、MCP servers 等支持的组件，参见Plugins 文档。它负责安装、共享与更新；内部流程是否正确、权限是否合理，仍要各自验证。

例如，团队可以把稳定的检查 Skill、独立审查配置及必要 Hook 组织成一个插件。安装者仍需知道它会读取什么、执行什么、需要哪些授权；插件内的 Skill 通常带命名空间，用于区分不同来源的同名能力。

问题只是“今天的检查漏了 changelog”就先修 Skill；如果是“五个项目各自维护不同版本的检查流程”，才需要考虑统一分发。打包前先实际试用，确认流程能工作，再考虑让更多项目使用。

07 按缺口逐步组合

回到最初的发布检查。当前项目已有可运行的测试脚本和 Git 工具，方案可以一步步推导：

本地 CLI 已能读取评论，就沿用现有工具；只看几行配置的审查，也可留在主会话。每增加一个机制，都要说明它补足什么职责，以及相应的权限、上下文和维护成本。现有能力足够时，保持原方案即可。