Agent UX 模式选型 — 七模式与金融 HITL 的适配，以及"信任决定模式"的反直觉

日期: 2026-08-31 阶段: Phase 3 - AML 调查 Copilot 标签: #agent-ux #human-in-the-loop #progressive-authorization

核心问题

P2 把 AML Copilot 的三屏工作流（证据→类型学→SAR）搭起来了，AmlCopilot.tsx 里已有一个轻量的 AgentPlanPanel（plan-and-execute 的雏形）。但 P3 要把它从"步进式规则原型"演进到"LLM Agent 辅助调查"时，必须先回答一个产品决策：一个面向反洗钱调查员的 Agent，到底该上哪几种 UX 模式？

业界 2025-2026 列出的 agent UX 模式不下十几种（Fuselab 一篇就列了 12 种）。全上 = 界面噪声 + 工程浪费；乱上 = 调查员要么不信任要么盲信。今天回答三件事：(1) 把 Fuselab 七个核心模式（2025-08）逐个拆开，看每个在金融合规 HITL 场景下到底解决什么问题、有没有反作用；(2) 对比 Smashing Magazine（2026-02）与 ThoughtWorks Tech Radar Vol 34（2026-04）两个更近的源，看 13 个月里模式库有没有迭代、有没有新增；(3) 给 AML Copilot 定选哪 4 个、为什么砍掉另 3 个。

核心反直觉先抛出来：UX 模式的选择，取决于用户对系统的信任度，而不是系统的功能集。同一个 Agent，给信任它的资深调查员和给第一次用的新调查员，该呈现的模式是不同的——这条决定了 AML Copilot 不是"上满所有模式"，而是按"信任曲线"分阶段开放。

关键内容

A. Fuselab 七模式精读：每个在金融 HITL 下解决什么、有什么反作用

Fuselab《Agent UX: UI Design for AI Agents》(2025-08-28) 的核心论点是一句话："the interface is the accountability layer between user intent and autonomous action"（界面是用户意图与自主行动之间的问责层）。它列的七个核心模式（原文直引），逐个放进 AML 调查场景审视：

1. Transparency（透明推理） — "showing the agent's reasoning at every decision point, not just the output"。在 AML 里这是合规底线而非锦上添花：SAR 叙述若不能逐条回溯到"哪条规则、哪笔证据交易触发"，调查员无法承担监管问责。本仓库 typology.ts 的每条 RuleHit 已带 description（含具体金额）+ evidenceTxIds，AmlTypologyPanel 已经在做透明推理。反作用：透明若做成"把模型 chain-of-thought 原样倒给用户"，反而制造噪声 + 暴露不可靠的中间推理。透明的正确粒度是"决策点 + 触发信号"，不是"思维流"。

2. User Control（可覆盖/暂停/重定向） — "override, pause, and redirect capabilities at every stage"。AML 里对应 AmlSarPanel 已有的"批准/退回/修改段落"。反作用：override 必须留痕——金融场景下"人改了什么"本身是审计对象，无痕 override 等于破坏问责链。

3. Proactive Status Communication（主动状态通报） — "the agent communicates what it is doing before the user asks"。反作用低，但对当前步进式原型价值有限（没有真正的异步长任务）；P3 接 LLM 后若证据汇集要跑数秒，才真正需要。

4. Structured Error Recovery（结构化错误恢复） — "explain what went wrong, provide context, and suggest a next step"。AML 里的"错误"包括：检索不到证据、类型学未达阈值、LLM 输出格式违规。evalChecks.ts 的 runCodeChecks 已经把这些失败分了类（format_violation/hallucination/retrieval_miss/typology_misjudge）——错误恢复的"解释"层已经有数据。

5. Plan-and-Execute（计划-执行） — "shows the user a proposed action plan before the agent begins working"。这是 Day 79 要实装的主线，当前 AgentPlanPanel 是占位雏形。

6. Confidence Signaling（置信度信号） — "attaches a visible indicator to every agent output"。Day 80 主线。

7. Progressive Delegation / Authorization（渐进式授权） — "starts the agent with limited autonomy and expands it as the user builds trust"，原文补一句关键的："earns permission through demonstrated reliability rather than demanding it at launch"（靠证明可靠性来赢得权限，而非上线时就索要）。Day 81 主线。

Fuselab 同篇还列了 5 个扩展模式（8-12：Planning Visibility / Tool-Use Disclosure / Memory Surfacing / Multi-Step Workflow Tracking / Recovery Routing），多数是前七个的细化变体——例如 Planning Visibility ⊂ Plan-and-Execute，Recovery Routing ⊂ Error Recovery。选型时只需锚定七个核心，扩展模式按需取子集。

反直觉洞察①（透明≠倒出思维流）：直觉认为"越透明越可信"，于是想把 LLM 的 reasoning tokens 整段展示。但 Fuselab 的措辞是 "reasoning at every decision point"——是离散的决策锚点，不是连续思维流。倒出原始 CoT 在 AML 里有双重害处：① 噪声淹没真正的触发信号；② 中间推理常含"先怀疑再否定"的探索，暴露给调查员反而动摇对最终结论的信任。透明的单位是可回溯的证据-规则映射（本仓库已有的 evidenceTxIds），不是 token 流。

B. 三源并读：Smashing(2026-02) × Tech Radar Vol 34(2026-04) × Fuselab(2025-08)，13 个月里模式库变了吗

时效硬规则要求：实装前（2026-08）模式库已是 13 个月前的 Fuselab，必须看更近的源是否迭代。三源对照：

关键演化：从"模式清单"收敛到"治理轴"。Smashing(2026-02) 不再罗列十几个模式，而是把它们归到三轴——Control（控制：override/pause）、Consent（同意：执行前授权）、Accountability（问责：留痕/可回溯）。这三轴恰好是金融合规的语言（DORA 运营韧性、SR 11-7 模型风险三道防线都在讲"控制点 + 可问责"）。Tech Radar Vol 34(2026-04) 进一步把"securing permission-hungry agents"列为四大主题之一，明说 Agent 倾向于"索要过多权限"，需要主动治理——这是给"渐进式授权"（模式 7、Day 81）背书的最新行业信号。

结论：13 个月里模式名没大变，但叙事从"功能清单"转向"治理框架"。 AML Copilot 选型应直接采用 Smashing 的三轴作为分组骨架，把 Fuselab 七模式挂到三轴下。

反直觉洞察②（更近的源往往是"收敛"而非"新增"）：做时效核查时容易期待"新源 = 新模式"，于是去找"2026 有什么 2025 没有的新模式"。但成熟领域的真实演化是收敛——Smashing(2026-02) 的贡献不是发明新模式，而是把 Fuselab 的 12 个收敛成 3 轴。对选型而言，"少而对的分组"比"多而散的清单"更有指导力。盲目追新增会错过这个收敛信号。

C. 选哪 4 个模式：信任曲线驱动的选型决策

把七模式按"信任决定模式"原则映射到 AML 调查员的信任曲线上。决策算法（伪代码）：

selectPatterns(user_trust_level, domain=AML_compliance):
  # 合规域：问责轴模式无条件强制（与信任无关）——监管要求，不是体验选项
  required = { Transparency, UserControl }        # Accountability 轴：恒开

  # 信任轴：随信任度递进开放"让渡控制"的模式
  if trust == LOW:        # 新调查员 / Agent 新上线
      add { PlanAndExecute }          # 执行前必看计划 → 建立心智模型
      authorization = MANUAL_ALL      # 全部人审（Consent 轴拉满）
  elif trust == MEDIUM:
      add { PlanAndExecute, ConfidenceSignaling }   # 置信度引导注意力分配
      authorization = TIERED          # 低风险自动、高风险人审
  elif trust == HIGH:    # 资深调查员 / Agent 经长期校准
      add { ConfidenceSignaling }     # 计划可折叠，只看置信信号
      authorization = PROGRESSIVE     # 低风险自动通过、抽检

  return required ∪ trust_dependent, authorization

AML Copilot 最终选定 4 个核心模式（落到 Smashing 三轴）：

砍掉的 3 个及理由：

• Proactive Status Communication → 当前步进式原型无异步长任务，状态通报价值低；P3 接 LLM 且证据汇集变慢后再加（非首发）。
• Structured Error Recovery（独立面板） → 不做成独立模式，而是融进 Confidence Signaling（低置信即"可能错"）+ evalChecks 失败分类，避免再开一块 UI。
• Memory Surfacing → AML 调查是单案件无状态研判（每个 case 独立评估），不需要把跨会话记忆浮现给用户；P2 的三层 memory 是 Agent 内部机制，不必暴露成 UX 模式。

反直觉洞察③（同一 Agent，模式集随用户而非功能而变）：传统功能思维是"系统能做 X 就给 X 配个 UI"。但 agent UX 的核心是 B 节那句"靠证明可靠性赢得权限"——模式集是信任的函数，不是功能的函数。证据是：给资深调查员强制展开完整 plan-and-execute 会被当成"碍事的确认弹窗"而点烦；给新调查员直接开渐进式自动通过则会让他不敢信任结果。同一套后端能力，低信任用户该看"全计划+全人审"，高信任用户该看"折叠计划+只看置信信号+自动通过低风险"。这就是为什么 C 节的选型算法第一个入参是 user_trust_level 而不是 feature_flags。

设计要点/决策表

对本项目的落地

• 不新建文件，落为选型决策记录：本日产出是选型决策，指导 Day 79-81 三篇的实装。把 4 个选定模式记入 AmlCopilot.tsx 顶部注释的"P3 UX 模式清单"，并标注每个模式对应的实装 Day，避免后续开发漂移到"上满 12 模式"。
• AgentPlanPanel 升级路径明确：当前 AmlCopilot.tsx 里的 AgentPlanPanel 注释已写"Plan-and-Execute 预览模式的轻量示意（参考 Fuselab 2025-08）"——Day 79 把它从"占位步骤条"升级成"执行前计划面板（步骤/工具/预估成本/证据源）"，对应模式 5。
• 三轴映射进组件结构：Accountability 轴 → 复用 AmlTypologyPanel（透明）+ AmlSarPanel 审计轨迹（留痕）；Consent 轴 → Day 79 计划面板的"批准后才执行"；Control 轴 → Day 81 渐进式授权复用 src/agent/mcp/toolRegistry.ts 的 schema 校验思路与 P2 风控网关策略语义。
• 信任曲线为 P3 上线后运营动作：C 节的 user_trust_level 三档在 W1-W2 仅落选型逻辑，真实"信任度量"（按调查员历史 override 率/批准率计算）为上线后埋点，不谎称已实现；首发以 MEDIUM 档（计划面板 + 置信信号 + 分级授权）为默认。

参考资料

1. Fuselab Creative — Agent UX: UI Design for AI Agents：七核心模式（Transparency/User Control/Proactive Status/Structured Error Recovery/Plan-and-Execute/Confidence Signaling/Progressive Delegation）+ 5 扩展模式；"interface is the accountability layer"；"earns permission through demonstrated reliability rather than demanding it at launch" (2025-08)
2. Smashing Magazine — Designing Agentic AI: Practical UX Patterns for Control, Consent, and Accountability：把模式收敛到 Control/Consent/Accountability 三轴；受监管场景"forced pauses are features not failures" (2026-02)
3. ThoughtWorks Technology Radar Vol 34：四主题之一 "securing permission-hungry agents"；"putting coding agents on a leash"；HITL 反对"step out of the loop" (2026-04)
4. 本仓库 src/components/aml/AmlCopilot.tsx（AgentPlanPanel 雏形）、AmlTypologyPanel.tsx、AmlSarPanel.tsx（透明/留痕已有）、src/aml/evalChecks.ts（错误分类已有） (2026-06)

SOTA 检查 (2026-06-11)

• "agent UX = 问责层"在 2026-06 是稳固共识：Fuselab(2025-08)、Smashing(2026-02)、Tech Radar Vol 34(2026-04) 三源一致——界面是"用户意图与自主行动之间的问责层"，受监管场景下"强制暂停是特性不是缺陷"。本日 WebSearch 未见推翻此框架的主流新方法论。
• 叙事正从"模式清单"收敛到"治理三轴"：Smashing(2026-02) 的 Control/Consent/Accountability 三轴是最新的收敛口径；选型应采用三轴而非 Fuselab 的扁平清单——这是 13 个月里最实质的演化（见反直觉②）。
• "securing permission-hungry agents"是新升温信号：Tech Radar Vol 34(2026-04) 把"权限饥渴的 Agent 需治理"列为主题，给渐进式授权（Day 81）提供了最新行业背书；待 Day 81 实装时复核该主题是否已有更具体的权限治理模式落地。
• 过时警示：早期（2024 及以前）"给 Agent 配个聊天框就算 agent UX"的认知已过时——2026 的共识是 agent UX 是独立设计学科，需 control/consent/accountability 三轴系统化设计。
• 待跟踪：实装前（2026-08）应重跑一次 WebSearch，确认 Fuselab/Smashing 是否在 2026 H1 之后发布更新模式库，以及"信任度量"是否有标准化方法（当前各家自定义）。