Hooks、Subagents 和 MCP 都能扩展 Claude Agent SDK，但解决的是三类不同问题：在工具调用前后执行控制、把任务交给隔离上下文、把外部系统暴露为工具。把它们混成“生产化组件清单”，容易让 Hook 承担业务编排，让子 Agent 获得不必要权限，或把 MCP 服务器误当作只读数据源。本文用职责、权限、输入输出和失败恢复四个维度说明何时选择哪一种机制。
先用一句话区分
| 机制 | 主要职责 | 不应默认承担 |
|---|---|---|
| Hooks | 在 Agent 执行关键点检查、记录或转换行为 | 长时间业务编排、外部系统实现 |
| Subagents | 隔离上下文，以专门指令完成边界清楚的子任务 | 绕过主任务权限、共享全部敏感上下文 |
| MCP | 通过标准协议提供外部工具和数据访问 | 自动获得可信、只读或幂等属性 |
选择前先写清楚问题是“在哪里拦截”“谁来完成独立分析”还是“怎样访问外部能力”。一个问题不一定需要三者同时出现。
Hooks：处理横切控制点
Agent SDK Hooks 官方文档将 Hooks 用于在关键执行点拦截和定制 Agent 行为。适合的任务包括：
- 在工具调用前根据工具名、参数和任务策略允许或拒绝。
- 在调用后记录脱敏结果、延迟和错误状态。
- 为统一追踪补充任务标识。
- 在停止或失败路径中释放当前任务资源。
Hook 的输入和输出必须按当前 SDK 事件契约实现，不要自创 before_bash、after_result 等名称并假设 SDK 会识别。
Hook 不等于完整安全边界
Hook 代码与 Agent 运行在同一应用责任范围内，也会失败、超时或配置遗漏。关键禁止项还应落实到 SDK deny 规则、受限进程账号、文件系统和外部系统权限。
设计每个 Hook 时明确：
匹配哪些事件和工具
需要读取哪些参数
允许、拒绝或修改什么
失败时默认允许还是拒绝
日志中哪些字段需要脱敏
超时与异常如何返回
规则应可单独测试，并覆盖允许、拒绝、异常和取消。审计 Hook 不能为了记录方便保存完整密钥、源码或业务响应。
Subagents：隔离上下文与专门指令
官方 Subagents 文档说明，子 Agent 可用于隔离上下文、并行执行任务和应用专门指令。它适合边界独立、输入可裁剪、输出可合并的分析，例如对同一个 Diff 分别检查测试风险和文档缺口。
一个适合委派的子任务应具备：
- 明确输入，不需要继承主会话的全部历史。
- 单一输出契约，例如结构化发现而非直接改代码。
- 与其他子任务没有写入顺序依赖。
- 独立的工具和数据权限。
- 超时或失败时主任务能降级处理。
并行不是默认目标
多个子 Agent 同时修改同一工作区、读取动态状态或调用有副作用的工具，会产生竞争和难以复现的结果。并行更适合只读、独立的分析；涉及写入时，应使用独立工作副本或由协调者串行应用经过确认的变更。
主 Agent 不应把整个上下文无条件转发。只传递完成子任务必需的文件、Diff、规则和已脱敏数据。子 Agent 的结论还需要引用证据，协调者不能只按票数合并相互冲突的判断。
MCP：把外部能力变成工具
Agent SDK MCP 官方文档覆盖 MCP 服务器配置、传输方式、认证、工具发现和错误处理。MCP 适合连接工单、知识库、日志、浏览器或内部服务，但“能调用”不代表“应该拥有全部账号权限”。
评估一个 MCP 工具时检查：
输入 schema 是否限制对象和范围
认证代表哪个用户或服务账号
工具是读取、写入还是不可逆提交
是否支持幂等键或重复调用保护
输出是否可能包含凭据和敏感数据
超时、部分成功和限流怎样表达
服务器日志与 Agent 日志如何关联
只读和写入工具应分开暴露，并使用权限不同的身份。不要只靠工具描述中的“请勿用于生产”约束真实写权限。
MCP 服务器是独立信任边界
服务器实现、部署、认证和数据访问都有自己的风险。Agent SDK 的权限规则只能决定是否调用已经暴露的工具，不能替代 MCP 服务器内部的鉴权、输入校验、速率限制和审计。
用问题类型选择机制
需要在每次编辑前检查路径
选择 PreToolUse Hook 配合 SDK deny 规则和文件系统权限。没有必要为每次路径判断启动子 Agent，也不需要 MCP。
需要对一个 Diff 做两类独立审查
选择输入受限的只读 Subagents。每个输出使用同一发现 schema，最终由主流程去重并保留冲突。
需要读取外部工单
选择只读 MCP 工具，认证到权限最小的账号，并让工具返回必要字段。是否再用子 Agent 分析，取决于工单和代码审查是否能独立拆分。
需要阻止生产发布
不要只写 Prompt 或交给子 Agent判断。使用外部发布系统的权限与审批作为硬边界，SDK deny 规则和 Hook 作为附加控制。
一个受控的故障分析组合
假设任务是根据测试环境工单和仓库代码生成定位报告，不允许修改系统：
MCP：只读取得指定工单字段，屏蔽附件和无关客户数据。
Hook：拒绝任何写工具和范围外 MCP 调用，记录脱敏工具摘要。
Subagent A：根据工单复现步骤定位候选代码。
Subagent B：检查相关测试覆盖和缺失分支。
Coordinator：合并带文件证据的结果，保留冲突和未确认项。
这个组合的交付物只是定位报告。补丁生成、CI 验证和工单写回属于新的阶段，需要重新授权，不能因为前一阶段读取成功就自动升级权限。
共同的失败设计
无论使用哪种机制，都应定义：
| 失败 | 必须知道 | 处理原则 |
|---|---|---|
| Hook 拒绝或异常 | 哪条规则、哪个调用 | 安全失败并保留脱敏原因 |
| Subagent 超时 | 输入、已完成状态 | 主任务标为不完整，不伪造结论 |
| 子结果冲突 | 各自证据和范围 | 保留冲突，交给协调者或人判断 |
| MCP 超时 | 工具、对象、是否有副作用 | 不盲目重试写操作 |
| MCP 部分成功 | 哪些对象已改变 | 停止并按服务器契约恢复 |
| 主任务取消 | 仍运行的子任务和工具 | 传播取消并确认资源释放 |
成功路径之外的集成测试是生产评估的必要部分。只演示一次正常调用，无法证明权限和恢复行为。
设计评审清单
这个需求究竟需要控制点、上下文隔离还是外部工具？
每个组件接收的最小输入是什么？
权限是否在 SDK 和目标系统两侧都收窄？
哪个组件有写入或不可逆副作用？
哪些调用能并行，哪些必须串行？
拒绝、超时、取消和部分成功如何表示？
输出是否保留来源与未确认项？
日志是否足以追踪但没有过量保存敏感内容？
回答不了这些问题时，先保持单 Agent、只读和同步流程，避免为了使用功能而增加架构复杂度。
结论与限制
Hooks 负责执行点控制，Subagents 负责隔离的专门任务，MCP 负责外部工具接入。三者的共同原则是最小输入、最小权限、显式副作用和可观察失败，而不是堆叠功能数量。
具体事件、Subagent 配置和 MCP 传输会随 SDK 更新，代码实现必须参考锁定版本的官方文档。本文是职责与风险选择框架，不替代目标系统的身份、权限和恢复设计。