W12 周总结 — Agent UX 模式库定稿，以及「金融特化」如何重写每一个通用模式

日期: 2026-09-06 阶段: Phase 3 - AML 调查 Copilot 标签: #agent-ux #pattern-library #financial-specialization

核心问题

W12（Day 78-84）这一周做的是一件事：把 P3 的 AML Copilot 从「能跑通工作流」升级成「带完整 Agent UX 模式的合规调查助手」。一周里实装了 6 个动作——Day 78 选型（4 模式）、Day 79 plan-and-execute、Day 80 置信度信号、Day 81 渐进式授权、Day 82 错误恢复、Day 83 HITL×durable。现在到了周总结，要回答三个只有把一周连起来看才能回答的问题：

1. 我实装的模式，和 Fuselab 七模式原版（2025-08）差在哪？ 不是「我照着抄了」，而是每一个通用模式落到 AML 都被金融合规特化改写了——这些差异点本身是这一周最值钱的产出，因为它们是「为受监管场景设计 agent」的可复用经验，不是 AML 独有。
2. 6 个模式串起来，端到端长什么样？ 一份 SAR 从「选案」到「上报」，依次穿过哪几道 UX 闸、每道闸由哪天的实装把守——走一遍 walkthrough 才能验证模式之间没有缝。
3. 这套模式库的 SOTA 状态？ W12 临近 EU AI Act Article 14（人工监督，2026-08-02 生效）的窗口，重新核查这一周的设计是否仍对标 2026-06 主线。

贯穿全篇的主线：通用 agent UX 模式是「词汇表」，金融合规是「语法」——同样的词，受监管场景下的句子结构完全不同。 Fuselab 自己也在 2026 承认这点（regulated-industries guide）：「不要从消费级 AI 借用交互模式」。

关键内容

A. 实装模式 × 金融特化：每个通用模式被改写了什么

W12 选定的 4 个核心模式（Day 78）+ 补的 2 个（Day 82/83），逐个对照「Fuselab 原版定义」与「本项目落地后的金融特化点」。这张表是本周的核心产出：

把这 6 行的特化点抽象出来，得到三条「金融特化语法规则」——这是比任何单个模式都更可复用的结论：

G1：默认值朝「安全的那边」倒，且做成不可配置硬约束。 渐进授权默认零权限（Day 81）、超时默认不批准（Day 83）、critical 失败默认人工（Day 82）——三处都是「方向」而非「数值」的决策，且都被钉成代码层硬约束。

G2：刻度不超过系统真实分辨力。 置信度三档而非百分比（Day 80）、judge 二元而非五档（Day 16）——给用户超过系统真实分辨力的精度，是在承诺一个给不出的东西，反而误导。

G3：「凭什么准许去做」与「做了什么」同等留痕。 授权三路出口全留痕（Day 81）、超时降级留痕（Day 83）、override 改了什么留痕（Day 78）——监管问的不是「你拦了什么」，是「你为什么没拦这个」。

Fuselab 自己的 2026 regulated-industries guide 印证了这套语法——它给金融 AI 列的三个模式（confidence thresholds / audit trails regulators can follow / override paths with human final call）恰好对应本项目的置信度信号、审计轨迹、渐进授权，并明确警告不要借用消费级 AI 的交互模式：

"ChatGPT-style confidence phrasing, conversational personas, and generic confidence indicators all work well in consumer contexts" 但在受监管环境里失效——后者要求 "reviewable decisions"。原话还有一句定调："the audit trail becomes part of the interface architecture"（审计轨迹成为界面架构的一部分，不是隐藏的数据库关切）。

反直觉洞察①（W12 的真正产出不是「6 个模式」，而是「3 条改写规则」）：6 个模式的清单是 Fuselab 早就给的（2025-08），照搬没有价值。本周真正新增的认知是 G1/G2/G3——把任意一个通用 agent UX 模式「翻译」成受监管版本的三条规则。 证据：拿一个 W12 没碰的模式（Day 78 砍掉的 Memory Surfacing）来试——按 G1 跨会话记忆默认不浮现（AML 单案件无状态、浮现反而制造串案风险）；按 G3 若浮现须留痕「为何把 A 案信息带进 B 案」。三条规则能生成对任意模式的特化判断——模式清单是借来的，改写规则是自己的。

B. 端到端 walkthrough：一份 SAR 穿过 6 道 UX 闸

把 6 个模式按「一份 SAR 从选案到上报」的真实路径串起来，验证模式间无缝。消息流（标注每道闸的把守 Day 与可能的分叉）：

[调查员选定 case C-007] ──────────────────────────────────────────────
        │
        ▼ ❶ 计划面板 (Day 79 plan-and-execute)
   buildPlan(C-007) → 「3 步 / 4 工具 / 预估 $0.066 / 预计引 7 笔证据」
   withinBudget? ── 否 → 禁用批准、提示缩范围（不半途中断）
        │ 是 → 调查员批准 → 冻结计划（控制流锁死，防注入）
        ▼ ❷ 执行（证据汇集 → 类型学比对 → SAR 草稿）
   每步调用工具前 ─► 闸：authorize(action, trust, confidence) (Day 81)
        │
        ├─ 工具超时/返回空 ─► ❸ 错误恢复 (Day 82)
        │     classifyError → FailureClassId
        │     tool_failure 瞬时 → auto-retry+退避
        │     retrieval_miss → fix-and-retry（放宽 query）
        │     hallucination/typology 误判 → 强制 human_takeover ──┐
        ▼                                                          │
   ❹ 置信度信号 (Day 80)                                           │
   类型学命中级 + SAR 字段级 → 绿/黄/红三档                          │
   LOW 段红色高亮 + 待审置顶 + 禁批量批准绕过                        │
        │                                                          │
        ▼ ❺ 授权决策 (Day 81)：提交 SAR = 高风险 + 不可逆           │
   authorize → SYNC_APPROVE（恒同步人审，信任度封不了顶）          │
        │  三路出口全写 AuthDecisionRecord 进审计轨迹               │
        ▼                                                          │
   ❻ HITL × durable 审批 (Day 83) ◄───────────────────────────────┘
   interrupt({payload, wakeAt}) 抛异常 → 序列化落盘 → 进程释放
   ttlKind=sensitive(高风险) → wakeAt = now + 24h
        │
        ├─ 合规官批准 → resume(approve) → SAR 提交（幂等键 taskId-submit，恰好一次）
        ├─ 合规官退回 → 调查冻结/降级
        └─ 24h 超时无人审 → escalate 上级（绝不 auto-approve）→ 再超时 → expired 降级回人工
        ▼
   ✅ SAR 上报 FIU（仅在人工同步批准这一条路径上发生）

这条 walkthrough 暴露了一个关键性质——6 个模式不是平行的 6 个 feature，而是串行的 6 道闸，且越往后越「向人收口」：计划面板（❶）只需一次轻批准，到提交 SAR（❺❻）收紧成强制同步人审 + 持久化审批 + 超时不批。autonomy 在工作流前段宽（起草、高亮证据可 AUTO），到「不可逆动作」处归零。这正是 Fuselab regulated guide 的 "80% autonomous, 100% accountable"——自治度是工作流位置的函数，accountability 是常量 1。

反直觉洞察②（模式库的价值在「闸的排序」，不在「闸的集合」）：直觉把 UX 模式当成可勾选的 feature list——上了置信度、上了授权、上了错误恢复就算齐了。但 walkthrough 显示：同一组模式，排序错了就漏。反例：若把「授权决策（❺）」放在「置信度信号（❹）」之前，那么一个 LOW 置信的高风险动作可能先被授权层按「风险档」放行、而 LOW 置信「强制人审」的信号还没算出来——两道闸的护栏会出现时间差缝隙。正确序是「先算置信（❹）→ 置信喂给授权（❺）」，让 authorize() 的入参就含 confidence（Day 81 决策树第一条就是 if confidence==LOW → SYNC_APPROVE）。模式之间有数据依赖偏序：置信度是授权的输入、授权决策是审计的输入、错误归类是恢复路径的输入。模式库定稿定的不是「有哪些模式」，是「模式间的依赖偏序」——这是 walkthrough 而非清单才能定下来的东西。

C. 模式库笔记：定稿一张「依赖偏序图」+ 砍掉的模式复核

把 B 节的偏序固化成模式库的「依赖图」（谁是谁的输入），作为 P3 后续开发的防漂移基线：

失败归类(Day11 taxonomy) ──► 错误恢复路径(Day82)
                                    │ human_takeover
置信度信号(Day80) ──► 授权决策(Day81) ──► 审计轨迹(Day75/81)
       ▲                  │ SYNC_APPROVE        ▲
   κ校准(Day17)           ▼                     │
（信号合法性前置）   HITL×durable审批(Day83) ────┘
                          │ 幂等键
                    崩溃恢复(Day36) ◄── 共享幂等基础设施
计划-执行(Day79) ──► 成本预算(budget.ts) ── 冻结计划防注入

定稿三条不变式（invariants），作为后续任何 UX 改动的回归断言：

1. 置信度 → 授权：authorize() 必含 confidence 入参，LOW 恒 SYNC_APPROVE。删这条 = B 节反直觉②的缝隙复现。
2. 授权三路 → 审计：AUTO/ASYNC/SYNC 三出口全 append AuthDecisionRecord。删任一路 = G3 违反（无法回答「为何没拦」）。
3. HITL 超时 → 绝不 approve：onTimeout 返回值集合 ∌ approved（Day 83 已钉成单测断言）。删这条 = 给无声自动上报开后门。

复核 Day 78 砍掉的 3 个模式，W12 实装完后是否仍该砍：

反直觉洞察③（「砍掉的模式」复核比「实装的模式」更能暴露设计漂移）：周总结容易只复盘「做了什么」。但回头看「当初砍了什么、现在还该砍吗」，反而抓到两个真实变化：(1) 状态通报从「价值低」变成「Day 83 引入 durable 审批后价值升高」——因为我们自己制造了异步长任务；(2) 错误恢复从「融进别的模式」改判为「值得独立」——因为 Day 82 实装后发现它的交互复杂度被低估了。砍掉决策是有保质期的：选型时（Day 78）的「砍」基于当时的系统形态，系统演进后（Day 83 加了 durable）前提变了，砍掉决策必须重审。这正是时效硬规则在「内部设计决策」上的体现——不只是外部资料会过时，自己的取舍前提也会过时。

设计要点/决策表

对本项目的落地

• 不新建源文件，落为模式库文档 + 注释基线：W12 周总结的产出是设计基线而非新代码。把 A 节的「6 模式 × 金融特化表」与 C 节的「依赖偏序图 + 3 条不变式」写入 src/components/aml/AmlCopilot.tsx 顶部的「P3 UX 模式清单」注释块（Day 78 已起的那块），标注每个模式的实装文件与依赖关系，防止后续开发漂移成「平行 feature 堆砌」。
• 3 条不变式落成可回归断言：不变式 1（置信→授权）在 authorization.ts 的类型签名上保证（authorize 的 confidence 为必填参数，非可选）；不变式 2（授权三路→审计）在 authorization.ts 单测断言三种 AuthDecision 都产出 AuthDecisionRecord；不变式 3（超时∌approve）已在 Day 83 的 approvalQueue 单测落地。三条断言进 CI gate（呼应 Day 19 blocking eval gate），任一被破坏即阻断 merge。
• walkthrough 落成端到端冒烟测试：在 src/components/aml/__tests__/ 新增一个 walkthrough 测试，跑 B 节的「选案 → 计划 → 执行 → 置信 → 授权 → HITL 审批 → 上报」全链，断言每道闸按偏序触发（尤其「提交 SAR 必经 SYNC_APPROVE + interrupt 落盘」），且 happy path 与「超时升级」「critical 失败转人工」两条分叉都能跑通。
• P3 补充模式排期：C 节复核结论入 P3 待办——「状态通报」随 LLM 接入（证据汇集变慢 + durable 审批排队）列为 P3 首批补充；「错误恢复独立面板」在 Day 82 落地基础上 P3 完善交互。不谎称已实现：W12 落机制层（决策逻辑/数据结构/偏序/不变式断言），真实 LLM 接入、真实信任度量、真实审批后端为 P3 动作。
• 诚实标注：模式库文档头注明确——6 个模式中，透明推理已有、其余 5 个在 W12 落「形状正确 + 逻辑可测」的机制层；trustLevel 首发固定 LOW（最保守）、置信度 v1 仅由规则引擎确定性得分驱动（无 LLM 过自信）、审批 TTL 为行业默认占位待合规团队定。

参考资料

1. Fuselab Creative — AI Design for Regulated Industries: 2026 Guide（fuselabcreative.com/ai-design-regulated-industries，2026）：金融 AI 三模式（confidence thresholds 须精确分数非"fairly confident"/audit trails regulators can follow/override paths 人保留最终决定权）；"audit trail becomes part of the interface architecture"；明确警告不要借消费级 AI 模式（会话人格/模糊置信/通用指示器）；"80% autonomous, 100% accountable" — 本日 WebFetch 一手
2. Fuselab Creative — Agent UX: UI Design for AI Agents（2025-08）：七核心模式原版定义；"interface is the accountability layer"；本周特化的对照基准
3. Innovatrix / agentic-design.ai — Agentic AI Design Patterns 2026 / UI-UX Patterns：真实系统层叠 Tool Use/ReAct/Reflection/HITL；progressive disclosure + confidence visualization + mixed-initiative；Sandbox Mode 对受监管行业尤要 (2026)
4. Strata / Galileo — Human-in-the-Loop 2026 Guide：SLA-matched escalation lanes（15s 低风险 / 2min PII / 15min 金融拨款）；审批界面应建在审批者已在的工具里（Slack/email），离开工具响应变慢 (2026)
5. 本项目 Day 78（选型 4 模式 + 三轴）、Day 79（plan-and-execute）、Day 80（置信度信号 + κ 前置）、Day 81（渐进授权 + deny-by-default）、Day 82（错误恢复 + critical 强制人工）、Day 83（HITL×durable + 超时不批）、Day 17（κ 校准）、Day 75（不可篡改审计）、Day 19（blocking eval gate）；src/components/aml/AmlCopilot.tsx、src/aml/authorization.ts、src/aml/confidence.ts、src/agent/hitl/approvalQueue.ts（2026-06）

SOTA 检查 (2026-06-11)

• 「受监管 agent UX = 通用模式 + 合规特化」在 2026-06 是稳固且升温的共识：Fuselab 2026 regulated-industries guide 明确把金融 AI 与消费级 AI 的 UX 切开（三模式 + 拒绝借用消费级模式），与 Day 78 引的 Smashing(2026-02) 三轴、Tech Radar Vol 34(2026-04) "securing permission-hungry agents" 同向。本周的 G1/G2/G3 三条改写规则与这股主线一致，未见被推翻。
• EU AI Act Article 14（人工监督）是 W12 的最新合规背景：高风险 AI 系统须具备「人工监督能力」（人能理解、干预、推翻 AI 输出）——本项目的强制同步人审（Day 81）、override 留痕（Day 78）、SAR 签发人保留最终决定权（Day 5）正是产品级响应；与 Day 49 的 Article 50（透明义务/内容标注，2026-08-02 生效）分管不同维度，AML Copilot 两者都触及。核查（须带法规状态）：Annex III 高风险义务经 Digital Omnibus 临时协议（2026-05-07）推迟至 2027-12-02，但 Article 14 的人工监督作为高风险系统核心设计要求，仍是产品应前置满足的方向。
• SLA-matched escalation 是 2026 升温的 HITL 细化：Strata/Galileo(2026) 给出 15s/2min/15min 三档升级车道——但注意这是通用/同步场景的车道（拨款类秒级到分钟级）；AML 的 SAR 审批是异步天级任务（Day 83 的 7d/24h TTL），两者不同量级，不可直接套用。本项目用 durable interrupt + wakeAt 兜底（Day 83）而非秒级车道，与 AML 审批的真实时长匹配。
• 过时认知警示：(1) 不要把 agent UX 当可勾选 feature 清单——有数据依赖偏序，排序错即漏护栏（反直觉②）；(2) 不要借消费级 AI 的交互模式（会话人格/模糊置信）进受监管产品（Fuselab 2026 明确警告）；(3) 不要假设选型时的「砍掉决策」永久成立——系统演进（如 Day 83 引入异步审批）会让前提失效，须重审（反直觉③）。
• 待跟踪：(a) EU AI Act Article 14 的具体「人工监督」技术标准（CEN/CENELEC harmonized standards）是否在 2026 H2 落地，影响强制人审的设计细节；(b) MCP Apps（2026-07-28 终版）服务端渲染 UI 能否标准化「审批/置信/授权」三类界面的承载；(c) Fuselab/Smashing 是否在 2026 H2 发布模式库更新，届时复核 G1/G2/G3 是否仍覆盖新模式。