行情数据质检：双法官复核与报告修订
官方 cookbook 示例
- 行业
- 金融 · 行情数据质检
- 来源
- open-multi-agent 官方 cookbook
- 当前阶段
- 可运行示例
这是 open-multi-agent 官方 cookbook 示例，由元定义维护。它给一段 BTCUSDT 盘口数据做入回测前的质检：报告 Agent 只看得到局部连续的增量和成交，先给出暂定的 ACCEPT；两名法官各拿一份它看不到的数据源复核，推翻后要求改为 QUARANTINE，两票都通过才定稿。
场景
典型场景：量化团队把交易所的 L2 盘口增量录下来做回测。单看增量文件，update ID 首尾相接、盘口没有交叉、数量合法，看起来可以直接用；但快照与增量流的衔接是否成立、采集器中途有没有断线重连，证据分别在快照元数据和采集日志里。只看一份材料下结论，带缺口的区间就会混进回测。
这个示例演示的是把「先下结论、再由持有不同材料的复核方挑错」写进任务定义：报告任务挂上 verify 配置，每名法官通过 judgePrompt 拿到只属于自己的数据源；有人反对就把意见交回报告 Agent 修订，结论从 ACCEPT 改成 QUARANTINE，并写明缺失的 update ID 区间、断线时间窗和补数动作。
方案
| 角色 | 任务 DAG | 工具 | 模型 | 部署形态 |
|---|---|---|---|---|
| depth-sequence-extractor | 任务 1 extract-depth-sequence（根任务，无依赖） | tools: []，无工具 | claude-sonnet-4-6 / anthropic | npx tsx 单次运行的本地脚本 |
| trade-activity-extractor | 任务 2 extract-trade-activity（根任务，与任务 1 并列） | tools: []，无工具 | claude-sonnet-4-6 / anthropic | 同上 |
| integrity-report-proposer | 任务 3 propose-integrity-report，依赖任务 1 与任务 2，挂 verify 复核 | tools: []，无工具 | claude-sonnet-4-6 / anthropic | 同上 |
| protocol-continuity-judge | 任务 3 的法官，独占 snapshot-metadata.json | tools: []，无工具 | claude-sonnet-4-6 / anthropic | 同上 |
| backtest-risk-judge | 任务 3 的法官，独占 collector-log.txt 与 data-quality-policy.md | tools: []，无工具 | claude-sonnet-4-6 / anthropic | 同上 |
表中模型为示例仓库的默认配置；实际选型在方案阶段按场景确定。
五个 Agent 都有 outputSchema：两份审计、一份完整性报告（decision 取 ACCEPT / QUARANTINE / REPAIR_REQUIRED 三值之一）和法官裁决 { accept, critique }，均用 zod 定义；任务 3 设 dependencyPayload: 'structured'，只把两个抽取任务校验过的 JSON 注入提示词。
verify 配置为 quorum: 2、maxRounds: 2、onDissent: 'revise'。consensus.ts 里法官按顺序逐个裁决，同意票达到 quorum 即通过；本轮不足且还有轮次时，把上一版答案和全部反对意见拼成修订提示词，交回任务 3 的 Agent 重写。只有被接受的修订版才会替换任务结果。
judgePrompt 是一个按法官名返回说明的函数，快照元数据、采集日志和数据质量规则只拼进对应法官的提示词，报告 Agent 首轮看不到它们；设置了 judgePrompt 后框架不再套用内置的 mode 说明。
报告 Agent 的 afterRun 钩子记下每一版结构化报告，脚本据此打印决策路径（如 ACCEPT -> QUARANTINE）。
结果
可运行产物与验证方式：
需要 API key 与 Node.js 20 以上。脚本头部写明前置条件是 ANTHROPIC_API_KEY，模型可用 MODEL 环境变量覆盖；运行命令 npx tsx packages/core/examples/cookbook/market-data-integrity-verify-loop.ts。
控制台依次打印决策路径、每轮每名法官的 ACCEPT / DISSENT 与反对理由，以及最终的 JSON 报告。
跑完后执行 9 条断言：首版为 ACCEPT、末版为 QUARANTINE、两名法官首轮都参与、第二轮两票同意、报告记下 900101–900104 的 update ID 缺口与 09:29:59.940 至 09:30:00.210 的断线时间窗、分别引用 snapshot-metadata.json 与 collector-log.txt、给出重新下载或重建数据的补救动作。任一条 FAIL 则以退出码 1 结束；runTasks 返回失败时脚本抛出 The market-data integrity workflow failed.，退出码同样为 1。
fixtures 目录下的盘口、成交、快照、采集日志和质量规则全部标注为 MOCK 合成数据，脚本不连接交易所、不发起行情请求；产出是一段模型生成的报告文本，供演示与验证流程使用。
出处
与元定义的关系
本页素材是 open-multi-agent 官方仓库里的 cookbook 示例，由元定义维护。
如果你手上有一条真实的行情或交易数据入库流程，要让多个 Agent 分别核对快照、采集日志和质量规则，结论经复核通过才放进回测或风控，并接进你自己的数据管线，元定义对应的服务是 AI Agent 定制开发 →
最后更新
想知道类似的流程在你这边怎么落地?