AI 智能体记忆架构在 LangGraph 中的落地实现 原创

记忆是一个系统，用于记录之前交互的信息。对于 AI 智能体（AI Agent）来说，记忆非常重要，因为它能让 AI 智能体记住之前的交互，从反馈中学习，并适应用户的偏好。当 AI 智能体处理更复杂的任务和大量用户交互时，这种能力对于提高效率和用户满意度变得至关重要。

AI 智能体中有两种记忆类型：短期记忆和长期记忆：

• 短期记忆（Short-term memory）：也称为线程范围记忆（thread-scoped memory），通过在会话中维护消息历史来跟踪正在进行的对话。LangGraph 将短期记忆作为 AI 智能体状态的一部分进行管理。状态通过检查点（checkpointer）持久化到数据库中，以便随时恢复线程。短期记忆会在调用图或完成步骤时更新，并且在每个步骤开始时读取状态。
• 长期记忆（Long-term memory）：存储跨会话的用户特定或应用级别的数据，并在不同的对话线程中共享。它可以在任何时间、任何线程中被回忆。记忆可以被限定在任何自定义的命名空间（namespace）中，而不仅仅是在单个线程ID内。LangGraph提供了存储（stores），让你可以保存和回忆长期记忆。

下文详细剖析之。

一、AI 智能体短长期记忆架构设计与落地

1、短期记忆架构设计与落地

短期记忆让你的 AI 智能体应用能够在单个线程或对话中记住之前的交互。线程会组织一个会话中的多次交互，类似于电子邮件将消息分组为单个对话的方式。

LangGraph 将短期记忆作为 AI 智能体状态的一部分进行管理，并通过线程范围的检查点持久化。这种状态通常包括对话历史以及其他状态化数据，例如：上传的文件、检索的文档或生成的工件。通过将这些内容存储在图的状态中，AI 智能体可以访问给定对话的完整上下文，同时保持不同线程之间的分离。

1.1、管理短期记忆

对话历史是短期记忆的最常见形式，而长对话对当前的大语言模型（LLMs）来说是一个挑战。完整的对话历史可能无法完全放入 LLM 的上下文窗口中，从而导致无法恢复的错误。即使你的 LLM 支持完整的上下文长度，大多数 LLM 在处理长上下文时表现仍然不佳。它们会被过时或离题的内容“分散注意力”，同时还会导致响应速度变慢和成本增加。

聊天模型通过消息接受上下文，这些消息包括开发者提供的指令（系统消息）和用户输入（人类消息）。在聊天应用中，消息会在人类输入和模型响应之间交替，随着时间推移，消息列表会变得越来越长。由于上下文窗口有限，且消息列表中的 token 数量过多可能会导致成本增加，因此许多 AI 智能体应用可以从手动删除或忘记过时信息。

2、长期记忆架构设计与落地

LangGraph 中的长期记忆允许系统在不同的对话或会话中保留信息。与线程范围的短期记忆不同，长期记忆是保存在自定义的“命名空间（namespaces）中的。

长期记忆是一个复杂的挑战，没有一种通用的解决方案。然而，以下问题提供了一个框架，帮助你了解不同的技术：

• 记忆的类型是什么？人类使用记忆来记住事实（语义记忆）、经历（情景记忆）和规则（程序性记忆）。AI 智能体也可以以同样的方式使用记忆。例如：AI 智能体可以使用记忆来记住关于用户的特定事实，以完成任务。
• 你希望何时更新记忆？记忆可以作为 AI 智能体应用程序逻辑的一部分进行更新（例如：“热路径”上）。在这种情况下，AI 智能体通常会在回应用户之前决定记住事实。或者，记忆可以作为一个后台任务进行更新（在后台/异步运行的逻辑中生成记忆）。

3、记忆类型剖析

不同的 AI 智能体应用需要不同类型的记忆。尽管类比并不完美，但研究人类记忆类型可以提供一些见解。一些研究甚至将这些人类记忆类型映射到 AI 智能体中使用的类型。

3.1、语义记忆

语义记忆，无论是人类还是 AI 智能体，都涉及对特定事实和概念的保留。在人类中，它可能包括在学校学到的信息以及对概念及其关系的理解。对于 AI 智能体，语义记忆通常用于通过记住过去的交互中的事实或用于个性化应用的概念。

注意：语义记忆与“语义搜索”不同。语义搜索是一种通过“含义”（通常是嵌入向量）查找相似内容的技术。语义记忆是心理学中的一个术语，指的是存储事实和知识，而语义搜索是一种基于含义而非精确匹配检索信息的方法。

第一、用户画像（Profile）

语义记忆可以通过不同的方式管理。例如，记忆可以是一个单一的、不断更新的“用户画像”，其中包含关于用户、组织或其他实体（包括 AI 智能体本身）的范围明确且具体的信息。用户画像通常只是一个带有各种键值对的 JSON 文档，你选择这些键值对来代表你的领域。

在记住用户画像时，你需要确保每次都在更新画像。因此，你需要传入之前的画像，并让大模型生成一个新的画像（或者生成一个 JSON 补丁来应用到旧画像上）。随着画像变得越来越大，这可能会变得容易出错，可能需要将画像拆分为多个文档，或者在生成文档时进行严格解码，以确保记忆模式保持有效。

第二、文档集合（Collection）

或者，记忆可以是一个随着时间不断更新和扩展的文档集合。每个单独的记忆可以更狭窄地限定范围，更容易生成，这意味着你不太可能随着时间的推移丢失信息。对于 LLM 来说，生成新对象以存储新信息比将新信息与现有画像协调起来更容易。因此，使用文档集合通常会导致更高的回忆率。

然而，这将一些复杂性转移到了记忆更新上。大模型现在必须删除或更新列表中的现有项目，这可能会很棘手。此外，一些大模型可能默认过度插入，而另一些大模型可能默认过度更新。

使用文档集合还意味着将复杂性转移到对列表的记忆搜索上。当前的存储支持语义搜索和按内容过滤。

最后，使用记忆集合可能会使向大模型提供全面上下文变得具有挑战性。尽管单个记忆可能遵循特定的模式，但这种结构可能无法捕捉记忆之间的完整上下文或关系。因此，当使用这些记忆来生成回应时，大模型可能会缺少在统一画像方法中更容易获得的重要上下文信息。

无论采用哪种记忆管理方法，核心要点是 AI 智能体将使用语义记忆来支撑其回应，这通常会导致更个性化和相关的互动。

3.2、情景记忆

情景记忆，无论是人类还是 AI 智能体，都涉及回忆过去的事件或行动。事实可以写入语义记忆，而经历可以写入情景记忆。对于 AI 智能体，情景记忆通常用于帮助 AI 智能体记住如何完成任务。

在实践中，情景记忆通常是通过少量样本提示（few-shot example prompting）来实现的，AI 智能体通过学习过去的序列来正确执行任务。有时“展示”比“告诉”更容易，LLM 从示例中学习得很好。少量样本学习让你可以通过在提示中更新输入-输出示例来“编程”你的 LLM，以展示预期的行为。尽管可以使用各种最佳实践来生成少量样本示例，但挑战通常在于根据用户输入选择最相关的示例。

注意：记忆存储只是存储少量样本数据的一种方式。如果你想更多地参与开发，或者将少量样本更紧密地与你的评估框架联系起来，你也可以使用LangSmith 数据集来存储你的数据。然后可以使用现成的动态少量样本示例选择器来实现相同的目标。LangSmith 会为你索引数据集，并根据关键词相似性（使用类似 BM25 的算法）检索与用户输入最相关的少量样本示例。

3.3、程序性记忆

程序性记忆，无论是人类还是 AI 智能体，都涉及记住执行任务所使用的规则。在人类中，程序性记忆就像内化的任务执行知识，例如：通过基本的运动技能和平衡感学会骑自行车。而情景记忆则涉及回忆特定的经历，比如：你第一次在没有辅助轮的情况下成功骑自行车，或者一次难忘的自行车骑行经历。对于 AI 智能体，程序性记忆是模型权重、AI 智能体代码和 AI 智能体提示词的组合，这些共同决定了 AI 智能体的功能。

在实践中，AI 智能体修改其大模型权重或重写代码的情况相对较少。然而，AI 智能体修改自己的提示词则更为常见。

一种有效的改进 AI 智能体指令的方法是通过“反思”或元提示（meta-prompting）。这涉及将 AI 智能体当前的指令（例如：系统提示词）以及最近的对话或明确的用户反馈提示词给 AI 智能体。然后，AI 智能体根据这些输入来改进自己的指令。这种方法特别适用于那些难以提前指定指令的任务，因为它允许代理从交互中学习和适应。

例如：我们构建了一个使用外部反馈和提示词重写来生成高质量推文摘要的推文生成器。在这种情况下，具体的摘要提示词很难提前指定，但用户可以很容易地批评生成的推文，并提供关于如何改进摘要过程的反馈。

以下是使用 LangGraph 记忆存储实现此功能的伪代码示例。使用存储来保存提示，​​update_instructions​​​节点获取当前提示（以及捕获在​​state["messages"]​​​中的与用户的对话反馈），更新提示词，并将新提示词保存回存储。然后，​​call_model ​​从存储中获取更新后的提示词并使用它来生成回应。

# Node that *uses* the instructions
def call_model(state: State, store: BaseStore):
    namespace = ("agent_instructions", )
    instructions = store.get(namespace, key="agent_a")[0]
    # Application logic
    prompt = prompt_template.format(instructinotallow=instructions.value["instructions"])
    ...
# Node that updates instructions
def update_instructions(state: State, store: BaseStore):
    namespace = ("instructions",)
    current_instructions = store.search(namespace)[0]
    # Memory logic
    prompt = prompt_template.format(instructinotallow=instructions.value["instructions"], cnotallow=state["messages"])
    output = llm.invoke(prompt)
    new_instructions = output['new_instructions']
    store.put(("agent_instructions",), "agent_a", {"instructions": new_instructions})
    ...

4、写入记忆架构设计与落地

AI 智能体写入记忆主要有两种方法：“热路径”（in the hot path）和“后台”（in the background）。

4.1、在热路径中（热更新）

在运行时创建记忆既有优点也有挑战。优点是，这种方法可以实现实时更新，使新记忆能够立即用于后续交互。它还可以实现透明性，因为用户可以在记忆被创建和存储时得到通知。

然而，这种方法也存在挑战。如果 AI 智能体需要一个新工具来决定要记住什么内容，这可能会增加复杂性。此外，推理要保存到记忆中的内容可能会对 AI 智能体的延迟产生影响。最后，AI 智能体需要在创建记忆和其他职责之间进行多任务处理，这可能会影响记忆的数量和质量。

例如，ChatGPT 使用一个 ​​save_memories ​​工具将记忆作为内容字符串插入或更新，每次用户发送消息时，它都会决定是否以及如何使用这个工具。

4.2、在后台（冷更新）

将创建记忆作为一个单独的后台任务有诸多优点。它可以消除主应用中的延迟，将应用逻辑与记忆管理分离，并让 AI 智能体能够更专注地完成任务。这种方法还提供了灵活的时间安排，以避免重复工作。

然而，这种方法也有自己的挑战。确定记忆写入的频率变得至关重要，因为更新不频繁可能会导致其他线程缺少新的上下文。决定何时触发记忆形成也很重要。常见的策略包括在设定的时间后调度（如果发生新事件则重新调度）、使用 cron 调度，或者允许用户或应用逻辑手动触发。

5、记忆存储架构设计与落地

LangGraph 将长期记忆作为 JSON 文档存储在存储中。每个记忆都组织在一个自定义的命名空间（类似于文件夹）和一个独特的键（类似于文件名）下。命名空间通常包括用户或组织 ID 或其他标签，以便更容易地组织信息。这种结构支持记忆的层次化组织。然后通过内容过滤支持跨命名空间搜索。

from langgraph.store.memory import InMemoryStore
def embed(texts: list[str]) -> list[list[float]]:
    # Replace with an actual embedding function or LangChain embeddings object
    return [[1.0, 2.0] * len(texts)]
# InMemoryStore saves data to an in-memory dictionary. Use a DB-backed store in production use.
store = InMemoryStore(index={"embed": embed, "dims": 2})
user_id = "my-user"
application_context = "chitchat"
namespace = (user_id, application_context)
store.put(
    namespace,
    "a-memory",
    {
        "rules": [
            "User likes short, direct language",
            "User only speaks English & python",
        ],
        "my-key": "my-value",
    },
)
# get the "memory" by ID
item = store.get(namespace, "a-memory")
# search for "memories" within this namespace, filtering on content equivalence, sorted by vector similarity
items = store.search(
    namespace, filter={"my-key": "my-value"}, query="language preferences"
)

本文转载自​​​玄姐聊AGI​​  作者：玄姐