证据汇集 pipeline 架构设计 — 五段流程的接口契约与失败隔离

日期: 2026-08-17 阶段: Phase 3 - AML 调查 Copilot 标签: #evidence-pipeline #interface-contract #fault-isolation

核心问题

P1/P2 把零件造齐了：P1 有 typology 规则引擎 + SAR 模板 + eval 检查，P2 有 orchestrator dispatch + hybridSearch RRF + 三层 memory + durable checkpoint。P3 要把它们串成一条端到端调查流水线——给一个告警案件，自动「汇集证据→比对类型学→起草 SAR→交人工复核→落审计」。

但「串起来」不是把函数顺次调用那么简单。今天回答三个工程问题：

1. 对位：FIS-Anthropic「Financial Crimes AI Agent」(2026-05) 和学术界 Co-Investigator AI (arXiv 2509, 2025-09) 的 pipeline 各分几段、我的五段如何对位？每段的输入/输出契约是什么？
2. 复用：哪些 P2 零件能直接复用、哪些必须新建？复用 hybridSearch RRF / orchestrator dispatch / Budget 的理由是什么？
3. 失败传播：流水线某段失败，是让整案崩、还是降级出残缺结果？合规场景下漏证据 vs 报错哪个代价大？

这是 P3 的奠基笔记——后面所有日子（Day 65 检索、Day 66 成本、Day 67 类型学）都是在这条 pipeline 的某一段上深耕。

关键内容

A. 五段流程对位与接口契约

FIS 公告 (2026-05) 的描述极简但点出了骨架：「At case open, the agent will assemble the complete evidence package across a bank's core systems automatically... and evaluate activity against known typologies」，随后「compress AML alert and case investigations from days to minutes... enhance SAR narrative quality」，且「investigators will remain in control of every decision... every agent conclusion is traceable」。把这句话拆开，正好是五段：证据汇集 → 类型学比对 → SAR 起草 → HITL 复核 → 审计留痕。

Co-Investigator AI (arXiv 2509.08380, 2025-09) 把同一骨架展开成 10 个组件，可与五段一一对位：

接口契约——五段之间传递的不是裸文本，而是带 schema 的结构化对象。每段的契约（伪代码）：

// 段间数据契约：一个不可变的"案件证据卷宗"逐段累积
interface CaseDossier {
  caseId: string
  // ① 证据汇集产出
  evidence: { txns: AmlTransaction[]; kyc: PartyProfile[]; priorAlerts: Alert[];
              retrievalSource: 'hybrid' | 'bm25'; recall: number }
  // ② 类型学比对产出（复用 P1 TypologyAssessment）
  assessment?: { topTypology: TypologyId|null; hits: RuleHit[]; scores: Record<TypologyId,number> }
  // ③ SAR 起草产出
  draft?: { sections: SarSection[]; citedTxIds: string[]; generatedBy: 'rule-template'|'llm' }
  // ④ HITL 复核产出
  review?: { action: 'approve'|'return'|'edit'; editedSections?: SarSection[]; reviewer: string }
  // ⑤ 审计：每段追加一条，永不删除
  audit: AuditEvent[]
}

function pipeline(caseId: string, budget: Budget): CaseDossier {
  let d: CaseDossier = { caseId, evidence: gather(caseId, budget), audit: [] }
  d.audit.push(ev('evidence_gathered', { recall: d.evidence.recall }))
  d.assessment = assessCase(toAmlCase(d.evidence))            // 复用 P1 typology.ts
  d.audit.push(ev('typology_assessed', { top: d.assessment.topTypology }))
  d.draft = draftSar(d.evidence, d.assessment)               // 复用 P1 sarDraft.ts
  d.audit.push(ev('sar_drafted', { generatedBy: d.draft.generatedBy }))
  return d   // ④⑤ 在 UI 层由调查员驱动，pipeline 在此交棒
}

关键设计：卷宗只追加不重写（append-only），每段把自己的产出挂到新字段，从不修改前段字段。这让 ⑤ 审计天然成立——audit[] 就是 pipeline 的事件溯源日志，对位 FIS「every conclusion traceable」。

B. 复用决策与理由

P3 的纪律是「能复用就不新建」，但复用要有理由，不是图省事。三个核心复用决策：

复用 hybridSearch RRF（不为证据检索另起炉灶）。src/agent/rag/hybridSearch.ts 的 rrfFuse 是纯函数、无外部依赖、空列表自动退化（向量缺失即等价 BM25）。证据汇集要从多源（交易流水/KYC/历史告警）召回，RRF 的「多列表融合」语义天然适配——把每个数据源当一条 ranked list 喂进去即可（Day 65 详谈）。复用理由：RRF 已在 P2 测过、退化路径已验证，重写等于重测。

复用 orchestrator dispatch（不为 pipeline 另写调度）。orchestratorAgent.ts 的 dispatchKnowledge/Research/Portfolio 模式是「主 agent 按子任务分发给专精子 agent，每次 dispatch 前断言 Budget」。证据汇集本身可拆成「拉交易/拉 KYC/拉历史告警」三个子任务，正好套用 dispatch 模式（Day 66 详谈）。复用理由：dispatch 已内建 assertCanStep/assertCostOk/assertNotTimedOut 四道断言，调查流水线的成本/超时护栏直接继承。

复用 Budget（不为单案成本另造计量）。orchestrator/budget.ts 的 makeBudget 已有 costCapUsd / addCost / assertCostOk。把「单 orchestrator 会话预算」语义平移成「单案件预算」即可——一个案件就是一次会话。复用理由：合规场景下成本要可审计，Budget 的 cost() 读数直接进 audit[]。

反直觉洞察（复用 P2 的多 agent 编排，但 P3 不需要"自由"的 agent）：P2 orchestrator 让 LLM 自主决定调哪个子 agent、调几次——这是开放问答场景的优点。但 AML pipeline 是固定五段，证据→类型学→SAR 的顺序由合规流程写死，不能让 LLM 自由编排。所以 P3 复用的是 dispatch 的「带 Budget 断言的子任务调用」机制，而非 orchestrator 的「LLM 自主规划」策略。把 stopWhen: steps >= 8 的自由循环换成确定性五段管道——证据汇集内部可以并行多源（用 dispatch），但段与段之间是硬编码顺序。误把整条 pipeline 交给 LLM 自由编排，会在合规审计时无法回答「为什么这个案子跳过了类型学比对」。

C. 失败传播与隔离

Co-Investigator (2025-09) 的关键架构选择是「fault isolation through modularity... failures or updates in a single agent do not cascade」。这条直接决定 P3 的失败语义。每段失败有两种处置——fail-degrade（降级出残缺结果） 或 fail-stop（中断整案）——取决于该段失败后剩余结果对调查员是否仍有价值：

段失败处置状态机：
  ① 证据汇集失败（某一源拉取超时）
       → fail-degrade: 标记 evidence.recall 下降 + audit 记 'source_X_unavailable'
       → 理由：缺一源仍可继续，但 recall 必须可见（合规上漏证据要留痕）
  ② 类型学比对失败（规则引擎抛错）
       → fail-stop 该案: assessment=null，draft 段不启动
       → 理由：没有类型学结论的 SAR 草稿无意义且误导
  ③ SAR 起草失败（LLM 超时/Budget 超限）
       → fail-degrade: 回退到 P1 规则模板 sarDraft（generatedBy='rule-template'）
       → 理由：模板草稿虽糙但完整，调查员可在其上编辑
  ④ HITL 永不"失败": 调查员可随时 return/edit，这是设计终点不是失败点
  ⑤ 审计失败（写 audit 抛错）
       → fail-stop 全案: 无审计的调查结果在合规上不可用
       → 理由：FIS「every conclusion traceable」是硬约束，审计不可降级

隔离边界：每段 try/catch，失败写入 audit[] 的 system actor 事件，再按上表决定降级或中断。关键是 ② 和 ⑤ 是 fail-stop（结论缺失/不可审计时整案停），① 和 ③ 是 fail-degrade（残缺但有价值时带标记继续）。

设计要点/决策表

对本项目的落地

• 新建 src/aml/pipeline.ts：导出 runInvestigation(caseId, budget) → CaseDossier，实现 A 节五段管道与 B 节复用。①段调 gatherEvidence（Day 65 落地），②段调 P1 assessCase（src/aml/typology.ts 已有），③段调 P1 draftSar（src/aml/sarDraft.ts 已有），④⑤在 UI/审计层。纪律：pipeline 是确定性顺序，不引入 LLM 自由编排。
• 新建 src/aml/types.ts 扩展 CaseDossier：在现有 AmlCase/TypologyAssessment/SarDraft/AuditEvent（均已定义）之上组合出 append-only 卷宗类型，audit: AuditEvent[] 复用现有 AuditEvent（已有 at/actor/action/detail）。
• 复用 src/agent/orchestrator/budget.ts：单案预算用 makeBudget({ costCapUsd, abortTimeoutMs, ... })，①段多源汇集前 assertCostOk()，Budget.cost() 在 ⑤ 段写入审计（Day 66 详谈降级）。
• 失败隔离骨架：每段 try/catch 按 C 节决策表 degrade 或 stop，失败事件以 actor:'system' 写入 audit[]。②⑤ 抛错即 return 残缺卷宗（带 stop 标记），①③ 抛错记标记后继续。
• 诚实标注：W1 起 ③段 generatedBy 仍为 'rule-template'（P1 模板），LLM 起草（generatedBy:'llm'）为 P3 后续接入；本日只落 pipeline 骨架 + 复用接线 + 失败状态机单测，不谎称 LLM 已接入。

参考资料

1. FIS — FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes（官方公告）：case open 自动汇集证据包、比对已知类型学、investigators in control、every conclusion traceable、BMO/Amalgamated 部署中、GA H2 2026 (2026-05)
2. Singh et al. — Co-Investigator AI: The Rise of Agentic AI for Smarter, Trustworthy AML Compliance Narratives, arXiv:2509.08380：10 组件 pipeline（Data Ingestion→Privacy Guard→Crime Type Detection→Planning Agent→7 Typology Agents→External Intelligence→Narrative Generation→Compliance Validation→Feedback→Dynamic Memory）；fault isolation through modularity；叙述完整度 70%（特定类型 87%）、起草省时 61% (2025-09)
3. Unit21 — Agentic AI for AML Compliance: A Practitioner's Guide：HITL 模型下 agent 提供速度+上下文、合规官保留最终决策责任 (2026)
4. 本仓库 src/agent/rag/hybridSearch.ts（rrfFuse 多列表融合）、src/agent/orchestrator/orchestratorAgent.ts（dispatch+Budget 断言）、src/agent/orchestrator/budget.ts（makeBudget）、src/aml/typology.ts（assessCase）、src/aml/types.ts（CaseDossier 组件类型）(2026-06)

SOTA 检查 (2026-06-11)

• 「五段确定性管道 + HITL 终点」是 2026-06 agentic AML 的事实结构：FIS-Anthropic (2026-05) 与 Co-Investigator (2025-09) 独立收敛到同一骨架（证据→类型学→叙述→复核→审计），SymphonyAI/Hawk/Napier 等商业方案 (2026) 描述一致——证据汇集自动化 + 调查员保留终决权。本日未见挑战这一结构的主流替代。
• fault isolation 是共识但实现各异：Co-Investigator 用「sub-agent 模块化」隔离，本项目用「per-段 try/catch + degrade/stop 决策表」隔离——后者更简单、更可审计（每个失败都进 audit[]），对单机原型足够；大规模多 agent 系统才需要 Co-Investigator 的 spawn/隔离机制。
• 待跟踪：FIS GA 在 H2 2026，届时若放出更细的 pipeline 接口规范（尤其证据源连接器契约），需回填本笔记 A 节接口契约；EU AI Act Article 50 透明义务 2026-08-02 生效，③段 LLM 起草上线时 SAR 草稿需机器可读「AI 生成」标记（Day 后续合规笔记详谈），本结构的 generatedBy:'llm' 字段已为此预留。
• 过时警示：把整条 AML pipeline 交给「LLM 自由编排的 ReAct agent」是 2024-2025 早期 demo 思路，2026 合规落地一致转向确定性管道 + 段内有限自主——自由编排无法回答审计追问「为何跳过某段」，B 节反直觉洞察仍是 live 踩坑点。