快照能告诉你现在是什么状态，但不能告诉你为什么到这里。对 AI agent 来说，这个缺口会直接影响审计、回放和补偿。
为什么 runtime 需要事件流
| 仅快照模式的问题 | 事件流能补什么 |
|---|---|
| 难以追踪状态迁移原因 | 每次迁移有因果事件 |
| 回放粒度粗 | 支持按事件重建路径 |
| 难以做增量审计 | 事件可直接用于审计链 |
event sourcing 不是替代快照，而是和快照共存。
推荐结构
- 事件流：append-only，记录事实
- 状态快照：加速读取，按需重建
- ledger：跨系统对账索引
三者分工清晰，才不会出现“日志像账本、账本像缓存”。
失败案例：只存终态导致争议无法复盘
某平台仅保留 run_status=completed，但客户质疑中间审批被跳过。由于没有审批事件链，团队无法证明流程是否按规则执行。后续补齐事件模型后，争议处理时间大幅缩短。
Checklist
- 关键状态迁移都有事件定义
- 事件包含 causationId 与 correlationId
- 快照可由事件重建校验
- 事件保留策略与合规要求一致
- replay 与审计基于事件链而非猜测
延伸阅读：
