AgentScope ReMe 中间件实战用嵌入式文件记忆实现跨会话长期记忆【免费下载链接】agentscopeBuild and run agents you can see, understand and trust.项目地址: https://gitcode.com/GitHub_Trending/ag/agentscope导读ReMe 是 AgentScope 团队自研的基于文件的记忆工具包reme-ai本文围绕 AgentScope 仓库中的 ReMe 中间件示例文档 与其配套的 reme_demo.py 演示脚本系统讲解如何把 ReMeMiddleware 接入 AgentScope Agent实现一次会话写入偏好、下次全新会话自动召回的长期记忆能力。读完本文你将掌握 ReMeMiddleware 的安装、构造参数、三种检索控制模式static_control/agent_control/both、session_id记忆作用域、单实例跨 Agent 共享以及底层嵌入式 ReMe 应用的最小化配置原理。背景为什么需要 ReMe它和 mem0 有何不同AgentScope 的长期记忆中间件家族位于 src/agentscope/middleware/_longterm_memory包含AgenticMemoryMiddleware、Mem0Middleware与ReMeMiddleware三类实现。其中 ReMereme-ai具有两个与 mem0 截然不同的设计取向嵌入式进程内运行ReMeMiddleware 直接把reme.ReMe应用构建并持有在进程内无需启动任何独立服务进程对比 mem0 的独立 service 形态。应用在首次使用时惰性创建由await mw.close()显式销毁。听对话式记忆写入ReMe 通过on_reply钩子监听对话——每一轮回复结束后新的(user, assistant)交流片段都会被自动通过 ReMe 的auto_memory任务写回。Agent 自身从不主动保存记忆也没有 add 工具mode参数只决定如何检索不决定是否写入。这个设计决定了 ReMeMiddleware 的 API 形态面向 Agent 的记忆能力是只读搜索 自动写入下面逐一展开。安装与导入reme-ai是 AgentScope 的可选依赖通过 extra 安装即可声明于 pyproject.tomlmemory-reme [reme-ai0.4.0.6]# reme-ai 是可选的 AgentScope 依赖通过 extra 拉取 pip install agentscope[memory-reme] # 等价于 pip install agentscope reme-ai export DASHSCOPE_API_KEYsk-...ReMeMiddleware从中间件包统一导出见 middleware/init.pyfrom agentscope.middleware import ReMeMiddleware from agentscope.tool import Toolkit演示脚本需要 DashScope 密钥因为它用 AgentScope 的 DashScope 对话模型驱动 ReMe 的 LLM 型auto_memory写回用 DashScope 向量模型驱动语义检索——两者都注入到嵌入式应用里唯一需要的外部凭据就是一个 DashScope key。构造 ReMeMiddleware参数模型与模型注入中间件构造时通过普通参数配置没有外部应用需要管理。用户可调设置全部收敛在嵌套的Parameterspydantic 模型上Agent 服务会将该模型的 JSON Schema 渲染成配置表单结构性装配workspace_dir则留在构造函数上ReMeMiddleware( workspace_dir.reme, parametersReMeMiddleware.Parameters( chat_modelmy_chat_model, # 注入 ReMe 的 LLM 组件 # 驱动 auto_memory 写回 embedding_modelmy_embedding_model, # 注入其 embedding 组件 # 同时自动开启 ReMe 的向量存储 modeboth, top_k5, ), )Parameters四个字段的完整语义源码见 middleware.py参数类型 / 默认值行为说明chat_modelChatModelBase \| None默认None注入嵌入式应用默认名as_llm组件应用生命周期内固定提供时只有 DashScope key 也可运行。省略时由 AgentScope 最小化配置从 ReMe 的LLM_*环境变量LLM_BACKEND/LLM_MODEL_NAME/LLM_API_KEY/LLM_BASE_URL见 config.py兜底提供 LLMembedding_modelEmbeddingModelBase \| None默认None注入默认名as_embedding组件并自动开启向量存储embedding_store组件被挂到file_store上省略时检索保持纯 BM25 关键词模式modestatic_control \| agent_control \| both默认both仅决定检索方式写回在所有模式下都自动执行top_kint默认5每次检索返回的最大记忆条数同时也是memory_search工具对外广告的默认limit两个模型都在构造时固定从不取自 Agent因此即便一个中间件实例被多个 Agent 共享嵌入式应用单一 LLM / embedding 组件也有明确且唯一的定义。为什么要注入 embedding_modelAgentScope 的最小化 ReMe 配置在 BM25-only 模式下不创建任何 embedding 组件。注入一个 AgentScopeembedding_model中间件会在 ReMe 启动前补齐并接好这些组件从而启用向量检索——无需另外配置 ReMe 自己的 embedding 凭据。这一点在测试 test_embedding_model_enables_internal_vector_store 中有明确验证提供 embedding 模型后file_store的embedding_store从空字符串变为default并新增as_embedding、embedding_store组件。从实现看注入发生在_ensure_started中middleware.py应用构建后、一次性start()之前先对as_llm/as_embedding调用update_component再启动构造期间embedding_model的dimensions会透传给 ReMe 的 embedding 组件配置。三种检索模式中间件如何控制记忆ReMe每一轮回复后都会通过auto_memory把新交流写回所有模式皆然——mode只选择 Agent检索记忆的方式。默认是both。static_control中间件代查Agent 无感知三步流程对应 on_reply / on_reasoning 钩子on_reply前用最新用户消息在后台启动一个asyncio任务搜索 ReMe与回复并行运行。on_reasoning在每次推理步骤前轮询该任务一旦完成中间件向state.context追加一个AssistantMsg(namememory, ...)的HintBlock内部以## Relevant memories from past conversations为段首见 middleware.py使下一次模型调用可见。注入是best-effort单次回复仅一次模型调用可能在检索完成前就结束提示会落到后续步骤或本轮跳过——与AgenticMemoryMiddleware的取舍一致包含工具调用的轮次两次及以上推理步骤能稳定注入。on_reply后把新产生的(user, assistant)交流片段通过auto_memory写回。注意注入的记忆消息会持续保留在 Agent 上下文中跨轮累积。若长会话堆积过多需配合compress_context或自定义中间件做后处理。agent_control把记忆搜索权交给 Agent中间件只暴露一个memory_search(query, limit)工具其余不干预自动写回照常运行。需显式把工具挂进 Agent 的 toolkitmw ReMeMiddleware(..., modeagent_control) agent Agent( ..., toolkitToolkit(toolsawait mw.list_tools()), middlewares[mw], )同时on_system_prompt会在系统提示词末尾追加一段简短引导告诉 LLM 存在memory_search工具文案见 middleware.py每个工具的具体使用指引则走标准工具 Schema。此模式下不做自动检索。工具实现见 _tools.pymemory_search是只读、并发安全的工具limit缺省值取自中间件的top_k空 query 或空结果返回明确占位文案作为中间件自带的标准能力其权限检查自动放行ALLOW不打断 Agent 调用。both默认两条路径并存自动检索注入 memory_search工具含系统提示词引导同时生效兼顾无感注入与按需显式搜索。记忆作用域session_id写入按会话隔离检索跨会话共享ReMe 的写回按session_id作用域该值在钩子触发时从agent.state.session_id实时读取——中间件从不存储它middleware.py测试 test_session_id_not_stored_on_middleware 验证了中间件没有_session_id属性。而搜索是全 workspace 范围跨越所有会话这正是后一个会话能召回前一个会话的记忆即便session_id不同的原因。要固定一个可续接的会话在 Agent 上设置 idfrom agentscope.state import AgentState agent Agent(..., stateAgentState(session_idalice-main))演示脚本正是如此——session-1写入偏好session-2全新 Agent、空对话上下文通过共享 workspace 召回它。单中间件实例跨多 Agent 共享由于session_id每次调用实时读取不存储、chat model 构造时固定绑定嵌入式应用的单一 LLM一个ReMeMiddleware可以安全地被多个 Agent、多个会话共享——构建一次逐个传入mw ReMeMiddleware( workspace_dir.reme, chat_modelchat_model, embedding_modelembedding_model, modeboth, ) agent_a Agent(..., middlewares[mw], stateAgentState(session_ida)) agent_b Agent(..., middlewares[mw], stateAgentState(session_idb))这正是演示脚本的做法。底层保障有两层写回按各 Agent 的session_id隔离并发检索任务按session_id为键跟踪self._retrieval_tasks不同会话的并发回复互不干扰——相关测试见 test_shared_middleware_isolates_sessions 与 test_concurrent_sessions_isolate_retrieval_tasks。关闭时调用await mw.close()销毁嵌入式应用AgentScope 不管理中间件生命周期finally: await mw.close()配置细节AgentScope 自持的最小化 ReMe 配置中间件始终构建一份 AgentScope 自持的最小化 ReMe 配置config.py而非加载 ReMe 独立版的default.yaml。这份配置完整保留记忆生命周期所需的全部能力对话写回auto_memory任务把每轮交流抽取进每日记忆卡daily card写回发生在on_reply后置钩子且只提交本轮增量对state.context按消息 id 做差集并排除注入的memory提示消息避免历史被重复喂给提取 Agent见 middleware.py 与测试 test_write_back_is_per_turn_increment梦境整合dream consolidationdream_cron每天 23:00cron 表达式0 23 * * *与可手动执行的auto_dream把每日卡整合进 digest 记忆节点与兴趣主题dream_extract_step/dream_integrate_step/dream_topics_step/dream_finish_step四步流水线config.py跨 daily digest 的检索search任务vector_weight0.7、candidate_multiplier3.0与 dream 内部使用的node_searchcandidate_multiplier5.0。只注册该生命周期依赖的文件/索引任务index_update_loop、reindex、auto_memory、dream_cron、auto_dream、node_search及daily_list/frontmatter_*/move/read/write/daily_write/edit等受限文件工具ReMe 的资源摄取、独立 chat、每日论文与运维类任务一律不加载——测试 test_config_is_agentscope_owned_and_minimal 断言了完整的任务集合并明确排除resource_watch_loop、digest_watch_loop、daily_paper。检索默认是BM25-only除非提供了embedding_modelReMeMiddleware( workspace_dir.reme, parametersReMeMiddleware.Parameters( embedding_modelmy_embedding_model, # 打开向量存储 ), )最小化配置的as_llm组件尊重 ReMe 的LLM_*环境变量注入 AgentScopechat_model则绕过这些变量。索引时序提示auto_memory写回在每日卡落盘后立即返回但卡片只有被 ReMe 索引后才可被搜索到。演示脚本在每次写回后强制同步执行一次reindex使下一次读取能确定性地看到新写入的记忆而不依赖 ReMe 的后台索引循环——具体见reme_demo.py中的_reindex函数reme_demo.py。演示脚本深度解析一次可运行的跨会话记忆验证reme_demo.py 是完整可运行的一站式验证脚本核心流程如下workspace 准备默认每次运行创建全新空临时目录tempfile.mkdtemp(prefixreme_demo_)保证可复现可用REME_WORKSPACE_DIR覆盖为持久目录如.reme以便事后检查记忆卡用户指定目录默认原样复用仅当同时设置REME_DEMO_RESET1时才清空——脚本从不静默删除用户点名的目录。模型装配用同一个DASHSCOPE_API_KEY创建DashScopeChatModel(modelqwen3.7-max, streamTrue)与DashScopeEmbeddingModel(modeltext-embedding-v4, dimensions1024)。共享中间件一个ReMeMiddleware(workspace_dir..., parametersParameters(chat_model..., embedding_model..., modeMODE, top_k5))MODE both注释提示可改static_control/agent_control体验差异。会话 1_build_agent(chat_model, mw, session-1, tools)构造数据助手 Agent系统提示词要求 Agent 在请求可能依赖历史持久事实时主动用memory_search并说明记忆保存是自动的。用户消息为任何图表请默认深色模式并使用 matplotlib我常驻杭州。脚本通过agent.reply_stream逐事件打印中间件贡献[reme → context (static)]静态路径注入的记忆便签检索后台进行搜索完成后在推理步骤注入best-effort——单次回复可能在落地前就结束[tool call (agent)]Agent 自主发起的memory_search调用不存在 add 工具——写入是自动的[assistant]由TextBlockDeltaEvent流拼接出的最终回复[context → reme (auto)]轮次结束后写入 ReMe 的内容通过全 workspace 搜索反查。强制索引 反查await _reindex(mw)后调用_memories_in_reme(mw, chart preferences location)打印 workspace 中已持久化的记忆。会话 2全新 Agent、空对话上下文、session_idsession-2用户消息为画一张月度销售的柱状图——请选合理的主题和库。ReMe 在会话间搭桥session-1写入的matplotlib / 深色模式 / 杭州偏好被检索注入或由 Agent 主动memory_search查出Agent 据此给出符合偏好的默认值。清理finally: await mw.close()显式关闭嵌入式应用让 ReMe 的后台任务 / 线程池干净退出。脚本顶部还有两处工程细节值得借鉴logging.getLogger(reme).setLevel(logging.ERROR)静默 ReMe 启动信息使输出聚焦中间件贡献每条打印行都带static/agent标签标明其来源控制路径。测试验证钩子接线与数据形状适配reme_middleware_test.py 用_FakeReMeAppmock 掉真实的嵌入式 ReMe 应用专测 AgentScope 侧的钩子接线与适配器检索-注入-写回全链路test_retrieve_inject_write断言搜索以用户消息为 query、limit5调用写回携带 userassistant 且按session_id作用域注入的记忆以名为memory的 assistant 角色 HintBlock 追加进state.context并在最终模型调用中可见tests/reme_middleware_test.py#L593-L666写回增量语义test_write_back_includes_full_turn_increment验证写回覆盖用户输入、工具调用步骤、工具结果与最终答案且注入的记忆提示永不被写回tests/reme_middleware_test.py#L668-L731失败隔离test_search_failure_does_not_break_reply证明检索失败只记日志、不阻断回复且写回照常进行数据形状适配_extract_query_text对 HITL 恢复事件返回None跳过记忆 IO与_extract_memory_texts容忍 ReMe 多种返回形态见 utils.py均有独立单测覆盖。小结ReMeMiddleware 为 AgentScope Agent 提供了一条零 agent 负担的长期记忆路径写入完全自动化LLM 抽取的auto_memory写回、检索三模式可调无感注入 / Agent 主动搜索 / 两者并用、单实例可跨 Agent 跨会话安全共享。若你的场景需要纯语义召回务必注入embedding_model以开启向量存储若在意写入的即时可检索性可参照演示脚本在写回后同步执行reindex。更完整的可运行参照实现可阅读 reme_demo.py 与其文档 README.md其余长期记忆方案mem0、AgenticMemory位于 examples/long_term_memory 目录下对照学习。【免费下载链接】agentscopeBuild and run agents you can see, understand and trust.项目地址: https://gitcode.com/GitHub_Trending/ag/agentscope创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AgentScope ReMe 中间件实战：用嵌入式文件记忆实现跨会话长期记忆
AgentScope ReMe 中间件实战用嵌入式文件记忆实现跨会话长期记忆【免费下载链接】agentscopeBuild and run agents you can see, understand and trust.项目地址: https://gitcode.com/GitHub_Trending/ag/agentscope导读ReMe 是 AgentScope 团队自研的基于文件的记忆工具包reme-ai本文围绕 AgentScope 仓库中的 ReMe 中间件示例文档 与其配套的 reme_demo.py 演示脚本系统讲解如何把 ReMeMiddleware 接入 AgentScope Agent实现一次会话写入偏好、下次全新会话自动召回的长期记忆能力。读完本文你将掌握 ReMeMiddleware 的安装、构造参数、三种检索控制模式static_control/agent_control/both、session_id记忆作用域、单实例跨 Agent 共享以及底层嵌入式 ReMe 应用的最小化配置原理。背景为什么需要 ReMe它和 mem0 有何不同AgentScope 的长期记忆中间件家族位于 src/agentscope/middleware/_longterm_memory包含AgenticMemoryMiddleware、Mem0Middleware与ReMeMiddleware三类实现。其中 ReMereme-ai具有两个与 mem0 截然不同的设计取向嵌入式进程内运行ReMeMiddleware 直接把reme.ReMe应用构建并持有在进程内无需启动任何独立服务进程对比 mem0 的独立 service 形态。应用在首次使用时惰性创建由await mw.close()显式销毁。听对话式记忆写入ReMe 通过on_reply钩子监听对话——每一轮回复结束后新的(user, assistant)交流片段都会被自动通过 ReMe 的auto_memory任务写回。Agent 自身从不主动保存记忆也没有 add 工具mode参数只决定如何检索不决定是否写入。这个设计决定了 ReMeMiddleware 的 API 形态面向 Agent 的记忆能力是只读搜索 自动写入下面逐一展开。安装与导入reme-ai是 AgentScope 的可选依赖通过 extra 安装即可声明于 pyproject.tomlmemory-reme [reme-ai0.4.0.6]# reme-ai 是可选的 AgentScope 依赖通过 extra 拉取 pip install agentscope[memory-reme] # 等价于 pip install agentscope reme-ai export DASHSCOPE_API_KEYsk-...ReMeMiddleware从中间件包统一导出见 middleware/init.pyfrom agentscope.middleware import ReMeMiddleware from agentscope.tool import Toolkit演示脚本需要 DashScope 密钥因为它用 AgentScope 的 DashScope 对话模型驱动 ReMe 的 LLM 型auto_memory写回用 DashScope 向量模型驱动语义检索——两者都注入到嵌入式应用里唯一需要的外部凭据就是一个 DashScope key。构造 ReMeMiddleware参数模型与模型注入中间件构造时通过普通参数配置没有外部应用需要管理。用户可调设置全部收敛在嵌套的Parameterspydantic 模型上Agent 服务会将该模型的 JSON Schema 渲染成配置表单结构性装配workspace_dir则留在构造函数上ReMeMiddleware( workspace_dir.reme, parametersReMeMiddleware.Parameters( chat_modelmy_chat_model, # 注入 ReMe 的 LLM 组件 # 驱动 auto_memory 写回 embedding_modelmy_embedding_model, # 注入其 embedding 组件 # 同时自动开启 ReMe 的向量存储 modeboth, top_k5, ), )Parameters四个字段的完整语义源码见 middleware.py参数类型 / 默认值行为说明chat_modelChatModelBase \| None默认None注入嵌入式应用默认名as_llm组件应用生命周期内固定提供时只有 DashScope key 也可运行。省略时由 AgentScope 最小化配置从 ReMe 的LLM_*环境变量LLM_BACKEND/LLM_MODEL_NAME/LLM_API_KEY/LLM_BASE_URL见 config.py兜底提供 LLMembedding_modelEmbeddingModelBase \| None默认None注入默认名as_embedding组件并自动开启向量存储embedding_store组件被挂到file_store上省略时检索保持纯 BM25 关键词模式modestatic_control \| agent_control \| both默认both仅决定检索方式写回在所有模式下都自动执行top_kint默认5每次检索返回的最大记忆条数同时也是memory_search工具对外广告的默认limit两个模型都在构造时固定从不取自 Agent因此即便一个中间件实例被多个 Agent 共享嵌入式应用单一 LLM / embedding 组件也有明确且唯一的定义。为什么要注入 embedding_modelAgentScope 的最小化 ReMe 配置在 BM25-only 模式下不创建任何 embedding 组件。注入一个 AgentScopeembedding_model中间件会在 ReMe 启动前补齐并接好这些组件从而启用向量检索——无需另外配置 ReMe 自己的 embedding 凭据。这一点在测试 test_embedding_model_enables_internal_vector_store 中有明确验证提供 embedding 模型后file_store的embedding_store从空字符串变为default并新增as_embedding、embedding_store组件。从实现看注入发生在_ensure_started中middleware.py应用构建后、一次性start()之前先对as_llm/as_embedding调用update_component再启动构造期间embedding_model的dimensions会透传给 ReMe 的 embedding 组件配置。三种检索模式中间件如何控制记忆ReMe每一轮回复后都会通过auto_memory把新交流写回所有模式皆然——mode只选择 Agent检索记忆的方式。默认是both。static_control中间件代查Agent 无感知三步流程对应 on_reply / on_reasoning 钩子on_reply前用最新用户消息在后台启动一个asyncio任务搜索 ReMe与回复并行运行。on_reasoning在每次推理步骤前轮询该任务一旦完成中间件向state.context追加一个AssistantMsg(namememory, ...)的HintBlock内部以## Relevant memories from past conversations为段首见 middleware.py使下一次模型调用可见。注入是best-effort单次回复仅一次模型调用可能在检索完成前就结束提示会落到后续步骤或本轮跳过——与AgenticMemoryMiddleware的取舍一致包含工具调用的轮次两次及以上推理步骤能稳定注入。on_reply后把新产生的(user, assistant)交流片段通过auto_memory写回。注意注入的记忆消息会持续保留在 Agent 上下文中跨轮累积。若长会话堆积过多需配合compress_context或自定义中间件做后处理。agent_control把记忆搜索权交给 Agent中间件只暴露一个memory_search(query, limit)工具其余不干预自动写回照常运行。需显式把工具挂进 Agent 的 toolkitmw ReMeMiddleware(..., modeagent_control) agent Agent( ..., toolkitToolkit(toolsawait mw.list_tools()), middlewares[mw], )同时on_system_prompt会在系统提示词末尾追加一段简短引导告诉 LLM 存在memory_search工具文案见 middleware.py每个工具的具体使用指引则走标准工具 Schema。此模式下不做自动检索。工具实现见 _tools.pymemory_search是只读、并发安全的工具limit缺省值取自中间件的top_k空 query 或空结果返回明确占位文案作为中间件自带的标准能力其权限检查自动放行ALLOW不打断 Agent 调用。both默认两条路径并存自动检索注入 memory_search工具含系统提示词引导同时生效兼顾无感注入与按需显式搜索。记忆作用域session_id写入按会话隔离检索跨会话共享ReMe 的写回按session_id作用域该值在钩子触发时从agent.state.session_id实时读取——中间件从不存储它middleware.py测试 test_session_id_not_stored_on_middleware 验证了中间件没有_session_id属性。而搜索是全 workspace 范围跨越所有会话这正是后一个会话能召回前一个会话的记忆即便session_id不同的原因。要固定一个可续接的会话在 Agent 上设置 idfrom agentscope.state import AgentState agent Agent(..., stateAgentState(session_idalice-main))演示脚本正是如此——session-1写入偏好session-2全新 Agent、空对话上下文通过共享 workspace 召回它。单中间件实例跨多 Agent 共享由于session_id每次调用实时读取不存储、chat model 构造时固定绑定嵌入式应用的单一 LLM一个ReMeMiddleware可以安全地被多个 Agent、多个会话共享——构建一次逐个传入mw ReMeMiddleware( workspace_dir.reme, chat_modelchat_model, embedding_modelembedding_model, modeboth, ) agent_a Agent(..., middlewares[mw], stateAgentState(session_ida)) agent_b Agent(..., middlewares[mw], stateAgentState(session_idb))这正是演示脚本的做法。底层保障有两层写回按各 Agent 的session_id隔离并发检索任务按session_id为键跟踪self._retrieval_tasks不同会话的并发回复互不干扰——相关测试见 test_shared_middleware_isolates_sessions 与 test_concurrent_sessions_isolate_retrieval_tasks。关闭时调用await mw.close()销毁嵌入式应用AgentScope 不管理中间件生命周期finally: await mw.close()配置细节AgentScope 自持的最小化 ReMe 配置中间件始终构建一份 AgentScope 自持的最小化 ReMe 配置config.py而非加载 ReMe 独立版的default.yaml。这份配置完整保留记忆生命周期所需的全部能力对话写回auto_memory任务把每轮交流抽取进每日记忆卡daily card写回发生在on_reply后置钩子且只提交本轮增量对state.context按消息 id 做差集并排除注入的memory提示消息避免历史被重复喂给提取 Agent见 middleware.py 与测试 test_write_back_is_per_turn_increment梦境整合dream consolidationdream_cron每天 23:00cron 表达式0 23 * * *与可手动执行的auto_dream把每日卡整合进 digest 记忆节点与兴趣主题dream_extract_step/dream_integrate_step/dream_topics_step/dream_finish_step四步流水线config.py跨 daily digest 的检索search任务vector_weight0.7、candidate_multiplier3.0与 dream 内部使用的node_searchcandidate_multiplier5.0。只注册该生命周期依赖的文件/索引任务index_update_loop、reindex、auto_memory、dream_cron、auto_dream、node_search及daily_list/frontmatter_*/move/read/write/daily_write/edit等受限文件工具ReMe 的资源摄取、独立 chat、每日论文与运维类任务一律不加载——测试 test_config_is_agentscope_owned_and_minimal 断言了完整的任务集合并明确排除resource_watch_loop、digest_watch_loop、daily_paper。检索默认是BM25-only除非提供了embedding_modelReMeMiddleware( workspace_dir.reme, parametersReMeMiddleware.Parameters( embedding_modelmy_embedding_model, # 打开向量存储 ), )最小化配置的as_llm组件尊重 ReMe 的LLM_*环境变量注入 AgentScopechat_model则绕过这些变量。索引时序提示auto_memory写回在每日卡落盘后立即返回但卡片只有被 ReMe 索引后才可被搜索到。演示脚本在每次写回后强制同步执行一次reindex使下一次读取能确定性地看到新写入的记忆而不依赖 ReMe 的后台索引循环——具体见reme_demo.py中的_reindex函数reme_demo.py。演示脚本深度解析一次可运行的跨会话记忆验证reme_demo.py 是完整可运行的一站式验证脚本核心流程如下workspace 准备默认每次运行创建全新空临时目录tempfile.mkdtemp(prefixreme_demo_)保证可复现可用REME_WORKSPACE_DIR覆盖为持久目录如.reme以便事后检查记忆卡用户指定目录默认原样复用仅当同时设置REME_DEMO_RESET1时才清空——脚本从不静默删除用户点名的目录。模型装配用同一个DASHSCOPE_API_KEY创建DashScopeChatModel(modelqwen3.7-max, streamTrue)与DashScopeEmbeddingModel(modeltext-embedding-v4, dimensions1024)。共享中间件一个ReMeMiddleware(workspace_dir..., parametersParameters(chat_model..., embedding_model..., modeMODE, top_k5))MODE both注释提示可改static_control/agent_control体验差异。会话 1_build_agent(chat_model, mw, session-1, tools)构造数据助手 Agent系统提示词要求 Agent 在请求可能依赖历史持久事实时主动用memory_search并说明记忆保存是自动的。用户消息为任何图表请默认深色模式并使用 matplotlib我常驻杭州。脚本通过agent.reply_stream逐事件打印中间件贡献[reme → context (static)]静态路径注入的记忆便签检索后台进行搜索完成后在推理步骤注入best-effort——单次回复可能在落地前就结束[tool call (agent)]Agent 自主发起的memory_search调用不存在 add 工具——写入是自动的[assistant]由TextBlockDeltaEvent流拼接出的最终回复[context → reme (auto)]轮次结束后写入 ReMe 的内容通过全 workspace 搜索反查。强制索引 反查await _reindex(mw)后调用_memories_in_reme(mw, chart preferences location)打印 workspace 中已持久化的记忆。会话 2全新 Agent、空对话上下文、session_idsession-2用户消息为画一张月度销售的柱状图——请选合理的主题和库。ReMe 在会话间搭桥session-1写入的matplotlib / 深色模式 / 杭州偏好被检索注入或由 Agent 主动memory_search查出Agent 据此给出符合偏好的默认值。清理finally: await mw.close()显式关闭嵌入式应用让 ReMe 的后台任务 / 线程池干净退出。脚本顶部还有两处工程细节值得借鉴logging.getLogger(reme).setLevel(logging.ERROR)静默 ReMe 启动信息使输出聚焦中间件贡献每条打印行都带static/agent标签标明其来源控制路径。测试验证钩子接线与数据形状适配reme_middleware_test.py 用_FakeReMeAppmock 掉真实的嵌入式 ReMe 应用专测 AgentScope 侧的钩子接线与适配器检索-注入-写回全链路test_retrieve_inject_write断言搜索以用户消息为 query、limit5调用写回携带 userassistant 且按session_id作用域注入的记忆以名为memory的 assistant 角色 HintBlock 追加进state.context并在最终模型调用中可见tests/reme_middleware_test.py#L593-L666写回增量语义test_write_back_includes_full_turn_increment验证写回覆盖用户输入、工具调用步骤、工具结果与最终答案且注入的记忆提示永不被写回tests/reme_middleware_test.py#L668-L731失败隔离test_search_failure_does_not_break_reply证明检索失败只记日志、不阻断回复且写回照常进行数据形状适配_extract_query_text对 HITL 恢复事件返回None跳过记忆 IO与_extract_memory_texts容忍 ReMe 多种返回形态见 utils.py均有独立单测覆盖。小结ReMeMiddleware 为 AgentScope Agent 提供了一条零 agent 负担的长期记忆路径写入完全自动化LLM 抽取的auto_memory写回、检索三模式可调无感注入 / Agent 主动搜索 / 两者并用、单实例可跨 Agent 跨会话安全共享。若你的场景需要纯语义召回务必注入embedding_model以开启向量存储若在意写入的即时可检索性可参照演示脚本在写回后同步执行reindex。更完整的可运行参照实现可阅读 reme_demo.py 与其文档 README.md其余长期记忆方案mem0、AgenticMemory位于 examples/long_term_memory 目录下对照学习。【免费下载链接】agentscopeBuild and run agents you can see, understand and trust.项目地址: https://gitcode.com/GitHub_Trending/ag/agentscope创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考