Agent 记忆方案对照
比较口径
下表只描述公开产品的调用边界、治理方式和工程取舍，不给出市场排名，也不暗示某个方案在所有场景下更好。实际效果应使用相同数据、模型和 token 预算单独验证。
属性矩阵
符号含义：◎ 主要优势；○ 可以做到，但需要应用配置或编排；△ 存在明显取舍；— 不是该方案的重点。这里比较的是产品边界，不是未经统一数据集验证的准确率排名。
| 属性 | Turing LTM | Mem0 | Zep | AWS AgentCore Memory | 阿里云百炼 Memory | 腾讯云数据库 Agent Memory |
|---|---|---|---|---|---|---|
| Turing 项目 / Environment 治理 | ◎ | △ | ○ | — | △ | △ |
| API、Managed Chat、CLI + Skills 一致接入 | ◎ | △ | ○ | ○ | ○ | ○ |
| 异步派生与来源追溯 | ◎ | ○ | ○ | ◎ | ○ | ○ |
| 直接修改 / 删除派生记忆 | △ | ◎ | ○ | △ | ○ | ○ |
| 自托管与存储可替换性 | — | ◎ | △ | — | — | — |
| Agent 框架内的细粒度编排 | ○ | ○ | ○ | ○ | ○ | ○ |
| 托管运维与平台级权限 | ◎ | ○ | ◎ | ◎ | ◎ | ◎ |
| 多云 / 厂商独立性 | ○ | ◎ | ○ | — | — | — |
Turing LTM 的主要特征
- 平台治理：Project、Environment、Space、Actor 和 shared facts 形成明确的数据边界，不依赖业务方自行约定 metadata。
- 多入口一致性：Public API、Managed Chat、Developer Platform、CLI + Skills 使用同一套 Event 与读取语义。
- 异步与可追溯：Event 进入队列后异步派生 Profile、Facts 和 Summary，读取结果可以回到来源 Event、revision 和 trace。
- 编排方式可选：Managed Chat 可以托管 Recall、证据注入和合格终态 Capture；Public API 仍保留完整控制权。
Turing LTM 的限制
- 不是自托管数据库：存储由 Turing 管理，不能像 Mem0 OSS 一样自由替换底层组件。
- 不是任意 CRUD：V1 的公共写入入口是 Event，派生记录不能按 Mem0 的方式直接 update / delete。
- 平台绑定更强：如果应用不使用 Turing 的项目、权限和 Environment，平台治理优势就不一定能抵消接入成本。
需要特别评估的情况
- 全部记忆基础设施必须部署在自己的网络或数据库中。
- 需要对每条派生记忆做直接 CRUD、导出或本地离线处理。
- 已经有成熟的 Agent loop 和存储体系，只需要一个可嵌入的记忆组件。
方案范围
这是一份按产品层次筛选的代表性短名单，不是市场份额排名：开源记忆层选 Mem0；海外托管方案选 Zep、AWS AgentCore Memory；中国厂商选阿里云百炼 Memory、腾讯云数据库 Agent Memory。LangMem 是重要的框架内存工具，但与独立托管记忆服务不在同一层，因此不放入主矩阵。Letta/MemGPT 更接近完整 Agent runtime，也不在这里直接比较。Google Vertex AI Memory Bank 是合理替代项，尤其适合强调多云厂商覆盖的评估。