# LiveDemand: OPC 跨 Agent 记忆共享系统

> 来源：内部架构分析 + 市场调研（AutoGen/CrewAI/mem0/LangChain/Letta）
> 搜集时间：2026-04-24
> 调研者：小研（xiaoyan）
> 方法：OpenClaw 源码/配置分析 + 行业多 Agent 记忆方案横向对比

---

## 一、问题背景（用户痛点）

OPC 有 8 个专职 Agent（小策、小研、小码、小质、小维、小文、小数、小推），通过 Telegram 群 + `sessions_send` 协作。
当前架构中，每个 Agent 完全隔离运行，共享记忆能力为零。

### 真实痛点（从实际运营提炼）

**P1 — 调研成果无法复用（最痛）**
- 小研做完 `restaurant-food-safety-compliance` 调研，小策、小码完全不知道
- 每次跨 Agent 协作，需要人工在消息里重复粘贴路径、决策、背景
- 小码接手任务时不知道 PRD 的技术选型原因，可能重复踩坑

**P2 — 项目上下文重建成本高**
- LegalFlow V2 涉及小策(调度)、小研(PRD)、小码(实现)、小质(测试)、小维(部署)
- 每个 Agent 看到的只是自己负责的那一段，没有完整项目视图
- Agent 重启后历史记忆归零，必须靠人工在消息里重新说明背景

**P3 — 决策无法追溯**
- 为什么选 Next.js 而不是 Vue？为什么用 Supabase 而不是 PostgreSQL？
- 这类架构决策分散在各 Agent 的 session 里，无法被其他 Agent 查阅
- 新任务可能与旧决策冲突，但没有机制发现

**P4 — sessions_send 是唯一跨 Agent 通道，无法承载知识**
- `sessions_send` 是消息传递，不是知识存储
- 发出去的消息不能被结构化检索
- 上下文窗口有限，每次协作都要重新提供完整背景

---

## 二、OpenClaw 现有工具盘点

通过阅读源码和配置文件，整理当前 OpenClaw 跨 Agent 可用能力：

### 2.1 已有工具

| 工具 | 用途 | 跨 Agent 能力 |
|------|------|---------------|
| `memory_get` | 读当前 Agent 的 SQLite memory | ❌ 仅限当前 Agent |
| `memory_search` | 语义搜索当前 Agent 的 memory | ❌ 仅限当前 Agent |
| `sessions_history` | 读取另一个 session 的历史记录 | ✅ 可跨 Agent 读取 |
| `sessions_list` | 列出所有 session | ✅ 可见全局 |
| `sessions_send` | 向另一 Agent 发消息 | ✅ 单向消息传递 |
| `sessions_spawn` | 启动新的子 Agent | ✅ 可传递初始上下文 |

### 2.2 SQLite 分析

```
/root/.openclaw/memory/
├── main.sqlite     (68KB — main agent)
└── xiaoma.sqlite   (68KB — 小码 agent)
```

- 每个 Agent 有独立 SQLite，互不共享
- 目前只有 main 和 xiaoma 建立了 memory 库（其他 Agent 尚未建立）
- `memory_get`/`memory_search` 只能访问当前 Agent 的 SQLite

### 2.3 共享文件系统（关键发现）

所有 Agent 都在同一台服务器上运行，共享文件系统：

```
/home/ubuntu/OPC/          ← 所有 Agent 均可读写
/root/.openclaw/workspace-*/   ← 各 Agent 私有工作区
```

**这是最大的天然优势：共享文件系统 = 零成本共享内存总线**

### 2.4 sessions_history 潜力分析

```python
sessions_history(sessionKey="xiaoma", limit=50)
# 可以读取小码最近50条对话记录
# 但：无结构化、无语义搜索、成本高（需读大量原始对话）
```

结论：`sessions_history` 适合做"最近做了什么"查询，不适合做结构化知识检索。

---

## 三、市场主流方案对比

### 3.1 mem0（推荐参考）

- **定位**：专为 AI Agent 的记忆层，支持用户/Agent/会话级记忆
- **核心能力**：向量 + KV + 图数据库三合一；自动提取记忆、去重、更新
- **部署**：可自托管（mem0 OSS）或云服务（$0.01/1k ops）
- **适配性**：支持任意 LLM，有 Python SDK
- **缺点**：需要额外部署服务；OPC 目前架构是 shell 命令/文件操作，集成成本较高

### 3.2 AutoGen SharedMemory

- **定位**：微软 AutoGen 的共享记忆模块
- **核心能力**：Agent 间共享同一个 memory store；支持 ChromaDB 向量检索
- **适配性**：紧耦合 AutoGen 框架，OPC 用的是 OpenClaw，不直接适用
- **参考价值**：设计思路——"所有 Agent 写入同一个 namespace 的 vector store"

### 3.3 CrewAI Memory

- **定位**：CrewAI 框架内置记忆系统
- **类型**：Short-term（RAG）、Long-term（SQLite）、Entity memory、Contextual memory
- **适配性**：同样是框架级解决方案，不适合直接移植
- **参考价值**：Entity memory 思路——按实体（项目名、决策、人名）建立索引

### 3.4 LangChain Agent Memory

- **定位**：ConversationBufferMemory、VectorStoreRetrieverMemory 等
- **适配性**：需要 Python 环境和 LangChain 依赖
- **参考价值**：分层记忆设计（短期 buffer + 长期 vector）

### 3.5 Letta（前身 MemGPT）

- **定位**：最成熟的 Agent 持久记忆框架
- **核心能力**：in-context memory + archival memory + recall memory 三层架构
- **亮点**：Agent 自主决定何时"存档"记忆、何时检索
- **适配性**：独立服务，API 接入，可与任意 Agent 框架配合
- **成本**：可自托管，依赖 PostgreSQL + pgvector

### 3.6 方案对比评分

| 方案 | 实施复杂度 | 与 OpenClaw 适配 | 延迟 | 成本 | 可靠性 | 总分 |
|------|-----------|-----------------|------|------|--------|------|
| **共享文件系统（OPC-Native）** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | **25/25** |
| mem0 自托管 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 19/25 |
| Letta 自托管 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | 15/25 |
| sessions_history 检索 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 19/25 |
| AutoGen/CrewAI 迁移 | ⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | 11/25 |

---

## 四、痛点聚类与频率分析

基于 OPC 8 个 Agent 实际运营4周的问题观察：

### Cluster A：项目上下文丢失（最高频）
- 频率：每个跨 Agent 任务都会遇到
- 典型场景：小策分配任务给小码，需要在消息里完整粘贴 PRD 路径 + 技术栈 + 注意事项
- 影响：每次协作额外 2-5 分钟的"背景传递"时间

### Cluster B：决策无法追溯（中频）
- 频率：每周 2-3 次
- 典型场景：小码重新选择了已经被否决的技术方案
- 影响：返工成本，浪费 LLM token

### Cluster C：调研成果重复生产（低频但高成本）
- 频率：每月 1-2 次
- 典型场景：同一个技术问题被多个 Agent 各自调研一遍
- 影响：直接浪费 $5-20 的 LLM API 成本

### Cluster D：Agent 重启后失忆（结构性问题）
- 频率：每次 Agent 重启
- 典型场景：新 session 的 Agent 不知道上周做了什么
- 影响：需要人工重新 brief，或靠 MEMORY.md 手工维护

---

## 五、需求优先级评估

| 需求 | 用户价值 | 实施难度 | 频率 | 评级 |
|------|---------|---------|------|------|
| 共享项目上下文文件 | 高 | 低 | 极高 | **BUILD** |
| 跨 Agent 决策记录库 | 高 | 低 | 高 | **BUILD** |
| Agent 间知识检索协议 | 中 | 中 | 中 | **BUILD** |
| mem0 向量检索集成 | 中 | 高 | 低 | REVIEW |
| 自动记忆提取（LLM驱动） | 低 | 高 | 低 | SKIP |
| 全局 Agent 知识图谱 | 低 | 极高 | 低 | SKIP |

---

## 六、核心洞察

1. **OPC 不需要向量数据库** — 项目数量少（<20个），关键词检索 + 文件组织足够
2. **共享文件系统是杀手锏** — 所有 Agent 在同一服务器，`/home/ubuntu/OPC/` 天然共享
3. **结构化 > 语义化** — 按项目 slug 组织，比向量检索更可靠、更快、成本为零
4. **写入标准 > 读取技术** — 关键是建立"每个 Agent 完成任务必须写记忆"的标准协议
5. **最小可行记忆**：一个 `context/` 目录 + 标准 Markdown 格式 + Agent 读写约定