故障复盘：三路并行取证到根因报告
开源示例 · 官方 recipe
这是 open-multi-agent 官方 cookbook 示例，由元定义维护。五个 Agent 组成一张任务图：日志模式、发布关联、影响面三路取证从零时刻同时开跑，结果收敛给根因分析，再由写手合成一份结构固定的复盘文档并落盘。
场景
典型场景：线上出现 5xx 突增，值班同学要同时做三件互不依赖的事：把日志里的错误簇和第一次回归时间点扒出来、把最近几次发布按时间和改动路径对上、估算受影响的接口和请求量。这三件事人手不够时只能串行做，等做完再拼因果，复盘文档往往拖到第二天。
示例演示的是把这三路取证写成三个根任务，让它们从同一时刻并行开始，再把结果作为显式依赖交给下游的根因假设与文档合成。
方案
| 角色 | 任务 DAG | 工具 | 模型 | 部署形态 |
|---|---|---|---|---|
| log-pattern-extractor | extract-log-patterns（根任务，无依赖） | 未声明 | claude-sonnet-4-6 / anthropic | npx tsx 单次运行的本地脚本 |
| deploy-correlator | correlate-deploys（根任务，无依赖） | 未声明 | claude-sonnet-4-6 / anthropic | 同上 |
| blast-radius-analyst | analyze-blast-radius（根任务，无依赖） | 未声明 | claude-sonnet-4-6 / anthropic | 同上 |
| root-cause-hypothesizer | hypothesize-cause，依赖前两个根任务 | 未声明 | claude-sonnet-4-6 / anthropic | 同上 |
| postmortem-writer | write-postmortem，依赖全部四个上游任务 | 未声明 | claude-sonnet-4-6 / anthropic | 同上 |
表中模型为示例仓库的默认配置；实际选型在方案阶段按场景确定。
三个取证 Agent 的系统提示各自规定了一份 JSON 输出结构：错误簇与首次回归时间戳、按时间与改动路径排序的发布候选及排除项、受影响接口与错误率区间。下游两个 Agent 输出 Markdown，写手的文档章节固定为 Summary / Timeline / Impact / Contributing Factors / Action Items。
重试只配在下游：hypothesize-cause 和 write-postmortem 两个任务各设 maxRetries: 2、retryDelayMs: 500、retryBackoff: 2。五个 Agent 都未声明 tools 或 toolPreset，按 OMA 默认拒绝的授权规则解析为零个内置工具——日志和发布记录是作为文本直接嵌进任务描述的，来自仓库 examples/fixtures/ 下的两份示例数据：206 行的 incident-logs.txt 和含 5 条发布记录的 incident-deploys.json。
结果
可运行产物与验证方式：
默认需要 API key。脚本头部写明前置条件是 ANTHROPIC_API_KEY；运行命令 npx tsx packages/core/examples/cookbook/incident-postmortem-dag.ts。
有一个本地验证开关。设 EXAMPLE_PROVIDER=openrouter 会把五个 Agent 与编排层默认值一起切到 OpenAI 兼容适配器上的 openrouter/free，改读 OPENAI_API_KEY 与 OPENAI_BASE_URL；源码里提交的 Agent 配置仍是 anthropic / claude-sonnet-4-6，启动时会打印当前生效的 provider 与 model。
并行由脚本断言。跑完后 verifyParallelism() 取三个根任务 task_start 时间戳的极差，小于 500 毫秒才打印 Parallel execution (< 500ms): YES，否则打印 ASSERTION FAILED 并以退出码 1 结束。
产物会落盘。成功时把 postmortem-writer 的 Markdown 写入系统临时目录下的 incident-postmortem.md，并在控制台打印完整路径；失败时改为逐条列出状态为 failed 的任务。
成本是可见的。运行结束打印 input / output token 总量，并按脚本内写死的单价换算出一个估算值——这是示例自带的换算。
可核实
| 来源 | 链接 | 核实日期 |
|---|---|---|
| packages/core/examples/cookbook/incident-postmortem-dag.ts（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/cookbook/incident-postmortem-dag.ts ↗ | |
| packages/core/examples/fixtures/incident-logs.txt（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/fixtures/incident-logs.txt ↗ | |
| packages/core/examples/fixtures/incident-deploys.json（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/fixtures/incident-deploys.json ↗ | |
| packages/core/examples/README.md cookbook 条目（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/README.md ↗ | |
| packages/core/src/orchestrator/task-execution.ts（依赖上下文注入，commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/src/orchestrator/task-execution.ts ↗ |
与元定义的关系
本页素材是 open-multi-agent 官方仓库里的 cookbook 示例，由元定义维护；脚本读取的日志与发布记录是仓库自带的示例数据。
如果你要把这条链路接到自己的日志平台、发布系统和值班工具上——取证并行、结论可追溯到具体日志簇与提交、复盘文档按公司模板输出——元定义对应的服务是 多智能体系统集成 →
相关服务
最后更新
想知道类似的流程在你这边怎么落地?