在异步系统中，即使只有一个进程可能失败，也不存在一个确定性算法能保证共识达成。
这意味着：你无法完美地检测一个进程是"慢了"还是"挂了"。所有分布式算法都在这个约束下做取舍。
一个分布式数据系统不可能同时满足以下三个保证：
但现实中 P 是必选项（网络分区一定会发生），所以真正的选择是：CP（如 etcd/ZooKeeper，分区时拒绝写入）vs AP（如 Cassandra/DynamoDB，分区时允许不一致写入）。
分布式系统的核心难题可以归纳为一句话：在不完美的网络上，如何让多个独立的进程对"真相"达成一致？ 网络会延迟、消息会丢失、时钟会漂移、机器会宕机。每一个看似简单的操作——"写入一个值"、"选一个 Leader"、"同步一段记忆"——在分布式环境下都变成了需要精心设计的难题。
如何让一组节点就某个值达成一致？这是分布式系统最根本的问题。Leader Election、Log Replication、分布式锁——都归结为共识。代表算法：Raft、Paxos、Zab。
当数据被复制到多个节点，并发修改如何处理？"最后写入胜"（LWW）不是万能药。CRDT 提供了数学上保证收敛的方案。代表：Yjs、Automerge。
不存当前状态，存所有事件。从"是什么"到"怎么来的"的思维转变。审计、回溯、时间旅行——都因事件而成为可能。代表：KurrentDB（原 EventStoreDB）、LangGraph Checkpoint。
分布式系统中没有全局时钟。"同时发生"是没有意义的。Lamport 时钟、向量时钟、混合逻辑时钟（HLC）——给事件排序的不同方案。因果关系是唯一可靠的顺序。
跨服务操作如何保证原子性？2PC 太慢，Saga 更适合微服务。TCC 是折中。工具调用链的部分失败——本质上是分布式事务问题。
分布式系统出了问题怎么定位？Metrics/Logs/Traces 三支柱。OpenTelemetry 统一标准。一个请求跨5个服务的追踪链路是基本需求。
Leslie Lamport 发表 "Time, Clocks, and the Ordering of Events"，奠定了分布式系统中事件排序的理论基础
Fischer, Lynch, Paterson 证明异步系统中确定性共识不可能，推动了随机化算法和超时机制的发展
Lamport 提出 Paxos 共识算法（虽 1998 年才正式发表），成为工业界最广泛使用的共识协议基础
Eric Brewer 提出 CAP 猜想，2002 年由 Gilbert 和 Lynch 证明。塑造了此后 20 年分布式数据库的设计方向
Amazon 发表 Dynamo 论文，AP 系统的标杆。向量时钟 + 一致性哈希 + Gossip，影响了 Cassandra、Riak 等
Shapiro 等人正式定义 CRDT（Conflict-free Replicated Data Type），为无冲突复制提供了数学基础
Ongaro 和 Ousterhout 发表 "In Search of an Understandable Consensus Algorithm"，以可理解性为目标，成为 Paxos 的实用替代
CoreOS 发布 etcd v2，Kubernetes 选择 etcd 作为状态存储，Raft 算法进入大规模生产验证
Kevin Jahns 发布 Yjs，高性能 CRDT 实现库，Yata 结构使实时协作编辑成为可能，npm 周下载量超 90 万
Martin Kleppmann 团队推出 Automerge，JSON-like CRDT，用于去中心化数据同步。在 Isabelle 中形式化验证正确性
LangGraph 引入 Checkpoint 机制，Agent 的状态以 Event Sourcing 方式持久化，支持时间旅行调试和状态回溯
EventStoreDB 更名为 KurrentDB，50M+ 下载，F500 企业部署，微秒级延迟，成为 Event Sourcing 的首选数据库
| 取舍维度 | 选项 A | 选项 B | 代表系统 | Agent 中的映射 |
|---|---|---|---|---|
| 一致性 vs 可用性 | CP：分区时拒绝写入 | AP：分区时允许不一致 | CP: etcd, ZooKeeper / AP: Dynamo, Cassandra | Agent 记忆同步：强一致 vs 最终一致 |
| 共识算法 | Paxos：更通用，更难理解 | Raft：更易理解，足够通用 | Paxos: Chubby / Raft: etcd, Consul | 多 Agent 协调："下一步做什么"的共识 |
| 冲突解决 | OT：需要中心化服务器 | CRDT：去中心化，数学保证收敛 | OT: Google Docs / CRDT: Yjs, Automerge | Agent 记忆合并：并发修改不冲突 |
| 状态存储 | CRUD：存当前状态 | Event Sourcing：存所有事件 | CRUD: 绝大多数 / ES: KurrentDB, Kafka | Agent Checkpoint：状态快照 vs 事件日志 |
| 事务模型 | 2PC：强一致，但阻塞 | Saga：最终一致，补偿回滚 | 2PC: XA / Saga: 微服务编排 | 工具调用链：全部成功 vs 部分失败补偿 |
| 时间模型 | 物理时钟：NTP 同步 | 逻辑时钟：Lamport/向量时钟 | 物理: Spanner TrueTime / 逻辑: Dynamo | Agent 事件排序：因果顺序优先 |
当多个 Agent 需要协调"谁做什么"时——这正是共识问题。选一个 Leader Agent 分配任务，或者用 Raft 让一组 Agent 就任务分配达成一致。AutoGen 的 GroupChat 本质上是一个弱共识协议。
多个 Agent 实例可能同时修改共享记忆。如何保证合并后一致？CRDT 提供了数学保证。如果用 OT，你需要中心化服务器——但 Agent 常常在边缘运行（手机、本地），中心化不可用。
"搜索 web → 提取内容 → 生成摘要 → 发送消息"——如果中间步骤失败怎么办？这正是 Saga 模式要解决的问题。每个步骤需要补偿操作（或至少要回滚状态）。
一个用户请求可能触发多个 Agent，每个 Agent 调用多个工具。要理解整个调用链，你需要分布式追踪——就像微服务中的 Jaeger/Zipkin，但对象是 Agent 和工具。
很多 Agent 架构的问题，分布式系统领域已经有了成熟的解法。问题只是：你是否意识到这个映射关系？
如果理解了 Agent 系统就是分布式系统，你会发现：
分布式系统理论如何指导 Agent 架构选择：
agents/ 知识库
从 SaaS 视角理解分布式系统的实际应用：
saas/ 知识库
Ongaro & Ousterhout, 2014. Raft 论文。理解分布式共识的最佳入口。
raft.github.io/raft.pdf
Leslie Lamport, 1978. 分布式系统中最被引用的论文。偏序关系和因果性的数学基础。
DeCandia et al., 2007. AP 系统的工程实践标杆。最终一致性的经典案例。
Shapiro, Preguiça, Baquero, Zawirski, 2011. CRDT 的奠基论文。
crdt.tech
Martin Fowler, 2005. Event Sourcing 模式的经典描述。
martinfowler.com
交互式 Raft 可视化，5个节点的选举和日志复制动画。
The Secret Lives of Data