返回 AICAP-180
B3 · Day 25agent loop + 评测统计

多步 AML 任务接入

- 承接昨天：Day 24 手写好了 framework-free 的 agent loop（observe→act→observe，硬上限 8 步）。今天给它接上第一个真实多步任务——AML 调查，验证「为什么这类任务天然需要 agent 而非 workflow」（呼应 Day 21 的判据）。

阶段: B3 · agent loop + 评测统计（Day 21-30） 标签: #aml #multi-step-agent #typology #sar-draft

今日导引（由浅入深）

  • 承接昨天：Day 24 手写好了 framework-free 的 agent loop（observe→act→observe，硬上限 8 步）。今天给它接上第一个真实多步任务——AML 调查，验证「为什么这类任务天然需要 agent 而非 workflow」（呼应 Day 21 的判据）。
  • 为什么是 AML：AML 调查是 AIPA 主线作品 AML Copilot 的内核，所以这一天既是 B3 的能力验证，也是把已有 AML 规则引擎（typology / sarDraft）当工具喂给 agent 的第一次缝合。
  • 通向明天：明天（Day 26）把这条回路挂进评测 harness（runTaskEval），用双指标（completion + tool-call 数）量化「做对了没 / 绕没绕远路」。
  • 最小可判定产出：解 1 个三步 AML 任务（汇证据→比 typology→出草稿），记步数与 tool-call 次数，验证在 step≤8 上限内完成——离线 fixture 可先跑三步轨迹，真实驱动需 key。

1. 机理精读

AML 调查是天然多步 agent 任务。

  • 它的工作流是：证据汇集 → typology（类型学）比对 → SAR 草稿，而且每一步都依赖上一步的观测结果。
  • 你得先看到「这账户 10 天内有 4 笔 $9,000 现金存款」，才能决定去比对 structuring 类型学；得先确认命中了 structuring，才能据此起草 SAR 的「可疑原因 (Why)」段。
  • 路径无法预先编排：不同案件命中的规则不同、走的分支不同、要不要追加调取不同。
  • 这正是 Day 21 判据里「步数/路径不可预先确定」的标准正例，所以该用 agent loop 而非固定链。

typology = 可疑模式的结构化分层。 AML 的「类型学」是把洗钱手法归成可机读的模式族。本仓 typology.ts 建模三类：

  • structuring（结构化拆分）——把现金拆成多笔贴线 $10,000 CTR 门槛的存款规避申报（STRUCT-01/02）。
  • layering（分层过账）——资金经多个账户链式快进快出隐匿来源（LAYER-01/02）。
  • mule_network（钱骡网络）——扇入扇出、新户快进快出的中转账户（MULE-01/02）。
  • 每条规则给出确定性命中 + 证据交易 id + 中文描述，是「证据 → typology 比对」这一步的工具底座。参考 IBM AMLworld (2024-04) 的 typology 标注体系。

每步依赖上一步观测，无法预先编排。

  • 第 1 步「汇证据」产出一批交易；第 2 步「比 typology」的输入正是第 1 步的交易，输出是命中规则 + 聚合得分 + topTypology。
  • 第 3 步「出草稿」的输入又是第 2 步的 assessment，输出是引用了具体证据交易的 SAR 段落。
  • 后一步的 prompt 内容由前一步的观测决定——这是 agent loop（而非 workflow 链）的本质用武之地：loop 把每步的工具观测回填进 transcript，模型据此决定下一步。

HITL 与审计轨迹是这类任务的硬约束。

  • AML 不是「模型说了算」：SAR 草稿必须经调查员人工复核（HITL）才能提交。
  • 整条证据→判定→草稿链要可审计、可回溯——这正是为什么 draftSar 把所有数值/交易都锚到 evidenceTxIds。
  • 这对标 FIS+Anthropic 2026-05 的 AML Copilot 模式（证据→typology→SAR→HITL→审计轨迹）。
  • 今天只接通三步回路；HITL 与审计轨迹由 P3 深化（本仓已有 hitl.ts / auditTrail.ts）。

2. 推导 / 手算 / 代码走读

代码走读两个被注入为工具的 AML 引擎（都已建、确定性、零 key 可测）：

src/aml/typology.ts（typology 比对工具）：

  • 主入口 assessCase(c: AmlCase): TypologyAssessment（typology.ts:321）：依次跑 6 条规则 checkStruct01/02、checkLayer01/02、checkMule01/02，把命中按类型学累加得分（cap 到 1），取 ≥阈值（ASSESS_THRESHOLD=0.5）的最高分项为 topTypology。

  • 阈值常量直接对齐法规：CTR_THRESHOLD_CENTS=1_000_000（$10,000 CTR/FinCEN Form 112）、贴线带下限 $8,000、STRUCT-01 窗口 10 天 / ≥3 笔。

  • 主规则 SCORE_PRIMARY=0.6（单独命中即过阈值），辅规则 SCORE_SECONDARY=0.4（须叠加）。门槛常量直接对齐法规：CTR_THRESHOLD_CENTS = 1_000_000（$10,000 CTR / FinCEN Form 112）。

  • 每条命中是 RuleHit = {ruleId, typology, description, evidenceTxIds, score}——evidenceTxIds 就是「汇证据」这一步的可追溯锚点。

  • V2 入口 assessCaseV2（typology.ts:598）额外产出结构化可解释理由 explanations、钱骡图 muleGraphMetrics、叠加仲裁 arbitrateTypologies——供 UI 高亮与 SAR 引用，仍是确定性规则引擎（非 LLM）。

  • STRUCT-01 的确定性判定（worked）：checkStruct01（typology.ts:86）滑窗找「≤10 天内 ≥3 笔金额在 [$8,000, $10,000) 的现金存款」，命中即给 score=SCORE_PRIMARY=0.6（单独过 ASSESS_THRESHOLD=0.5），证据 = 这批存款的 txId。这一步是纯规则、零随机——模型不参与判定，只负责调用与叙述。

  • 聚合：assessCase 把同类型学的命中得分求和 cap 到 1，取 ≥0.5 的最高分项为 topTypology；V2 的 arbitrateTypologies 在多类型并列时按 layering>mule_network>structuring 确定性仲裁，避免 argmax 平手随机。

src/aml/sarDraft.ts（SAR 草稿工具）：

  • 主入口 draftSar(c, assessment): SarDraft（sarDraft.ts:61）：按 FinCEN SAR 的 5W1H 结构拼六段——引言/告警概述、主体身份 (Who)、可疑活动描述 (What/When/Where)、可疑原因 (Why)、作案手法 (How)、总结与后续。
  • 它只引用 assessment 里的证据：citedTxIds = dedupe(assessment.hits.flatMap(h => h.evidenceTxIds))（sarDraft.ts:64），所有数值/交易引用都回溯到规则引擎的证据链——保证草稿可审计。
  • 诚实标注（文件头）：W1 原型是规则模板生成（非 LLM），按 5W1H 拼中文段落；generatedBy: 'rule-template'；LLM 版在 P3 接入。

接线逻辑：把 assessCase（或 assessCaseV2）与 draftSar 分别包成 Day 24 loop.ts 的 LoopTool（{name, run}），注入 runAgentLoop。

三步轨迹手动走查（离线 fixture）：

step1: model 看 task（一个 AmlCase）→ 调 evidence/lookup 工具汇集证据交易
        → 观测：N 笔贴线现金存款 + 它们的 txId
step2: model 看证据 → 调 assess_typology 工具（assessCase）
        → 观测：{hits:[STRUCT-01...], scores, topTypology:'structuring'}
step3: model 看 assessment → 调 draft_sar 工具（draftSar）
        → 观测：6 段 SAR 草稿（5W1H），citedTxIds 回溯到 step2 的 evidenceTxIds
step4: model 给最终答案（"已生成 SAR 草稿，待 HITL 复核"）
        → return {completion=1, toolCalls=3, steps=4, hitCap:false}

要点：每一步的工具输入都是上一步的观测（证据→命中→草稿），toolCalls≥2、steps≤8、hitCap=false；草稿的 citedTxIds 必须能逐条回溯到证据交易，保证可审计。真实模型驱动版需 key。

3. 今日实战

  1. 把 src/aml/typology.ts（assessCase）与 src/aml/sarDraft.ts（draftSar）各包成一个 LoopTool（注入工具）。
  2. 用 Day 24 的 runAgentLoop 解 1 个三步 AML 任务：汇证据 → 比 typology → 出草稿。
  3. 记**步数（steps）**与 tool-call 次数（toolCalls），验证 step ≤ 8 上限内完成（hitCap=false）。
  4. 先用离线 fixture 跑通三步轨迹、出 tool_call 计数并 commit；真实模型驱动需 key。

4. 今日实测 / 产出

  • 产出目标：transcript 显示 completion=1, tool_calls 计数。
  • 状态：待跑（需 OPENROUTER_API_KEY）；离线 fixture 可先跑通三步轨迹出 tool_call 计数并 commit。
  • loop.ts 已建测试绿；AML 工具接线步骤如上（typology + sarDraft 作注入工具）。
  • 验证点：三步任务应在 maxSteps=8 上限内完成（hitCap:false），toolCalls ≥ 2（typology + sarDraft 各至少一次）。

5. 常见误区 / 陷阱

  • 把 AML 调查写成固定链。 不同案件命中规则不同、分支不同，写死链会漏掉路径依赖；这正是该用 agent loop 的理由。
  • 让模型直接「编」typology 结论。 判定必须来自确定性规则引擎（assessCase），模型只负责编排与叙述；否则丧失可审计性。
  • SAR 草稿引用证据不回溯。 所有数值/交易必须回溯 evidenceTxIds；脱离证据链的草稿不可提交。
  • 跳过 HITL 直接「提交」。 AML 是 HITL 硬约束，草稿须经调查员复核；模型自动提交是合规红线（safety/restraint 类任务专门测这点）。
  • 把规则引擎的 description 当 SAR 终稿。 draftSar 产的是草稿（generatedBy:'rule-template'），LLM 化叙述与人工复核都在后续；直接当终稿提交会漏掉 CDD/客户说明等必要核实。

6. 学习资源（每条带 YYYY-MM）

  • IBM, AMLworld / IBM Anti-Money Laundering 数据集与 typology 标注 — 2024-04（typology 分类公开基准参考，本日机理主线）
  • FIS + Anthropic, AML investigation Copilot 模式（证据→typology→SAR→HITL→审计轨迹）— 2026-05（当前对标叙事）
  • FinCEN, SAR (FinCEN Form 111) / CTR (Form 112) filing requirements — 2024（5W1H 叙述结构 + $10,000 CTR 门槛依据）
  • 本仓代码：src/aml/typology.ts（assessCase / assessCaseV2 / 6 条规则）与 src/aml/sarDraft.ts（draftSar 5W1H）— 2026-06
  • 本仓代码：src/agent/loop.ts（runAgentLoop，本日把 AML 工具注入其中）— 2026-06

SOTA检查 (2026-06 更新)

  • 当前主流方案：IBM AMLworld (2024-04) 的 typology 分类仍是公开基准参考；FIS+Anthropic 2026-05 的 AML Copilot 模式（证据→typology→SAR→HITL→审计轨迹）是当前对标叙事。
  • 是否仍 SOTA：是。三步 agent 化（证据→typology→SAR）+ HITL + 审计轨迹是 2026 金融 GenAI 落地的主流形态。
  • 数据集对标：IBM AMLworld (2024-04) 提供带 typology 标注的合成交易图，是公开评测 typology 检出的常用基准；本仓 AML 数据为合成（诚实标注），真实标注数据集接入仍 gated。
  • 过时黑名单：勿用过时合规时间线（如「AI Act 高风险 2026-08 生效」旧说法已推迟至 2027-12-02）；勿让 LLM 替代确定性 typology 判定而丢失可审计性。
  • 架构定调：「确定性规则引擎判定 + LLM 编排/叙述 + HITL 复核 + 审计轨迹」是 2026 金融 GenAI 落地的稳健分工——判定可解释、叙述提效、人负责签字。本日把前两块用 agent loop 缝起来。
  • 下次复查点：周一 WebSearch「FIS Anthropic AML Copilot 2026」「FinCEN SAR 2026」；08-02 AI Act Article 50 + Omnibus 确认当周复核合规期限。

衔接

  • 昨天：Day 24 — 无框架 agent loop 骨架（observe→act→observe，硬上限 8 步）
  • 今天：把 loop 接到 AML typology + sarDraft，解三步任务（汇证据→比 typology→出草稿），记步数/tool-call
  • 明天：Day 26 — runTaskEval 打通（把 loop 挂进评测 harness，双指标度量 completion + tool-call 数）
上一篇 · Day 24
无框架 agent loop 骨架
下一篇 · Day 26
runTaskEval 打通