Agent蜂群 核心 L2 记忆架构：ReMeLight 嵌入式长期文件记忆架构 ，人机共治打通多 Agent 共享认知

Agent蜂群 核心 L2 记忆架构：ReMeLight 嵌入式长期文件记忆架构 ，人机共治打通多 Agent 共享认知

尼恩说在前面：从单 Agent 到分布式 Agent 蜂群，是眼下的前沿热点

尼恩辅导了大量小伙伴，从零平地飞起、 成功拿到 AI 架构offer，逆天改命。 近日有 VIP 学员面试求助，说面试官问一系列的蜂群架构题目：

• 做过 Agent Team吗？ Agent Team 怎么做 记忆架构？

目前，各大公司的Agent 已经开始 从"单兵 Agent"走向"多 Agent 协同的蜂群"，底层的架构思路发生了 巨大变化。

面试，也越来越侧重AgentTeams 蜂群架构能力。 于是，尼恩给大家写了一套 深入分析的 课程讲义，并且后续规划录制成视频。

本文,是 <尼恩蜂群架构圣经1> 第32篇。 后面还有两个<蜂群架构圣经>在写作中…

ReMe：二级 ReMeLight 嵌入式文件长期记忆知识库

什么是 ReMe？

ReMeLight 定位是 QwenPaw 三级 Agent 记忆架构中的 L2 二级长期记忆层。

ReMeLight 走 local-first 本地优先路线，支持云化托管 + 人机共治 + 自进化，是一套 Agent 中长期记忆底座。

ReMeLight 核心理念 ：Memory as File，File as Memory——记忆即文件，文件即记忆。

ReMeLight 把 文件化记忆范式、Vault 工作区、Auto-Dream 梦境整理、两阶段检索 这几项能力，跟阿里自身的业务域、云存储底座、中台 Agent 体系做了适配和扩展。

ReMeLight 补齐了企业落地那一圈边界 + 权限 + 多租户，还有跟现有阿里云 MemoryStore / Tablestore 记忆存储的分层协同关系。

一、设计初衷：解决阿里 Agent 体系中长期记忆的黑盒痛点

现在阿里内部跑着大量 Agent——数字人导购 + 智能客服 + 研发 Coding Agent + 企业办公助理 + 运维 Agent + 线下展厅自助数字人——它们的记忆方案大体上就两类：

• 一类是 L1 会话内存上下文，会话一销毁记忆就没了；
• 另一类是向量库、MemoryStore 这类结构化记忆，记忆写进数据库内部，属于黑盒状态。

黑盒记忆在业务落地上有几个比较突出的瓶颈：

(1) 不可观测、也不可直接干预：业务运营、客服小二、研发都没法直观看到 Agent 到底记住了哪些事实、偏好、历史工单结论；等记忆出现幻觉、事实冲突的时候，只能通过一堆复杂 API 去删记忆、修记忆，没法直接动手编辑。

放到电商售后 + 金融风控 + 医疗健康这些强合规业务里，"Agent 到底记住了什么"本身就是一个审计对象。黑盒向量库往往只能回答"召回了哪些块"，却回答不了"这条结论为什么被当成事实保留下来"。ReMe 把记忆变成 Markdown 之后，记忆条目、来源、置信度、责任人、修改记录就都成了可读对象；运营同学不需要会写 SQL、也不懂向量检索脚本，也能参与治理。

(2) 跨 Agent 迁移成本高：同一个用户、同一个项目的记忆，在导购 Agent + 售后 Agent + 人工坐席 Agent + 数字人 Agent 之间很难低成本共享；每个 Agent 各抽各的、各存各的，重复计算不说，事实还容易对不上。

打个比方，用户先在直播间数字人里说"对羊毛过敏、偏好莫兰迪色"，售后 Agent 又收到"希望退换货走上门取件"。要是两套 Agent 各存各的，就会出现导购推荐羊绒大衣、售后却不知道历史偏好的错位。ReMe 用同一份 Vault 当作"用户 / 项目 / 店铺级认知中枢"，让多个 Agent 从"各自脑内记忆"变成"共享工作区记忆"。

(3) 溯源链路弱：记忆结论往往没法稳定绑定到原始对话、工单截图、业务单据、上传文档，业务风控、客诉复盘就缺了证据链路这一环。

传统 RAG 的溯源通常只回到"文档 chunk"这一层。但是 Agent 业务里的关键证据往往是"2026-03-12 16:20 的客服会话""订单 20260312XXXX 的退款工单""用户上传的过敏检测报告 PDF"。ReMe 的 Wikilink 可以把一条长期记忆回链到 session + resource + daily + 原始工单，形成一条可复核的证据链。

(4) 记忆膨胀失控：简单的向量 RAG 解决的只是文档检索，缺了"沉淀 + 合并 + 去冲突 + 适度遗忘"这套记忆巩固机制；长期对话下来召回噪声一路走高，token 开销也跟着往上走。

RAG 解决的是"从知识库里找文档"，不是"从交互历史里形成稳定的经验与人设"。如果用户和 Agent 聊了三个月，把所有聊天记录向量化之后一股脑召回，模型就会被过期优惠、临时情绪、已作废约定干扰。ReMe 的 Auto Memory + Auto-Dream 本质上是给 Agent 配了一套"睡眠巩固机制"：白天记笔记，夜里写纪要，长期只留下经得起复用的经验。

ReMe 文件化二级记忆，做的就是把 L2 中长期记忆从数据库内部的隐式状态，转成可读、可编辑、可版本回溯、可跨环境迁移的 Markdown 文件资产；它在 QwenPaw 三级记忆架构里承接的是 L1 短期会话内存和 L3 企业大知识库之间的那个中间层。

• L1：会话短时记忆，内存上下文，单次对话生命周期；
• L2：ReMe 文件化二级记忆，放的是用户事实 + 偏好 + 工单摘要 + 项目约定 + 业务经验，跨会话持久化，人机一起维护；
• L3：企业全域 RAG 知识库，放的是产品文档 + 规章 + 商品库 + 运维手册 + 合同库这类静态大规模知识。

ReMe 文件化二级记忆整套闭环是这样的：

对话捕获 → Auto Memory 生成当日主题卡片 → Auto-Dream 后台梦境巩固、沉淀长期记忆 → 两阶段混合检索召回记忆片段 → 注入 Agent prompt 完成应答。

同时运营、小二、研发可以直接改 Markdown 文件，改完的结果会自动同步给所有挂载同一份 Vault 的 Agent。

边界说明：

• ReMe 不是用来替代阿里云 Tablestore MemoryStore、向量检索服务的，而是互补分层：强事务、高并发在线交易记忆、百万级高吞吐画像写入继续交给托管 MemoryStore；
• 但是那些需要人工介入编辑、需要强溯源、需要经验沉淀、需要跨 Agent 共享、还需要在离线 / 边缘端本地优先跑的中长期经验记忆，交给 ReMe 文件化记忆；
• 在阿里混合架构里，ReMe 的 Vault 可以本地文件挂载，也可以基于 3FS / Tablestore FileMemory 做云端托管，支持 Fuse 挂载；业务侧统一走文件语义访问记忆，底层存储对业务是透明的。

可以这么理解 ReMe 文件化二级记忆：内存 / 数据库管的是状态，文件 Vault 管的是认知。

• 比方说"用户当前登录态、账户余额、订单锁"就不适合放 ReMe；
• 但是"用户不喜欢催购话术、店铺售后默认上门取件、某个项目禁止用某个已经弃用的 SDK"就非常适合放 ReMe。

背景知识：ReMeLight 的前世今生

ReMeLight 是 QwenPaw 内嵌长期记忆体系 。

QwenPaw 的第二级记忆 ReMeLight 是一个 嵌入式文件长期记忆知识库，包含的是 dream 梦境整理、daily_paper 每日会话沉淀、BM25 + Embedding 混合检索，还有洋葱中间件链注入 Agent 主循环这套机制 。

那开源项目 ReMe 跟 ReMeLight（QwenPaw 内嵌记忆）之间到底是什么关系？

• Auto-Dream（梦境整理）原生属于独立开源项目 ReMe（前身叫 MemoryScope），归在 AgentScope 体系下，是一套独立记忆底座 SDK；
• QwenPaw 是上层 Agent 应用，内部嵌了一份裁剪、简化过的 ReMe 实现，起名叫 ReMeLight；
• ReMeLight 对标、复用的是原版 ReMe 的核心理念和 Auto-Dream 机制，而不是原版 ReMe 本身；
• ReMeLight 依附于 QwenPaw 而存在；
• 一句话总结：ReMe 是底层记忆底座，QwenPaw 是消费这个底座的 Agent，而 ReMeLight 就是 QwenPaw 内嵌的那个轻量子集。

原始项目 ReMe 仓库是 agentscope-ai/ReMe，由阿里通义实验室 EconML 团队研发，是 AgentScope 生态下独立记忆套件，不属于 QwenPaw 子模块。它有独立代码仓库、官方文档、PyPI 包 reme-ai，还有配套 ReMe Studio 可视化面板和独立 MCP 服务。

项目早期叫 MemoryScope，后来正式更名成 ReMe（Remember Me，Refine Me）。

它原生配套两大核心能力：auto_memory 用来生成 daily 短期卡片，auto_dream 负责梦境记忆整理。原生执行逻辑是扫描 Vault 下 daily/ 目录里的短期卡片，收敛、合并、沉淀到 digest/ 长期记忆目录，用滑动时间窗口约束单次处理规模，去做新增事实 + 佐证原有结论 + 修正冲突信息 + 标记失效记忆这几件事。

原生 Vault 包含的是 session/ + resource/ + daily/ + digest/ + metadata/ 这套完整分层目录，也就是 Auto-Dream 机制对应的原始载体。

部署形态上 ReMe 支持独立进程运行，对外暴露 HTTP + MCP + CLI 几种接入方式，支持 QwenPaw + OpenClaw + Claude Code + Harness 等多种不同 Agent 共享同一份 Vault 记忆工作区。

QwenPaw（前身 CoPaw）是 AgentScope 生态里的个人 Agent 工作站。为了适配单机本地轻量化部署，它内置的是裁剪之后的 ReMeLight：去掉独立后台常驻服务、多 Agent 共享 Vault、完整 ReMe Studio 这些能力；存储结构简化成 daily_paper（等价于原版 ReMe 的 daily）+ 单文件 MEMORY.md（等价于原版 ReMe 的 digest）；内部的 dream 逻辑是对原版 ReMe Auto-Dream 的简化复刻。

ReMeLight 随 QwenPaw 主进程生命周期运行，属于单实例独占记忆空间，原生不支持跨 Agent 共享 Workspace。

洋葱中间件链是 QwenPaw 自身 Agent 主循环的扩展注入方案；原版独立 ReMe 本身并不包含洋葱中间件能力。ReMe 作为 SDK / MCP 服务，由上层接入方自己去编排中间件链路。

三、ReMeLight 嵌入式文件长期记忆的4 大核心理念

理念 1. Memory as File，File as Memory：记忆本体是 Markdown 文件，索引只是派生缓存

记忆唯一可信源是 Markdown，附带 frontmatter 元数据还有 Wikilink 双向链接。

向量索引、BM25 索引、知识图谱全部属于派生缓存，可以随时删除、随时重建。
这个设计带来的是极强的治理优势：支持 Git 版本快照 + 审批留痕 + 批量导出 + 跨租户拷贝 + 边缘终端离线同步。

数字人、客服、研发助手在展厅、门店、本地开发机上可以脱离中心存储，本地加载 Vault 独立跑记忆能力，等网络恢复之后再做双向同步。

在金融、政务、电商售后这些场景里，"记忆能不能被审计"往往比"召回快不快"更重要。

文件化之后，一条记忆的变更就像代码变更一样可以 review：谁改的、改了哪一行、为什么改、对应哪个工单都可以留痕。

理念 2. Memory from Experience：记忆是提炼收敛后的经验，不是原始对话流水堆砌

不要直接把全部历史对话一股脑塞进记忆里。

Auto Memory 先做轻量化摘要，Auto-Dream 在低峰、空闲窗口做记忆巩固：新增事实 + 佐证原有结论 + 修正冲突信息 + 淘汰过期无效记忆。

适配的是客服工单、导购跟进、项目研发这些场景：沉淀下来的是"用户核心诉求、售后约定、商品偏好、项目编码规范、踩坑排障结论"，而不是完整聊天流水——这样才能够有效控制召回噪声和 token 消耗。

这跟人类记忆很像——人不会把每一天、每一句闲聊都背下来，而是记住"这个客户对物流时效很敏感"“这个项目里消息队列必须用 RocketMQ”“这款粉底液容易卡粉”。

ReMe 的价值不是"存得多"，而是"留得对"。

理念 3. Human-Agent Shared Memory：人机共治记忆资产，运营具备控制权

这一点非常贴合阿里客服、导购业务的人机协同模式：

• AI Agent 自动提炼记忆；
• 同时人工小二、运营、业务专家可以直接打开 Vault 里的 Markdown 卡片，去修正错误偏好、补充业务约定、标记记忆失效。

人工修改后的记忆，所有同 Vault 的 Agent 下一轮对话就能生效，形成的是"AI 自动沉淀 + 人工校准"的闭环，能大幅降低记忆幻觉带来的客诉风险。

很多 Agent 系统失败不是因为模型不行，而是因为"模型记错之后没人能改"。

ReMe 把运营人员变成了记忆系统的管理员，而不是把记忆锁死在算法团队手里。

理念 4. Connected and Traceable：全链路溯源，每一条记忆都绑定证据源

每一条 digest 长期记忆卡片都带着 Wikilink 回链到原始会话 session、上传的业务资源（工单、商品资料、PDF 需求文档）。

在客诉复盘、风控审计、售后质检这些场景里，当 Agent 输出一条基于记忆的结论时，可以一键追溯到原始对话原文，满足电商、金融业务对可审计的要求。

比方说 Agent 说"该用户同意延期 7 天发货"，客诉部门点开记忆卡片就能看到它来自"2026-04-01 售后会话 #82312 + 用户上传的微信截图 resource/wechat_20260401.png"，而不是模型凭空编出来的"我记得他说过"。

四、ReMe 框架中的 Vault 记忆空间分层存储模型

ReMe 框架中，一个 Vault 对应一份独立记忆空间。

在阿里业务里，Vault 的归属维度可以灵活定义：单 C 端用户、一个商家店铺、一个项目团队、一条数字人会话租户、一个客服坐席组。

Vault 内部目录严格按照记忆生命周期分层，把原始素材、短期加工记忆、长期沉淀记忆、运行缓存隔离开，去适配权限管控 + 备份策略：

• session/ + resource/：原始来源层。存的是原始对话会话记录、上传的业务资源（工单 + 需求文档 + 商品资料 + 售后凭证），是记忆溯源的原始证据，必须纳入备份、审计范围；
• mem_session/：Agent 运行态。会话运行时临时配置、运行变量，不属于业务记忆资产，不需要备份，会话结束就能清理；
• daily/：当日短期记忆卡片（Auto Memory 产出）。按主题、按日期聚合的会话摘要、临时结论，属于浅加工记忆，由 Agent 对话结束后自动生成；
• digest/：二级记忆核心长期沉淀层。是 Auto-Dream 梦境整理的输出，是跨会话复用的稳定记忆单元：用户偏好 + 历史工单进度 + 项目规范 + 排障经验 + 导购跟进要点；
• metadata/：派生索引缓存目录。BM25 索引 + Embedding 向量索引 + 知识图谱缓存，全部可重建，不纳入核心备份链路，故障场景直接重建就行。

按照上面原版 ReMe 完整 Vault 的结构，Vault 里面不是固定数量的 Markdown，而是按照业务动态生成的，有大量 md 文件：

(1) session/：每一轮会话生成一份或多份 Markdown，保存原始对话；

(2) resource/：导入的外部文档（工单、需求、商品资料等），本身是源文件，可以是 md / pdf / doc，ReMe 会转成 md 存进去或者挂载索引；

(3) daily/：Auto Memory 产出，按日期 + 主题生成多张独立 Markdown 卡片，一天可以几十上百张，不是一个 daily 文件就完事；

(4) digest/：Auto-Dream 梦境整理输出的长期记忆卡片，一条稳定记忆就是一份独立 Markdown，一个 Vault 下面可以成千上万个 digest md，每条记忆自带 frontmatter、wikilink 双向链接；

(5) mem_session/：运行时临时配置，一般不是业务 md，多是 json / yaml；

(6) metadata/：索引缓存（向量、BM25、图谱缓存），不是记忆 Markdown，是派生缓存，没有业务记忆内容，可以删掉重建。

总之原版 ReMe 是"一记忆一 md 卡片"的碎片化卡片库。

daily / digest 下面都是一堆离散独立的 Markdown 文件，不是一个大 md。

QwenPaw 里的 ReMeLight 简化版做了大幅收拢，文件数量极少：

(1) daily_paper：按日期合并，一天一个 YYYY-MM-DD.md，当天所有会话摘要追加进同一个文件，不再拆成多主题卡片；

(2) MEMORY.md：只有单独这一个主 Markdown 文件，所有长期记忆全部写在这一个文件里，不再拆成一堆 digest 卡片。

二者最核心的差异：

• ReMe：digest = 大量分散的独立 md 卡片
• ReMeLight：长期记忆全部收拢到单文件 MEMORY.md

版本	daily 层形态	长期 digest 层形态
原版 ReMe（Vault 分层）	daily/ 目录，多张独立主题 md 卡片（Auto Memory）	digest/ 目录，大量独立 md 记忆卡片（Auto-Dream 输出）
ReMeLight（QwenPaw 内嵌）	daily_paper，按天单 md，持续追加	单个 MEMORY.md 文件，全部长期记忆写在一起

仓库模式（Repository 仓储模式） 在记忆存储架构上的落地

ReMe / ReMeLight 对外抽象记忆仓储接口：query_memory + write_memory + compact_memory；底层可以切换实现（完整 Vault 多卡片、单 MEMORY.md、云 MemoryStore）。

仓储模式基础知识：Repository 不是 GoF 那 23 个，却是企业架构常客

Repository（仓储）模式出自 Martin Fowler《企业应用架构模式》和 Eric Evans 的 DDD。它解决的问题很直白：领域对象不该知道数据存在哪、怎么取。它把"数据访问"封装成一个"像内存集合一样"的接口，业务代码只面向 add / get / query 这种集合语义编程；底下不管是 MySQL、是文件、还是向量库，业务一概不关心。本质就一句话——存储细节对上层透明，业务只认接口、不认实现。GoF 那 23 个模式里没有它，但是它是把"持久化"从业务逻辑里剥出来的关键一刀。

Repository（仓储）经典实现：从 ORM 到 Agent 框架的同源套路

这套抽象到处都是：Spring Data 的 Repository<T> 让业务直接 userRepo.findById()，底下落 JDBC 还是 JPA 都无所谓；Entity Framework 的 DbContext 把表映射成 DbSet 集合；放到 Agent 框架里，LangChain 的 VectorStore / BaseChatMessageHistory、LlamaIndex 的 StorageContext 干的也是同一件事——把记忆 / 向量的存取抽象成统一接口，底层能换 Chroma + Qdrant + PGVector。共性规律是所有"能换存储"的系统背后都藏着一个 Repository 抽象层。

Repository（仓储）在 QwenPaw 中的项目落地：一个接口，三套落地

回到本文。ReMe / ReMeLight 把记忆存取收敛成三个接口：query_memory（检索）、write_memory（落盘）、compact_memory（压缩巩固），上层 Agent 主循环、洋葱中间件链只调这三个方法。但是底层实现却能三选一，而且本文前面都讲过：

• 完整 Vault 多卡片：原版 ReMe 的 digest/ 一记忆一 md，用文件仓储实现；
• **单 MEMORY.md**：ReMeLight 收拢成单文件，用"单文件追加"实现同一套接口；
• 云 MemoryStore：要上云、要强事务高吞吐时切到 Tablestore，接口签名不变。

前面讲洋葱中间件链时， 提到"替换记忆后端、不改动主循环"，依赖的正是这一层 Repository 抽象的接口，如： query_memory / write_memory 。有了这一层 Repository 抽象的接口， 洋葱中间件链 从本地文件切换到 Tablestore，上层调用方代码不需要改动。要是没了这个抽象层，那么更换存储实现就需要直接去修改主循环里的记忆读写代码。

五、洋葱中间件链：记忆中间件责任链注入 Agent 主循环

运行时序（一次用户请求完整链路）

(1) 用户消息输入，进入洋葱中间件链；

(2) 记忆查询中间件（前置 Hook）：调用 ReMeLight 检索接口，根据当前用户 query 召回相关长期记忆片段，附加到消息上下文；

(3) 经过其他中间件（权限过滤、prompt 模板、工具权限校验等）；

(4) 消息送入大模型推理；

(5) 模型输出回复，流经中间件后置 Hook；

(6) 记忆落盘中间件（后置 Hook）：本轮对话关键信息追加写入 daily_paper 每日文档；当 PowerContext 热上下文窗口达到阈值，触发上下文压缩钩子，将会话重要信息下沉到二级记忆，释放 L1 内存窗口。

QwenPaw 并不是把记忆逻辑硬编码、写死在推理流程里，而是采用洋葱中间件链（Onion Middleware Chain）这套架构，把记忆模块当作中间件挂载在 Agent 主消息循环上。

责任链模式（洋葱中间件链 Onion Middleware）架构思维落地

QwenPaw 的洋葱中间件链是前置记忆检索 Hook + 后置记忆落盘 Hook + 权限 + 模板这些中间件串联起来的。

• 请求一层层穿过中间件，响应反向回传；记忆查询放在前置，记忆持久化放在后置；
• 优势是插拔式的：随时能开启 / 关闭记忆中间件、替换记忆后端，不改动 Agent 主循环代码。

洋葱中间件是责任链的变体（嵌套式责任链），在 Web 框架、Agent 框架里都非常常见。

基础知识：从单向责任链到 Onion Middleware嵌套式洋葱

GoF《设计模式》里的责任链（Chain of Responsibility）原始定义是：把多个请求处理者串成一条链，每个节点自己决定"我处理不处理、处理完还往不往下传"。
它的本质是单向放行——请求从链头走到链尾，谁感兴趣谁拦截，处理完就继续往后流；但是响应阶段没有回头路，节点只能在一去路线上做文章。

洋葱中间件（Onion Middleware，也叫拦截器链 Interceptor Chain）是责任链的双向嵌套变体：请求像箭一样一层层穿进最内层（到达大模型推理这个"核心"），响应再原路一层层穿出来。

同一个中间件因此拥有前置（pre）和后置（post）两个切面——进来的时候能改请求，出去的时候能改响应。这正是 Agent 记忆最需要的形态：检索要发生在"进模型前"，落盘要发生在"出模型后"，同一段记忆逻辑必须横跨两个切面，单向责任链干不了这事。

Onion Middleware 经典实现：Web 与 Agent 框架的同源实践

这套模型一点都不新鲜，Web 框架早玩透了：

• Koa / Express：async (ctx, next) => { ...前置...; await next(); ...后置... }，next() 就是往洋葱里钻的钥匙，请求 - 响应都过一遍；
• ASP.NET Core：InvokeAsync(context, next)，管道（Pipeline）同样是前后置双切面；
• Agent 框架：LangChain 的 BaseCallbackHandler、LlamaIndex 的 EventHandler、AgentScope 的 middleware 注册机制，本质都是一个意思——把"记忆检索 + 权限校验 + 工具管控 + 计费埋点"挂成可插拔的环，主推理循环只管 next()。

共性规律是主循环永远不写业务细节，只负责驱动中间件链，业务能力全靠挂载。

三、QwenPaw 项目落地：记忆逻辑这样被"挂"上去

回到本文的 QwenPaw。它把记忆模块做成洋葱链上的一个中间件，而不是硬编码进推理流程：

• 前置记忆检索 Hook：用户消息一进来就先走它，调用 ReMeLight 检索接口，按当前 query 召回长期记忆片段，附加进消息上下文；
• 后置记忆落盘 Hook：模型输出后流经它，本轮关键信息追加写入 daily_paper；当 PowerContext 热窗口达阈值，触发上下文压缩钩子，把重要信息下沉到二级记忆，释放 L1 内存；
• 权限过滤、prompt 模板、工具权限校验中间件夹在中间，层层包裹（见下方时序图）。

代价与取舍也相对清晰：中间件不是免费的——每多挂一层就多一次 next() 调用开销，链路一长排错也变难（得逐环打 trace）。所以 QwenPaw 把记忆后端做成可替换的，闲时用本地 ReMeLight、要上云就切 Tablestore，主循环一行不动。这正是洋葱架构"插拔式进化"的价值：记忆能力从"写死的功能"变成了"能随时插拔、替换、开关的零件"。

中间件责任链架构优势

(1) 解耦记忆逻辑和 Agent 主业务逻辑，能灵活开启、关闭记忆中间件；

(2) 便于替换记忆后端：既可以用内置 ReMeLight 本地文件记忆，也可以替换成 Tablestore、AnalyticDB 这类云记忆服务；

(3) 适配扩展：新增记忆策略只需要新增中间件，不需要改动 Agent 主循环代码。

配置入口：记忆相关配置存放在项目 agent.json 的 running.reme_light_memory_config 节点，比方说 summarize_when_compact 这个开关，控制的是上下文压缩时是否自动向记忆层落盘摘要信息。

六、检索架构：两阶段检索（宽召回 + Reranker 重排），适配业务召回质量管控

ReMe 采用的是混合两阶段检索。

这套检索链路可以直接对接阿里内部的检索网关、百炼 Embedding、自研 Reranker，和 L3 企业 RAG 检索做统一协议对齐：

一阶宽召回（Wide Retrieval）

多路召回并行：BM25 全文关键词检索 + Wikilink 链接图谱扩展；可选接入百炼 Embedding 做语义向量召回；多路结果用 RRF 倒数排名融合去抹平关键词打分、向量打分之间的分布差异，输出候选记忆片段集合。

适合客服场景：用户输入口语化问题，既召回关键词匹配的工单记录，也召回语义相似的历史偏好。

比方说用户问"上次那个不肯退的订单后来咋处理"，BM25 命中"退 / 订单 / 工单"，Wikilink 从用户卡片跳到历史售后事项，向量召回再把"拒收后协商补券"的相似经验带出来。

多路合并比单路 RAG 稳得多。

二阶 Reranker 精排

对候选集合做相关性重排，过滤低相关、过时、冲突的记忆；返回结果携带文件路径、行号、溯源链接，而不是一次性把大量记忆全部塞进 Prompt。

Agent 按需决定是读取摘要还是跟随链接展开原始证据，精准控制上下文 token 预算，适配数字人、客服这类对 token 成本敏感的在线业务。

业务侧可以配置检索策略：C 端导购优先召回偏好、历史咨询；售后客服优先召回未完结工单、历史投诉；研发 Agent 优先召回项目约定、历史排障案例。

这相当于把"记忆检索"从向量库黑盒变成可治理的检索引擎：业务可以配召回域、配时间衰减、配敏感字段屏蔽、配冲突仲裁规则，而不是把所有记忆块无脑拼进 system prompt。

七、Dream 梦境定时记忆整理机制

dream 是 QwenPaw 的记忆巩固后台任务，对应 ReMe 的 Auto-Dream 能力，用来从大量 daily_paper 每日会话文档收敛、更新 MEMORY.md 长期记忆文件，防止记忆无限膨胀、事实冲突。

原始设计：

• 后台任务扫描 daily 短期卡片，收敛、合并到 digest 长期记忆，默认滑动窗口、提取有限记忆单元，去执行新增 + 佐证 + 修正 + 失效标记。

适配阿里生产调度改造：

• 不再固定定时跑，而是接入阿里内部调度平台，在业务低峰窗口（客服夜间闲时、导购流量低谷、研发夜间空闲）触发 Dream 任务，避免高峰占用 LLM 算力；
• 同时增加业务标签路由：客服工单记忆、研发项目记忆、数字人导购记忆可以配置独立的合并策略、冲突判定规则、记忆过期 TTL。

算力分层：纯文件读写、BM25 检索、Wikilink 图谱遍历不需要 LLM，边缘展厅、自助终端这类弱网离线场景可以持续使用；Auto Memory 摘要、Auto-Dream 记忆巩固、语义向量召回依赖模型服务，弱网时暂停巩固，网络恢复后再补跑。

触发方式：

• 支持 cron 定时后台自动运行；
• 也支持手动命令 /dream 强制执行。

执行步骤：

① 对原有 MEMORY.md 做备份；

② 读取最近一批 daily_paper 每日会话文档；

③ 执行记忆处理规则：去冗余合并、新事实覆盖过期旧信息、剔除无效过时记录、归纳同类经验、修正互相冲突的结论；

④ 将整理完成的稳定知识回写至 MEMORY.md。

资源约束：

dream 任务会消耗 LLM 算力；本地部署可以配置执行窗口，避开高峰交互时间，避免抢占对话推理资源；弱网离线环境下可以暂停 dream，网络恢复后再补跑记忆整理。

五、ReMeLight 嵌入式文件长期记忆 适配业务落地场景

个人助理、Coding Agent、个人知识库、经验驱动的 Agent。

下面结合电商、客服、数字人、研发、运维、线下终端体系扩展落地场景，区分适合场景、不适合场景，还有跟现有体系的分工边界。

ReMeLight 嵌入式文件长期记忆 优先适配、高价值落地场景

电商导购 / 直播数字人 Agent

一个店铺 / 一个用户对应独立 Vault。跨轮、跨天对话记住用户尺码偏好、肤质敏感点、价格区间、之前咨询过的商品、还有没下单的顾虑；线下展厅自助数字人、门店大屏数字人本地 Vault 优先，断网也不丢用户记忆，联网之后再同步回中心。

数字人流水线里 L2 记忆层直接对接 ReMe，每次用户提问先检索记忆，给到连贯、有延续感的口播应答，解决的是"每次对话都从头问一遍"的割裂问题。

人机协同智能客服、售后工单 Agent

Vault 按用户 ID 隔离。沉淀历史工单进度、用户投诉要点、用户特殊约定（退款方式、上门时间、特殊售后政策）；人工小二可以直接打开 Markdown 记忆卡片修正错误记录；换不同客服 Agent、数字人接待同一个用户共享同一份记忆；客诉质检时顺着 Wikilink 追溯原始对话证据。适合售后跟进、分期付款、退换货跟进这类长周期会话。

研发 Coding Agent、项目助手（QwenPaw、OpenClaw 等）

Vault 绑定代码仓库 / 项目空间。

沉淀项目编码规范、架构决策记录、历史坑点、第三方依赖约定、上线排障步骤；多个开发 Agent、测试 Agent、运维 Agent 共享同一个项目 Vault；新接入项目的研发助手直接读取沉淀的项目经验，不需要反复沟通历史方案；研发也可以直接编辑 Markdown 归档架构决策。

比方说"订单服务不允许在事务里调外部 HTTP"“灰度发布必须先切 5% 内部流量”"这个 NPE 是 Fastjson 老版本导致"这类知识，放文档库里没人看，放 ReMe 里会被 Agent 主动召回。

企业办公、内部业务助理 Agent

面向员工、部门团队的记忆 Vault，沉淀会议结论、跨团队协作约定、审批偏好、历史诉求；支持员工在本地 PC 离线使用，文件记忆跟随工作空间迁移。

运维、巡检、故障处置 Agent

沉淀故障现象、根因、处理 SOP、历史变更记录；当同类告警再次出现，优先召回过往处置经验，同时运维专家持续补充、修正记忆卡片，把隐性运维经验沉淀成可检索资产。

ReMeLight 嵌入式文件长期记忆 不适合场景

ReMe 文件化记忆不替代在线高吞吐结构化记忆库，下面这些场景优先使用 Tablestore MemoryStore、PolarDB Agent Memory：

(1) 高并发交易链路、强事务、强一致性的用户画像写入，每秒上万次记忆读写；

(2) 超大规模全域用户画像、标签体系，需要多维索引、实时在线过滤；

(3) 严格多租户强隔离、高频权限动态变更、需要行级权限的核心金融业务；

(4) 百万级、十亿级体量的静态企业全域知识库检索（这部分属于 L3 层，交给独立 RAG 平台）。

一句话边界：需要人经常看、经常改、要溯源、允许本地离线、经验持续自进化的中长期经验记忆交给 ReMe；高吞吐、强事务、结构化标签画像交给托管 MemoryStore。