AI 扩展计划 / Playbooks
AI EventStorming / Agent Workflow Discovery Playbook
以下 primary / official sources 作为术语和架构锚点。本文把它们转成 AI workflow discovery、agent orchestration、金融零售流程治理和可审计证据语言。访问日期按 2026-06-29 记录。
646 行AI_EVENT_STORMING_AGENT_WORKFLOW_DISCOVERY_PLAYBOOK.md
AI EventStorming / Agent Workflow Discovery Playbook
定位: 面向 AI BA、AI PM、Solution Architect、Enterprise Architect、Agent Workflow Architect 和金融零售流程 owner 的 AI 产品发现与架构 traceability 手册。 核心问题: 当 AI 不只是总结信息, 而要进入支付争议、AML 调查、信贷运营、KYC、客服和风险流程时, 如何用 EventStorming 把 domain event、command、actor、policy、external system、hotspot、read model、AI insertion point、tool call、HITL、exception / compensation 和 eval trace 串成可发现、可设计、可审计、可验证的 workflow discovery 方法。 使用方式: 本文默认读者已经具备 CBAP 级业务分析能力, 不讲事件风暴入门和便利贴基础。重点是把事件风暴升级为 AI product discovery、agent workflow design、异常路径设计和架构可追溯资产。
重要说明: 本文是学习、作品集和架构训练材料, 不是法律意见、合规结论、审计意见、模型验证报告或生产架构批准。金融零售正式项目必须由 Business Owner、Architecture、Engineering、Security、Privacy、Legal、Compliance、Model Risk、Operational Risk、Internal Audit、Data Owner、Platform Owner 和相关系统 owner 共同确认适用边界、客户影响、监管义务、模型风险和上线门禁。
1. Source Anchors
以下 primary / official sources 作为术语和架构锚点。本文把它们转成 AI workflow discovery、agent orchestration、金融零售流程治理和可审计证据语言。访问日期按 2026-06-29 记录。
| Source | Official / primary link | 本手册使用方式 |
|---|---|---|
| EventStorming official | https://www.eventstorming.com/ | 用于锚定 EventStorming 作为协作式领域探索方法, 并延展到 AI workflow discovery、hotspot 暴露、时序事件链和团队共识。 |
| Domain Language / DDD | https://www.domainlanguage.com/ddd/ | 用于锚定 ubiquitous language、domain event、bounded context、policy、command 和模型边界, 避免 AI workflow 只按页面或系统菜单建模。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 插入点、HITL、异常补偿、评估、监控和治理证据。 |
2. One-Sentence Positioning
AI EventStorming / Agent Workflow Discovery 的一句话定位:
用 EventStorming 发现业务事实链和责任边界,
再把每个 domain event 周围的 command、actor、policy、system、read model、hotspot 和 exception
转成 AI insertion point、tool contract、HITL gate、compensation path 和 eval trace。
中文记忆:
AI workflow 发现不是“把 PRD 交给模型拆任务”, 而是先把业务事实、决策权、系统副作用和异常路径摊开, 再决定 AI 应该辅助、建议、决策、行动、监控还是模拟。
这份手册训练三类能力:
| 角色 | 需要形成的能力 | 典型产出 |
|---|---|---|
| AI BA / BA Lead | 能主持 AI-ready EventStorming, 把事件、命令、策略、异常和人机协作点写成需求与验收证据 | AI event storm board、hotspot map、HITL requirement、exception catalog |
| AI PM | 能判断 AI 插入点的产品价值、风险边界、用户体验、运营成本和度量方式 | AI insertion matrix、workflow value hypothesis、eval target、adoption metric |
| Solution Architect / Enterprise Architect | 能把发现结果追溯到 agent workflow、tool gateway、policy engine、state machine、audit log 和 eval pipeline | Agent workflow trace matrix、tool contract、control architecture、evidence trace |
适合放入作品集的最终产出:
| Portfolio artifact | 展示能力 |
|---|---|
| AI Event Storm Board | 能把金融零售流程从系统功能清单还原为业务事实链、决策点、控制点和异常点。 |
| EventStorming-to-AI Mapping | 能把 domain event、command、actor、policy、system、read model、hotspot 映射为 AI 能力边界。 |
| Agent Workflow Trace Matrix | 能从一个业务事件追溯到 command、tool call、policy gate、HITL、new event、audit evidence 和 eval。 |
| Hotspot-to-Eval Map | 能把不确定、争议、高风险和高成本节点转成评估样本、失败阈值、监控指标和 release gate。 |
| Exception and Compensation Checklist | 能设计 retry、rollback、manual repair、audit note、customer communication 和 regulatory evidence。 |
| Financial Retail Case Pack | 能用 payment dispute、AML investigation、credit ops 三个场景讲清 AI agent workflow discovery 方法。 |
3. 为什么 AI Workflow 发现不能只靠 PRD 或流程图
PRD 和流程图仍然有价值, 但它们往往描述“系统要做什么”和“流程应该怎么走”。AI agent workflow 的风险在于: 模型会参与判断、生成计划、调用工具、跨系统行动、等待人工审批、处理异常并留下长期证据。只靠 PRD 或线性流程图, 很容易漏掉业务事实、决策权、系统副作用和异常补偿。
3.1 PRD / 流程图的常见盲区
| 盲区 | 在 AI workflow 中的风险 | EventStorming 补强方式 |
|---|---|---|
| 只写功能, 不写事实 | “AI 自动处理争议”听起来完整, 但不知道哪些业务事实已经发生、哪些只是候选判断 | 用 past-tense domain event 固定事实, 如 DisputeOpened、EvidenceReceived、ProvisionalCreditApproved。 |
| 只画 happy path | Agent 上线后大量遇到证据缺失、工具失败、审批超时、客户反悔、系统状态冲突 | 用 hotspot、exception event、compensation event 暴露非正常路径。 |
| 决策逻辑藏在文字里 | 模型可能把政策解释、资格判断、风险分层和审批条件混在同一个 prompt 中 | 把 policy / decision 显式化, 关联 DMN、policy-as-code、approval rule 和 eval。 |
| 工具副作用不清 | Agent 调用 API 后可能改 case、发通知、冻结账户、发起退款或提交监管材料 | 用 command 和 external system 标记每个副作用, 绑定 tool contract、权限、幂等和审计。 |
| 人工复核一句带过 | “需要人工审核”没有说明谁审核、看什么证据、能做哪些动作、多久超时、如何升级 | 把 HITL 作为 workflow state 和 event, 记录 role、SLA、evidence、decision reason 和 new event。 |
| 读模型不清 | Agent 需要什么上下文、员工看什么 dashboard、审计看什么 trace, 经常事后才发现缺数据 | 用 read model 设计运营视图、AI context pack、evidence view 和 audit view。 |
| 评估与流程断裂 | Eval 只测回答准确率, 没有覆盖真实流程中的关键失败 | 把 hotspot、policy gate、exception path 和 customer-impacting event 转成 eval trace。 |
3.2 AI Workflow Discovery 的关键转变
| 从 | 到 |
|---|---|
| 从页面功能 | 到业务事实链和责任边界 |
| 从流程节点 | 到事件、命令、策略、角色、系统和读模型 |
| 从“AI 能不能做” | 到“AI 在哪个事件前后以什么自治等级做什么” |
| 从提示词需求 | 到 tool contract、policy gate、HITL、state transition 和 audit evidence |
| 从单点准确率 | 到事件链级 eval、异常路径级 eval 和控制有效性 eval |
| 从上线前验收 | 到 discovery -> design -> build -> eval -> monitor -> incident learning 的闭环 |
3.3 事件风暴在 AI 发现中的核心价值
EventStorming 对 AI workflow 的价值不在于贴便利贴, 而在于把跨角色的隐性知识变成可讨论的事实链:
Business event
-> command that caused it
-> actor or system that issued command
-> policy that allowed / denied / routed it
-> external system that executed side effect
-> read model that made decision visible
-> hotspot where uncertainty or disagreement appears
-> AI insertion point that changes cognition or action
-> HITL / exception / compensation path
-> eval trace that proves behavior stays inside boundary
如果一个 AI use case 不能沿着这条链路讲清楚, 它很可能只是 demo, 还不是金融零售可落地的 agent workflow。
4. EventStorming-to-AI Mapping
EventStorming 的对象可以直接映射为 AI agent workflow 的设计对象。关键不是改变 EventStorming 语言, 而是让每个对象都能回答 AI 时代的新问题: 模型看什么、能做什么、谁批准、用什么工具、失败怎么恢复、如何评估。
4.1 核心映射表
| EventStorming object | 传统含义 | AI workflow discovery 问题 | AI / architecture artifact |
|---|---|---|---|
| Domain event | 已经发生的业务事实 | 这个事实是否能作为 agent workflow 的启动、转移、暂停或终止信号 | Event schema、workflow event、audit event、monitoring signal |
| Command | 触发业务变化的意图或请求 | AI 是否可以生成、建议、提交或执行这个命令 | Tool command、API contract、idempotency key、approval requirement |
| Actor | 发起命令或承担责任的人 / 系统 | 是客户、员工、审批人、系统服务、AI agent 还是第三方 | Actor model、authority matrix、RACI、agent identity |
| Policy | 事件发生后触发的规则、约束或反应 | 哪些判断必须由规则服务、策略引擎、风控模型或人工复核决定 | Policy-as-code、DMN decision、risk tier、guardrail |
| External system | 领域外但流程依赖的系统 | Agent 调用该系统是查询、写入、外发、资金动作还是监管动作 | Tool gateway、OpenAPI / AsyncAPI contract、side-effect matrix |
| Hotspot | 不确定、争议、复杂或高风险点 | 这里是否需要 AI assist, 或必须限制 AI autonomy | Discovery question、risk scenario、eval case、control point |
| Read model | 为某类角色服务的信息视图 | Agent、员工、审批人、审计和客户分别需要什么可见证据 | AI context pack、reviewer evidence view、audit trace view |
| Time axis | 事件发生顺序和等待关系 | AI workflow 是同步、异步、长事务、等待人工还是等待外部事件 | State machine、timer、SLA、retry、escalation、compensation |
4.2 Domain Event
Domain event 必须使用过去时表达业务事实, 这样 AI workflow 才不会把“想做的事”和“已经发生的事”混在一起。
| 好的 event | 不好的 event | 原因 |
|---|---|---|
PaymentDisputeOpened | Open dispute | 前者是事实, 后者是命令或操作。 |
MerchantEvidenceReceived | Get merchant docs | 前者能触发下一步判断, 后者只是任务。 |
HighRiskAmlAlertEscalated | Escalate risky case | 前者能成为审计事实, 后者是动作请求。 |
CreditMemoDraftReviewed | Review memo | 前者说明审查已经发生, 后者不说明结果。 |
AI 设计问题:
| 问题 | 设计影响 |
|---|---|
| 这个 event 能否启动 agent workflow | 定义 trigger、scope、case id、tenant、risk tier 和 data minimization。 |
| event payload 中哪些字段可给模型 | 定义 data entitlement、masking、purpose limitation 和 evidence reference。 |
| 事件是否客户可见或监管相关 | 提升审计、HITL、版本和证据保留要求。 |
| 事件是否可能乱序或重复 | 需要 idempotency、event version、correlation id 和 ordering rule。 |
4.3 Command
Command 是对系统或人提出“请做某事”的意图。AI 介入 command 时, 要区分草拟、建议、提交和执行。
| Command | AI 可参与方式 | 必要控制 |
|---|---|---|
RequestMerchantEvidence | 自动草拟调单请求, 推荐证据清单 | 模板版本、事实引用、发送前审批或抽样复核 |
ApproveProvisionalCredit | 生成资格判断摘要和风险提示 | 人工审批、金额阈值、policy decision id、幂等键 |
CreateAmlInvestigationPlan | 推荐调查步骤和优先级 | Investigator 接受 / 修改, 禁止自动关闭 alert |
SubmitCreditMemoForReview | 生成 memo 草稿和缺口清单 | Underwriter 复核、引用校验、版本留痕 |
FreezeAccount | 只可生成建议和证据包 | 高风险动作前双人审批、法务 / 合规边界、kill switch |
Command 需求至少包括:
| 字段 | 说明 |
|---|---|
| Command name | 业务语义稳定, 不用 UI 操作名代替。 |
| Issuer | 人、系统、agent 或 delegated user。 |
| Preconditions | 允许发起命令所需事实、状态和权限。 |
| Policy gate | 授权、风险、限额、审批、分离职责。 |
| Tool / API | 执行命令的系统接口和 owner。 |
| Idempotency | 重试和 replay 如何避免重复副作用。 |
| Result event | 成功、失败、拒绝、待审批、补偿后的事件。 |
4.4 Actor
AI workflow 中 actor 不能只写“用户”。同一个流程里至少有客户、前台员工、运营人员、审批人、合规调查员、系统服务、AI agent、外部机构等角色。
| Actor type | 关键问题 | 设计要求 |
|---|---|---|
| Customer | 是否提供资料、发起争议、接收通知、受影响 | 客户可见动作和沟通必须有高质量证据和审查边界。 |
| Frontline user | 是否采纳 AI 建议、编辑文案、提交请求 | UI 必须显示证据、限制、reject / edit / escalate 动作。 |
| Operations specialist | 是否处理例外、修复 case、补充材料 | 需要 manual repair queue、SLA 和 case note。 |
| Risk / Compliance reviewer | 是否批准高风险路径或监管材料 | 需要完整 evidence binder、policy trace、decision reason。 |
| AI agent | 是辅助者、建议者、执行者还是监控者 | 必须有 agent identity、scope、tool allowlist 和 audit trail。 |
| External system | 是否产生或消费业务事实 | 需要契约、错误模型、重试、DLQ 和 data lineage。 |
4.5 Policy
Policy 是 AI workflow 的边界语言。它不应该藏在 prompt 里, 也不应该只存在于 SOP 文档。
| Policy type | 金融零售示例 | AI workflow 设计 |
|---|---|---|
| Eligibility policy | 争议是否在可处理时限内, 信贷材料是否完整 | DMN / policy-as-code 输出 decision、reason code、version。 |
| Risk routing policy | AML alert 是否进入 EDD, 大额争议是否进 supervisor queue | Policy gate 决定 workflow state 和 HITL queue。 |
| Authorization policy | 谁能发起退款、冻结账户、关闭 alert | Tool gateway 调 PDP / PEP, 记录 decision id。 |
| Communication policy | 客户通知是否包含合规措辞、禁用承诺 | Draft guard、template registry、review gate。 |
| Model use policy | 哪类场景允许 AI recommend, 哪类只允许 summarize | AI insertion pattern 和 autonomy tier。 |
| Data policy | 哪些字段可被模型读取、保存、传给 vendor | Retrieval filter、masking、retention、audit event。 |
4.6 External System
External system 的重点不是“需要集成哪个系统”, 而是该系统会不会让 agent workflow 产生不可忽视的副作用。
| System | 典型交互 | 风险等级 | 架构要求 |
|---|---|---|---|
| Case management | 创建任务、更新状态、写 case note | 中 | Tool contract、字段级权限、版本和审计。 |
| Core banking / card processor | 临时入账、扣款、冻结、账户状态变更 | 高 | 强审批、幂等、reconciliation、compensation。 |
| AML platform | 创建调查、添加 evidence、推荐 disposition | 高 | 不允许无监督关闭高风险 alert, 保留 investigator decision。 |
| KYC vendor | 查询身份、提交补件、接收评分 | 中到高 | Vendor SLA、错误模型、source freshness、manual override。 |
| Notification service | 给客户、商户、监管或内部发送消息 | 高 | 模板、审批、delivery trace、撤回 / 更正策略。 |
| Data warehouse / feature store | 读取交易、客户、风险特征 | 中 | 数据血缘、权限过滤、freshness 和 explainability。 |
4.7 Hotspot
Hotspot 是 AI 产品发现最有价值的区域。它通常意味着: 信息不完整、责任不清、规则有争议、系统不一致、成本很高、风险很高或现有流程靠专家经验维持。
| Hotspot type | 表现 | AI discovery response |
|---|---|---|
| Evidence ambiguity | 同一证据被不同人解释不同 | 建 evidence rubric、citation requirement、review calibration eval。 |
| Policy conflict | SOP、系统规则、监管要求或业务目标冲突 | 拉出 policy owner, 做 decision table 和 conflict resolution rule。 |
| System state mismatch | 核心系统、case、通知状态不一致 | 设计 reconciliation event、manual repair 和 audit note。 |
| Human bottleneck | 审批或专家判断积压 | AI 先做 triage / summary / checklist, 不直接替代最终判断。 |
| Tool side-effect risk | 一个工具动作影响资金、账户或客户权益 | 提高 autonomy gate, 加 pre-action HITL 和 compensation。 |
| Eval blind spot | 没有样本覆盖罕见但高影响情形 | 从 hotspot 生成 scenario eval 和 incident drill。 |
4.8 Read Model
Read model 在 AI workflow 里至少有四类, 不应只做一个“智能助手上下文”。
| Read model | 使用者 | 内容 |
|---|---|---|
| AI context pack | Agent / model activity | 最小必要事实、证据引用、政策版本、允许动作、不可用边界。 |
| Reviewer evidence view | 员工 / 审批人 | AI 输出、证据、来源时间、政策命中、缺失信息、建议动作和风险提示。 |
| Operations control view | Ops lead / process owner | 队列、SLA、异常、手工修复、返工、低置信度、审批积压。 |
| Audit trace view | Internal audit / risk / compliance | 事件链、模型版本、tool call、policy decision、HITL、override、补偿和 case note。 |
4.9 Time Axis
时间轴决定 agent workflow 是“单次响应”还是“长事务”。金融零售场景常常跨分钟、小时、天甚至月。
| Time-axis question | 架构影响 |
|---|---|
| 哪些 event 必须按顺序处理 | 需要 sequence、causation id、version 和 concurrency control。 |
| 哪些步骤需要等待客户、商户、外部机构或审批人 | 需要 timer、SLA event、reminder、escalation 和 pause / resume。 |
| 哪些命令可以重试 | 需要 retry policy、idempotency ledger 和 side-effect classification。 |
| 哪些 event 超时后会改变客户权益或监管风险 | 需要 proactive monitoring、exception queue 和 management report。 |
| 哪些流程会跨版本运行 | 需要 workflow versioning、prompt / policy version lock 和 audit trace。 |
5. AI Insertion Patterns: Assist / Recommend / Decide / Act / Monitor / Simulate
AI 插入点不是“这里加个 Copilot”。每个插入点都要绑定事件链位置、自治等级、输入证据、输出动作、控制要求和评估方式。
5.1 六类插入模式
| Pattern | AI 做什么 | 适合放在事件链哪里 | 默认控制 |
|---|---|---|---|
| Assist | 帮人整理、查找、摘要、抽取 | event 之后、human command 之前 | 引用、证据完整性、人工最终判断。 |
| Recommend | 推荐下一步、队列、问题清单、处理策略 | policy / hotspot 周围 | reason code、替代方案、reject / override 记录。 |
| Decide | 输出可执行决策 | 只适合低风险、可解释、可回滚、规则明确场景 | DMN / policy gate、阈值、抽样复核、人工覆盖。 |
| Act | 调用工具改变状态或外发 | command 执行阶段 | Tool gateway、approval、幂等、side-effect ledger、compensation。 |
| Monitor | 持续观察 SLA、异常、漂移、队列和控制失效 | event stream / operations view | 告警阈值、false alert 管理、incident workflow。 |
| Simulate | 用历史或合成事件链测试政策、流程、产能和风险 | TO-BE 设计和 release gate 前 | scenario set、assumption log、human sign-off。 |
5.2 插入模式与事件链映射
Domain event happened
-> Assist: summarize what happened and collect evidence
-> Recommend: suggest next command or route
-> Decide: apply bounded decision when risk is low and policy is explicit
-> Act: submit controlled command through tool gateway
-> Monitor: observe new events and detect drift / SLA / exception
-> Simulate: test alternative policy or workflow on event history
5.3 自治等级
| Autonomy tier | AI 权限 | 金融零售适用边界 |
|---|---|---|
| L0: No-side-effect assist | 只读、摘要、草稿 | 大多数内部效率场景的起点。 |
| L1: Human-issued command | AI 准备参数, 人点击提交 | 客服、争议、信贷 memo、KYC 补件。 |
| L2: Policy-bounded action | AI 在明确规则、低金额、低风险范围内执行 | 低风险 case note、低影响任务创建、内部提醒。 |
| L3: Human-approved action | AI 发起高影响命令, 人审批后执行 | 临时入账、客户外发、账户限制建议、监管 narrative。 |
| L4: Supervised automation | AI 批量处理, 人监控抽样和异常 | 低风险分类、资料完整性检查、队列路由。 |
| L5: Prohibited / exceptional | AI 不得直接执行 | 高风险账户冻结、监管提交、拒贷最终决定、AML alert 无监督关闭。 |
5.4 插入点评审问题
| 问题 | 好答案 |
|---|---|
| AI 插在什么 event 前后 | 能指出触发 event、前置事实、后续 command 和结果 event。 |
| AI 输出是否改变业务状态 | 如果改变, 必须有 command、tool contract、policy gate 和 audit evidence。 |
| AI 是否需要读取敏感数据 | 必须有 data entitlement、masking、purpose 和 retention 规则。 |
| 人什么时候介入 | 介入点是 workflow state, 不是页面提示。 |
| 失败如何被发现 | 有 eval、runtime monitor、exception event 和 owner。 |
| 失败如何恢复 | 有 retry、compensation、manual repair、customer correction 和 audit note。 |
6. Agent Workflow Trace: Domain Event -> Command -> Tool -> Policy Gate -> HITL -> New Event
Agent workflow trace 是把 discovery 结果变成架构资产的关键。它要能从任意客户结果、系统动作或审计问题回溯到事件链。
6.1 标准 Trace Chain
Domain event
-> candidate command
-> command issuer
-> AI insertion pattern
-> policy gate
-> tool contract
-> HITL state
-> side-effect ledger
-> new domain event
-> read model update
-> eval trace
-> audit evidence
6.2 Trace 字段
| Field | 说明 |
|---|---|
trace_id | 跨事件、命令、工具、审批和 eval 的链路 ID。 |
correlation_id | 同一客户案件、争议、alert 或信贷申请的业务关联 ID。 |
causation_id | 当前事件由哪个 command、event 或 workflow step 触发。 |
event_name | 已发生的 domain event。 |
command_name | 发起的命令或人类任务。 |
actor_id | 人、系统或 agent identity。 |
policy_decision_id | 授权、风险、路由或审批要求的决策引用。 |
tool_call_id | Tool gateway 中的调用记录。 |
hitl_decision_id | 人工批准、拒绝、编辑、升级或覆盖记录。 |
result_event | 命令执行后产生的新业务事实。 |
eval_case_id | 关联到的评估样本、scenario 或 monitoring rule。 |
evidence_refs | 证据包、输入事实、输出哈希、系统记录、case note。 |
6.3 Payment Dispute Trace 示例
| Trace step | 示例 |
|---|---|
| Domain event | PaymentDisputeOpened |
| Candidate command | AssessDisputeEligibility |
| Actor | Customer triggered, DisputeOps owns |
| AI insertion | Assist + Recommend: 汇总交易、原因码、时限、历史争议、缺失证据 |
| Policy gate | Dispute policy decision: amount, reason code, filing window, customer risk tier |
| Tool | getCardTransaction, getCustomerHistory, draftEvidenceRequest |
| HITL | Ops specialist 复核 eligibility 和客户通知草稿 |
| New event | DisputeEligibilityReviewed 或 AdditionalEvidenceRequested |
| Exception | 交易状态与卡组织记录不一致 -> DisputeStateMismatchDetected |
| Eval trace | Eligibility reason accuracy、unsupported claim rate、missing evidence recall |
| Audit evidence | policy version、AI summary output hash、reviewer decision、customer notification template |
6.4 Architecture Traceability
EventStorming 输出要能落到架构视图:
| Discovery object | Architecture object |
|---|---|
| Domain event | Event schema、CloudEvents type、workflow transition、audit event |
| Command | API operation、workflow task、tool contract、idempotency rule |
| Actor | IAM role、agent identity、delegated authority、segregation policy |
| Policy | PDP / PEP、DMN service、risk rule、approval matrix |
| External system | Integration connector、system owner、SLA、error contract |
| Hotspot | Risk scenario、eval case、control point、incident playbook |
| Read model | UI view、agent context pack、review evidence screen、audit dashboard |
| Time axis | State machine、timer、retry、DLQ、escalation、compensation |
7. Exception and Compensation Design
Exception and compensation 不是上线后的运维细节, 而是在 EventStorming 阶段就要识别的一等对象。AI agent workflow 如果只设计 happy path, 会把错误更快、更隐蔽地扩散到多个系统。
7.1 Exception Taxonomy
| Exception type | 示例 | 处理方式 |
|---|---|---|
| Missing evidence | 客户未提交凭证, AML 缺交易解释, 信贷缺收入证明 | 生成 evidence request, 暂停 workflow, 设置 SLA 和 reminder。 |
| Conflicting evidence | 客户陈述与交易记录冲突, 商户证据和卡组织状态冲突 | 升级人工复核, 标记 evidence conflict, 禁止自动结案。 |
| Policy conflict | SOP 与系统规则不一致, 新政策尚未同步到知识库 | 调用 policy owner review, 锁定旧版本, 记录 conflict decision。 |
| Tool failure | KYC vendor 超时, card processor API 返回未知错误 | Retry with backoff, circuit breaker, DLQ, manual repair。 |
| Unauthorized action | Agent 试图调用超出权限的工具 | Deny event, security alert, policy tuning, eval 增补。 |
| Low confidence / unsupported claim | AI 生成无法被证据支持的判断 | 强制人工复核, 输出 unsupported claim flag。 |
| Duplicate / replay risk | 重试导致重复通知、重复临时入账 | Idempotency ledger, side-effect check, replay-safe activity。 |
| Customer impact after error | 错误通知已发送, 错误状态已展示给客户 | Customer correction, apology / remediation flow, audit note。 |
7.2 Compensation Patterns
| Pattern | 适用场景 | 设计重点 |
|---|---|---|
| Rollback | 状态更新或内部任务可撤回 | 必须确认没有外部不可逆副作用。 |
| Retry | 临时失败、网络抖动、依赖服务超时 | 区分 read retry 和 write retry, 写操作必须幂等。 |
| Forward recovery | 已发生副作用无法简单撤销 | 用更正事件、补充通知、后续调整让流程回到可接受状态。 |
| Manual repair | 系统状态冲突、证据冲突、人工判断必要 | 建 repair queue、owner、SLA、case note、管理报表。 |
| Compensating command | 退款撤销、临时入账冲正、任务重开、通知更正 | 作为正式 command, 需要权限、审批和 audit event。 |
| Audit note | 解释为什么发生异常、谁判断、依据是什么、如何修复 | 不能只写自由文本, 应带 reason code、evidence ref 和 trace id。 |
7.3 Compensation Checklist
| 检查项 | 设计要求 |
|---|---|
| 是否有外部副作用 | 查询、草稿、内部状态、客户通知、资金动作、监管材料分级处理。 |
| 是否可重复执行 | 所有 write command 必须定义 idempotency key 和 duplicate response。 |
| 是否可撤销 | 区分技术回滚、业务补偿、客户更正和不可补偿风险。 |
| 是否需要人工批准 | 涉及资金、账户、客户权益、监管或高风险客户沟通的补偿需要审批。 |
| 是否影响客户 | 需要客户通知策略、话术版本、客户服务 handoff 和投诉升级。 |
| 是否要进入审计 | 记录原始 event、错误原因、补偿 command、批准人、结果 event。 |
| 是否需要 eval 增补 | 每次异常都应判断是否新增 scenario eval 或 regression test。 |
7.4 Exception Event 命名
| Event | 用途 |
|---|---|
EvidenceMissingDetected | 证据不足, workflow 暂停或请求补件。 |
PolicyConflictDetected | 政策冲突, 需要 owner 决策。 |
ToolCallRejectedByPolicy | Agent 工具调用被权限或风控拒绝。 |
ManualRepairRequested | 系统状态或证据需要人工修复。 |
CompensationCommandIssued | 触发补偿动作。 |
CustomerCorrectionSent | 对客户发送更正或补充说明。 |
AuditNoteRecorded | 对异常和修复过程留痕。 |
8. Financial Retail Case: Payment Dispute / AML Investigation / Credit Ops
8.1 Payment Dispute Event Storming
目标: 发现 AI 在支付争议中的价值点, 同时控制资金、客户沟通、卡组织规则和证据风险。
| Event chain | AI opportunity | Control / eval |
|---|---|---|
DisputeOpened | Assist: 汇总交易、客户陈述、历史争议、原因码 | Evidence completeness eval、PII masking。 |
TransactionMatched | Recommend: 判断争议类型和所需证据 | Reason code accuracy、policy version trace。 |
EligibilityReviewed | Recommend: 是否建议临时入账或补件 | Human approval、amount threshold、override log。 |
MerchantEvidenceRequested | Act with approval: 生成并发送调单请求 | Template guard、delivery audit、idempotency。 |
MerchantEvidenceReceived | Assist: 提取关键事实和冲突点 | Citation accuracy、conflict detection recall。 |
ProvisionalCreditApproved | Act after HITL: 发起临时入账 | Dual control for high amount、side-effect ledger。 |
DisputeResolved | Assist: 生成 case note 和客户说明 | Customer communication review、audit evidence。 |
典型 hotspot:
| Hotspot | 发现问题 | 设计回应 |
|---|---|---|
| 客户陈述不完整 | AI 容易补全不存在的事实 | 输出 missing evidence list, 禁止 unsupported claim。 |
| 临时入账规则复杂 | 金额、时限、原因码、客户风险都影响判断 | DMN / policy-as-code 决定资格, AI 只解释和准备证据。 |
| 多系统状态不一致 | Case、card processor、notification 状态不同步 | Reconciliation event + manual repair queue。 |
| 客户通知敏感 | 错误承诺会造成投诉或合规风险 | Template registry + approval + message audit。 |
8.2 AML Investigation Event Storming
目标: 让 AI 提高调查效率, 但不让模型无监督关闭 alert、替代可疑活动判断或生成无证据 narrative。
| Event chain | AI opportunity | Control / eval |
|---|---|---|
AmlAlertGenerated | Assist: 汇总 alert reason、交易模式、客户资料 | Data entitlement、source freshness。 |
CustomerProfileRetrieved | Assist: 生成 KYC / CDD 摘要 | Citation, stale data warning。 |
TransactionClusterIdentified | Recommend: 建议调查路径和问题清单 | Investigator review、red flag recall。 |
ExternalScreeningMatched | Assist: 解释名单匹配和不确定性 | False positive handling、policy trace。 |
InvestigationPlanApproved | HITL: 调查员确认计划 | Decision log、override reason。 |
NarrativeDrafted | Draft: 生成 case narrative 草稿 | Unsupported claim check、citation coverage。 |
DispositionReviewed | Recommend only: 不能自动关闭高风险 alert | Senior review、maker-checker、audit pack。 |
典型 hotspot:
| Hotspot | 风险 | 设计回应 |
|---|---|---|
| Alert disposition 权限 | 自动关闭 alert 会造成重大合规风险 | AI 只能 recommend, human owns disposition。 |
| 交易模式解释 | 模型可能把相关性讲成意图 | 要求事实 / 推断分离, narrative 带证据引用。 |
| 名单匹配不确定 | 同名、拼写差异、跨语种 | AI 提供候选解释, 由 investigator 确认。 |
| 监管证据 | 事后必须解释为什么升级或关闭 | Trace matrix + evidence binder + policy version。 |
8.3 Credit Ops Event Storming
目标: 用 AI 降低信贷运营的资料整理、memo 草拟、政策解释和异常路由成本, 同时保护公平性、可解释性、客户权益和模型风险边界。
| Event chain | AI opportunity | Control / eval |
|---|---|---|
CreditApplicationSubmitted | Assist: 生成资料清单和缺口 | Completeness eval、data minimization。 |
IncomeDocumentReceived | Assist: 抽取收入、雇主、日期、异常 | Extraction accuracy、human correction log。 |
PolicyEligibilityChecked | Decide only if rule-based: 调政策服务 | DMN trace、reason code、version。 |
UnderwritingMemoDrafted | Draft: 生成 memo, 标注证据和缺口 | Citation coverage、bias review、unsupported claim。 |
ExceptionRouteRecommended | Recommend: 建议进入 manual underwriting / fraud review | Routing accuracy、override analytics。 |
CreditDecisionReviewed | HITL: underwriter 做最终判断 | Decision reason、adverse action trace。 |
CustomerNoticePrepared | Draft with approval: 生成客户通知 | Compliance template、human approval、audit。 |
典型 hotspot:
| Hotspot | 风险 | 设计回应 |
|---|---|---|
| 信贷最终决策 | 高影响、监管敏感、公平性风险 | AI 不直接拥有最终决定, policy / underwriter 负责。 |
| 拒绝理由 | 原因码必须准确、可解释、可审计 | DMN reason code + template + reviewer approval。 |
| 文档抽取错误 | 收入、日期、身份字段错误会影响结果 | Structured extraction eval + human correction loop。 |
| 历史偏差 | 训练样本和历史审批可能带偏差 | Fairness monitoring、manual review、model risk governance。 |
9. Artifact Templates
9.1 AI Event Storm Board Schema
# AI Event Storm Board: [Process / Domain]
## Scope
- Business outcome:
- Customer / employee impact:
- In-scope bounded context:
- Out-of-scope systems and decisions:
- Risk tier:
## Event Chain
| Seq | Domain event | Triggering command | Actor | Policy / decision | External system | Read model | Hotspot | AI insertion | Result / next event |
|---|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | | |
## Hotspots
| Hotspot | Why it matters | Evidence needed | Owner | AI opportunity | Control requirement | Eval target |
|---|---|---|---|---|---|---|
## Decisions and Policies
| Policy / decision | Input facts | Output | Reason code | Version owner | AI role | HITL requirement |
|---|---|---|---|---|---|---|
## Tool and System Touchpoints
| Tool / system | Query or command | Side effect class | Idempotency | Approval | Error model | Compensation |
|---|---|---|---|---|---|---|
## Exception Paths
| Exception event | Detection rule | Workflow state | Human role | Recovery action | Audit evidence |
|---|---|---|---|---|---|
9.2 Agent Workflow Trace Matrix
| Trace item | Description | Example |
|---|---|---|
| Domain event | 已发生的业务事实 | PaymentDisputeOpened |
| Event schema owner | 事件 owner 和版本 | Payments domain owner, v1 |
| Candidate command | 事件后可能触发的命令 | AssessDisputeEligibility |
| AI insertion pattern | assist / recommend / decide / act / monitor / simulate | Assist + Recommend |
| Input evidence | AI 可读取的证据引用 | transaction, dispute reason, customer history |
| Policy gate | 授权、资格、风险、审批 | dispute eligibility policy |
| Tool call | 受治理工具或 API | getCardTransaction, draftCustomerNotice |
| HITL | 人工复核或批准 | Dispute specialist approval |
| Side effect | 状态、通知、资金、监管影响 | customer notification, provisional credit |
| Result event | 工具或人类动作后的事实 | EligibilityReviewed |
| Exception path | 失败、冲突、超时、低置信度 | EvidenceMissingDetected |
| Compensation | retry、rollback、manual repair、audit note | manual repair + corrected notice |
| Eval trace | 对应测试场景和指标 | reason accuracy, unsupported claim rate |
| Audit evidence | 可复盘证据 | trace id, policy version, reviewer decision |
9.3 Hotspot-to-Eval Map
| Hotspot | Failure scenario | Eval type | Metric | Release threshold | Runtime monitor | Owner |
|---|---|---|---|---|---|---|
| Evidence ambiguity | AI 把客户陈述当作已验证事实 | Scenario eval | Unsupported claim rate | Critical cases zero tolerance | Unsupported claim alert | Process owner + Model risk |
| Policy conflict | AI 使用过期政策解释资格 | Regression eval | Policy version accuracy | High severity pass rate | Policy freshness monitor | Policy owner |
| Tool side-effect | AI 重试造成重复通知或重复入账 | Workflow simulation | Duplicate side-effect count | Zero duplicate write in test set | Idempotency violation alert | Platform owner |
| Human bottleneck | AI 建议过多升级导致队列积压 | Ops simulation | Approval backlog, SLA breach | Within agreed capacity | Queue SLA dashboard | Ops lead |
| High-risk decision | AI 推荐关闭 AML alert 但证据不足 | Red-team eval | Under-escalation rate | High-risk false close zero tolerance | Senior review sampling | Compliance owner |
9.4 Compensation Checklist
| Area | Question | Evidence |
|---|---|---|
| Side effect class | 这个动作是 read、draft、internal update、customer communication、money movement 还是 regulatory action | Side-effect matrix |
| Idempotency | 重试和 replay 是否会重复执行 | Idempotency key, duplicate response |
| Rollback | 能否技术回滚, 或只能业务补偿 | Rollback / compensation decision |
| Retry | 哪些错误可重试, 重试多久, 谁能重放 | Retry policy, DLQ owner |
| Manual repair | 人工修复队列是否有 owner、SLA、权限和 case note | Repair queue log |
| Customer impact | 是否需要客户更正、解释或补偿 | Customer correction event |
| Audit note | 是否记录原因、责任、证据、批准和结果 | Audit note with trace id |
| Eval update | 该异常是否应进入 regression / red-team / scenario eval | Eval case id |
9.5 Workshop Output Review Checklist
| Review question | Pass signal |
|---|---|
| 是否每个 AI 插入点都有前后 event | 能从事件链定位 AI 在哪里工作。 |
| 是否每个 tool call 都能映射到 command | 没有无业务语义的裸工具调用。 |
| 是否每个高风险 command 都有 policy gate | 权限、限额、风险和审批可追溯。 |
| 是否每个 HITL 都有角色、证据和动作集 | 人不是形式审批, 能 reject / edit / escalate / override。 |
| 是否每个 hotspot 都有 eval 或 monitor | 发现的不确定性进入验证闭环。 |
| 是否异常路径能产生 event | 失败、补偿、手工修复和审计都有事实记录。 |
| 是否 read model 覆盖 AI、人、运营和审计 | 不只服务模型上下文, 也服务监督和复盘。 |
10. Interview Answers
10.1 30 秒版本
AI workflow discovery 不能只靠 PRD 或流程图, 因为 Agent 会参与判断、调用工具、等待人工、处理异常并产生跨系统副作用。我会用 EventStorming 先把 domain event、command、actor、policy、external system、hotspot、read model 和 time axis 摊开, 再决定 AI 是 assist、recommend、decide、act、monitor 还是 simulate。每个 AI 插入点都要追溯到 tool contract、policy gate、HITL、result event、exception path、compensation 和 eval trace, 这样才能同时支持产品发现、架构设计、上线评估和审计复盘。
10.2 2 分钟版本
我会把 AI EventStorming 当成一种 agent workflow discovery 方法, 而不是基础流程梳理。第一步不是问“AI 能做什么”, 而是把业务按时间轴还原成已发生的 domain events, 例如 PaymentDisputeOpened、MerchantEvidenceReceived、ProvisionalCreditApproved。然后识别每个事件前后的 command、actor、policy、external system、read model 和 hotspot。
在这个基础上, 我会给每个 AI 插入点定自治等级: assist 做摘要和证据整理, recommend 给下一步建议, decide 只放在低风险且规则明确的节点, act 必须走 tool gateway、policy gate、幂等和审批, monitor 用于 SLA 和异常, simulate 用于流程和政策变更评估。这样可以避免把政策判断、工具动作和人工责任全部塞进 prompt。
最后我会做 traceability。每条链路都要能从 domain event 追到 command、tool call、policy decision、HITL decision、result event、exception / compensation 和 eval case。比如支付争议里, AI 可以总结交易和证据、推荐补件或临时入账资格, 但临时入账必须由政策服务和人工审批控制, 工具调用要幂等, 异常要进入 manual repair 或 customer correction, 评估要覆盖证据遗漏、原因码错误和重复副作用。这样 AI workflow 才是可发现、可治理、可验证、可审计的。
10.3 Solution Architect 版本
从 Solution Architect 视角, 我会把 EventStorming 输出转成 agent workflow control architecture。Domain event 对应 event schema 和 workflow transition; command 对应 API operation 或 workflow task; actor 对应 IAM、agent identity 和 delegated authority; policy 对应 PDP / PEP、DMN 或 policy-as-code; external system 对应 tool gateway contract; hotspot 对应 eval case 和 control point; read model 对应 AI context pack、review evidence view 和 audit trace view。
关键设计不是让 Agent 直接访问所有系统, 而是让 Agent 通过受治理的 workflow 和 tool gateway 行动。每个写操作都有 idempotency key、side-effect ledger、policy decision id 和 result event。高影响动作必须进入 HITL state, 有 maker-checker、SLA、evidence packet 和 override reason。异常路径提前设计 retry、DLQ、manual repair、compensating command 和 audit note。上线门禁则把 hotspot-to-eval map、workflow simulation、tool contract test、policy regression 和 audit replay 一起纳入 release gate。
10.4 BA Lead 版本
从 BA Lead 视角, 我不会把 workshop 做成普通流程访谈。我会让业务、运营、风险、合规、架构、数据和系统 owner 围绕真实事件链协作, 把争议、例外和隐性规则暴露出来。我的重点是把“谁在什么时候基于什么证据做什么判断”说清楚, 并把 AI 的角色限制在明确边界内。
交付上, 我会输出 AI event storm board、agent workflow trace matrix、hotspot-to-eval map 和 compensation checklist。每个需求都不只写功能, 还写触发事件、命令、策略、证据、人工角色、异常、补偿和审计字段。这样开发能落到工具契约和状态机, 风险合规能看到控制点, 产品能衡量价值, 审计能复盘证据。对金融零售 AI 来说, 这比单纯写“AI 帮助处理案件”更接近可上线的业务架构。
10.5 常见追问
| 追问 | 回答要点 |
|---|---|
| EventStorming 和 BPMN 怎么配合 | EventStorming 先发现事实链、边界、热点和策略, BPMN 再把 TO-BE 流程编排成任务、网关、事件、异常和补偿。前者偏发现和共识, 后者偏执行契约。 |
| 如何避免 AI 变成黑箱流程节点 | 每个 AI 插入点都必须有 input evidence、output schema、policy gate、tool boundary、HITL decision、eval case 和 audit evidence。 |
| 哪些地方不适合 AI 自动决策 | 高影响、不可逆、监管敏感、证据不完整、政策冲突或公平性风险高的节点, 例如 AML alert 关闭、账户冻结、拒贷最终决定。 |
| Hotspot 如何转成 eval | 把 hotspot 改写为 failure scenario, 定义样本、指标、阈值、监控和 owner, 例如证据冲突、过期政策、重复副作用、低置信度误通过。 |
| 如何证明架构 traceability | 从客户结果或审计问题反向追溯到 event、command、actor、policy decision、tool call、HITL、result event、compensation 和 eval case。 |
11. 使用建议
把这份 playbook 用在 AI 产品发现时, 建议每次 workshop 只选一个端到端场景, 例如 payment dispute、AML alert investigation 或 credit memo drafting。不要一开始试图建全企业 agent 蓝图。先把一个流程的 event chain、hotspot、AI insertion、HITL、exception 和 eval trace 做深, 再把稳定模式沉淀为平台能力。
最小可交付版本:
| Day | 产出 |
|---|---|
| Day 1 | AI Event Storm Board: event chain、command、actor、policy、system、hotspot。 |
| Day 2 | AI insertion matrix + agent workflow trace matrix。 |
| Day 3 | Exception / compensation checklist + hotspot-to-eval map。 |
| Day 4 | Architecture traceability review: tool gateway、policy gate、HITL、audit、monitoring。 |
| Day 5 | Portfolio case write-up: 金融零售场景、关键取舍、风险控制、面试表达。 |
验收标准:
| 标准 | 合格表现 |
|---|---|
| Discovery quality | 业务事实、决策权、系统副作用和异常路径被显式化。 |
| AI boundary | 每个 AI 插入点都有自治等级和不可做边界。 |
| Control design | 高风险动作有 policy gate、HITL、tool contract 和 compensation。 |
| Eval readiness | Hotspot 能转成 scenario eval、monitor 和 release gate。 |
| Architecture traceability | 从事件链能追到架构组件、工具调用、审计证据和运行指标。 |