LLM - AgentScope + Mem0 搭建实战可用的 AI Agent 记忆系统

文章目录

  • 快读
  • 工程实战指南
    • [一、为什么Agent 一定要有"记忆"](#一、为什么Agent 一定要有“记忆”)
    • [二、记忆系统的工程抽象:短期 vs 长期](#二、记忆系统的工程抽象:短期 vs 长期)
      • [2.1 在不同框架里的概念映射](#2.1 在不同框架里的概念映射)
      • [2.2 通用集成模式:四步循环](#2.2 通用集成模式:四步循环)
    • [三、短期记忆实战:用 AutoContextMemory 做上下文工程](#三、短期记忆实战:用 AutoContextMemory 做上下文工程)
      • [3.1 三大策略:缩减 / 卸载 / 隔离](#3.1 三大策略:缩减 / 卸载 / 隔离)
      • [3.2 用 AutoContextMemory 落地上下文工程](#3.2 用 AutoContextMemory 落地上下文工程)
    • [四、长期记忆实战:Mem0 架构与 AgentScope 集成](#四、长期记忆实战:Mem0 架构与 AgentScope 集成)
      • [4.1 Mem0 背后的 Record & Retrieve 流程](#4.1 Mem0 背后的 Record & Retrieve 流程)
      • [4.2 AgentScope 中对 Mem0 的集成方式](#4.2 AgentScope 中对 Mem0 的集成方式)
      • [4.3 Mem0 与 RAG 的工程差异](#4.3 Mem0 与 RAG 的工程差异)
    • [五、端到端实践:用 AgentScope + AutoContextMemory + Mem0 搭一个可用的智能助手](#五、端到端实践:用 AgentScope + AutoContextMemory + Mem0 搭一个可用的智能助手)
      • [5.1 步骤 1:选框架与模型](#5.1 步骤 1:选框架与模型)
      • [5.2 步骤 2:接好短期记忆(上下文工程)](#5.2 步骤 2:接好短期记忆(上下文工程))
      • [5.3 步骤 3:接好长期记忆(Mem0)](#5.3 步骤 3:接好长期记忆(Mem0))
      • [5.4 步骤 4:构建带双层记忆的 Agent](#5.4 步骤 4:构建带双层记忆的 Agent)
      • [5.5 步骤 5:设计"写什么"和"读什么"的策略](#5.5 步骤 5:设计“写什么”和“读什么”的策略)
    • 六、工程落地关注点与优化建议
      • [6.1 准确性:别让"错误记忆"害了你](#6.1 准确性:别让“错误记忆”害了你)
      • [6.2 安全与隐私:长期记忆=长期风险](#6.2 安全与隐私:长期记忆=长期风险)
      • [6.3 多模态与未来演进](#6.3 多模态与未来演进)
    • 七、给工程实践者的几条建议
  • 实操
    • [一、路由 Agent 的系统 Prompt 设计](#一、路由 Agent 的系统 Prompt 设计)
      • [1.1 路由 Agent 的职责](#1.1 路由 Agent 的职责)
      • [1.2 路由 Agent 系统 Prompt 示例](#1.2 路由 Agent 系统 Prompt 示例)
    • [三、Mem0 记忆 schema 设计示意](#三、Mem0 记忆 schema 设计示意)
    • [四、AgentScope 多 Agent + Mem0 示意代码](#四、AgentScope 多 Agent + Mem0 示意代码)
      • [4.1 初始化模型与短期记忆](#4.1 初始化模型与短期记忆)
      • [4.2 初始化 Mem0LongTermMemory(长期记忆)](#4.2 初始化 Mem0LongTermMemory(长期记忆))
      • [4.3 定义路由 Agent](#4.3 定义路由 Agent)
      • [4.4 定义业务 Agent(以订单 Agent 为例)](#4.4 定义业务 Agent(以订单 Agent 为例))

快读

记忆的基本概念

  • 大模型记忆分成会话级(短期)和跨会话级(长期):前者保证一段对话内的上下文连贯,后者在多次会话间保留用户偏好、事实和经验。
  • 不同框架命名不同,但都遵循"短期(Session 内)+长期(跨 Session)"的划分,比如 Google ADK 的 Session/Memory、LangChain 的 short-term/long-term memory、AgentScope 的 memory/long_term_memory。

Agent 集成记忆的通用模式

  • 通用流程是:推理前从长期记忆按当前 query 检索 → 将检索结果注入当前会话上下文 → 推理结束后从会话消息中抽取可沉淀的信息写回长期记忆 → 长期记忆内部用 LLM+向量化做提取和检索。
  • 短期记忆保存整个会话中的所有消息(用户、模型、工具调用等),直接作为 LLM 的上下文,受 max token 限制,需要压缩、摘要、卸载等策略管理。

短期记忆的上下文工程

  • 核心三种策略:上下文缩减(保留前 N 字/摘要)、上下文卸载(原文存外部,只在上下文中留引用)、上下文隔离(多 Agent,把上下文拆给子 Agent)。
  • 不同框架的实现示例:Google ADK 用 events_compaction_config 配压缩;LangChain 用 SummarizationMiddleware 做摘要;AgentScope 用 AutoContextMemory 提供 6 级渐进压缩和四层存储,支持更细粒度控制和追溯。

长期记忆的技术架构

  • 长期记忆围绕 Record & Retrieve 两个流程,核心组件包括:LLM、Embedding 模型、向量库、图数据库、Reranker 和用于审计的 SQLite 日志。
  • Record 流程是 LLM 提取事实 → 向量化 → 存向量库(可能同步到图库)→ 写日志;Retrieve 流程是 query 向量化 → 向量检索 → 图库补充 → 重排 → 返回结果注入上下文。

与 RAG、产品和趋势

  • 个性化长期记忆在技术架构上与 RAG 相似(向量存储、相似性检索、注入上下文),但更强调用户画像、记忆管理和跨会话个性化,而不是文档问答。
  • 行业趋势包括:记忆即服务(MaaS)、更精细的分层记忆管理、多模态记忆、以及模型参数化记忆等;当前主流路线仍是外部记忆增强,mem0 等开源项目在长期记忆产品中较领先。

工程实战指南

一、为什么Agent 一定要有"记忆"

在真实业务里,LLM 的"无记忆"会非常致命:它只看得到当前上下文窗口内的内容,看不到更久远的历史,也无法跨会话记住用户是谁、喜欢什么、做过什么。

当对话变长、任务变复杂、用户希望个性化体验时,没有记忆系统的 Agent 会暴露出三类典型问题。

  • 会话内:一旦 token 超过窗口,就"失忆",前文的讨论、工具输出、分析过程都丢了。
  • 会话间:下次再来,完全认不出用户,不知道用户偏好、历史决策和约定。
  • 成本侧:长对话全量塞进上下文,费用爆炸,延迟变长,还容易引出无关内容。

因此,一个工程上可用的记忆系统,至少要覆盖两类能力:

  • 短期记忆:在单次会话中做"上下文工程",在有限 token 内尽量保留重要历史。
  • 长期记忆:跨会话沉淀用户信息、任务状态、领域经验,并在需要时按需加载。

下面的内容会完全站在工程实战视角,基于 AgentScope 做短期记忆管理(AutoContextMemory),用 Mem0 做长期记忆,并给出端到端代码示例。


二、记忆系统的工程抽象:短期 vs 长期

从工程视角,记忆可以用一个很简单的划分:是否跨 Session

  • 短期记忆(Session 级):只在一次连续会话内有效,直接参与当前模型推理。
  • 长期记忆(跨 Session):在多次会话之间共享,如用户画像、偏好、历史任务、常驻知识等。

2.1 在不同框架里的概念映射

虽然名字不同,但主流框架本质上都是这两层结构。

框架 短期记忆概念 长期记忆概念 说明
Google ADK Session(会话事件) Memory(跨对话知识库) Session 内交互 + 独立 Memory 组件
LangChain short-term memory long-term memory(外挂) 长期记忆是高阶扩展能力
AgentScope memory(Memory 接口) long_term_memory 接口 短期和长期都有明确组件边界

在本文方案中:

  • 短期记忆:选择 AgentScope 的 AutoContextMemory,自动做上下文压缩与卸载。
  • 长期记忆:通过 Mem0LongTermMemory 集成 Mem0,托管 Record / Retrieve 的所有复杂逻辑。

2.2 通用集成模式:四步循环

无论用什么框架,Agent + Memory 的通用循环基本都是这四步:

  1. 推理前:根据当前 user query,从长期记忆检索相关信息。
  2. 上下文注入:将检索结果作为额外上下文注入短期记忆。
  3. 推理执行:LLM 基于"当前对话 + 长期记忆"做推理。
  4. 记忆更新:从本轮对话中抽取值得长期保存的信息写回长期记忆。

AgentScope + Mem0 默认已经帮你实现了大部分 glue 逻辑,你只需要配置好 Memory 组件即可。


三、短期记忆实战:用 AutoContextMemory 做上下文工程

短期记忆的问题不是"有没有",而是"怎么控制不爆窗又不丢关键信息"

典型痛点是:工具调用结果很长、历史对话很多、但是大部分内容只在当时有用、之后只需要结论。

3.1 三大策略:缩减 / 卸载 / 隔离

文章中把狭义的上下文工程归纳为三大策略,非常贴合工程落地。

  • 上下文缩减(Reduction):
    • 对长文本保留前 N 字符作为预览;
    • 或直接生成摘要,只留关键结论。
  • 上下文卸载(Offloading):
    • 原始大内容写到外部存储(文件 / DB),上下文中只保留引用 ID;
    • 当确实需要时再按 ID 加载原文。
  • 上下文隔离(Isolation):
    • 使用多 Agent,将复杂子任务的上下文隔离到子 Agent 中;
    • 主 Agent 只要看子 Agent 的结果,而不是所有中间过程。

这些策略的选择原则是:时间远近、数据类型、是否需要可恢复原文等。

3.2 用 AutoContextMemory 落地上下文工程

AgentScope 的 AutoContextMemory 提供了一套工程实用的实现:

  • 实现 Memory 接口,可以直接挂在 Agent 上。
  • 支持 6 种渐进式压缩策略 ,例如:
    • 优先压缩历史工具调用结果;
    • 卸载大型消息到外部存储;
    • 合并多轮闲聊为摘要等。
  • 提供四层存储:工作内存、原始内存、卸载上下文和压缩事件,方便追溯和调试。

一个典型的 Java 配置示例是这样的:

java 复制代码
// 创建 AutoContextMemory,配置阈值与 token 限制
AutoContextMemory memory = new AutoContextMemory(
    AutoContextConfig.builder()
        .msgThreshold(100)              // 历史消息超过 100 条开始触发压缩
        .maxToken(128 * 1024)           // 最大上下文 token 上限
        .tokenRatio(0.75)               // 超过 75% 上限时启动压缩流程
        .build(),
    model
);

// 创建带短期记忆的 Agent
ReActAgent agent = ReActAgent.builder()
    .name("Assistant")
    .model(model)
    .memory(memory)
    .build();

工程实践建议:

  • 初期可以设置较宽松的 maxToken + 较低的 msgThreshold,让 Agent 尽量多保留历史,先观察 token 消耗情况再收紧。
  • 若工具调用结果较长,优先打开"卸载大消息 + 留摘要 + 存引用"策略,而不是简单截断。

四、长期记忆实战:Mem0 架构与 AgentScope 集成

短期记忆解决的是"一次对话里别失忆",长期记忆要解决的则是"下次再见时还能认出你"。

这就需要一套能跨会话持续存、能精准检索的记忆基础设施,Mem0 就是目前最成熟的开源选择之一。

4.1 Mem0 背后的 Record & Retrieve 流程

从架构图来看,长期记忆主要围绕两个过程:Record 和 Retrieve。

核心组件:

  • LLM:从短期会话中抽取"可记忆事实"(用户偏好、行为、总结等)。
  • Embedding 模型:把文本变成向量,用于相似度检索。
  • VectorStore:存储记忆向量 + 元数据(时间、来源、类型等)。
  • GraphStore(可选):存实体与关系,用于复杂推理。
  • Reranker:对初步检索结果进行重排,增强相关性。
  • SQLite:记录所有记忆读写操作,方便审计和回溯。

Record 流程:

短期会话消息 -> LLM 提取事实 -> 向量化 -> 写入 VectorStore/GraphStore -> 记录操作日志

Retrieve 流程:

当前 query -> 向量化 -> 在向量库检索 top-k -> 图数据库补充关系 -> Rerank -> 返回上下文

对开发者而言,Mem0 已经把这些复杂能力封装成统一 API,AgentScope 做的事情是:在合适的时机调用 Mem0 的 Record / Retrieve,并把结果接到 Agent 的上下文里。

4.2 AgentScope 中对 Mem0 的集成方式

AgentScope 提供了 Mem0LongTermMemory 实现,可以直接挂在 ReActAgent 上作为 longTermMemory。

java 复制代码
// 1. 初始化 Mem0 长期记忆组件
Mem0LongTermMemory mem0Memory = new Mem0LongTermMemory(
    Mem0Config.builder()
        .apiKey("your-mem0-api-key")   // 从 Mem0 控制台获取
        // .baseUrl("https://api.mem0.ai") // 如需自托管或特定环境可配置
        .build()
);

// 2. 创建带短期 + 长期记忆的 Agent
ReActAgent agent = ReActAgent.builder()
    .name("Assistant")
    .model(model)
    .memory(memory)           // 短期记忆:AutoContextMemory
    .longTermMemory(mem0Memory) // 长期记忆:Mem0
    .build();

这样搭起来之后:

  • Agent 在对话过程中的"可长期记忆信息"会通过 Mem0LongTermMemory 写入 Mem0。
  • 每次新 query 到来时,Mem0 会基于用户身份和 query 自动检索相关记忆,并注入到短期记忆中。

4.3 Mem0 与 RAG 的工程差异

Mem0 的底层技术栈非常像一个"个体级 RAG 系统":向量化、检索、重排、注入上下文。

但与文档问答型 RAG 相比,它有几个工程上的关键不同点:

  • 写入来源不同:
    • RAG:主要从已有文档/知识库导入。
    • Mem0:主要从用户交互中增量抽取(会话驱动)。
  • 粒度不同:
    • RAG:文档段落、章节等。
    • Mem0:用户偏好、行为事实、历史决策、任务状态。
  • 维度不同:
    • RAG:多用户共享一个知识库。
    • Mem0:更强调 user 维度隔离,一人一套长期记忆。

这也意味着,在设计长记忆 schema 时,要先想清楚:按用户、按任务、按业务域,分别沉淀哪些信息。


五、端到端实践:用 AgentScope + AutoContextMemory + Mem0 搭一个可用的智能助手

5.1 步骤 1:选框架与模型

  • 选择 AgentScope 作为 Agent 框架(Java 生态 + 企业级场景友好)。
  • 选择一个主模型(如企业自建模型或主流闭源 API),并为 AutoContextMemory 配备一个相同或轻量模型用于 token 估算等。

伪代码示例:

复制代码
LLMModel model = ... // 初始化你的主 LLM 模型 

5.2 步骤 2:接好短期记忆(上下文工程)

根据业务预期对话长度配置 AutoContextMemory:

java 复制代码
AutoContextMemory memory = new AutoContextMemory(
    AutoContextConfig.builder()
        .msgThreshold(80)           // 单会话超过 80 条消息后开始压缩
        .maxToken(64 * 1024)        // 单次调用最大 64k tokens
        .tokenRatio(0.8)            // 超过 80% 上限时触发压缩
        .build(),
    model
);

工程建议:

  • 如果你的业务中工具输出特别长(如代码生成、日志检索),建议在 AutoContextConfig 里打开"优先卸载工具输出"的策略,而不是让它留在工作内存里长期占位。
  • 对咨询类场景,可以更激进地做"多轮归纳摘要",每隔 N 轮将闲聊合并成一段"对话总结"。

5.3 步骤 3:接好长期记忆(Mem0)

准备好 Mem0 服务(云端或自托管),拿到 apiKey/baseUrl 等。

java 复制代码
Mem0LongTermMemory mem0Memory = new Mem0LongTermMemory(
    Mem0Config.builder()
        .apiKey("your-mem0-api-key")
        // .baseUrl("http://your-mem0-host:port") // 可选
        .build()
);

5.4 步骤 4:构建带双层记忆的 Agent

java 复制代码
ReActAgent agent = ReActAgent.builder()
    .name("PersonalAssistant")
    .model(model)
    .memory(memory)          // 短期记忆:AutoContext
    .longTermMemory(mem0Memory) // 长期记忆:Mem0
    .build();

此时,你拿到的是一个具备:

  • 会话内自动上下文控制;
  • 会话间自动长期记忆的 Agent 架子。

5.5 步骤 5:设计"写什么"和"读什么"的策略

有了 Mem0,并不代表所有内容都该写进去,否则长期记忆会非常噪声。工程上可以这样设计规则:

写入策略(Record):

  • 写入内容类型:
    • 用户显式偏好("我喜欢简洁回答""以后都用中文回复")。
    • 用户的长期任务/目标("接下来两周帮我准备面试")。
    • 具有持续价值的事实(个人背景、常驻配置、约定好的工作流)。
  • 写入时机:
    • 每轮结束后由一个"记忆提取 Prompt"让 LLM 决定:当前轮是否有可长期保存的信息,有则调用 Mem0。
    • 或者只在特定工具调用 / 特定意图触发时写入。

读取策略(Retrieve):

  • 每次新 Session 启动时,根据 userId 和当前 query 做一次 Mem0 检索,将 top-k 结果注入到短期记忆开头部分。
  • 对特定意图(如"继续上次的计划")可以再次主动调用 Mem0,按"任务维度"检索历史状态。

在 AgentScope 中,这些策略通常通过:

  • 自定义工具 / 中间层逻辑;
  • 或者在 ReActAgent 的规划逻辑中,显式增加"记忆管理工具调用"步骤来实现。

六、工程落地关注点与优化建议

真正落地时,除了"能用",还要关注准确性、成本、安全与多模态扩展等问题。

6.1 准确性:别让"错误记忆"害了你

  • 记忆建模:需要一个合理的用户画像 schema,区分"偏好""事实""任务状态"等不同类型。
  • 记忆管理:要支持更新与遗忘,例如用户改口、撤回、账号注销等场景。
  • 检索准确性:适配合适的 embedding 模型和重排策略,对误召回要有容错策略(例如让模型看到"这可能不完全相关")。

6.2 安全与隐私:长期记忆=长期风险

  • 数据加密与访问控制:后端必须做好租户级隔离和权限校验。
  • 防数据中毒:对外部来源的内容(如用户上传文件)写入记忆前需要毒性检测和过滤。
  • 用户控制权:提供"查看/导出/删除我的记忆"接口和 UI,是产品层必备能力。

6.3 多模态与未来演进

当前大多数记忆系统仍然以文本为主,但趋势非常明确:

  • 多模态记忆:图像、语音、文本统一编码到同一向量空间,对工程侧意味着统一 embedding + 高性能索引方案。
  • Memory-as-a-Service:记忆系统独立成云服务,像数据库一样被多个 Agent 应用复用。Mem0 本质上就是这条路线的代表之一。
  • 参数化记忆:未来会出现更多"Memory Adapter"类技术,把一部分高频记忆写进模型参数,结合外部 Mem0 形成"内外混合记忆"。

七、给工程实践者的几条建议

  • 先把短期记忆做好,再上长期记忆:先用 AutoContextMemory 解决"会话内暴窗"的问题,再引入 Mem0。
  • 长期记忆从"小而精"开始:先只记"用户偏好 + 关键任务状态",避免一开始就把所有内容都写进去变成噪声堆。
  • 把记忆系统当成基础设施:像设计数据库那样设计 schema、权限和运维,而不是只当一个"附属功能"

实操

一、路由 Agent 的系统 Prompt 设计

1.1 路由 Agent 的职责

  • 根据用户输入识别意图。
  • 选择合适的业务 Agent(如:订单 Agent、客服 Agent、营销 Agent 等)。
  • 在必要时,将用户长期偏好/历史上下文作为提示信息附带给业务 Agent。

1.2 路由 Agent 系统 Prompt 示例

text 复制代码
# 角色
你是一个多智能体系统中的「意图路由 Agent」。
你的任务是:
1. 理解用户当前输入的真实意图。
2. 在多个业务 Agent 中选择最合适的一个或多个进行处理。
3. 为后续的业务 Agent 提供简明的任务说明和必要的用户上下文。

# 可用业务 Agent 列表(示例)
- order_agent:处理订单查询、创建、修改、取消等电商订单相关请求。
- service_agent:处理售后、投诉、退款、物流异常等服务类问题。
- marketing_agent:处理优惠券、营销活动咨询、个性化推荐等问题。
- faq_agent:处理通用问题、基础说明、帮助文档查询等。

# 记忆相关说明
系统为每个用户维护短期记忆和长期记忆:
- 短期记忆:当前会话中的历史对话,由底层 AutoContextMemory 自动管理,你无需关心 token 细节。
- 长期记忆:基于 Mem0 存储的用户偏好、历史行为、长期任务状态等,会在路由前自动检索出若干条关键信息。

你会收到一个字段 `user_long_term_memory`,其中包含与本次请求最相关的若干条用户记忆(若没有则为空)。
你需要:
1. 在路由决策时参考这些记忆(如用户偏好的沟通方式、历史问题背景等)。
2. 在返回给业务 Agent 的任务描述中,合理引用这些记忆(例如"用户之前反馈过类似物流问题")。

# 输入
你会收到以下结构化输入(由上游系统封装):
- user_query:用户本轮自然语言输入。
- user_long_term_memory:列表,每一条是面向 LLM 的自然语言描述,如:
  - "用户偏好使用中文简洁回答"
  - "用户在 2024-12-20 购买过 iPhone 15 Pro,订单号 XXX"
  - "用户对上一次售后处理不满意,期望更快答复"

# 输出要求
1. 以 JSON 格式输出你的路由决策,**不要输出多余自然语言**。
2. JSON 字段定义:
   - target_agents:数组,元素为需要调用的业务 Agent 名称(如 ["order_agent"])。
   - route_reason:字符串,简要说明路由原因(面向开发者调试,可引用 user_long_term_memory)。
   - task_instruction:字符串,发给目标业务 Agent 的任务描述,要求:
     - 用简洁中文撰写。
     - 说明用户想要解决的问题。
     - 补充与本次任务相关的长期记忆信息(如果有)。

# 输出示例
{
  "target_agents": ["service_agent"],
  "route_reason": "用户反馈包裹多次丢件,且长期记忆显示其对物流问题较为敏感",
  "task_instruction": "用户反馈本次包裹疑似丢件,请你查询物流进度并给出处理方案。用户过去多次遇到类似问题,对响应速度比较敏感,请在回答中体现重视并说明后续跟进方式。"
}



## 二、业务 Agent 的 Prompt 设计(结合短期 + 长期记忆)

假设有一个 `order_agent`,需要使用 AutoContextMemory 做短期记忆管理,Mem0 提供的长期记忆会通过上层逻辑注入到短期上下文中(例如以"系统消息 + 历史信息"的方式)。

### 2.1 订单 Agent 系统 Prompt 示例

```text
# 角色
你是电商平台中的「订单服务 Agent」,专门处理与订单相关的业务:
- 订单创建、修改、取消
- 订单状态、物流进度查询
- 订单售后相关的前置处理(需要时会转交给 service_agent)

# 上下文来源说明
- 短期记忆:当前会话的历史消息,由系统通过 AutoContextMemory 自动管理并注入。
- 长期记忆:系统可能会通过一段系统消息提供与用户历史订单、偏好相关的信息(由 Mem0 提供)。

你需要:
1. 在回答用户问题时,优先结合当前会话最新信息。
2. 合理使用长期记忆中与本次问题相关的信息,但不要引用与当前问题无关的历史细节。
3. 对用户保持简洁、专业、礼貌的中文回复。

# 回答风格
- 结构清晰,可使用有序/无序列表。
- 优先给出直接结论,然后根据需要提供补充说明。
- 避免暴露内部系统字段名、ID 结构等实现细节。

# 若需要调用工具
如果系统为你提供了工具(例如:查询订单详情、查询物流信息等),请遵循工具使用规范:
- 先明确你需要什么信息。
- 再决定是否调用工具。
- 最终向用户给出自然语言解释,而不是工具返回的原始 JSON。

三、Mem0 记忆 schema 设计示意

在多 Agent + 意图路由场景中,Mem0 的记忆可以从三个维度建模:

  1. 用户维度(user_profile / preferences)
  2. 任务/会话维度(task / session)
  3. 业务维度(domain:order / service / marketing 等)

一个简单的 schema 思路(伪结构,真实实现由 Mem0 内部管理):

json 复制代码
{
  "id": "memory_id",
  "user_id": "user_123",
  "domain": "order",          // order/service/marketing/global
  "type": "preference",       // preference/fact/task_state/summary
  "content": "用户偏好使用中文简洁回答",
  "created_at": "2025-12-27T10:00:00Z",
  "metadata": {
    "source": "chat",
    "session_id": "session_abc",
    "importance": 0.8
  }
}

在工程代码里,一般做法是:

  • 写入时:根据规则抽取"可记忆内容",拼成自然语言 content + 元数据 metadata,交给 Mem0。
  • 读取时:根据 user_id 和当前 query 检索出若干条自然语言记忆,直接拼到路由 Agent 的 user_long_term_memory 输入列表中。

四、AgentScope 多 Agent + Mem0 示意代码

下面给出一个简化 Java 伪代码,体现结构和关键点,方便你在项目中改造。

4.1 初始化模型与短期记忆

java 复制代码
// 初始化主模型
LLMModel model = ...; // 例如 OpenAI/Azure/自建模型

// 初始化 AutoContextMemory(短期记忆)
AutoContextMemory shortTermMemory = new AutoContextMemory(
    AutoContextConfig.builder()
        .msgThreshold(100)       // 消息超过 100 条开始压缩
        .maxToken(128 * 1024)    // 单次上下文 token 上限
        .tokenRatio(0.75)        // 超过 75% 开始触发压缩
        .build(),
    model
);

4.2 初始化 Mem0LongTermMemory(长期记忆)

java 复制代码
Mem0LongTermMemory mem0Memory = new Mem0LongTermMemory(
    Mem0Config.builder()
        .apiKey("your-mem0-api-key")
        // .baseUrl("https://api.mem0.ai") // 如有自建可替换
        .build()
);

4.3 定义路由 Agent

java 复制代码
ReActAgent routerAgent = ReActAgent.builder()
    .name("RouterAgent")
    .model(model)
    .memory(shortTermMemory)        // 路由 Agent 也使用短期记忆
    .longTermMemory(mem0Memory)     // 可选:让路由 Agent 也使用 Mem0
    .systemPrompt(ROUTER_SYSTEM_PROMPT) // 即上面「路由 Agent 系统 Prompt」
    .build();

业务侧调用时,可以在调用 routerAgent 前,显式从 Mem0 拉一遍用户相关记忆,拼到 user_long_term_memory 字段(也可以由 Mem0LongTermMemory 在内部自动完成):

java 复制代码
// 伪代码:组装路由输入
Map<String, Object> routerInput = new HashMap<>();
routerInput.put("user_query", userQuery);
routerInput.put("user_long_term_memory", mem0Memory.search(userId, userQuery)); // 返回若干条文本记忆

String routerResultJson = routerAgent.run(JsonUtils.toJson(routerInput));
RouterDecision decision = JsonUtils.fromJson(routerResultJson, RouterDecision.class);

4.4 定义业务 Agent(以订单 Agent 为例)

java 复制代码
ReActAgent orderAgent = ReActAgent.builder()
    .name("OrderAgent")
    .model(model)
    .memory(shortTermMemory)          // 也可以为每个 Agent 定制不同 Memory 实例
    .longTermMemory(mem0Memory)       // 如需在业务 Agent 内直接读写长期记忆
    .systemPrompt(ORDER_AGENT_PROMPT) // 即上面「订单 Agent 系统 Prompt」
    .build();

当路由结果返回后:

java 复制代码
for (String target : decision.getTargetAgents()) {
    String taskInstruction = decision.getTaskInstruction();

    if ("order_agent".equals(target)) {
        String reply = orderAgent.run(taskInstruction);
        // 返回给用户
    }
    // 其他 agent 类似
}

记忆写入策略(Record)通常在中间层做:在每轮对话结束后,根据当前对话 + 工具结果,用一个"记忆提取 Prompt"生成若干条可写入 Mem0 的自然语言,再调用 mem0Memory.save(userId, content, metadata) 即可。


相关推荐
冬奇Lab1 小时前
一天一个开源项目(第36篇):EverMemOS - 跨 LLM 与平台的长时记忆 OS,让 Agent 会记忆更会推理
人工智能·开源·资讯
冬奇Lab1 小时前
OpenClaw 源码深度解析(一):Gateway——为什么需要一个"中枢"
人工智能·开源·源码阅读
AngelPP5 小时前
OpenClaw 架构深度解析:如何把 AI 助手搬到你的个人设备上
人工智能
宅小年5 小时前
Claude Code 换成了Kimi K2.5后,我再也回不去了
人工智能·ai编程·claude
九狼5 小时前
Flutter URL Scheme 跨平台跳转
人工智能·flutter·github
ZFSS5 小时前
Kimi Chat Completion API 申请及使用
前端·人工智能
天翼云开发者社区7 小时前
春节复工福利就位!天翼云息壤2500万Tokens免费送,全品类大模型一键畅玩!
人工智能·算力服务·息壤
知识浅谈7 小时前
教你如何用 Gemini 将课本图片一键转为精美 PPT
人工智能
Ray Liang7 小时前
被低估的量化版模型,小身材也能干大事
人工智能·ai·ai助手·mindx
shengjk18 小时前
NanoClaw 深度剖析:一个"AI 原生"架构的个人助手是如何运转的?
人工智能