事件溯源（Event Sourcing）是一种不保存"当前状态"、只保存"改变状态的事件"的软件架构模式。系统现在长什么样，是把历史上发生过的所有事件按顺序重放一遍算出来的。
打个比方：银行不会只存一个"余额"数字。它记的是流水——工资入账、买菜扣款、利息结算、转账冲正。余额只是这些流水加总的结果。想查上周二为什么少了 50 块？翻流水。想改余额？不能直接改，只能补一笔"冲正"或"调整"事件。事件溯源就是给系统建这样一本流水账：只追加（append-only），历史事件不改、不删；要改变状态，就再追加一个新事件。
和容易混淆的概念对比：
| 概念 | 主要存什么 | 能不能改历史 | 典型用途 |
|---|---|---|---|
| 传统增删改查（CRUD） | 当前状态，如一条用户记录 | 直接覆盖 | 快速查当前 |
| 审计日志（Audit Log） | 当前状态，另加一份日志 | 日志通常只读，状态是主存储 | 事后追责 |
| 事件溯源 | 事件流本身 | 只追加，不改不删 | 重建状态、回放、审计 |
关键差别：审计日志是"状态为主、日志为辅"；事件溯源是"事件为主、状态是算出来的缓存"。
对 AI 从业者来说，这套思路特别适合长跑智能体（long-running agent）。一个智能体可能连续跑几小时甚至几天：收到目标、生成计划、调用搜索、读文件、写代码、等人类确认、重试失败步骤。进程一旦崩溃或上下文丢失，传统做法很难说清"它刚才到底做到哪了"。把每一步都记成事件——收到目标、决定调用某工具、工具返回、文件被修改、用户反馈——重启后从头重放，或从最近一次状态快照（snapshot）接着重放，状态就能重建，且不丢历史。
回放事故也方便。智能体闯祸时，事件流就是一部按时间排序的"事故录像"：能看出它在第几步被哪条工具返回带偏，而不是对着一堆散落日志猜。审计同样直接：谁在什么时候批准了什么操作、智能体自己决定了什么，全在追加流里，适合合规复盘。
普通人其实天天见这种思路：手机账单、外卖订单状态、聊天记录，都是流水账。客服能查到你三个月前改过收货地址，不是靠一个"当前地址"字段，而是因为在某个时间点追加了一条"地址变更"事件。
状态是瞬时的，事件才是历史。