多智能体协作处理安全修复与事故复盘

4 个工作日、约 30 个 AI agent 会话、5 条工作线，作者完成约 17 项安全修复，同时处理生产事故、复盘和平台积压。支撑这套做法的，是把 AI 分成负责人、协调者、执行者和审查者，再由人守住生产决策关口。

这篇最值得借鉴的，是任务怎么交代、证据怎么核验、并行怎么收口。它也暴露了一个问题：代码产出提速后，审核、审批和人的注意力，会成为新的瓶颈。

多个 agent 怎么才能像团队一样工作

作者遇到的是几类事情同时到期：多个服务的安全问题要修，生产事故要止损、取证和复盘，此外还有环境扩容、成本调查、客户性能问题，以及经理日常的会议和 1:1。

单个长会话很难承载这些工作。不同任务的上下文会混杂，哪些在等 CI、哪些在等审核、哪些需要人决策，也容易失去踪迹。因此，作者给安全修复、事故、文档与根因分析（RCA）、云基础设施、成本调查分别建了工作线。

下面这段分工解决的是「谁执行、谁监督、谁拍板」：

Me (decisions, approvals, every production gate)
  └── Lead (one per workstream: plan, order, prod actions after my yes)
        ├── Coordinator (status log, dependencies, chasing stale items)
        ├── Task × N (one per PR, ticket or hypothesis)
        └── Reviewer × N (adversarial: gets the diff, not the answer)

最该留意最后一行：Reviewer 拿到代码差异，不拿作者预设的结论。要求它找问题，可以减少「帮我验证这个方案」带来的顺从倾向。作者称，几项自己认为显然正确的修复，都被审出了实际问题。

任务状态直接写进会话标题，例如 05 🔄 DEPLOYING service-a – fix 12、07 ✅ LIVE service-b – fix 07 (flag off) 和 02 ⏸ HOLD cloud – needs decision。编号表达顺序，状态表达进展，侧栏就成了看板。

但执行并行不等于上线并行：同一个服务一次只推进一项生产变更，每次上线后单独观察。否则出了问题，很难判断该回滚哪一个。

任务说明和 skills，决定 agent 能否独立推进

作者认为，自己最大的能力变化是开始认真写任务说明（brief）。新 Task agent 不知道你的默认习惯，也不会自动理解「做完」包含哪些环节。

这份模板把目标、位置、验收、边界和汇报方式放在了一起：

GOAL         Fix finding #12 in service-a: <one-sentence description>
WHERE        repo, files, the ticket, the original finding
DONE MEANS   PR open, tests added, CI green, behind a new flag created OFF,
             PR description with rollout + rollback, ticket comment drafted
CONSTRAINTS  no changes outside <module>; keep legacy behavior as the flag default
REPORTING    report head commit, evidence and blockers to the Lead.
             Do NOT merge, deploy, or touch flags.

要盯住 DONE MEANS 和最后一行：交付物包括测试、CI、默认关闭的新开关、上线与回滚说明，但执行者没有合并、部署或修改开关的权限。完成准备与获准执行，是两个状态。

作者把不少跑偏归因于自己漏写约束、验收模糊，或者没指出相关文件。这是很实用的提醒：多开会话之前，先检查任务是否已经清楚到可以交给另一个工程师。

brief 负责当前任务，skills 则保存团队的长期知识，包括架构、部署拓扑、事故历史、有效的观测查询、工单约定和协作规则。这里的 skill 可以理解为按需加载的知识文件。

他们曾遇到 agent 用一条根本不会产生的日志「验证」上线。发现后，作者把教训写进观测 skill，避免后来者重复犯错。但知识文件也会过期，所以作者建议给它们做版本管理、删除陈旧事实，并标注日期。

为什么上线必须比写代码慢一点

作者的生产规则很具体。所有修复先放在默认 OFF 的 feature flag 后面，旧行为仍是默认行为；合并和部署后，客户行为暂时不变，直到有人明确开启开关。

合并、部署、开关切换、关闭工单和外部消息，都需要人逐项批准。同意合并不等于同意部署，agent 转述「用户批准了」也不能算授权。生产环境默认只读，允许查日志、指标和集群状态。

部署后还要经过观察期（soak），检查错误率、延迟、重启和相关安全监控，同时对比前一个时间窗口、前一天的同一窗口。出现无法解释的退化，先回滚，再调查。原文没有给出观察时长和通过阈值，团队落地时还得补齐。

并行扩大的是准备能力，生产变更仍要逐项收口。

这些规则经历了实际故障检验：一次发布因 staging 未发现的问题而回滚；另一次修复混入 main 上其他尚未发布的改动，需要重新交付。因此，他们新增了合并前检查 main 待发布内容的规则。staging 容量耗尽也曾让所有端到端测试停摆，必须先修共享基础设施。

最终，作者报告约 17 项安全修复完成合并、生产部署、观察和文档；事故完成止损与复盘，并起草约 26 项后续工作；威胁检测计划形成 30 多条需求故事并启动试点；另外交付约半打平台修复。

但作者也退回了相当一部分输出，包括只修表象的方案、缺乏证据的验证结论，以及测错对象的查询。原文没有给出退回比例。

我的判断

这套经验最有价值的地方，是把 AI 协作拆成了可检查的责任关系：任务有边界，审查有独立视角，上线有证据，生产操作有人负责。对已经频繁使用 AI 编程的团队，这比继续优化一句提示词更有参考价值。

但「4 天交付这么多」不能直接当成效率基准。作者说明，名称、漏洞细节、部分日期和数字经过泛化或取整；文章也没给出任务复杂度、总投入工时、模型与工具配置，更没有单 agent 或传统流程的对照。这是一次操作经验分享，无法据此推算普通团队的提效倍数。

它还依赖成熟的开关、回滚、观测和权限体系。默认关闭能隔离行为变化，但安全修复部署后若始终不开启，新防护也可能没有生效。作者称文章发布前所有修复均已上线并启用；团队自己的验收标准同样要覆盖启用后的效果。

相比一个人始终盯着单会话，这种分工更适合可拆分的多条工作线；对于简单改动，多角色协调未必划算。Reviewer 也仍是 AI，它能补充审查视角，不能取代服务负责人的判断。

作者引用 Anthropic 内部研究，支持「交互式 agent 经常在等人」的观察，但输入材料没有提供研究方法和具体占比，只能把它看作旁证。

另一个判断值得保留：采用 AI 不该变成增加工时或按 PR 数考核。作者建议观察工单到生产的周期、重复劳动减少量，以及回滚和事故等质量指标，并把节省的时间用于减轻值班负担、保障休假。否则，团队先感受到的可能是压力。

能拿来做什么

• 给下一项 Node 服务修复或依赖升级写一份五段式 brief，列清允许修改的模块、测试要求、交付证据和禁止执行的动作，先验证任务能否独立交付。
• 给高风险改动单独开一个 Reviewer 会话，提供 diff 和必要背景，让它寻找缺陷；要求每项发现指向具体代码或证据，再交由人审核。
• 把部署步骤、有效监控查询和历史回滚原因整理成带日期的 skills。遇到一次错误验证，就修正对应知识文件，别只在当前对话里提醒。
• 从一个真实工单试行并行协作，预留人的审查时间，并检查 staging、CI 等共享资源容量；用交付周期和质量判断收益，再决定是否增加 agent 数量。