Claude Code 插件实战：用 Incident Commander 子代理构建结构化事件响应流程

导读：本文围绕 claude-howto 仓库中 devops-automation 插件内的 incident-commander 子代理展开，解析它的定位、frontmatter 配置与五大核心职责，并结合 /incident 命令、配套子代理、Bash 脚本与 MCP 服务器，说明如何在 Claude Code 中搭建一条从告警评估、团队协调到事后复盘（post-mortem）的完整事件响应链路。读完本文，你将能独立理解并部署一套基于 Claude Code 子代理的线上故障处置工作流。

什么是 Incident Commander 子代理

在 Claude Code 的插件体系中，子代理（subagent）是一种轻量级、可独立调度的"专家角色"。devops-automation 插件（见 插件说明）打包了部署、监控与事件响应三大能力，其中 incident-commander 专门负责统筹事件响应。

它的完整定义位于 incident-commander.md，整个文件非常简洁，只包含一段 YAML frontmatter 和一段职责清单：

---
name: incident-commander
description: Coordinates incident response
tools: Read, Write, Bash, Grep
---

# Incident Commander

Manages incident response:
- Severity assessment
- Team coordination
- Status updates
- Resolution tracking
- Post-mortem facilitation

这份定义虽然简短，却是整个事件响应工作流的"指挥中枢"：它不负责具体的部署操作，也不负责告警数据的底层解析，而是把故障处置过程中的判断、协调、沟通与追踪收拢到一个可被反复调用的角色中。

配置解析：frontmatter 的三个关键字段

子代理的行为边界完全由 frontmatter 决定，incident-commander 的配置有三个要点：

字段	值	作用
name	incident-commander	子代理的唯一标识，供主线程或 /incident 命令按名称委派任务
description	Coordinates incident response	描述子代理擅长的工作，Claude Code 据此在合适的场景自动选择它
tools	Read, Write, Bash, Grep	授予的工具权限，恰好覆盖事件处置全流程：读日志、写记录、跑诊断命令、检索代码与配置

tools 字段值得展开：事件响应的每一步都依赖这四个工具的组合。Read 用于读取告警详情、配置文件与相关文档；Write 用于创建事件记录、更新状态文件、起草事后复盘文档；Bash 用于执行诊断命令（如 kubectl get pods、curl 健康检查）；Grep 用于在代码库或日志目录中快速定位故障相关片段。相比插件中的 alert-analyzer（仅授予 Read, Grep, Bash），Incident Commander 多了 Write，这正是"记录与复盘"职责的体现——它不仅要读和查，还要持续产出事件文档。

五大核心职责详解

1. 严重性评估（Severity assessment）

事件处置的第一步是分级。Incident Commander 需要综合告警内容、影响范围、受影响用户规模等信息，判断故障是 P0（服务完全不可用）、P1（核心功能受损）还是更低级别。这一判断直接决定后续的响应力度、升级路径与通知范围。

2. 团队协调（Team coordination）

分级之后是指挥调度。Incident Commander 负责确定谁来响应、是否需要升级、何时升级，并把处置任务分派给合适的执行者。在插件内部，它天然与 deployment-specialist（负责回滚、蓝绿发布、金丝雀发布等部署操作）和 alert-analyzer（负责告警关联、趋势分析、根因识别）形成分工：Commander 判断"做什么"，Specialist 执行"怎么改"，Analyzer 回答"为什么坏"。

3. 状态更新（Status updates）

事件处置过程中，状态同步至关重要。Incident Commander 需要持续把"已确认、处置中、已缓解、已解决"等状态更新到事件记录中，确保所有相关方（值班团队、管理层、业务方）对当前进展有一致的认知，避免重复操作与信息孤岛。

4. 解决情况追踪（Resolution tracking）

从确认故障到确认恢复，Incident Commander 需要验证每个处置步骤是否真正生效。这一步通常与插件自带的脚本联动：例如用 health-check.sh 检查 API 端点、数据库连通性与 Pod 就绪数，用 rollback.sh 回滚到上一个可用版本，再以健康检查结果确认"解决"这一结论是否成立，从而把事件状态从"处置中"推进到"已解决"。

5. 事后复盘（Post-mortem facilitation）

故障解决不代表事件结束。Incident Commander 的最后一项职责是组织事后复盘：梳理时间线（什么时间发生了什么、谁在什么节点做了什么）、分析根因、总结改进项，并输出可归档的复盘文档。复盘文档既是团队的资产，也是后续避免同类事故的依据。

与 /incident 命令的协作：一条完整的事件处理链路

子代理不是孤立存在的，devops-automation 插件通过 incident.md 定义了 /incident 斜杠命令，与 Incident Commander 形成了"命令入口 → 指挥中枢 → 执行者"的协作结构：

1. 创建事件记录（Create incident record）
2. 评估严重度与影响（Assess severity and impact）
3. 通知值班团队（Notify on-call team）
4. 收集诊断信息（Gather diagnostic information）
5. 协调响应工作（Coordinate response efforts）
6. 记录解决方案（Document resolution）
7. 安排事后复盘（Schedule post-mortem）

对照可以发现，这七步与 Incident Commander 的五大职责几乎一一对应：/incident 命令定义了流程骨架，Incident Commander 则是驱动这个骨架运转的指挥角色。在实际会话中，用户输入 /incident 后，Claude Code 会加载命令流程，并在需要时把具体工作委派给 incident-commander 子代理执行。

从源码结构看，这条链路还串联了插件的其余组件，形成一个完整的事件处置闭环：

• 诊断阶段：调用 health-check.sh 检查 API、数据库与 Pod 状态；由 alert-analyzer 完成告警关联与根因识别
• 处置阶段：由 deployment-specialist 执行部署或回滚操作，必要时调用 rollback.sh 进行回滚
• 验证阶段：再次运行健康检查，确认服务恢复
• 复盘阶段：由 Incident Commander 汇总时间线与根因，产出事后复盘文档

支撑事件响应的底层组件

要理解 Incident Commander 为什么"指挥得动"这些操作，需要看清插件为其准备的执行资源：

脚本层提供了可直接执行的处置工具：deploy.sh 依次执行代码检查、测试、构建、kubectl apply 部署与健康检查；rollback.sh 通过 kubectl rollout undo 回滚到上一个修订版本并等待就绪；health-check.sh 分别探测 API 端点、数据库（pg_isready）与 Pod 就绪数。这些脚本是 Commander 下达"回滚"、"验证"指令时背后的实际执行者。

Hook 层提供了部署前后的质量闸门：pre-deploy.js 在部署前校验 kubectl 是否安装、是否已连接集群；post-deploy.js 在部署后等待 Pod 就绪并执行冒烟测试。这两道闸门让 Incident Commander 在协调处置时拥有可靠的"部署是否成功"判断依据。

MCP 层让 Commander 具备对 Kubernetes 集群的实时感知能力。插件在 kubernetes-config.json 中注册了 @modelcontextprotocol/server-kubernetes，通过 KUBECONFIG 环境变量接入集群，Incident Commander 可以借此查询 Pod 状态、事件与资源使用情况，为严重性评估和解决追踪提供第一手数据。

如何在你的项目中落地

安装插件

/plugin install devops-automation

安装后会获得四个斜杠命令（/deploy、/rollback、/status、/incident）、三个子代理（deployment-specialist、incident-commander、alert-analyzer）以及对应的脚本、Hook 与 Kubernetes MCP 服务器。

前置条件

• Claude Code 2.1 及以上版本
• 安装 Kubernetes CLI（kubectl）并配置集群访问

export KUBECONFIG=~/.kube/config

触发事件响应

/incident

之后即可在会话中把处置工作交给 Incident Commander，例如让它"评估当前告警的严重级别并通知值班团队"、"协调回滚并验证服务恢复"、"生成本次故障的事后复盘文档"。

小结

Incident Commander 是 devops-automation 插件中负责"统筹"的子代理角色：它用 Read, Write, Bash, Grep 四个工具覆盖了事件处置的完整生命周期，把严重性评估、团队协调、状态更新、解决追踪与事后复盘五件事收敛成可反复调用的能力。在与 /incident 命令、alert-analyzer / deployment-specialist 两个兄弟子代理、三个运维脚本、两道部署 Hook 以及 Kubernetes MCP 的配合下，它构成了 Claude Code 生态中一套结构清晰、可直接落地的线上故障处置工作流。