Shared Memory：四种 Agent 写入架构
比较按 Key 单写者、乐观多写者 + CAS、事件日志 + 物化视图与 CRDT 复制记忆的拓扑、写入权、一致性与故障边界。
多个 Agent 共享读取同一份 memory，不代表它们都应该直接修改 canonical state。先固定 state owner、write boundary、read model 和 trust boundary，再讨论具体数据库。
有约束的设计问题
50 个 Agent 同时更新 10 万个 memory key。关键事实不能丢失，语义冲突必须可审计，p95 读延迟低于 150ms。canonical state 应该由谁拥有？
这个问题只比较 shared durable memory 的 write topology。短期/长期记忆分类、向量检索、prompt window 和 embedding model 属于相邻但不同的设计问题。
四种 topology signature
| 架构 | Topology signature | State owner | Write / read boundary |
|---|---|---|---|
| Per-key Single Writer | fan-in → key router → owner/actor → canonical memory → fan-out | 每个 key 的一个逻辑 owner | owner 内串行写；读者只读已提交状态 |
| Optimistic Multi-writer + CAS | writers → versioned store → commit 或 conflict loop | 条件写提交点 | writer 直写 expected version；冲突侧重读/重试 |
| Event Log + Materialized View | proposals → durable log → materializer → canonical view | append-only log 是 write SoT；view 是派生 | 写入与读取分离；读侧必须暴露 freshness |
| CRDT Replicated Memory | local replicas ↔ peer merge → converged view | 多个 replica 分布式拥有状态 | 本地写入；同步后最终收敛 |
Reducer 和 curator 是机制，不是第五、第六种拓扑。Reducer 可以位于单写者或 materializer 内，处理可机械合并的 typed delta；curator 或 human gate 用于 storage concurrency control 无法判断的语义与治理冲突。
统一评价轴
Per-key Single Writer
- Best for：需要强顺序的实体事实、账户状态和会话记忆。
- Trade-off：一致性边界清楚，但 hot key 会压住 owner mailbox。
- Scaling unit：memory key / actor partition。
- Failure boundary：单个 key owner 与 mailbox。
- Consistency / latency / cost：强顺序，多一跳，中等运维成本。
Optimistic Multi-writer + CAS
- Best for：低冲突、短事务、简单字段更新。
- Trade-off：路径最短；冲突率升高时出现重读、重试和业务合并。
- Scaling unit：store partition / record key。
- Failure boundary：冲突 record 与发起重试的 writers。
- Consistency / latency / cost：提交点强一致；低冲突时延迟低，热点重试成本陡升。
Event Log + Materialized View
- Best for：审计、回放、语义治理与可重建 read model。
- Trade-off：证据最完整，但引入 eventual consistency、projection version 和 backlog。
- Scaling unit：event partition + materializer consumer group。
- Failure boundary：单个 partition 的 materializer 与 view freshness。
- Consistency / latency / cost：日志内有序、视图最终一致；延迟和存储成本较高。
CRDT Replicated Memory
- Best for：离线协作，以及 set、counter、presence 等可证明 merge 的数据。
- Trade-off：本地高可用换来受限数据类型、同步元数据与 tombstone 管理。
- Scaling unit：replica / document / CRDT key。
- Failure boundary：单个 replica 或同步链路；其他 replica 可以继续写。
- Consistency / latency / cost：最终收敛、本地低延迟；同步和 tombstone 成本持续累积。
命名故障与恢复
| 架构 | Named failure | Blast radius | Data risk | Recovery |
|---|---|---|---|---|
| Single Writer | Hot-key owner stall | 该 key 停写，其他 partition 继续 | 非持久 mailbox 中的未提交 intent | fence key，恢复持久 mailbox/log，重新选主并按 commit 顺序重放 |
| CAS | Retry storm | 该 record 的 writers 与 partition capacity | CAS 防 lost update，但不判断自然语言事实真伪 | backoff + jitter + retry budget；热点升级为单写者或 curator |
| Event Log | Materializer backlog | 对应 read model 变旧，append 继续 | 用户基于 stale view 决策 | 暴露 freshness watermark，扩容 consumer，从 checkpoint 幂等重放 |
| CRDT | Tombstone growth | 所有 replica 的同步与存储成本上升 | 过早清理可能让删除值复活 | version vector 确认全局可见后压缩，隔离长期离线 replica，再生成受控 snapshot |
面试中怎样解释选择
先说主导约束，再指向拓扑中的 owner 和 commit point。随后沿 write path、event path、read path 逐段解释，最后用一个命名故障证明你理解 blast radius 和恢复，而不是只会背产品名。
如果选择 CAS，要明确“避免覆盖写”不等于“语义正确”。如果选择 Event Log，要声明 log 才是 write SoT，materialized view 可以重建。选择 CRDT 时必须指出具体 data type 的 merge rule；CRDT 能保证收敛，不能裁决两句自然语言谁更真实。