奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

事故响应 runbook：为什么「修完」之后还有一组人

2026-08-09

大部分团队的事故响应流程是这样收尾的：服务恢复，群里发一句「已修复」，然后各回各位。复盘要么排到下周，要么就没了。

agency-agents 这个仓库里有一份 strategy/runbooks/scenario-incident-response.md，配套在 runbooks.json 里有机器可读的团队配置。它把这套流程的角色分成了两组：一组在事故进行时全程在场（always），另一组在修复动作完成之后才上场（post-fix）。「修完」在这份 runbook 里不是终点，而是一次交接。

这篇讲怎么把这份名单真正装到自己的工具里、装完检查什么、以及它在哪些情况下帮不上忙。先把边界说清楚：我们只读了仓库文件，没有安装过其中任何一个 agent，也没有按 NEXUS 跑过任何一次流程，下面所有说法都是源码与文档口径。

这份 runbook 在仓库里长什么样

runbooks.json 收了四个场景，只有 incident-response 用的是 NEXUS-Micro 模式，另外三个（startup-mvp、enterprise-feature、marketing-campaign）都是 NEXUS-Sprint。

slug标题模式分组
incident-responseIncident ResponseNEXUS-Microalways(6) / post-fix(4)
startup-mvpStartup MVP BuildNEXUS-Sprintalways(9) / week 3+(3) / as needed(6)
enterprise-featureEnterprise Feature DevelopmentNEXUS-Sprintalways(15) / as needed(4) / as needed(3)
marketing-campaignMulti-Channel Marketing CampaignNEXUS-Sprintalways(5) / as needed(5) / as needed(4)

按 QUICKSTART.md 的说明，NEXUS-Micro 面向 5–10 个 agent、周期 1–5 天的场景，典型用途就是 bug 修复、单一交付物。这里的人数与天数是文档给出的建议区间，不是实测数据，也不是承诺。

always 组里我们核对到的有 support-infrastructure-maintainer、engineering-devops-automator、engineering-backend-architect、engineering-frontend-developer，全组共 6 个；post-fix 组是完整的 4 个：testing-evidence-collector、testing-api-tester、testing-workflow-optimizer、product-sprint-prioritizer。要引用具体 slug，回 runbooks.json 现查，别凭印象拼。

为什么第二组人存在

看 post-fix 这四个的分工，设计意图其实很直白：

  • testing-evidence-collector —— 花名册里给它的描述是「requires visual proof for everything」，对应 NEXUS 那条「所有评估都要有证据」的原则。事故复盘最常见的失败是「我们觉得修好了」，这个角色的提示词就是冲着把「觉得」换成可核对的记录去写的——至于模型照着这段提示词能不能真的做到，仓库没给依据，我们也没跑过。
  • testing-api-tester —— 修复之后回过头验接口，而不是只看监控曲线掉下去了。
  • testing-workflow-optimizer —— 对着流程本身提改进，不是对着这一次的 bug。
  • product-sprint-prioritizer —— 事故往往会翻出一堆技术债，这一步是把它们排进后续迭代，而不是任其消散在群聊里。

取证、回测、改流程、重排优先级——这四件事在人类团队里全都是「有空再说」的重灾区。这份 runbook 把它们从「修复」里拆出来单独成组，就是不让它们跟着修复动作一起被宣布结束。

顺带说一句：agent markdown 的 frontmatter 里那些 vibe 与 description 都是写给模型看的人设文本，不是任何人的真实履历，也不代表它真能做到。把它当成角色定位读就好。

怎么把这组人装下来

install.sh 的调用形态是 ./scripts/install.sh [selection] [mode] [behavior]。要装一个 runbook 团队，用得上的是选择器里的 --agent 和 --agents-file。

第一步永远是 --dry-run，它只打印计划、不写任何东西：

./scripts/install.sh \
  --tool claude-code \
  --agent support-infrastructure-maintainer,engineering-devops-automator,engineering-backend-architect,engineering-frontend-developer,testing-evidence-collector,testing-api-tester,testing-workflow-optimizer,product-sprint-prioritizer \
  --dry-run

逐个选项说明为什么在这：--tool claude-code 把目标收窄到一个工具，裸调用会往所有检测到的工具里装；--agent 接逗号分隔的 slug 列表，这是四个选择器（--tool、--division、--agent、--agents-file）里最精确的一个；--dry-run 是这个仓库对新手最有价值的开关——在往 ~/.claude/agents/ 这种共享目录写东西之前，先看一眼计划。仓库一共 255 个 agent，不加选择器就是全量落盘。

名单长了写在命令行里不好维护，改用 --agents-file，它每行一个 slug 或名字，支持 # 注释：

# incident-response / always
support-infrastructure-maintainer
engineering-devops-automator
engineering-backend-architect
engineering-frontend-developer

# incident-response / post-fix
testing-evidence-collector
testing-api-tester
testing-workflow-optimizer
product-sprint-prioritizer

./scripts/install.sh --tool claude-code --agents-file ./incident-response.txt --dry-run

确认计划没问题，去掉 --dry-run 再跑一次。如果你希望以后仓库更新能自动带过去，可以加 --link 用符号链接代替拷贝（改动会传播）。另外 install.sh 在 integrations/ 缺失时会自动去调 scripts/convert.sh，不想要这个行为就加 --no-convert。

Windows 侧注意：install.sh 是 shell 脚本，脚本注释里写明的平台是 Linux、macOS（需 bash 3.2+）、Windows 的 Git Bash 或 WSL。在 PowerShell 或 cmd 里直接敲是跑不起来的。

以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 --help 的实际输出为准。

产出物会落在哪

tools.json 把每个工具的安装机制记为 installKind，这决定了你能不能「只装这一个团队」：

工具formatinstallKind用户级目标
Claude Codeidentityper-agent.claude/agents/{slug}.md
Cursorcursor-mdcper-agent.cursor/rules/{slug}.mdc
Aideraider-conventionsrosterCONVENTIONS.md
Hermeshermes-router-pluginplugin.hermes/plugins/agency-agents-router

per-agent 是一个 agent 一份产物，八个 slug 就是八个文件，文件名主干与 slug 一致——这才是「装一个团队」说得通的形态。roster 是把所有 agent 合并成一个文件，产物形态上就不是一 agent 一文件；plugin 是构建出来的产物，在所有消费方都只能走命令行。挑工具时先看这一列。

还有一处路径差异容易踩：按 install.sh 的注释，Claude Code、Codex、Gemini CLI 这些落在家目录，而 opencode、Cursor、Aider、Windsurf 写的是当前目录。这个差别决定了你是给某个项目装还是给整个账户装，执行前先确认自己站在哪。

装完验收哪几处

  1. 文件数量与文件名。per-agent 类工具下，目标目录里应当出现与你名单一一对应的条目，文件名主干就是 slug。数量对不上，说明有 slug 没解析到。
  2. slug 能不能解析。仓库自带 scripts/check-runbooks.sh，它守的就是「runbook 里引用的每个 slug 都能解析到真实存在的 agent 文件」。名单是自己维护的时候，这一步尤其值得跑。
  3. Cursor 用户额外看一眼 frontmatter。convert.sh 生成 .mdc 时把 alwaysApply: false 和 globs: "" 写死了，也就是转换出来的规则默认不会自动生效，需要在 Cursor 里按需引用。装完觉得「像没装」，多半就是这里。
  4. 自己改过 agent markdown 的话，跑一遍 scripts/lint-agents.sh。它查三类问题：CRLF 行尾和 frontmatter 必填字段（name/description/color）缺失报 ERROR；推荐章节缺失、正文词数不足 50 只报 WARN，不会让检查失败。这两个级别别混为一谈。

顺带一个可以直接搬到自己项目里的做法：runbooks.json 里引用的是 slug 而不是显示名，_note 给的理由是显示名带前缀、会漂移，而 slug 抗改名、可测试。跨文件引用稳定 id 而不是展示文本——这条跟 AI 没关系，写任何配置都成立。

什么情况下别指望它

  • 它不是调度器。 strategy/ 目录里没有可安装的 agent（divisions.json 的 _note 明说这里放的是编排方法论），NEXUS 全部写在 markdown 里，靠提示词让模型自己按阶段推进，没有任何代码在强制执行阶段顺序或质量门。它不会在你跳过 post-fix 组时拦住你。
  • 真·线上事故的决策不能交出去。 止血、回滚、对外沟通这些动作要人拍板，这份 runbook 顶多帮你把「修完之后该做什么」列清楚，别把它接进告警链路当自动处置。
  • 不要一次性把 255 个 agent 灌进全局配置目录。 上下文占用、加载开销、命名冲突都是代价，用 --division 或 --agent 收窄是更稳的做法。具体影响有多大我们没有测过，不给数字。
  • 合规、法务、对外披露口径不在这份名单里。 名单是工程视角的。

真正值得从这份 runbook 里带走的其实只有一句：把「修完之后」写成一个有名字、有分组、有交接对象的阶段，它才有机会真的发生。至于执行者是模型还是人，反倒是次要的。

延伸阅读

本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、 tools.json、divisions.json、runbooks.json、strategy/ 下的编排文档与 scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。 本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent，也没有按 NEXUS 跑过任何一次流程。 目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员