合同审查：四任务 DAG 与步骤级重试

场景

典型场景：法务或采购团队收到一份待签合同，通常要做四件事：把条款拆出来、逐条对合规口径、给业务方一份高管摘要、最后合成一份可传阅的报告。人工串行做，摘要要等合规检查做完才动笔，而这两件事其实互不依赖；中间任一环出错，整条流程要从头再来一遍。

这个示例演示的正是把这四件事写成显式依赖图之后，编排层怎么处理并行与失败：互不依赖的两个任务同时开始，出错的那个任务单独重跑，已经完成的上游保持完成状态。

方案

表中模型为示例仓库的默认配置；实际选型在方案阶段按场景确定。

四个 Agent 都未声明 tools 或 toolPreset；OMA 的工具授权默认拒绝（src/tool/grants.ts：没有正向授权则解析为零个内置工具），这条流水线因此只做模型调用。

任务 2、3、4 各配 maxRetries: 2、retryDelayMs: 500、retryBackoff: 2，即最多三次尝试。框架侧的退避带等量抖动：retry.ts 先算 500 × 2^(n-1)（上限 30 秒），再在 [一半, 全额] 区间取抖动值才睡眠；而且按错误分类处理——鉴权、结构化输出校验、取消这类不可恢复的错误直接跳过重试。

团队开了 sharedMemory: true，但四个任务都没设 memoryScope: 'all'，所以提示词里注入的是直接前置任务的产出（## Context from prerequisite tasks 段）。合同正文来自仓库里的 fixtures/sample-contract.txt，是一份甲乙方写成占位符的虚构服务协议。

结果

可运行产物与验证方式：

需要 API key。脚本头部写明前置条件是 ANTHROPIC_API_KEY；运行命令 npx tsx packages/core/examples/cookbook/contract-review-dag.ts。

能观察到并行。进度回调打印每个任务的 task_start / task_complete 时间戳；跑完后 verifyParallelism() 比较 compliance-check 与 summary 的启动时间差，小于 500 毫秒才打印 Parallel execution (< 500ms): YES，否则打印 ASSERTION FAILED 并以退出码 1 结束。

能主动触发重试。用 FORCE_FAIL=task2 npx tsx … 运行，compliance-checker 的 beforeRun 钩子只在第一次尝试抛出 [FORCE_FAIL_TRIGGERED]；这是一个不带 HTTP 状态码的普通错误，按 isRetryableError 判定为可重试，于是控制台出现 task_retry 事件，第二次尝试通过，整条流程仍然完成。2026-09-06 在 commit 36e99fe 上实测：task_retry 打印 attempt 1 / maxAttempts 3、退避 267 毫秒，compliance-check 第二次尝试完成，四个任务全部成功并产出最终 Markdown 报告，退出码 0。这次实测把示例里提交的 anthropic / claude-sonnet-4-6 换成 DeepSeek 的 deepseek-v4-flash 运行，其余逻辑照原样。

最终产物是报告文本。控制台按 Agent 依次打印各自输出，成功时再单独打印 notifier 的 Markdown 报告（含执行摘要、合规结果、风险明细、建议动作），并汇总 input / output token 数。

示例用的是虚构合同，产出是一段模型生成的文本，供演示与验证流程使用。

可核实

与元定义的关系

本页素材是 open-multi-agent 官方仓库里的 cookbook 示例，由元定义维护。

如果你手上有一条真实的合同或单据审查流程，要把条款抽取、规则校验、报告生成拆成可并行、可单独重跑的任务，并接进你自己的合同库与审批系统，元定义对应的服务是 AI Agent 定制开发 →