事件溯源（event sourcing） 产品与架构
别名：
事件溯源
一种存储模型：存「怎么一步步变成现在的样子」而非「现在的样子」。每次发生的事（用户发了消息、Agent 回复了、调用了工具）是一条事件，事件只能追加、永不更新删除；需要当前状态时把事件按顺序重放、由事件序列折叠得出。Agent 场景选它的三个理由：审计调试、崩溃安全、断线恢复的前置。
它是什么
事件溯源（event sourcing）是一种存储模型：存「怎么一步步变成现在的样子」而非「现在的样子」。每次发生的事（用户发了消息、Agent 回复了、调用了工具）是一条事件，事件只能追加（append-only）、永不更新删除；需要当前状态时把事件按顺序重放、由事件序列折叠得出——银行流水、账本都是这个思路：余额不存，从每一笔交易算出来。
Agent 场景选它的三个理由
与「消息快照」（每轮覆盖写当前状态）对照，事件溯源有无法拒绝的三条：
- 审计与调试：Agent 的行为链条（用户说了什么 → 模型决定调工具 → 工具返回什么 → 模型怎么总结）天然是一条事件流，「回放这段对话」比「看一条被覆盖的状态」有用得多；
- 崩溃安全：追加（INSERT）远比覆盖（UPDATE）容易做到崩溃一致，配合数据库日志机制（WAL），已提交事件在进程崩溃后一个不少；
- 断线恢复的前置：第 16 章的「事件序号 + 重连续传」直接建立在「事件有全局单调序号、可分段重放」之上。
代价与对策
读当前状态需要重放（或维护投影表）；事件不断累积需要快照/归档兜底。本章的立场：会话层用事件溯源做事实源，再用投影表把读路径做快——两头的好处都拿（第 10 章）。事件序列的具体形态见 event-log。