这篇 Cookbook 的核心价值
Anthropic 的 SRE incident responder 示例非常适合运维团队参考，因为它没有把 Agent 写成「自动修生产」的危险脚本，而是把告警、runbook、日志、沙箱调查、PR 修复、人类审批和 Console trace 串成一条可审计链路。真正值得学的是安全工作流，而不是某个单点 API 调用。
先理解它的最小闭环
示例里由一个模拟 PagerDuty webhook 触发 Claude Managed Agent。Agent 的 workspace 挂载最近日志、基础设施配置和团队 runbook。内置工具负责在 sandbox 内读取文件、跑 bash、编辑配置；自定义工具负责打开 PR、请求人类批准和合并 PR。Agent 可以提出修复，但只有审批通过后才能继续合并，这条边界必须保留。
Runbook 不要塞进系统提示词
Cookbook 用 Skill 来承载团队 runbook 约定，这个设计很实用。Skill 是一个文件系统 bundle，Agent 只在相关时读取正文。团队落地时可以按故障签名维护 `oom.md`、`5xx.md`、`latency.md`、`deploy-regression.md` 等 runbook，每个 runbook 都写清排查顺序、常见根因、允许修改的配置和必须引用的证据。
生产化时要替换哪些 mock
- 把模拟 PagerDuty webhook 换成真实告警系统，但保留 payload 归档。
- 把本地 fixture 日志换成只读日志查询或临时导出的日志文件。
- 把单文件 infra mock 换成真实 GitHub 仓库资源，使用最小权限 token。
- 把本地审批换成 Slack、飞书或值班平台按钮，审批结果写回 session。
- 把 Console trace 接入事故复盘，让每次工具调用都能追溯。
不要让 Agent 直接修生产
这类 SRE Agent 的第一职责是缩短定位时间，而不是替代值班工程师。它可以读日志、找 failure signature、定位配置、生成 diff、起草 PR，但不应该直接 patch live resource。尤其是扩容、重启、修改限流、切流、数据库操作这类动作，都必须经过明确审批和回滚预案。
验收标准怎么写
一个可上线的事故响应 Agent 至少要满足四点，能证明它读过正确 runbook，能给出故障签名和证据，能生成最小 diff，能在合并前等待人工批准。还要额外检查失败分支，审批拒绝时它必须停止，工具调用失败时要报告原因，找不到证据时不能编造根因。
建议产出
团队可以把这篇 Cookbook 转成一份 SRE Agent 试点方案，先从只读 triage 开始，再允许创建 PR，最后才接审批后的合并。每个阶段都要保留完整 trace，否则出了事故之后没人能解释 Agent 到底做了什么。