深入理解 AI Agent · MEMORY #02：记忆的工程机制

记忆分层解决了"存在哪"的问题，而提取、检索、蒸馏这些机制，决定了记忆系统能不能真正跑起来。

一、上篇留下的问题

上篇从认知科学出发，拆解了 Agent 记忆的四种类型（情景、语义、程序、工作记忆），并给出了工程上的三层存储方案：结构化 KV 存规则与事实，向量库存语义记忆，对话窗口存短期上下文。

分层解决了"记忆存在哪"的问题。但还有四个工程问题没有回答：

记忆从哪来？ ------ 不能让开发者手动写 API 调用，Agent 得自己从对话中提取值得记住的信息。
提取错了怎么办？ ------ LLM 有幻觉，如果把错误信息写入长期记忆，后续会持续影响决策。
记忆多了怎么找？ ------ 10 条记忆可以遍历，10000 条记忆怎么办？纯向量检索够不够？
记忆会无限膨胀吗？ ------ 用户和 Agent 交互 1000 次后，记忆库会不会变成一场灾难？

这四个问题，每一个都指向一套具体的工程机制。今天把它们逐一拆开。

二、记忆提取：让 LLM 自己决定"记什么"

2.1 核心挑战

传统系统的"记忆"靠开发者手动写入------调 save_memory(user_id, content) 接口，写什么、什么时候写，都是代码控制。

Agent 系统不一样。对话是非结构化的、内容是开放的，Agent 需要从每轮对话中自动判断：哪些信息值得长期记住，哪些只是闲聊。

这个挑战本质上是一个信息抽取 + 价值判断的组合问题：

抽取：从非结构化对话中提取结构化事实
判断：评估这条信息的确定性，决定怎么处理它

2.2 主流方案的分歧

目前主流框架走了两条路线：

路线 A：结构化提取（Mem0 的思路）

用 Prompt 让 LLM 直接输出结构化的记忆条目。比如 Mem0 把记忆分为 facts、preferences、goals 三类，每次对话后让模型从对话中提取并填入对应分类。

路线 B：摘要压缩（Zep 的思路）

先把对话压缩成摘要，再从摘要中提取关键事实。多了一步压缩，但能处理更长的对话上下文。

两种路线没有绝对对错，区别在于：结构化提取更精准，适合规则、偏好这类短信息；摘要压缩能处理长对话，但压缩过程可能丢失细节。

2.3 一种工程实践：结构化提取 + 置信度

结合两条路线的优点，一种更灵活的方案是：让 LLM 输出结构化 JSON，同时给出置信度评分。

提取的 Prompt 设计有几个关键约束：

限定提取类型和数量：明确告诉模型"提取 0-2 条事实、0-1 条规则"，避免过度提取
强调"只提取明确表述的信息"：不要让模型推理或脑补，只提取对话中直接表达的
兜底逻辑：明确告诉模型"如果没有值得记住的新信息，各字段留空"
置信度自评：让模型对提取结果打分（0-1），表达"我有多确定这条信息是正确的"

一个典型的提取 Prompt 模板：

bash 复制代码

你是一个记忆提炼器，从对话中提取值得长期记忆的信息。

【提取类型】
- facts：用户明确表述的事实（0-2 条）
- rules：用户明确要求的行为规则（0-1 条）
- status_updates：当前状态更新

【输出格式】
{
    "facts": ["用户上周买了奶粉"],
    "rules": ["用户不喜欢被催单"],
    "status_updates": [{"key": "step", "value": "投诉处理中"}],
    "confidence": 0.85
}

【注意】
- 只提取对话中明确提及的信息，不要推理或编造
- confidence 0.0-1.0，越高越确定
- 无新信息则各字段为空

这种设计的好处是：提取结果是结构化的（方便存储和检索），置信度评分又为下一步的"路由决策"提供了依据。

2.4 提取 Pipeline 的工程实现

实际工程中，提取不是"调一次 LLM"这么简单。一个完整的提取 pipeline 通常包含以下步骤：

bash 复制代码

def extract_memory_pipeline(conversation_turns, user_profile):
    """记忆提取主流程"""

    # Step 1: 预处理 ------ 拼接对话上下文 + 注入用户画像
    context = build_context(conversation_turns, user_profile)

    # Step 2: LLM 结构化提取
    raw_result = llm_extract(context, prompt_template=EXTRACT_PROMPT)

    # Step 3: 输出校验 ------ JSON Schema 验证 + 字段合法性检查
    validated = validate_extraction(raw_result)
    if not validated:
        log_warning("提取结果校验失败", raw_result)
        return None

    # Step 4: 去重预检 ------ 与已有记忆做余弦相似度比对
    # 如果与已有记忆高度相似（cosine > 0.92），说明不是新信息
    duplicates = check_duplicates(validated, existing_memories, threshold=0.92)
    if duplicates:
        # 更新已有记忆的访问时间，而非新增
        update_access_time(duplicates)
        return None

    # Step 5: 置信度分流（见第三章）
    route_result = route_by_confidence(validated)
    return route_result

几个容易踩的坑：

上下文窗口溢出：长对话需要先做截断或摘要，不能把全部历史塞进提取 Prompt
JSON 解析失败：LLM 输出不一定总是合法 JSON，需要 try-catch + 重试机制（通常重试 1 次即可）
过度提取：如果不限制提取数量，模型会倾向于"宁可多提"，导致噪音大量涌入

三、置信度分流：不同确定度走不同通道

提取出记忆后，下一步是决定"怎么处置它"。

直接全部写入长期记忆？太危险。模型幻觉可能把错误信息固化，后续每次检索都会拿到这条错误记忆，持续影响决策。

全部人工确认？又太重。大部分提取结果是明确的（比如用户说"我是 Java 开发者"），逐条确认浪费人力。

解决方案是置信度分流------借鉴网络工程中"多队列调度"的思路，不同优先级走不同通道：

置信度区间	处置方式	理由
≥ 0.82	自动写入长期存储	模型高确定性，大概率正确
0.55 ~ 0.82	进入待审核队列，等待人工确认	模型拿不准，需要兜底
< 0.55	直接丢弃	信息价值低或不确定性太高

这里有两个值得讨论的设计选择：

阈值怎么选？ 0.82 和 0.55 不是拍脑袋的数字。阈值太低，会有大量模型幻觉污染长期记忆；阈值太高，很多有价值的信息会被漏掉。这组数值来自 Mem0 等开源框架在社区项目中的实践经验，不同业务场景的最优阈值差异可能很大------客服场景对错误容忍度低，高阈值更合适；个人助手场景宁可多记不漏，阈值可以放宽。实际部署时需要根据标注数据做网格搜索，找到适合自身业务的平衡点。

为什么需要丢弃？ 不是所有对话内容都值得记住。用户随口说的"今天天气不错"，对长期记忆没有价值。置信度低的直接丢弃，是控制记忆库膨胀的第一道防线。

3.1 阈值调优的工程方法

光知道"需要做网格搜索"还不够，实际怎么操作？这里给出一套可落地的调优流程：

Step 1：构建标注数据集

从真实对话中采样 200-500 条，让 2-3 个标注员独立判断每条提取结果的"正确性"和"价值性"。标注结果分三档：

完全正确且有价值（Positive）
正确但无价值 / 有价值但不确定（Ambiguous）
明显错误（Negative）

Step 2：绘制阈值-指标曲线

遍历不同的 (auto_threshold, pending_threshold) 组合，计算：

bash 复制代码

Precision = 正确写入的记忆 / 总写入记忆
Recall    = 正确写入的记忆 / 所有应该记住的信息
Cost      = LLM 调用次数 + 人工审核时间 × 时薪

核心矛盾是：Precision 和 Recall 此消彼长，Cost 随 pending 区间增大而增加。

Step 3：选点策略

不同业务选点逻辑不同：

业务场景	优先指标	推荐策略
客服 Agent	Precision > 0.95	高阈值（0.90/0.70），宁可漏记不可错记
个人助手	Recall > 0.80	低阈值（0.70/0.40），宁可多记不可遗漏
电商导购	F1-score 最优	网格搜索取 F1 峰值点

Step 4：持续校准

阈值不是设完就不管了。建议每积累 1000 条审核数据后重新跑一轮评估，漂移超过 5% 就调整阈值。

四、HITL：人机协作的质量兜底

4.1 为什么需要人？

LLM 在判断"这句话该不该被记住"时存在几个已知局限：

高风险信息：涉及金额、承诺、投诉的内容，错了代价很大
模糊暗示：用户说"以后别这么说了"，模型可能提取出错误的规则
隐含偏好：用户的真实偏好可能跟字面表达不一致

HITL（Human-In-The-Loop，人在回路）就是在模型自动处理和完全人工管理之间，加一个审核缓冲区。

4.2 工作流程

整个流程分两段：

第一段：模型自动处理

bash 复制代码

对话输入
    ↓
LLM 提取记忆 + 计算置信度
    ↓
置信度 ≥ 0.82？ → 自动写入 ✅
    ↓ 否
置信度 ≥ 0.55？ → 入 pending_queue 👀
    ↓ 否
跳过 ❌

第二段：人工审核

bash 复制代码

pending_queue
    ↓
审核员看到：提取内容 + 原始对话片段 + 置信度
    ↓
确认 / 修改 / 拒绝
    ↓
通过 → 写入长期存储 ✅
拒绝 → 标记丢弃

设计上的一个关键点：审核员看到的不只是提取结果，还有原始对话片段。这样才能判断模型是否准确提取了用户的意图，而不是凭空捏造。

4.3 实际运营中的经验

HITL 上线后会发现几个有趣的现象：

高置信度的内容偶尔也有错（模型很自信但事实错误）
低置信度的内容偶尔是对的（模型过于保守）
阈值不应该是固定的------需要根据实际运营数据持续调优

这意味着 HITL 不只是一个审核机制，还是一个数据飞轮：人工审核的结果可以反哺提取 Prompt 的优化，让模型的提取准确率持续提升。

4.4 审核队列的产品设计

工程上，HITL 审核队列的设计直接影响运营效率。几个关键设计点：

批量审核 vs 逐条审核：逐条审核效率太低，建议按"用户 + 时间窗口"聚合。比如展示"用户 A 过去 1 小时的 5 条待审核记忆"，审核员可以一次性判断。

审核界面的信息层级：

bash 复制代码

┌─────────────────────────────────────────────┐
│ 用户: 张三  |  时间: 2026-08-12 14:30       │
│ 置信度: 0.67                                 │
├─────────────────────────────────────────────┤
│ 原始对话:                                    │
│   用户: "以后别给我推那些便宜的替代品了"       │
│   Agent: "好的，我记住了"                     │
├─────────────────────────────────────────────┤
│ 提取结果: [规则] 用户不接受廉价替代品推荐      │
│                                              │
│ [✓ 确认]  [✎ 修改]  [✗ 拒绝]                │
└─────────────────────────────────────────────┘

审核员的核心判断依据是原始对话和提取结果之间的一致性，而不是提取结果本身是否"看起来合理"。

审核 SLA：pending 队列需要有处理时效要求。如果一条记忆在 pending 状态超过 24 小时未被处理，应该自动降级（降低优先级或丢弃），避免过期信息占据队列资源。

五、混合检索：三路信号融合

5.1 纯向量检索的三个盲区

记忆存进去了，怎么找回来？最简单的方案是向量检索：把用户查询编码成向量，找相似度最高的记忆。

向量检索擅长捕捉语义相似（"用户喜欢咖啡"能匹配"用户每天早上喝拿铁"），但它有三个盲区：

盲区	说明	例子
关键词精确匹配失败	向量空间里"近似"不等于"相同"	搜"K8s"匹配不到存了"Kubernetes"的记忆
时间无感知	所有记忆权重相同，无法区分新旧	一周前和三个月前的记忆同等重要
模糊语义干扰	语义相近但实际无关的内容被错误召回	搜"Java"把"爪哇咖啡"的记忆也拉出来

5.2 三路信号融合

解决方案是混合检索，结合三种信号源：

信号	作用	擅长场景
向量相似度	捕捉语义相近	"用户偏好"匹配"用户喜欢"
BM25 关键词	精确匹配专有名词	"K8s"精确匹配"K8s"
时间衰减	近期记忆加权	昨天的偏好 > 三个月前的偏好

最终得分 = α × 向量分 + β × BM25分 + γ × 时间衰减分

其中 α、β、γ 是可配置的权重。不同场景下可以调整权重配比：

需要精确匹配时（查技术关键词），提高 β
需要上下文关联时（查用户偏好），提高 α
实时对话场景，提高 γ

5.3 融合算法的工程细节

理论公式很简单，工程实现有一堆细节。下面是一个可落地的融合算法：

bash 复制代码

def hybrid_retrieval(query, top_k=10, alpha=0.6, beta=0.3, gamma=0.1):
    """三路信号融合检索"""

    # ---- 信号 1: 向量检索 ----
    query_embedding = embed_model.encode(query)
    vector_results = vector_store.search(
        query_embedding, top_k=top_k * 3  # 多召回，后续融合筛选
    )
    # 归一化到 [0, 1]
    vector_scores = min_max_normalize([r.score for r in vector_results])

    # ---- 信号 2: BM25 关键词检索 ----
    bm25_results = bm25_index.search(query, top_k=top_k * 3)
    bm25_scores = min_max_normalize([r.score for r in bm25_results])

    # ---- 信号 3: 时间衰减 ----
    # 半衰期设为 30 天，即 30 天前的记忆权重衰减到 0.5
    now = datetime.now()
    decay_constant = math.log(2) / timedelta(days=30)

    # ---- 融合 ----
    # 建立 memory_id -> {vector_score, bm25_score, time_score} 的映射
    all_candidates = merge_results(vector_results, bm25_results)

    final_scores = {}
    for mem_id in all_candidates:
        vs = vector_scores.get(mem_id, 0.0)
        bs = bm25_scores.get(mem_id, 0.0)

        # 时间衰减：exp(-λ × days_ago)
        days_ago = (now - mem_last_accessed(mem_id)).days
        ts = math.exp(-decay_constant * days_ago)

        final_scores[mem_id] = alpha * vs + beta * bs + gamma * ts

    # 按融合得分排序，取 top_k
    sorted_results = sorted(final_scores.items(), key=lambda x: -x[1])
    return sorted_results[:top_k]

几个关键工程决策：

归一化方法：向量相似度和 BM25 分数的量纲完全不同（余弦相似度在 $-1, 1$ ，BM25 没有上限），必须归一化到同一尺度才能加权融合。实践中 min-max 归一化就够了，z-score 归一化在样本量小时不稳定。

多召回策略 ：向量检索和 BM25 各取 top_k * 3 而非 top_k，是因为单路检索可能漏掉另一路能召回的好结果。融合后再截断，效果显著优于各取 top_k。

时间衰减半衰期：30 天是一个经验值。对于"用户偏好"类记忆，偏好变化较慢，半衰期可以设长（60-90 天）；对于"当前任务状态"类记忆，半衰期应该更短（7-14 天）。如果有记忆类型标签，可以按类型设置不同的半衰期。

5.4 一个工程直觉

混合检索不是新概念，RAG 系列已经详细讨论过。但在 Agent 记忆系统中，它的意义更特殊------Agent 的记忆不是静态文档，而是随对话不断变化的动态信息。混合检索让 Agent 能在"精确回忆"和"模糊联想"之间取得平衡，就像人类记忆一样：有时候你需要精确回忆起某个人说过的某句话，有时候你只是模糊记得"好像聊过这个话题"。

六、记忆蒸馏：解决无限膨胀

6.1 记忆膨胀问题

随着对话不断积累，记忆会越来越多。用户和 Agent 交互 100 次后，可能有 500 条 facts、200 条 rules。每次检索都在一个庞大的记忆库里操作，不仅增加延迟，还会引入更多噪音。

这其实是计算机科学中一个经典问题的镜像：缓存管理。操作系统的内存是有限的，需要在有限的空间里决定：留什么、丢什么、怎么合并碎片。Agent 记忆系统面临完全一样的挑战。

6.2 蒸馏机制

解决方案是记忆蒸馏（Memory Distillation）------定期把多条零散的相关记忆合并成一条更高层次的概括。

举个例子：

bash 复制代码

蒸馏前（5 条零散记忆）：
  - "用户喜欢喝美式咖啡"（3 次提及）
  - "用户不喝加糖的饮料"（2 次提及）
  - "用户最近在减脂"（1 次提及）
  - "用户早上习惯先处理邮件"（2 次提及）
  - "用户偏好异步沟通"（1 次提及）

蒸馏后（2 条概括记忆）：
  - "用户偏好：黑咖啡 + 无糖 + 健康饮食"
  - "用户工作习惯：早到、先清邮件、偏好异步沟通"

5 条变成 2 条，信息量没丢，但检索效率大幅提升。

这个命名借鉴了深度学习中的"知识蒸馏"（Knowledge Distillation），核心思想是一样的：用压缩后的表示保留核心信息。区别在于，知识蒸馏压缩的是模型参数，记忆蒸馏压缩的是 Agent 的长期经验。

业界已经有不少具体的蒸馏工程实践。比如 CowAgent 项目实现了**"梦境蒸馏"（Deep Dream）机制------在每天定时触发，对当天积累的零散记忆做合并提炼，类似人类睡眠中的记忆整理过程。微软的 agent-framework 则提供了对话压缩（Compaction Summary）**机制，设计了多种可组合的压缩策略（工具结果折叠、对话摘要、滑动窗口截断等），开发者可以根据场景编排不同的压缩流水线。这些实践说明，记忆的压缩与整理正在成为 Agent 框架的基础设施。

6.3 蒸馏调度的工程实现

蒸馏不是随时都能做的------太频繁浪费 LLM 调用成本，太稀疏又控制不住膨胀。一个实用的调度策略：

bash 复制代码

class DistillationScheduler:
    """记忆蒸馏调度器"""

    def __init__(self, config):
        self.trigger_threshold = config.get("trigger_threshold", 50)  # 新增记忆条数阈值
        self.min_interval_hours = config.get("min_interval_hours", 24)  # 最小触发间隔
        self.max_memory_count = config.get("max_memory_count", 500)  # 记忆库上限

    def should_trigger(self, new_count_since_last, hours_since_last, total_count):
        """判断是否需要触发蒸馏"""
        # 条件 1: 新增记忆超过阈值
        if new_count_since_last >= self.trigger_threshold:
            return True
        # 条件 2: 记忆库总量超过上限（强制触发）
        if total_count >= self.max_memory_count:
            return True
        # 条件 3: 距上次蒸馏超过 7 天且有新增（定期维护）
        if hours_since_last >= 168 and new_count_since_last > 5:
            return True
        return False

    def run_distillation(self, user_id):
        """执行蒸馏"""
        memories = get_all_memories(user_id)

        # Step 1: 按主题聚类（用 embedding 聚类）
        clusters = cluster_by_topic(memories, method="embedding_cosine", threshold=0.75)

        # Step 2: 对每个簇 > 3 条记忆的簇做合并
        for cluster in clusters:
            if len(cluster.memories) >= 3:
                merged = llm_merge_memories(cluster.memories)
                replace_memories(cluster.memories, merged)

        # Step 3: 清除过期记忆（超过 90 天未被检索且置信度 < 0.7）
        prune_stale_memories(user_id, inactive_days=90, max_confidence=0.7)

触发策略的设计思路：

增量触发：新增记忆达到 50 条时触发，保证蒸馏频率与记忆增长速度成正比
强制触发：记忆总量达到上限时强制蒸馏，这是防止记忆库失控的兜底机制
定期维护：即使增量不大，每周也做一次轻量整理，清理零散的"孤儿记忆"

6.4 配套策略

蒸馏之外，还需要几个配套策略：

过期清除：长期未被检索到的记忆，降低优先级或标记清除。类似操作系统的 LRU（Least Recently Used）策略。
冲突解决 ：当新记忆与旧记忆矛盾时（比如用户之前说"我喜欢用 Java"，现在说"我打算转 Go"），新记忆应该覆盖旧记忆。这需要一个去重 + 冲突检测机制。
重要性标记：核心规则（如"永远用中文回复"）的优先级应该高于临时偏好（如"今天想用英文写代码"）。

蒸馏、清除、冲突解决，这三个机制共同构成了记忆的生命周期管理------从"提取"到"写入"到"检索"到"蒸馏"到"清除"，形成完整闭环。

七、主流框架的设计取舍

聊完核心机制，最后横向对比几个主流的记忆框架，看看它们在工程上各有什么特点。

Mem0

核心思路：纯向量检索 + 直接写入，不提供显式 HITL 审核队列
记忆模型：facts + preferences + goals，预定义分类
优点：工程实现简洁，开箱即用
局限：无显式人工审核机制；不过其内部提取逻辑会静默过滤低置信度的结果，相当于做了一层隐式的置信度分流

Zep

核心思路：知识图谱 + 混合检索，通过图谱组织实体关系并检索高相关上下文
特色：自动从对话中抽取实体和关系构建知识图谱，区别于纯向量检索的关键在于能精确追溯实体间的关联；同时对话结束后自动压缩成摘要，相当于内置了蒸馏机制
优点：图谱关联比纯语义匹配更精准，摘要层控制了记忆膨胀
局限：同样没有显式 HITL 机制；图谱构建依赖抽取质量，幻觉可能污染图谱结构

Letta（MemGPT）

核心思路：借鉴操作系统的虚拟内存管理
特色：记忆分为主记忆（有限上下文窗口）和归档记忆（大量外部存储），Agent 自己决定什么时候把什么信息从归档搬进主记忆
优点：Agent 自主管理记忆，更接近"真正的记忆"
局限：每次"记忆搬运"都需要额外的 LLM 调用，成本较高

三个框架的核心差异

维度	Mem0	Zep	Letta
检索方式	纯向量	知识图谱 + 混合检索	分层调度
HITL	无	无	无
蒸馏	无	自动摘要	主记忆管理
适用场景	个人助手	对话型 Agent	长期自主 Agent

对比下来，没有哪个框架在所有维度上都是最优的。每个框架的选择都是一种工程权衡------在检索精度、系统复杂度、LLM 调用成本三者之间找平衡点。

7.1 选型决策树

面对具体项目时，可以用这个决策树快速定位：

bash 复制代码

你的 Agent 需要长期记忆吗？
├── 不需要（单轮/短对话） → 不需要记忆框架
└── 需要
    ├── 记忆规模 < 1000 条/用户
    │   ├── 需要精确实体关联？ → Zep（知识图谱）
    │   └── 主要是偏好/事实？ → Mem0（简单高效）
    ├── 记忆规模 1000-10000 条/用户
    │   ├── Agent 需要自主管理记忆？ → Letta
    │   └── 开发者可控？ → Mem0/Zep + 自建蒸馏
    └── 记忆规模 > 10000 条/用户
        └── 必须自建：混合检索 + 蒸馏 + 分层存储
            （上述框架均不能直接满足，需要在其基础上扩展）

八、生产环境上线 Checklist

最后整理一份记忆模块上线前的检查清单，供实操参考：

数据质量

提取 Prompt 经过 ≥ 50 条样本测试，结构化输出成功率 > 95%
置信度阈值经过网格搜索，Precision/Recall 满足业务要求
去重阈值（cosine similarity）已校准，不会误合并不同主题的记忆
冲突解决逻辑已验证，新偏好能正确覆盖旧偏好

检索效果

混合检索三路权重（α/β/γ）已在真实查询上验证
Top-K 值已调优：太小丢信息，太大引噪音
无关记忆过滤（irrelevant_min_score）已设置，避免不相关内容被召回
检索延迟 P99 < 200ms（不含 LLM 调用）

运维保障

HITL 审核队列有超时处理机制（pending > 24h 自动降级）
蒸馏调度器已配置，记忆库有上限兜底
关键指标有监控：提取成功率、pending 队列长度、蒸馏触发频率、检索命中率
有回滚方案：蒸馏出错时能恢复原始记忆

成本控制

单次记忆提取的 LLM 调用成本已核算（通常 1 次调用 ≈ 0.001-0.01 元）
蒸馏触发频率与 LLM 预算匹配
向量库存储成本已评估（按 10 万条记忆估算）

九、小结与预告

今天拆解了 Agent 记忆系统的 6 个核心工程机制：

机制	解决什么问题
记忆提取	从非结构化对话中自动提取结构化记忆
置信度分流	不同确定度的记忆走不同处理通道
HITL	人机协作，为模型提取提供质量兜底
混合检索	三路信号融合，平衡精确匹配与语义关联
记忆蒸馏	压缩合并，控制记忆库膨胀
生命周期管理	提取→写入→检索→蒸馏→清除的完整闭环

这些机制不是独立的------它们构成一条完整的记忆流水线：对话进来，经过提取和分流，通过审核兜底，通过混合检索被召回，通过蒸馏维持长期健康。

下一篇（MEMORY-03），会用 Dream-SaaS 项目来展示这些机制的具体落地：Java + Spring AI 怎么实现这些机制、5 个 Agent 怎么共享记忆、生产环境的真实表现。

🧠 深入理解 AI Agent · Memory 系列 · 02

有问题评论区见，欢迎交流~

参考资料

Mem0：github.com/mem0ai/mem0
Zep：github.com/getzep/zep
Letta (MemGPT)：github.com/letta-ai/le...
Packer et al., "MemGPT: Towards LLMs as Operating Systems", 2023. $2310.08560$ MemGPT: Towards LLMs as Operating Systems
Wang et al., "A survey on large language model based autonomous agents", Frontiers of Computer Science 2024. www.researchgate.net/publication...
Lilian Weng, "LLM Powered Autonomous Agents". LLM Powered Autonomous Agents | Lil'Log
Memory in the Age of AI Agents, 2026. blog.langchain.dev/memory-in-t...