AI Infra：记忆有3种模式，需要“事实”来统一

一、Memory Ownership

这里的 ownership 指的更多是谁在使用和加工记忆

• Agent-owned，需要卓越的技术产品
• User-owned，需要优秀的C端商业服务，软硬一体
• Networked，是价值潜力最高的 Infra 层，需要权限控制、冲突解决、版本管理等能力

二、3种模式详述

三、记忆模式的边界

3.1 Agent-owned

本质：短期工作记忆 + 私有执行上下文

实际作用：

* 当前任务状态（plan / scratchpad）
* 临时上下文（recent history）
* tool 调用状态

Agent执行需要：强一致（不能乱），低延迟（不能远程依赖）

这些记忆应该隔离，不需要共享，更应该是 runtime 内部组件，因为

* 强耦合具体任务
* 语义不稳定（随时变化）
* 噪音极高

3.2 User-owned

本质：用户长期状态（User Model），保存着用户的偏好（明确 + 隐式）、历史行为、个人知识、私有文件

User Memory =
   Event（行为流）
 + Semantic（结构化偏好）
 + Latent（embedding）

核心价值：让不同 Agent 对“同一个人”形成一致认知
挑战：权限（谁能读写）、用户控制（可删除/可迁移）、数据污染（Agent写错怎么办）

3.3 Networked

本质：共享世界模型（Shared World State），或是内置于模型的“常识”

* 公共知识（结构化）
* 实体关系（graph）
* 行为模式（aggregate）
* 工具状态（API / system）

实现共享有3种路径：

四、在3种记忆模式之外关键

记忆，是对事实的抽象，需要“事实”来约束

Agent-owned / User-owned / Networked 都是“状态视图”，而Event 是“事实源头”

* Agent memory = event 的局部投影
* User memory = event 的长期聚合
* Network memory = 多用户 event 的汇总

如果缺少事实，整个系统无法回溯、无法纠错、无法重建状态、无法做跨Agent同步，更真实的结构是：

Event Layer（唯一真实来源）
   ↓
派生：
   ├─ Agent memory（短期）
   ├─ User memory（长期）
   └─ Network memory（共享）

4.1 从产品市场机会来说，Event Layer 上限更高

• Agent-owned：太碎、没有网络效应
• User-owned：有用户锁定、有迁移成本、但是增长慢
• Networked：网络效应强：极难中立（平台会吞噬）
• Event Layer：所有层的基础、可做标准（log schema）、可做基础设施

4.2 事件/事实层与3种记忆的架构

4.2.1 架构一：Event-Sourced Hub（事件中心化）

        Agents / Apps / Sensors
                 ↓
            Event API（唯一入口）
                 ↓
          Event Store（append-only）
                 ↓
     ┌───────────┼───────────┐
     ↓           ↓           ↓
Agent Memory  User Memory  Network Memory
（projection） （projection） （projection）

交互机制

写入（统一入口）：不允许绕过事件层直接写 memory

• 所有输入统一进入 Event API

• 包括：

  • 多模态输入
  • Agent 行为
  • 工具调用结果

派生（异步投影）

读取（双通道）

• Agent：

  • 读 Agent Memory（低延迟）
  • 必要时回溯 Event

• 模型（latent）：

  • 从 Event → embedding → 检索

特点

优点：

• 单一事实源（source of truth）
• 可 replay / 可调试 / 可纠错
• 天然支持多 Agent 协同

缺点：

• 延迟增加（需要投影）
• 架构复杂度高
• 写入路径需要强治理

适用场景：

• 多 Agent 系统
• 中立记忆层（你当前方向）
• 需要强可追溯性

4.2.2 架构二：Dual-Write Mesh（双写网状结构）

        Agents / Apps
           ↓     ↓
     ┌─────┴─────┐
     ↓           ↓
Event Store   Memory API
                ↓
     ┌──────────┼──────────┐
     ↓          ↓          ↓
Agent Mem   User Mem   Network Mem

交互机制

写入（双路径）：Event 不再是唯一入口

每个输入：

• 同时写入：

  • Event Store（日志）
  • Memory API（结构化 or embedding）

Memory 内部处理

• 自动分流：

  • embedding → latent store
  • schema → semantic store
• 按策略写入三类 memory

同步机制

• 定期：

  • 从 Event 校验 Memory
  • 修复不一致

特点

优点：

• 延迟低（直接可用）
• 实现简单（接近现有 RAG 架构）
• 易于渐进式演化

缺点：

• 可能出现不一致（event vs memory）
• replay 能力弱
• 写入逻辑分散（难治理）

适用场景：

• MVP 阶段
• 单 Agent 或弱协同系统
• 从“搜索 → Agent”过渡期

4.2.3 架构三：On-demand Projection（按需投影）

        所有输入
           ↓
      Event Store（唯一存储）
           ↓
   （按需生成 memory）
           ↓
   ┌───────────────┐
   ↓               ↓
Agent Runtime   Query Engine
   ↓               ↓
临时 Memory     User / Network View

交互机制

写入：

• 只写 Event Store
• 不预构建任何 memory

读取（核心），memory 是“临时生成的视图”

当 Agent 或用户请求：

• 动态：

  • 从 Event 检索

  • 实时构建：

    • embedding
    • 结构化信息
    • context window

缓存（可选）

• 高频 query → 缓存为：

  • user memory
  • agent memory

特点

优点：

• 极简（单一存储）
• 永远一致（没有状态分叉）
• 灵活（不同 Agent 可生成不同视图）

缺点：

• 延迟高（每次都要构建）
• 成本高（重复计算）
• 工程难度大（实时结构化）

适用场景：

• early research
• 强依赖 latent world model
• 低 QPS / 高价值任务

4.2.4 三种架构对比

三种架构背后真正的差别是：谁控制“写入语义”，想要增加价值，必须控制写入入口（Event API）

标签：ai, agent