很多线上故障并不是没有规律，而是排查流程本身高度套路化。
比如某个详情页返回错了，很多后端同学的第一反应其实都差不多：
- 先对齐期望结果和实际结果
- 再看 Redis 缓存里的值对不对
- 再看数据库源数据有没有问题
- 再看 trace，确认链路停在哪一层
- 最后再判断是缓存陈旧、预期副作用没发生，还是持久化状态本身异常
也就是说，真正值钱的往往不是“工具权限”，而是那套排障顺序和证据链。
我之前做 AI 排障/自愈相关事情时，最大的感受就是：给模型接更多 DB、Redis、Trace、日志工具，并不会自动变成一个靠谱的排障工程师。
如果没有明确的顺序约束和证据边界，结果通常就是：
- 每次问法一变，排查路径也变
- 很容易被大段 trace / SQL / 日志噪声带偏
- 看起来说得头头是道，但证据链经不起推敲
所以我把这类“高度套路化”的排障流程抽出来，做成了一个开源 MVP：
debug-runbook
项目地址：
github.com/UnCooe/debu…
这个仓库今天真正开源的，不是原来那套内部系统的完整镜像，而是其中最可复用的一层：
- Runbook 选择
- 按顺序取证
- Evidence 规范化
- 基于证据组合触发结论
- MCP 接入入口
换句话说，它不是让 Agent 自由发挥，而是让 Agent 先按 Runbook 查，再下结论。
现在的仓库已经能直接跑一个 0 配置 demo，不需要先填 Langfuse、Postgres、Redis 凭证：
pnpm install
pnpm demo
pnpm benchmark
pnpm check
当前默认 demo 是一个很典型的场景：
- 订单创建成功了
- 但下游任务没有生成
这类问题如果交给一个“自由工具流”的 Agent，经常会在 trace、DB 和缓存之间来回乱跳。
但如果把排查套路写成 Runbook，它就会老老实实按顺序去看 trace、看持久化状态、看 idempotency / cache，最后输出结构化结论，而不是靠猜。
这里也把边界说清楚：
- 这是一个早期开源 MVP
- 它不是原内部 DAG 系统的开源版
- 它不包含私有权限系统和自动修复链路
- 当前更适合被理解成一个 runbook-driven investigation framework
如果你也在做 AI + 运维 / AI + 排障相关的事情，欢迎来拍砖。
我现在最想验证的不是“还能接多少工具”，而是：
- 你们线上最适合被标准化成 Runbook 的故障类型是什么？
- 你更信任“自由调用工具的 Agent”，还是“被排障手册强约束的 Agent”？
- 如果要把团队里老工程师的排障经验沉淀成 YAML / Skill，最大阻力是什么？
