AI EventStorming：Agent 工作流发现
AI EventStorming 是用业务事件链发现 AI 应该介入哪里、承担什么任务、调用什么工具、何时交给人、失败后如何补偿。它的价值不是把流程画得更漂亮，而是把 agent 工作流中的状态变化、决策点、外部系统、副作用、异常和证据显性化。
AI EventStorming / Agent Workflow Discovery 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| EventStorming | https://www.eventstorming.com/ | 参考事件风暴的事件、时间线、协作建模和复杂业务探索 |
| Domain Language / DDD | https://www.domainlanguage.com/ddd/ | 将事件风暴与 bounded context、domain event、ubiquitous language 连接 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将 AI workflow 的风险、评估和控制连接到治理闭环 |
核心导读
AI EventStorming 是用业务事件链发现 AI 应该介入哪里、承担什么任务、调用什么工具、何时交给人、失败后如何补偿。它的价值不是把流程画得更漂亮，而是把 agent 工作流中的状态变化、决策点、外部系统、副作用、异常和证据显性化。
Agent 不是一个“更聪明的按钮”。只要它会观察、推理、调用工具或触发流程，就必须被放回业务事件序列中评估：它改变了哪个状态，依赖哪些前置条件，失败会造成什么业务后果，哪些证据能证明它做对了。
问题定义
AI workflow 常见设计缺口：
- 只描述 happy path，没有异常、回滚、升级和补偿。
- 只写“AI 生成建议”，没有说明建议被采纳后触发哪些业务事件。
- tool calling 被当作技术集成，忽略权限、幂等、状态一致性和审计。
- 人工审核被写成一个泛化节点，没有队列、SLA、责任和反馈闭环。
- eval 用例与真实事件链脱节，无法覆盖流程中的关键失败。
EventStorming 要回答的问题：
| 建模问题 | AI 设计含义 |
|---|---|
| 发生了什么业务事件 | AI 输入和输出应绑定哪些状态变化 |
| 谁触发命令 | 用户、系统、agent、外部事件各自权限不同 |
| 哪些规则决定下一步 | policy、eligibility、risk score、confidence threshold |
| 哪些系统参与 | core banking、CRM、case management、payment rail、knowledge base |
| 哪些热点不确定 | 需要 eval、控制、人工复核或架构实验 |
核心原理与方法
EventStorming 到 AI workflow 的映射：
| EventStorming 元素 | AI workflow 解释 |
|---|---|
| Domain Event | 已发生且值得记录的业务状态变化 |
| Command | 用户、系统或 agent 试图改变状态的动作 |
| Actor | 客户、员工、agent、scheduler、外部系统 |
| Policy | 决定何时触发 AI、何时转人工、何时阻断 |
| External System | 被读取或调用的系统、模型、供应商和工具 |
| Read Model | AI 需要观察的上下文视图 |
| Hotspot | 语义不清、风险高、数据缺口、责任不明的点 |
方法步骤：
- 从真实业务事件开始，而不是从 AI 功能开始。
- 沿时间线标出命令、事件、政策、外部系统和人工动作。
- 标记 AI 可介入位置：观察、摘要、建议、分类、决策支持、执行、监控。
- 对每个 AI 介入点定义输入、输出、工具、状态变化、失败模式和证据。
- 将 hotspot 转化为 eval case、control requirement 或 architecture spike。
系统与架构模型
AI agent workflow 的事件架构可以表示为：
Business Event Stream
-> Context Assembly
-> AI Task / Agent Policy
-> Tool Invocation or Recommendation
-> Human Decision / Automated Action
-> Domain Event
-> Monitoring / Feedback / Compensation
每个 agent step 都应有工作流契约：
| 字段 | 说明 |
|---|---|
| Trigger Event | 触发 AI 的业务事件或状态 |
| Context Inputs | 可读取的数据、知识、历史事件和权限 |
| Task Type | summarize、classify、recommend、draft、decide、act |
| Tool Scope | 允许调用的工具、参数、幂等键和禁止动作 |
| Decision Policy | confidence threshold、risk tier、human approval、escalation |
| Output Event | AI 结果如何进入业务事件流 |
| Evidence | trace、source、tool log、human override、eval label |
| Compensation | 工具失败、错误建议或客户影响后的修复动作 |
一个成熟 agent workflow 不只包含 orchestration，还包含 state management：
- pending：等待上下文完整。
- suggested：AI 生成建议但未改变核心状态。
- approved：人工确认或策略允许执行。
- executed：工具调用成功并产生 domain event。
- escalated：进入人工队列。
- compensated：执行补偿动作或撤回影响。
关键机制与取舍
| 取舍 | 设计判断 |
|---|---|
| AI 建议 vs AI 执行 | 低影响、可逆动作可自动执行；高影响、不可逆动作需人工确认 |
| 同步体验 vs 异步控制 | 客户交互追求低延迟，但风险判断和工具执行可异步处理 |
| 单 agent vs 多 step workflow | 简单任务可单步，涉及状态变化和多个系统时应显式编排 |
| 全量上下文 vs 最小必要上下文 | 上下文越多推理越强，但隐私、成本和误用风险更高 |
| 错误重试 vs 补偿流程 | 技术失败可重试，业务副作用失败必须补偿和审计 |
关键机制：
- Event envelope：所有 AI 输出都包装为结构化事件，而不是散落文本。
- Idempotency key：工具调用必须可防重复执行。
- Policy gate：高风险状态变化经过策略门控。
- Human queue：人工接管要有队列、SLA、任务上下文和反馈记录。
- Failure taxonomy：把失败分为检索失败、推理失败、规则失败、工具失败、流程失败。
证据与控制
EventStorming 产生的 hotspot 应直接进入控制和评测。
| Hotspot | 转化结果 |
|---|---|
| 概念不清 | ubiquitous language、semantic eval |
| 外部系统副作用 | tool contract、权限控制、幂等测试 |
| 人工责任不明 | decision policy、approval trace、queue metric |
| 异常路径缺失 | compensation workflow、incident playbook |
| 数据不完整 | context readiness check、fallback behavior |
工作流证据要能重建每次 agent 行动：
| Evidence | 用途 |
|---|---|
| Event trace | 证明事件顺序、触发条件和状态变化 |
| Prompt/context record | 解释 AI 当时看到了什么 |
| Source/tool log | 证明知识来源和外部动作 |
| Policy decision | 解释为什么自动执行、拒绝或转人工 |
| Human override | 捕捉模型失败和业务偏好 |
| Compensation record | 证明错误影响已被修复 |
AI 产品与金融零售场景
以支付争议处理 agent 为例：
Transaction Posted
-> Customer Dispute Submitted
-> Case Created
-> AI Summarizes Evidence
-> AI Classifies Dispute Type
-> Policy Determines Required Documents
-> Agent Drafts Customer Response
-> Human Approves / Requests More Info
-> Case Status Updated
-> Resolution Communicated
关键设计：
| 事件点 | AI 介入 | 控制 |
|---|---|---|
| dispute submitted | 摘要客户叙述和交易事实 | 不生成责任结论 |
| evidence collected | 检查材料完整性 | 缺失材料转人工或请求补充 |
| dispute classified | 建议争议类型 | 低置信度进入人工队列 |
| response drafted | 生成回复草稿 | 必须引用政策和 case facts |
| status update | 可执行低风险状态更新 | 高影响状态需人工确认 |
真实取舍：完全自动化可以缩短处理时间，但争议处理涉及客户权益和监管时限。更稳健的设计是让 AI 加速证据整理、分类和草拟，将赔付、拒付、监管投诉关闭等动作保留为人工确认或规则驱动。
反模式
- 从“我要一个 agent”开始设计，而不是从业务事件和状态变化开始。
- 把人工审核当作一句话，没有队列、SLA、输入上下文和反馈机制。
- 工具调用缺少幂等、权限、补偿和审计。
- eval 只测单轮回答，不测多事件链中的状态一致性。
- 所有异常都转人工，导致运营队列不可控。
- 把 workflow 编排藏在 prompt 里，无法测试和治理。
最终心智模型
AI EventStorming 是把 agent 从“智能对话”还原为业务事件系统中的参与者。每个 AI 行动都应有触发事件、上下文、策略、工具边界、输出事件、证据和补偿。这样 AI workflow 才能被设计、测试、运营、审计和持续改进。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。