AI大模型工程师必知必会之企业级Agent记忆系统实战：从Context到Long-term Memory

马士兵教育

71人浏览 · 2026-08-14 16:43:43

马士兵教育 · 2026-08-14 16:43:43 发布

AI大模型工程师必知必会之企业级Agent记忆系统实战：从Context到Long-term Memory1. 为什么 Agent 记忆系统是下一个分水岭

2025 年以来，大模型应用的重心正在从"会聊天"快速转向"能干活"。一个能回答问题的 Chatbot 很容易做，但一个能在真实业务里持续承担任务的 Agent，关键差异通常不是模型本身，而是它是否拥有可靠的记忆。面试中被问到的频率越来越高的一句话是：你的 Agent 如何跨会话记住用户和任务上下文？如果只能回答"把历史对话塞进 Prompt"，那离企业级落地还有不小距离。

本文从 Context 的局限讲起，梳理企业级 Agent 记忆系统的分层设计，并给出一个可以直接运行的最小记忆模块，最后落到面试高频考点和项目表达上。

2. 先理清概念：Context、Working Memory 与 Long-term Memory

很多人把"记忆"等同于"把更多文本放进上下文"，这是最常见的误区。企业级 Agent 的记忆至少包含三个层次：

Context（上下文）：当前请求窗口内可见的文本、工具结果和系统提示，是一次推理时真正被模型"看到"的内容。
Working Memory（工作记忆）：单次任务过程中维护的临时状态，例如当前正在处理的步骤、中间结果、未完成的子目标。
Long-term Memory（长期记忆）：跨会话持久化的信息，包括用户偏好、历史事实、项目背景、成功经验和失败教训。

判断一个记忆系统是否成立，最直接的标准是：关掉当前会话再重新开始，Agent 是否还能恢复关键信息。如果做不到，它拥有的只是上下文，不是记忆。

3. Context 的困境：上下文窗口不是无限膨胀的

把历史不断塞进 Context 是最朴素的做法，但很快会撞上四面墙：

成本：Token 计费随上下文线性增长，高频调用下成本压力非常明显。
注意力稀释：上下文越长，模型对中间信息的关注越弱，长文本场景会出现"开头记得住、中间会丢失"的现象。
延迟：更长的输入意味着更长的预填充时间和更高的首字延迟。
无法持久化：上下文窗口结束后信息自然消失，会话之间无法传递经验。

因此，企业级系统的正确思路不是"无限扩大 Context"，而是"把 Context 当作稀缺资源，用长期记忆按需补充"。

4. 企业级 Agent 记忆系统的四层架构

一个完整的企业级 Agent 记忆系统通常可以拆成四层：

感知层：从对话、工具调用和业务事件中提取值得记忆的信息。
工作记忆层：管理单次任务内的临时状态，保证多步推理过程不丢失。
短期缓存层：保存最近几次交互的热数据，降低频繁检索的延迟。
长期记忆层：负责持久化存储、检索、更新和遗忘，是整个系统最核心的部分。

这四层中，长期记忆层决定了 Agent 能否跨会话复用经验，也是本文后续的重点。

5. 长期记忆的四个核心动作：写入、检索、更新、遗忘

长期记忆不能只是一个"存进去的数据库"，它需要完整的生命周期管理。四个核心动作缺一不可：

写入：从原始交互中抽取事实、偏好或事件，生成带元数据的记忆条目，避免把整段对话原样入库。
检索：根据当前任务意图查回最相关的记忆，通常采用向量相似度加关键词过滤的组合方案。
更新：当新信息与旧记忆冲突时，合并、修订或标记旧条目，避免同一条信息出现多个矛盾版本。
遗忘：按重要性、时效性和容量上限淘汰低价值记忆，防止记忆库无限膨胀。

很多团队只做了"写入和检索"，忽略了更新与遗忘，结果是记忆库越来越大，噪声越来越多，召回质量反而下降。

6. 技术选型：向量库、图谱与关系数据库如何配合

长期记忆的底层存储通常不是单一技术，而是根据数据类型组合使用：

存储类型	典型用途	代表方案
向量数据库	语义检索、相似偏好匹配	Milvus、Qdrant、pgvector
图数据库	实体关系、知识图谱推理	Neo4j、NebulaGraph
关系数据库	结构化事实、租户与权限元数据	PostgreSQL、MySQL
对象存储	原始会话归档、审计日志	S3、MinIO

工程上常见做法是：向量库负责召回，关系库负责事实与权限，图谱负责复杂关系推理，原始会话写入对象存储用于审计和回放。

7. 实战：用 Python 搭建一个可落地的记忆模块

下面给出一个不依赖外部服务、可以直接运行的记忆模块骨架。它包含记忆写入、基于余弦相似度的检索，以及简单的容量淘汰机制。

import math
from dataclasses import dataclass

@dataclass
class Memory:
    content: str
    embedding: list
    importance: float = 1.0

class MemoryStore:
    def __init__(self):
        self.memories = []

    def add(self, memory):
        self.memories.append(memory)

    def cosine_similarity(self, a, b):
        dot = sum(x * y for x, y in zip(a, b))
        norm_a = math.sqrt(sum(x * x for x in a))
        norm_b = math.sqrt(sum(x * x for x in b))
        return dot / (norm_a * norm_b + 1e-9)

    def recall(self, query_embedding, top_k=5):
        scored = []
        for memory in self.memories:
            sim = self.cosine_similarity(query_embedding, memory.embedding)
            scored.append((sim * memory.importance, memory))
        scored.sort(key=lambda item: item[0], reverse=True)
        return [memory for _, memory in scored[:top_k]]

class EpisodicMemory:
    def __init__(self, max_size=1000):
        self.store = MemoryStore()
        self.max_size = max_size

    def memorize(self, content, embedding, importance=1.0):
        memory = Memory(content=content, embedding=embedding, importance=importance)
        self.store.add(memory)
        while len(self.store.memories) > self.max_size:
            self.store.memories.pop(0)
        return memory

    def search(self, query_embedding, top_k=3):
        return self.store.recall(query_embedding, top_k=top_k)

if __name__ == "__main__":
    mem = EpisodicMemory(max_size=100)
    mem.memorize("用户偏好简洁回答，不喜欢长篇大论", [0.9, 0.1, 0.2], importance=1.5)
    mem.memorize("用户团队使用 Java 17 和 Spring Boot 3", [0.1, 0.8, 0.7], importance=1.2)
    mem.memorize("上次任务中用户要求输出中文", [0.3, 0.2, 0.9], importance=1.0)

    query = "用户喜欢什么样的回答风格"
    query_embedding = [0.85, 0.05, 0.15]
    results = mem.search(query_embedding, top_k=2)
    for item in results:
        print(item.content)

在真实系统中，embedding 通常由专门的向量模型生成，并把上面的余弦相似度替换为向量数据库的 TopK 查询。这个骨架的价值在于把"写入、检索、淘汰"三个环节讲清楚，方便你在此基础上接入业务逻辑。