💡

文章摘要

2026 年 6 月 15 日,Weaviate 宣布 Engram 正式 GA(General Availability)。Engram 将 Agent 记忆从「自建基础设施」升级为「托管服务」——原始交互通过异步 Pipeline 自动提取、去重、 reconciled,最终以混合检索方式返回结构化记忆。本文从架构设计、Pipeline 机制、权限隔离模型、与 Mem0/Zep/Letta 的对比、到 Python/TypeScript 完整接入代码,系统讲解 Engram 如何成为 Agent 记忆层的生产级解决方案。

一、Engram 的定位:为什么 Agent 需要「记忆即服务」

2026 年 6 月 15 日,Weaviate 宣布 Engram 正式 GA。 这是继 Mem0(47K Stars)、Zep 之后,又一个重量级玩家进入 Agent 记忆领域。但 Engram 的定位与前两者有本质不同——它不是一个独立的记忆 SDK,而是直接构建在 Weaviate 向量数据库之上的托管记忆服务

Weaviate CEO Bob van Luijt 在发布声明中说:

"Memory is the difference between an agent that answers a question and an agent that gets better at its job."

这句话精准地指出了 Agent 的核心瓶颈:没有记忆的 Agent 只是一个问答机器,有记忆的 Agent 才能真正「越用越好」。

1.1 当前 Agent 记忆的三大痛点

Engram 的发布直接瞄准了三个长期困扰开发者的问题:

痛点一:跨会话记忆丢失。 大多数 Agent 框架的「记忆」仅限于当前会话的上下文窗口。会话结束后,所有交互信息丢失。开发者常用的 workaround 是将整个对话历史重新注入模型——这在对话超过 10 轮后就会导致上下文溢出。

痛点二:多 Agent 上下文共享困难。 当一个任务涉及多个 Agent 协作时(例如搜索 Agent → 分析 Agent → 报告 Agent),上下文如何在 Agent 之间传递?传统方案是手动序列化/反序列化,但这种方式无法处理记忆的增量更新和冲突解决。

痛点三:记忆质量随时间劣化。 简单的「追加式」记忆系统会随着时间积累大量冗余和矛盾信息。没有自动化的去重、合并、衰减机制,记忆越多反而越拖累 Agent 的表现。

Engram 的核心主张是:记忆应该像数据库一样,是一种基础设施,而不是应用逻辑。

图表加载中…

💡 一句话理解

Engram 的「记忆即服务」定位与 Mem0 的「记忆 SDK」路线形成鲜明对比。如果你的基础设施已经用了 Weaviate,Engram 是零额外依赖的选择。

⚠️ 常见踩坑

Engram 目前仅支持 Weaviate Cloud,不支持自托管部署。如果你的合规要求禁止使用云服务,需要等待自托管版本或选择 Letta/Mem0 自托管方案。

二、Engram 技术架构:四层设计与数据流

Engram 的架构可以用四个层次来理解:摄入层、Pipeline 层、存储层、检索层。 每一层解决一个特定的问题,组合起来形成完整的记忆生命周期。

2.1 摄入层(Ingestion Layer)

应用端通过简单的 API 将原始事件(对话、用户反馈、Agent 执行日志)发送给 Engram。摄入是异步的、fire-and-forget 的——应用不需要等待记忆处理完成就可以继续工作。

这是 Engram 与 Mem0 的一个重要区别。Mem0 的记忆提取通常在请求路径中同步执行(虽然也有异步模式),而 Engram 从设计上就把记忆处理与应用逻辑解耦。

2.2 Pipeline 层(Processing Pipeline)

这是 Engram 最核心的创新。Pipeline 由一系列异步步骤组成:

  1. 事实提取(Fact Extraction):从原始文本中提取结构化事实
  2. 实体识别(Entity Resolution):识别事实中的实体及其关系
  3. 冲突检测(Conflict Detection):将新事实与已有记忆对比,发现矛盾
  4. 记忆合并(Memory Reconciliation):自动合并、更新、去重
  5. 量化(Vectorization):将处理后的记忆转为向量嵌入

Pipeline 的关键特性是「幂等性」。 同一条原始事件被多次发送,最终只会产生一条记忆。这解决了分布式系统中常见的事件重复问题。

2.3 存储层(Storage Layer)

记忆最终存储在 Weaviate 向量数据库中。Weaviate 本身支持混合检索(向量 + BM25 关键词),这意味着记忆检索不依赖纯语义相似度——对于精确事实回忆(如用户名字、订单号),关键词检索更可靠。

2.4 检索层(Retrieval Layer)

检索时,Engram 根据调用者的权限范围(Project + User + Property)自动过滤记忆。这确保了记忆隔离——A 项目的记忆不会泄漏到 B 项目,用户甲的记忆不会出现在用户乙的上下文中。

图表加载中…

💡 一句话理解

Pipeline 的幂等性设计值得借鉴。如果你自建记忆系统,也应该确保「同一条事件多次处理」不会产生重复记忆。实现方式可以是事件 ID 去重或内容 hash 去重。

⚠️ 常见踩坑

Pipeline 处理有延迟(通常 1-5 秒)。如果你的场景需要「即时记忆」(如用户刚说的偏好立刻生效),需要在应用层做短期缓存 + 异步持久化的双层设计。

三、权限隔离模型:Project × User × Property

Engram 的权限模型是其区别于 Mem0/Zep 的核心差异点之一。 记忆隔离不是事后补丁,而是从架构层面内置的。

3.1 三维隔离

维度 含义 典型场景
Project 项目级隔离 不同应用/产品的记忆完全隔离
User 用户级隔离 同一产品内不同用户的记忆隔离
Property 属性级隔离 同一用户内不同维度的记忆隔离(如偏好 vs 历史)

Property 维度是最有创意的设计。 它允许你在同一用户的记忆空间内进一步划分「记忆分区」。例如:

  • Property: "preferences" → 用户偏好(语言、主题、风格)
  • Property: "history" → 交互历史(过去的对话摘要)
  • Property: "skills" → 学到的技能(用户教给 Agent 的特定知识)

每个 Property 的记忆在检索时独立查询,结果可以按需组合。这种设计避免了「所有记忆混在一个池子里」导致的检索质量下降。

3.2 模板化记忆场景

Engram 提供了三个开箱即用的模板:

  1. 个性化(Personalization):基于 User + Property 的用户画像记忆
  2. 持续学习(Continual Learning):Agent 从反馈中学习并持久化改进
  3. 多 Agent 共享状态(Multi-Agent Shared State):Project 级别的共享记忆空间
python
# Weaviate Engram Python SDK 示例
import weaviate
from weaviate.classes.init import Auth

# 连接 Weaviate Cloud
client = weaviate.connect_to_weaviate_cloud(
    cluster_url="https://your-cluster.weaviate.network",
    auth_credentials=Auth.api_key("your-api-key"),
)

# 使用 Engram 记忆服务
from weaviate.engram import EngramClient

engram = EngramClient(client)

# 1. 摄入记忆(异步 Pipeline)
engram.ingest(
    project="my-app",
    user="user-123",
    property="preferences",
    events=[
        {
            "type": "conversation",
            "content": "用户偏好中文回复,不喜欢过于正式的语气",
            "metadata": {"source": "chat", "timestamp": "2026-06-17T10:00:00Z"}
        }
    ]
)

# 2. 检索记忆(混合检索)
memories = engram.retrieve(
    project="my-app",
    user="user-123",
    query="用户喜欢什么语言?",
    properties=["preferences"],  # 只检索偏好分区
    limit=5,
    search_type="hybrid"  # 向量 + BM25 混合
)

for mem in memories:
    print(f"[{mem.property}] {mem.content} (score: {mem.score:.3f})")
    # 输出: [preferences] 用户偏好中文回复... (score: 0.92)
typescript
// Weaviate Engram TypeScript SDK 示例
import { WeaviateClient, EngramClient } from 'weaviate-client';

const client = new WeaviateClient({
  scheme: 'https',
  host: 'your-cluster.weaviate.network',
  apiKey: 'your-api-key',
});

const engram = new EngramClient(client);

// 摄入记忆
await engram.ingest({
  project: 'my-app',
  user: 'user-123',
  property: 'preferences',
  events: [
    {
      type: 'conversation',
      content: '用户偏好中文回复,不喜欢过于正式的语气',
      metadata: { source: 'chat', timestamp: new Date().toISOString() },
    },
  ],
});

// 检索记忆
const memories = await engram.retrieve({
  project: 'my-app',
  user: 'user-123',
  query: '用户喜欢什么语言?',
  properties: ['preferences'],
  limit: 5,
  searchType: 'hybrid',
});

memories.forEach((mem) => {
  console.log(`[${mem.property}] ${mem.content} (score: ${mem.score.toFixed(3)})`);
});

💡 一句话理解

Property 分区是 Engram 的杀手级特性。建议按「记忆类型」而非「时间」来划分 Property——这样检索时可以精确控制召回哪类记忆。

⚠️ 常见踩坑

权限隔离是在检索时通过过滤实现的,不是在存储时物理隔离。这意味着如果 Weaviate 集群被攻破,所有项目的记忆都可能被访问到。高安全需求场景需要额外的加密层。

四、与 Mem0/Zep/Letta 的全面对比

Engram 不是 Mem0 的替代品,而是另一种路线的选择。 理解它们的差异,才能做出正确的技术选型。

4.1 架构对比

维度 Engram Mem0 Zep Letta
定位 托管记忆服务 记忆 SDK/平台 时间感知记忆 自托管 Agent 框架
底层存储 Weaviate(自有) 多后端支持 PostgreSQL + 向量 SQLite/PostgreSQL
记忆处理 异步 Pipeline 同步/异步可选 时间窗口聚合 自主记忆管理
隔离模型 三维(Project/User/Property) 二级(User/Agent) 二级(User/Session) 自定义
检索方式 混合检索(向量+BM25) 向量检索为主 时间加权检索 多路检索
部署方式 仅 Cloud Cloud + 自托管 Cloud + 自托管 仅自托管
开源 底层 Weaviate 开源 核心 SDK 开源 部分开源 完全开源
价格 免费 1000 次/月,$45/月起 免费 1000 次/月 免费 300 条消息 免费(自托管成本)

4.2 选型决策树

选择 Engram 的场景:

  • ✅ 已在使用 Weaviate 作为向量数据库
  • ✅ 需要严格的三维权限隔离
  • ✅ 偏好托管服务,不想维护基础设施
  • ✅ 需要混合检索(向量 + 关键词)

选择 Mem0 的场景:

  • ✅ 需要多后端灵活性(可以换 Pinecone/Chroma/Qdrant)
  • ✅ 需要深度定制记忆提取逻辑
  • ✅ 团队有自托管需求且不想依赖特定数据库

选择 Zep 的场景:

  • ✅ 时间感知是核心需求(如客服场景需要「上次对话」的时间线)
  • ✅ 需要自动的对话摘要和实体提取
  • ✅ 偏好 PostgreSQL 生态

选择 Letta 的场景:

  • ✅ 需要完全控制记忆管理逻辑
  • ✅ 正在使用 Letta(原 MemGPT)作为 Agent 框架
  • ✅ 合规要求禁止使用第三方云服务
图表加载中…

💡 一句话理解

如果你的项目刚起步,Engram 的免费层(1000 次 Pipeline/月)足够原型验证。超过免费层后,$45/月的起步价在托管服务中属于中等水平。

⚠️ 常见踩坑

Engram 目前不支持自托管。如果你的合规要求(如 GDPR、等保三级)禁止使用第三方云服务,Mem0 自托管或 Letta 是更安全的选择。

五、工程实践:将 Engram 集成到 Agent 系统

理论再好,落地才是关键。 这一节我们用一个完整的示例,展示如何将 Engram 集成到一个多 Agent 系统中。

5.1 场景设定

假设我们有一个客服 Agent 系统,包含三个子 Agent:

  • 路由 Agent:判断用户问题类型并分发
  • 技术 Agent:处理技术问题
  • 商务 Agent:处理商务咨询

三个 Agent 需要共享用户的基本信息(Project 级),但各自维护独立的交互记忆(Property 级)。

5.2 集成架构

核心设计原则:

  1. 统一 Project:所有 Agent 共享同一个 project="customer-service"
  2. User 级隔离:每个用户有独立的记忆空间
  3. Property 分区
    • "profile" → 用户基本信息(共享)
    • "tech-history" → 技术交互历史(技术 Agent 专用)
    • "biz-history" → 商务交互历史(商务 Agent 专用)
    • "preferences" → 用户偏好(共享)

5.3 记忆生命周期管理

记忆不是越多越好。一个健康的记忆系统需要:

  • 衰减:超过 90 天未被访问的记忆自动降低权重
  • 合并:重复的事实自动合并为一条
  • 清理:明确错误的记忆可以被标记删除

Engram 的 Pipeline 自动处理去重和合并,但衰减策略需要在应用层实现。

python
# 多 Agent 系统的 Engram 集成示例
from weaviate.engram import EngramClient

class MultiAgentMemory:
    """多 Agent 共享记忆管理器"""

    def __init__(self, engram: EngramClient):
        self.engram = engram
        self.project = "customer-service"

    async def store_user_profile(self, user_id: str, profile: dict):
        """存储用户基本信息(所有 Agent 共享)"""
        await self.engram.ingest(
            project=self.project,
            user=user_id,
            property="profile",
            events=[{
                "type": "profile_update",
                "content": str(profile),
                "metadata": {"updated_at": "2026-06-17T10:00:00Z"}
            }]
        )

    async def store_agent_interaction(
        self, user_id: str, agent_type: str, interaction: str
    ):
        """存储 Agent 交互历史(按 Agent 类型分区)"""
        property_map = {
            "tech": "tech-history",
            "biz": "biz-history",
        }
        await self.engram.ingest(
            project=self.project,
            user=user_id,
            property=property_map[agent_type],
            events=[{
                "type": "interaction",
                "content": interaction,
                "metadata": {"agent": agent_type}
            }]
        )

    async def get_context_for_agent(
        self, user_id: str, agent_type: str, query: str
    ) -> str:
        """为特定 Agent 获取上下文"""
        # 始终加载共享记忆
        shared = await self.engram.retrieve(
            project=self.project,
            user=user_id,
            query=query,
            properties=["profile", "preferences"],
            limit=3,
        )

        # 加载 Agent 专有记忆
        property_map = {
            "tech": "tech-history",
            "biz": "biz-history",
        }
        specific = await self.engram.retrieve(
            project=self.project,
            user=user_id,
            query=query,
            properties=[property_map[agent_type]],
            limit=5,
        )

        # 组合上下文
        context_parts = []
        context_parts.append("=== 用户信息 ===")
        for mem in shared:
            context_parts.append(f"[{mem.property}] {mem.content}")
        context_parts.append(f"\n=== {agent_type} Agent 历史 ===")
        for mem in specific:
            context_parts.append(f"[{mem.property}] {mem.content}")

        return "\n".join(context_parts)


# 使用示例
async def main():
    memory = MultiAgentMemory(engram_client)

    # 路由 Agent 分发技术问题到技术 Agent
    context = await memory.get_context_for_agent(
        user_id="user-123",
        agent_type="tech",
        query="用户的服务器部署问题"
    )
    print(context)

💡 一句话理解

多 Agent 系统中,建议用一个专门的「记忆管理模块」封装 Engram 调用,而不是让每个 Agent 直接调用 Engram API。这样可以在一处统一管理权限、缓存和降级策略。

⚠️ 常见踩坑

Engram 的 Pipeline 处理有 1-5 秒延迟。如果 Agent A 刚存了一条记忆,Agent B 立刻就要检索到,需要在应用层加一个「短期记忆缓存」——新存储的记忆先写入 Redis,等 Pipeline 处理完成后再从 Engram 检索。

六、性能与成本分析

Engram 的性能和成本是选型的关键考量。 基于 Weaviate 官方公布的信息和社区测试,我们整理了以下数据。

6.1 Pipeline 延迟

阶段 延迟 说明
摄入(Ingestion) <100ms 仅写入事件队列
Pipeline 处理 1-5s 异步处理,不阻塞应用
检索(Retrieval) 50-200ms 取决于记忆量和查询复杂度

6.2 成本模型

Engram 的定价基于 Pipeline 运行次数(每次 ingest 调用算一次 Pipeline run):

计划 价格 包含量 超出单价
Free $0 1,000 次/月 -
Starter $45/月 10,000 次/月 $0.005/次
Pro $199/月 100,000 次/月 $0.002/次
Enterprise 定制 定制 定制

成本对比: 如果你的 Agent 每天处理 1,000 次对话,每月约 30,000 次 Pipeline 运行,成本约 $45 + (20,000 × $0.005) = $145/月。对比自建记忆系统(需要维护向量数据库 + Pipeline 服务),这个价格在中小规模下是有竞争力的。

6.3 性能优化建议

  1. 批量摄入:将多条事件合并为一次 ingest 调用,减少 Pipeline 触发次数
  2. Property 分区:用 Property 缩小检索范围,避免全量扫描
  3. 缓存热记忆:高频访问的记忆在应用层缓存,减少对 Engram 的检索请求
  4. 监控 Pipeline 延迟:设置告警,当 Pipeline 延迟超过阈值时降级到短期缓存
图表加载中…

💡 一句话理解

如果你的 Agent 交互频率很高(如客服场景),批量摄入可以显著降低成本。将同一用户的多条消息合并为一次 ingest,Pipeline 只运行一次。

⚠️ 常见踩坑

Free 计划的 1,000 次/月限制比较紧。开发测试阶段可能够用,但一旦进入生产环境,需要立即升级到 Starter 计划。建议在开发阶段就用 staging 环境的独立 project 来隔离测试流量。

七、Engram 在 Agent 记忆生态中的位置

Engram 的出现标志着 Agent 记忆从「自建组件」走向「托管基础设施」。 这个趋势与云计算的发展路径高度一致——先是自建数据库,然后出现 RDS 等托管数据库服务。

7.1 记忆技术栈分层

2026 年的 Agent 记忆技术栈可以分为四层:

层次 组件 代表产品
L0: 向量数据库 底层存储引擎 Weaviate, Pinecone, Qdrant, Chroma
L1: 记忆服务 结构化记忆管理 Engram, Mem0 Cloud, Zep
L2: 记忆框架 SDK/库 Mem0 SDK, LangMem, Letta
L3: Agent 框架集成 内置记忆模块 LangGraph, CrewAI, AutoGen

Engram 占据 L1 层,与 Mem0 Cloud 和 Zep 直接竞争。它的差异化优势是Weaviate(L0 层)的深度集成——混合检索、权限隔离、Pipeline 处理都是原生实现的,不需要跨系统通信。

7.2 未来展望

Weaviate 在发布 Engram 时提到了几个未来方向:

  1. 多模态记忆:支持图像、音频等非文本记忆类型的摄入和检索
  2. 记忆联邦学习:跨组织共享记忆模式而不泄露具体记忆内容
  3. 自适应衰减策略:根据记忆的使用频率和重要性自动调整权重
  4. 记忆版本控制:支持记忆的回滚和历史版本查看

这些方向如果实现,将进一步巩固 Engram 在记忆服务层的地位。但目前它们还只是路线图上的规划

💡 一句话理解

技术选型不要只看当前功能,也要看团队的技术路线图。如果你需要的功能在路线图上且时间合理,可以等一等;如果路线图与你的需求不匹配,选择其他方案。

⚠️ 常见踩坑

Engram 的多模态记忆和联邦学习目前还只是路线图概念,不建议在生产系统中依赖。当前生产环境请使用文本记忆功能,多模态需求可以用 Mem0多模态嵌入作为临时方案。

八、总结与选型建议

Weaviate Engram 的 GA 是 Agent 记忆领域的一个重要里程碑。 它证明了「记忆即服务」的商业模式是可行的,也为开发者提供了一个低门槛的记忆解决方案。

核心结论

  1. Engram 最适合的场景:已使用 Weaviate 的团队、需要严格权限隔离的企业应用、偏好托管服务的中小团队
  2. Engram 不适合的场景:需要自托管的合规场景、需要深度定制记忆逻辑的研究项目、使用非 Weaviate 向量数据库的团队
  3. 竞争格局:Engram vs Mem0 vs Zep vs Letta 不是「谁最好」的问题,而是「谁最适合你的场景」的问题
  4. 未来趋势:记忆服务化是必然方向,但「自建 vs 托管」的平衡点取决于规模和合规要求

Agent 记忆的核心挑战从来不是「能不能记住」,而是「记住什么、忘记什么、如何高效回忆」。 Engram 通过异步 Pipeline 和三维权限模型提供了一个优雅的工程方案,但最终的记忆质量仍然取决于你的应用逻辑如何设计记忆的摄入和检索策略。

💡 一句话理解

如果你是 Agent 记忆领域的新手,建议从 Engram 的 Free 计划开始,先理解记忆的生命周期(摄入 → 处理 → 存储 → 检索),再决定是否需要更复杂的自建方案。

⚠️ 常见踩坑

不要过早优化记忆系统。很多 Agent 应用在初期只需要简单的对话历史就足够了。当你的 Agent 确实出现了「记忆不够用」的问题(如跨会话遗忘、多 Agent 上下文丢失),再引入 Engram 等记忆服务。