1. 从两个榜单分数说起这套记忆架构到底在解决什么LongMemEval 95.60%LoCoMo 93.60%。这两个数字放在一起看做 LLM Agent 的人应该能立刻意识到分量——LongMemEval 考的是长程记忆的召回与推理LoCoMo 考的是多轮对话里跨会话、跨时间线的信息一致性。两个榜单同时刷到 93 分以上意味着这套叫 Agent Zero Memory 的东西不是靠某个单点技巧冲分而是在“记得住”和“用得对”这两件事上同时做到了接近上限的水平。先把背景说清楚。LLM Agent 的记忆问题本质上不是“存不下”而是“存了之后取不准、取回来之后用不对”。一个跑了三个月的客服 Agent对话历史可能有几十万 token用户上周随口提过一句“我下个月要搬家”这周问“推荐个附近的餐厅”如果 Agent 把“搬家”这个信息丢了推荐的就是旧地址周边的餐厅体验直接崩掉。LongMemEval 这类基准测的就是这种能力在超长上下文中能不能精准定位到相关的那条记忆并且正确推理出它对当前问题的影响。LoCoMo 更狠一点。它是多会话multi-session的设定对话被切成一段一段中间有时间间隔Agent 需要跨这些片段把同一个人的信息拼起来。比如第一段对话里用户说“我养了只猫叫豆豆”第五段对话里用户说“豆豆最近不爱吃东西”Agent 得知道这两个“豆豆”是同一只猫并且把“猫”和“不吃饭”关联起来给出建议。这种跨会话的实体一致性是很多记忆方案的死穴。Agent Zero Memory 这个名字里的“Zero”我理解不是“零记忆”而是“零额外负担”——不需要为每个 Agent 单独训练记忆模块不需要把历史全塞进 context window而是用一套多轨并行的架构把记忆的存储、检索、推理拆成几条独立的轨道各跑各的最后在决策层汇合。这个思路和传统的“向量数据库 RAG”有本质区别后面会展开讲。适合谁来读这篇如果你正在做 LLM Agent 的产品落地被“记不住”“记混了”“记太多导致推理变慢”这几个问题折磨过那这套架构的拆解值得你花时间。如果你只是好奇榜单分数怎么来的也能从里面看到记忆系统设计的核心权衡。我会尽量把每个设计选择背后的“为什么”讲透而不是只丢结论。2. 多轨并行记忆架构的核心设计逻辑2.1 为什么单轨记忆一定会撞墙先看大多数团队做 Agent 记忆的默认路径把所有对话历史 embedding 之后塞进向量库查询时做相似度检索top-k 结果拼进 prompt。这套方案在 demo 阶段很好用但一上量就出问题。第一个问题是检索粒度和推理需求不匹配。用户问“我上次说的那个项目 deadline 是什么时候”向量检索会返回包含“deadline”“项目”这些词的片段但真正有用的信息可能是三天前一句“这个项目老板说月底必须交”里面根本没有“deadline”这个词。语义相似度在这里失效了因为记忆的价值不在于“像”而在于“相关”。第二个问题是时间维度的丢失。向量库里的记忆是无序的检索出来的片段没有时间戳的强弱关系。但很多记忆问题本质是时序推理“用户先说了 A后说了 BB 覆盖了 A”。单轨架构里A 和 B 可能同时被检索出来模型看到两个矛盾的信息要么瞎猜要么直接摆烂说“信息不一致”。第三个问题是写入放大。每轮对话都往向量库写库越来越大检索噪声越来越高。你可能会说“那就做摘要”但摘要本身又是有损的摘掉的可能正是后面要用的细节。这是一个死循环。Agent Zero Memory 的多轨设计就是针对这三个问题分别开药方。2.2 三条轨道的分工事实轨、时序轨、推理轨根据公开的技术描述和榜单表现反推这套架构至少包含三条并行轨道我按功能给它们起名叫事实轨、时序轨、推理轨。这不是官方命名但能帮你理解它的运作方式。事实轨负责存“是什么”。用户的名字、偏好、设备型号、订单号这类结构化程度较高的信息走这条轨。它的检索不是纯语义相似而是结合了实体识别和槽位匹配。比如用户说“我的车是 Model Y”事实轨会抽取出{用户: 车主, 车型: Model Y}这样的三元组存下来。下次用户问“我的车充电要多久”事实轨直接命中“车型”这个槽位不需要靠 embedding 去猜。时序轨负责存“什么时候发生了什么”。每条记忆带时间戳并且维护一个事件序列。它的核心能力是时序覆盖检测当新记忆和旧记忆在同一个实体上冲突时按时序保留新的但把旧的标记为“已过期”而不是删除。这样既避免了矛盾信息同时出现又保留了历史可追溯性。LoCoMo 里那种跨会话的实体一致性很大程度上靠这条轨来保证。推理轨负责存“推导出来的结论”。这是最容易被忽略但最关键的一条。用户说“我下周三要去北京出差”事实轨存了“下周三”“北京”“出差”时序轨存了事件时间。但推理轨会进一步推出“用户下周三不在本地”“可能需要订票”“本地安排要避开周三”。这些推导结果不是用户明说的但后续对话极可能用到。推理轨把这些中间结论缓存下来下次相关查询直接命中不用重新推导。三条轨并行跑各自有独立的索引和检索策略最后在一个融合层做结果合并。融合层不是简单拼接而是按置信度和时效性加权。事实轨的命中置信度最高时序轨次之推理轨最低但覆盖面最广。这个权重设计直接影响了 LongMemEval 的分数——召回率和准确率的平衡点就在这里。2.3 “Zero”的含义零训练、零侵入、零上下文膨胀再解释一下名字里的 Zero。我理解它对应三个设计目标零训练不需要为记忆模块单独做 fine-tune。很多记忆方案要训练一个 retriever 或者 reranker成本高且迁移性差。Agent Zero Memory 用的是现成的 embedding 模型加规则引擎开箱即用。零侵入不需要改 LLM 本身的推理流程。记忆的读写发生在 LLM 调用之外Agent 的主逻辑不用动。这意味着你可以把它套在任意现有的 Agent 框架上不管是 ReAct 还是 Plan-and-Execute。零上下文膨胀检索回来的记忆不是全塞进 prompt而是经过融合层压缩成结构化的“记忆卡片”每条卡片几十个 token只保留和当前 query 最相关的字段。这样即使记忆库很大prompt 长度也可控。这三个 Zero 加起来才是它能在榜单上跑出高分的同时保持工程可落地性的原因。纯刷分的方案很多但能同时兼顾分数和实用性的不多。3. 核心细节拆解记忆的写入、检索与融合3.1 写入阶段怎么把一段对话拆成三条轨的记忆写入是整套系统的入口也是最容易做错的地方。很多方案写入时只做 embedding信息在入口就丢了。Agent Zero Memory 的写入流程我拆成四步第一步实体与槽位抽取。对每轮对话跑一个轻量的 NER命名实体识别加关系抽取。这一步不需要大模型用 spaCy 或者小型的 BERT 变体就够。抽出来的东西包括人名、地名、时间、数字、产品名以及它们之间的关系。比如“我昨天在京东买了个键盘”抽出{时间: 昨天, 平台: 京东, 商品: 键盘, 动作: 购买}。第二步时序归一化。“昨天”“下周三”“上个月”这些相对时间全部转成绝对时间戳。这一步看似简单但跨时区、跨会话的时候很容易出错。我的经验是时间归一化一定要在写入时做不要留到检索时做否则每次查询都要重新算既慢又容易不一致。第三步冲突检测与版本管理。新记忆写入前先查事实轨里有没有同槽位的旧值。如果有且值不同按时序保留新的旧值打上superseded_by标记。注意是标记不是删除。LoCoMo 里有些问题专门考“用户之前说什么后来改了什么”删了就答不出来。第四步推理轨的结论生成。这一步可选但强烈建议做。对抽取出来的事实跑一组规则生成可能的推导结论。规则不用太复杂比如“出差 外地 具体日期”触发“该日期本地不可用”。这些结论存进推理轨带一个较低的置信度。写入的吞吐量是个工程问题。如果每轮对话都同步跑这四步延迟会上去。我的做法是写入走异步队列对话响应不等待写入完成。但要注意异步写入有个坑如果用户在写入完成前就问了相关问题会查不到。解决办法是维护一个短期的“热记忆”缓存最近几轮对话直接放内存不走完整写入流程。3.2 检索阶段三条轨怎么各查各的检索是分数的直接来源。三条轨的检索策略完全不同这是设计上的关键。事实轨检索走的是槽位匹配 语义兜底。用户 query 进来先做一次实体识别看能不能匹配到已知槽位。比如 query 里有“车”事实轨里正好有车型槽位直接命中。匹配不到才走 embedding 相似度。这个顺序很重要——槽位匹配的准确率远高于纯语义能命中就不要用 embedding。时序轨检索走的是时间窗口 事件链。先根据 query 里的时间词确定一个时间范围比如“上周”就查上周的事件。然后沿着事件链做前后扩展把相关的前置和后置事件也拉出来。时序轨的检索结果不是单条记忆而是一段事件序列这样模型能看到事情的来龙去脉。推理轨检索走的是结论匹配。query 进来直接匹配推理轨里缓存的结论。比如 query 是“周三有什么安排”推理轨里正好有“周三本地不可用”的结论直接返回。推理轨的命中率不高但一旦命中价值极大因为它省掉了模型重新推理的步骤。三条轨的检索是并行的各自返回 top-k 结果然后进融合层。这里有个细节三条轨的 k 值不一样。事实轨 k 可以小一点3 到 5 就够因为槽位匹配很准。时序轨 k 要大一点10 到 15因为事件链需要上下文。推理轨 k 最小1 到 2因为结论本身就是压缩过的。3.3 融合层怎么把三路结果拼成模型能用的记忆卡片融合层是整套架构里最“玄学”的部分也是分数差距拉开的地方。我根据榜单表现和常见做法推测它的融合逻辑包含三个维度置信度加权。每条记忆带一个置信度分数。事实轨的槽位匹配给 0.9语义匹配给 0.7时序轨的事件给 0.8推理轨的结论给 0.6。加权后排序取 top-N。时效性衰减。记忆的分数随时间衰减但衰减曲线不是线性的。事实类记忆比如“用户的名字”衰减很慢几个月前的名字现在依然有效。时序类记忆衰减快一周前的“今天要开会”现在基本没用。推理类记忆衰减最快因为推导结论的时效性最强。去重与压缩。三条轨可能返回重复信息。比如事实轨返回“用户住在北京”推理轨返回“用户本地在北京”这俩是同一件事。融合层要做语义去重合并成一条。合并后的记忆卡片格式大概是[事实] 用户车型: Model Y (置信度 0.92, 更新时间 2024-01-15) [时序] 2024-01-10 用户提到下周三去北京出差 (置信度 0.85) [推理] 2024-01-17 用户不在本地 (置信度 0.60, 来源: 出差事件推导)这种结构化卡片塞进 prompt模型读起来比一堆原始对话片段高效得多。实测下来同样信息量卡片格式的 token 消耗只有原始片段的 30% 到 40%。4. 实操复现从零搭一套简化版多轨记忆4.1 环境准备与依赖选型要复现这套架构不需要从头造轮子。我列一下我实际用过的技术栈都是成熟组件组件选型理由实体抽取spaCy 自定义规则轻量、快、可离线不需要 GPU向量检索FAISS 或 Chroma本地部署简单API 友好时序存储SQLite 时间索引够用别上重型数据库推理规则纯 Python 规则引擎规则不多的话没必要上 Drools 这类异步队列Redis RQ写入异步化避免阻塞对话安装命令大概是这样pip install spacy faiss-cpu chromadb redis rq python -m spacy download zh_core_web_sm如果你处理的是中文对话spaCy 的中文模型效果一般可以考虑换成 HanLP 或者 LTP。我实测 HanLP 在中文实体抽取上比 spaCy 准 10 个百分点左右但速度慢一些。看你的延迟要求。4.2 写入管道的代码骨架写入管道的核心是一个MemoryWriter类我贴一下关键逻辑import time from datetime import datetime class MemoryWriter: def __init__(self, fact_store, temporal_store, inference_store): self.fact_store fact_store self.temporal_store temporal_store self.inference_store inference_store self.rules load_inference_rules() def write(self, dialogue_turn): # 第一步实体与槽位抽取 entities extract_entities(dialogue_turn.text) slots extract_slots(entities, dialogue_turn.text) # 第二步时序归一化 timestamp normalize_time(dialogue_turn.time_ref, dialogue_turn.timestamp) # 第三步冲突检测 for slot in slots: old self.fact_store.get(slot.key) if old and old.value ! slot.value: self.fact_store.mark_superseded(old.id, slot.id) self.fact_store.put(slot, timestamp) # 第四步推理轨结论生成 for rule in self.rules: if rule.matches(slots, timestamp): conclusion rule.apply(slots, timestamp) self.inference_store.put(conclusion, confidence0.6) # 时序轨写入 self.temporal_store.put(dialogue_turn, timestamp)这段代码里有个细节值得说冲突检测那一步mark_superseded不是删除旧值而是打标记。查询的时候默认过滤掉被标记的但如果有 query 明确问“之前是什么”可以放开过滤。这个设计在 LoCoMo 的跨会话问题上很关键。4.3 检索与融合的代码骨架检索侧的核心是MemoryRetriever三条轨并行查然后融合class MemoryRetriever: def retrieve(self, query, top_n5): # 并行查三条轨 fact_results self.fact_store.search(query, k5) temporal_results self.temporal_store.search(query, k15) inference_results self.inference_store.search(query, k2) # 加权 for r in fact_results: r.score * 0.9 if r.match_type slot else 0.7 for r in temporal_results: r.score * 0.8 for r in inference_results: r.score * 0.6 # 时效性衰减 now time.time() for r in fact_results temporal_results inference_results: age_days (now - r.timestamp) / 86400 decay self.decay_curve(r.type, age_days) r.score * decay # 合并去重 all_results fact_results temporal_results inference_results all_results.sort(keylambda x: x.score, reverseTrue) deduped semantic_dedup(all_results) return deduped[:top_n]衰减曲线decay_curve我用的是一组经验参数事实类exp(-age/180)时序类exp(-age/7)推理类exp(-age/3)。这些数字不是理论最优是我调了几轮之后觉得比较稳的。你可以根据自己的场景调比如客服场景时序衰减可以更慢因为用户的问题周期可能更长。4.4 记忆卡片的生成与注入检索出来的结果要转成模型能读的卡片格式def format_memory_cards(results): cards [] for r in results: if r.type fact: cards.append(f[事实] {r.key}: {r.value} (置信度 {r.score:.2f})) elif r.type temporal: cards.append(f[时序] {r.time_str} {r.event} (置信度 {r.score:.2f})) else: cards.append(f[推理] {r.conclusion} (置信度 {r.score:.2f})) return \n.join(cards)注入 prompt 的时候把卡片放在 system message 或者 user message 的前面加一句“以下是相关记忆供参考”。实测下来卡片放在 user message 里比放在 system message 里效果好因为模型对 user message 的关注度更高。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查顺序我一般是这样先看实体抽取有没有错。如果 query 里的关键实体没抽出来后面全白搭。中文场景下人名和地名的抽取最容易出错。我的做法是维护一个领域词典把常见实体加进去抽取时优先匹配词典。再看时间归一化对不对。“下周三”这种相对时间如果归一化错了时序轨整个跑偏。建议写个单元测试把各种时间表达都覆盖一遍。最后看融合权重。如果事实轨的结果总是被时序轨挤掉说明时序轨的权重给高了。调权重的时候一次只调一个参数不然你分不清是哪个改动起了作用。5.2 记忆冲突怎么处理冲突分两种真冲突和假冲突。真冲突是用户确实改了信息比如“我换工作了”。这种按时序保留新的旧的标记过期。假冲突是抽取错误导致的比如把“我朋友的车是 Model 3”抽成了“用户的车是 Model 3”。这种要靠实体消歧来解决。我的做法是在槽位抽取时加一个主语判断只有主语是“我”或者用户 ID 的才写入用户槽位其他的一律走普通记忆存储。5.3 写入延迟太高怎么优化写入延迟主要来自实体抽取和推理规则。优化手段实体抽取用更小的模型或者做 batch 处理推理规则只保留高频的长尾规则异步跑写入走队列对话响应不等待我实测下来把写入异步化之后对话的 P99 延迟从 800ms 降到了 200ms 左右。代价是写入有最多几秒的延迟但大多数场景可以接受。5.4 记忆库越来越大怎么办这是所有记忆系统的终极问题。我的策略是分层存储层级存储内容保留策略热层最近 7 天记忆全量保留内存缓存温层7 天到 90 天保留事实和重要时序推理结论压缩冷层90 天以上只保留事实轨时序和推理归档冷层的记忆不参与实时检索但如果 query 明确指向很久以前可以触发冷层查询。这样既控制了检索规模又不丢历史信息。5.5 常见问题速查表现象可能原因排查动作检索结果全是无关记忆实体抽取失败检查 NER 输出补充领域词典同一信息反复出现去重逻辑失效检查 semantic_dedup 的阈值时序推理错误时间归一化有误单元测试覆盖相对时间表达写入后查不到异步队列积压检查队列长度和消费者数量推理轨从不命中规则覆盖不足统计规则触发率补充高频规则记忆卡片太长top_n 太大减小 k 值加强压缩6. 这套架构的边界与我的实际体会榜单分数好看不代表所有场景都能直接套。我在实际项目里踩过的坑有几个值得单独说。第一领域迁移不是免费的。Agent Zero Memory 的实体抽取和推理规则都是领域相关的。你在客服场景调好的规则换到医疗场景可能一半都失效。迁移的时候实体词典和规则库要重新过一遍工作量不小。第二多轨并行带来的是工程复杂度。三条轨意味着三套存储、三套检索逻辑、一个融合层。调试的时候一个问题可能出在任意一条轨上。我的建议是先把事实轨跑通再加时序轨最后加推理轨。一次性上三条轨出了问题你根本不知道从哪查。第三榜单分数和用户体验之间有 gap。LongMemEval 和 LoCoMo 考的是特定类型的记忆问题但真实用户的问法千奇百怪。我遇到过用户问“你还记得我上次说的那个吗”这种指代极其模糊的 query任何检索系统都很难处理。这时候与其硬检索不如让模型直接反问“您指的是哪件事”体验反而更好。第四推理轨的置信度阈值要谨慎。推理轨的结论是推导出来的不是用户明说的。如果置信度阈值设太低模型会把推导结论当事实用容易出错。我一般把推理轨的结论在卡片里明确标注“推理”让模型知道这是推导的不是用户原话。最后分享一个我在调这套架构时觉得最有用的技巧给每条记忆加一个“来源”字段。来源可以是“用户明说”“系统推导”“外部导入”。检索的时候来源影响置信度权重。用户明说的权重最高系统推导的次之外部导入的最低。这个字段看起来不起眼但在排查“为什么模型用了错误信息”的时候能帮你快速定位是哪个环节引入的。这套架构后续还能扩展的方向我比较看好的是记忆的主动遗忘。现在所有方案都在做“怎么记住”但真实的人类记忆是会遗忘的而且遗忘本身是一种智能。哪些记忆该忘、什么时候忘、忘了之后怎么恢复这些问题目前还没有好的答案。如果你在做相关的东西这块值得深挖。 多轨并行记忆架构：LLM Agent长程记忆与跨会话一致性实战
1. 从两个榜单分数说起这套记忆架构到底在解决什么LongMemEval 95.60%LoCoMo 93.60%。这两个数字放在一起看做 LLM Agent 的人应该能立刻意识到分量——LongMemEval 考的是长程记忆的召回与推理LoCoMo 考的是多轮对话里跨会话、跨时间线的信息一致性。两个榜单同时刷到 93 分以上意味着这套叫 Agent Zero Memory 的东西不是靠某个单点技巧冲分而是在“记得住”和“用得对”这两件事上同时做到了接近上限的水平。先把背景说清楚。LLM Agent 的记忆问题本质上不是“存不下”而是“存了之后取不准、取回来之后用不对”。一个跑了三个月的客服 Agent对话历史可能有几十万 token用户上周随口提过一句“我下个月要搬家”这周问“推荐个附近的餐厅”如果 Agent 把“搬家”这个信息丢了推荐的就是旧地址周边的餐厅体验直接崩掉。LongMemEval 这类基准测的就是这种能力在超长上下文中能不能精准定位到相关的那条记忆并且正确推理出它对当前问题的影响。LoCoMo 更狠一点。它是多会话multi-session的设定对话被切成一段一段中间有时间间隔Agent 需要跨这些片段把同一个人的信息拼起来。比如第一段对话里用户说“我养了只猫叫豆豆”第五段对话里用户说“豆豆最近不爱吃东西”Agent 得知道这两个“豆豆”是同一只猫并且把“猫”和“不吃饭”关联起来给出建议。这种跨会话的实体一致性是很多记忆方案的死穴。Agent Zero Memory 这个名字里的“Zero”我理解不是“零记忆”而是“零额外负担”——不需要为每个 Agent 单独训练记忆模块不需要把历史全塞进 context window而是用一套多轨并行的架构把记忆的存储、检索、推理拆成几条独立的轨道各跑各的最后在决策层汇合。这个思路和传统的“向量数据库 RAG”有本质区别后面会展开讲。适合谁来读这篇如果你正在做 LLM Agent 的产品落地被“记不住”“记混了”“记太多导致推理变慢”这几个问题折磨过那这套架构的拆解值得你花时间。如果你只是好奇榜单分数怎么来的也能从里面看到记忆系统设计的核心权衡。我会尽量把每个设计选择背后的“为什么”讲透而不是只丢结论。2. 多轨并行记忆架构的核心设计逻辑2.1 为什么单轨记忆一定会撞墙先看大多数团队做 Agent 记忆的默认路径把所有对话历史 embedding 之后塞进向量库查询时做相似度检索top-k 结果拼进 prompt。这套方案在 demo 阶段很好用但一上量就出问题。第一个问题是检索粒度和推理需求不匹配。用户问“我上次说的那个项目 deadline 是什么时候”向量检索会返回包含“deadline”“项目”这些词的片段但真正有用的信息可能是三天前一句“这个项目老板说月底必须交”里面根本没有“deadline”这个词。语义相似度在这里失效了因为记忆的价值不在于“像”而在于“相关”。第二个问题是时间维度的丢失。向量库里的记忆是无序的检索出来的片段没有时间戳的强弱关系。但很多记忆问题本质是时序推理“用户先说了 A后说了 BB 覆盖了 A”。单轨架构里A 和 B 可能同时被检索出来模型看到两个矛盾的信息要么瞎猜要么直接摆烂说“信息不一致”。第三个问题是写入放大。每轮对话都往向量库写库越来越大检索噪声越来越高。你可能会说“那就做摘要”但摘要本身又是有损的摘掉的可能正是后面要用的细节。这是一个死循环。Agent Zero Memory 的多轨设计就是针对这三个问题分别开药方。2.2 三条轨道的分工事实轨、时序轨、推理轨根据公开的技术描述和榜单表现反推这套架构至少包含三条并行轨道我按功能给它们起名叫事实轨、时序轨、推理轨。这不是官方命名但能帮你理解它的运作方式。事实轨负责存“是什么”。用户的名字、偏好、设备型号、订单号这类结构化程度较高的信息走这条轨。它的检索不是纯语义相似而是结合了实体识别和槽位匹配。比如用户说“我的车是 Model Y”事实轨会抽取出{用户: 车主, 车型: Model Y}这样的三元组存下来。下次用户问“我的车充电要多久”事实轨直接命中“车型”这个槽位不需要靠 embedding 去猜。时序轨负责存“什么时候发生了什么”。每条记忆带时间戳并且维护一个事件序列。它的核心能力是时序覆盖检测当新记忆和旧记忆在同一个实体上冲突时按时序保留新的但把旧的标记为“已过期”而不是删除。这样既避免了矛盾信息同时出现又保留了历史可追溯性。LoCoMo 里那种跨会话的实体一致性很大程度上靠这条轨来保证。推理轨负责存“推导出来的结论”。这是最容易被忽略但最关键的一条。用户说“我下周三要去北京出差”事实轨存了“下周三”“北京”“出差”时序轨存了事件时间。但推理轨会进一步推出“用户下周三不在本地”“可能需要订票”“本地安排要避开周三”。这些推导结果不是用户明说的但后续对话极可能用到。推理轨把这些中间结论缓存下来下次相关查询直接命中不用重新推导。三条轨并行跑各自有独立的索引和检索策略最后在一个融合层做结果合并。融合层不是简单拼接而是按置信度和时效性加权。事实轨的命中置信度最高时序轨次之推理轨最低但覆盖面最广。这个权重设计直接影响了 LongMemEval 的分数——召回率和准确率的平衡点就在这里。2.3 “Zero”的含义零训练、零侵入、零上下文膨胀再解释一下名字里的 Zero。我理解它对应三个设计目标零训练不需要为记忆模块单独做 fine-tune。很多记忆方案要训练一个 retriever 或者 reranker成本高且迁移性差。Agent Zero Memory 用的是现成的 embedding 模型加规则引擎开箱即用。零侵入不需要改 LLM 本身的推理流程。记忆的读写发生在 LLM 调用之外Agent 的主逻辑不用动。这意味着你可以把它套在任意现有的 Agent 框架上不管是 ReAct 还是 Plan-and-Execute。零上下文膨胀检索回来的记忆不是全塞进 prompt而是经过融合层压缩成结构化的“记忆卡片”每条卡片几十个 token只保留和当前 query 最相关的字段。这样即使记忆库很大prompt 长度也可控。这三个 Zero 加起来才是它能在榜单上跑出高分的同时保持工程可落地性的原因。纯刷分的方案很多但能同时兼顾分数和实用性的不多。3. 核心细节拆解记忆的写入、检索与融合3.1 写入阶段怎么把一段对话拆成三条轨的记忆写入是整套系统的入口也是最容易做错的地方。很多方案写入时只做 embedding信息在入口就丢了。Agent Zero Memory 的写入流程我拆成四步第一步实体与槽位抽取。对每轮对话跑一个轻量的 NER命名实体识别加关系抽取。这一步不需要大模型用 spaCy 或者小型的 BERT 变体就够。抽出来的东西包括人名、地名、时间、数字、产品名以及它们之间的关系。比如“我昨天在京东买了个键盘”抽出{时间: 昨天, 平台: 京东, 商品: 键盘, 动作: 购买}。第二步时序归一化。“昨天”“下周三”“上个月”这些相对时间全部转成绝对时间戳。这一步看似简单但跨时区、跨会话的时候很容易出错。我的经验是时间归一化一定要在写入时做不要留到检索时做否则每次查询都要重新算既慢又容易不一致。第三步冲突检测与版本管理。新记忆写入前先查事实轨里有没有同槽位的旧值。如果有且值不同按时序保留新的旧值打上superseded_by标记。注意是标记不是删除。LoCoMo 里有些问题专门考“用户之前说什么后来改了什么”删了就答不出来。第四步推理轨的结论生成。这一步可选但强烈建议做。对抽取出来的事实跑一组规则生成可能的推导结论。规则不用太复杂比如“出差 外地 具体日期”触发“该日期本地不可用”。这些结论存进推理轨带一个较低的置信度。写入的吞吐量是个工程问题。如果每轮对话都同步跑这四步延迟会上去。我的做法是写入走异步队列对话响应不等待写入完成。但要注意异步写入有个坑如果用户在写入完成前就问了相关问题会查不到。解决办法是维护一个短期的“热记忆”缓存最近几轮对话直接放内存不走完整写入流程。3.2 检索阶段三条轨怎么各查各的检索是分数的直接来源。三条轨的检索策略完全不同这是设计上的关键。事实轨检索走的是槽位匹配 语义兜底。用户 query 进来先做一次实体识别看能不能匹配到已知槽位。比如 query 里有“车”事实轨里正好有车型槽位直接命中。匹配不到才走 embedding 相似度。这个顺序很重要——槽位匹配的准确率远高于纯语义能命中就不要用 embedding。时序轨检索走的是时间窗口 事件链。先根据 query 里的时间词确定一个时间范围比如“上周”就查上周的事件。然后沿着事件链做前后扩展把相关的前置和后置事件也拉出来。时序轨的检索结果不是单条记忆而是一段事件序列这样模型能看到事情的来龙去脉。推理轨检索走的是结论匹配。query 进来直接匹配推理轨里缓存的结论。比如 query 是“周三有什么安排”推理轨里正好有“周三本地不可用”的结论直接返回。推理轨的命中率不高但一旦命中价值极大因为它省掉了模型重新推理的步骤。三条轨的检索是并行的各自返回 top-k 结果然后进融合层。这里有个细节三条轨的 k 值不一样。事实轨 k 可以小一点3 到 5 就够因为槽位匹配很准。时序轨 k 要大一点10 到 15因为事件链需要上下文。推理轨 k 最小1 到 2因为结论本身就是压缩过的。3.3 融合层怎么把三路结果拼成模型能用的记忆卡片融合层是整套架构里最“玄学”的部分也是分数差距拉开的地方。我根据榜单表现和常见做法推测它的融合逻辑包含三个维度置信度加权。每条记忆带一个置信度分数。事实轨的槽位匹配给 0.9语义匹配给 0.7时序轨的事件给 0.8推理轨的结论给 0.6。加权后排序取 top-N。时效性衰减。记忆的分数随时间衰减但衰减曲线不是线性的。事实类记忆比如“用户的名字”衰减很慢几个月前的名字现在依然有效。时序类记忆衰减快一周前的“今天要开会”现在基本没用。推理类记忆衰减最快因为推导结论的时效性最强。去重与压缩。三条轨可能返回重复信息。比如事实轨返回“用户住在北京”推理轨返回“用户本地在北京”这俩是同一件事。融合层要做语义去重合并成一条。合并后的记忆卡片格式大概是[事实] 用户车型: Model Y (置信度 0.92, 更新时间 2024-01-15) [时序] 2024-01-10 用户提到下周三去北京出差 (置信度 0.85) [推理] 2024-01-17 用户不在本地 (置信度 0.60, 来源: 出差事件推导)这种结构化卡片塞进 prompt模型读起来比一堆原始对话片段高效得多。实测下来同样信息量卡片格式的 token 消耗只有原始片段的 30% 到 40%。4. 实操复现从零搭一套简化版多轨记忆4.1 环境准备与依赖选型要复现这套架构不需要从头造轮子。我列一下我实际用过的技术栈都是成熟组件组件选型理由实体抽取spaCy 自定义规则轻量、快、可离线不需要 GPU向量检索FAISS 或 Chroma本地部署简单API 友好时序存储SQLite 时间索引够用别上重型数据库推理规则纯 Python 规则引擎规则不多的话没必要上 Drools 这类异步队列Redis RQ写入异步化避免阻塞对话安装命令大概是这样pip install spacy faiss-cpu chromadb redis rq python -m spacy download zh_core_web_sm如果你处理的是中文对话spaCy 的中文模型效果一般可以考虑换成 HanLP 或者 LTP。我实测 HanLP 在中文实体抽取上比 spaCy 准 10 个百分点左右但速度慢一些。看你的延迟要求。4.2 写入管道的代码骨架写入管道的核心是一个MemoryWriter类我贴一下关键逻辑import time from datetime import datetime class MemoryWriter: def __init__(self, fact_store, temporal_store, inference_store): self.fact_store fact_store self.temporal_store temporal_store self.inference_store inference_store self.rules load_inference_rules() def write(self, dialogue_turn): # 第一步实体与槽位抽取 entities extract_entities(dialogue_turn.text) slots extract_slots(entities, dialogue_turn.text) # 第二步时序归一化 timestamp normalize_time(dialogue_turn.time_ref, dialogue_turn.timestamp) # 第三步冲突检测 for slot in slots: old self.fact_store.get(slot.key) if old and old.value ! slot.value: self.fact_store.mark_superseded(old.id, slot.id) self.fact_store.put(slot, timestamp) # 第四步推理轨结论生成 for rule in self.rules: if rule.matches(slots, timestamp): conclusion rule.apply(slots, timestamp) self.inference_store.put(conclusion, confidence0.6) # 时序轨写入 self.temporal_store.put(dialogue_turn, timestamp)这段代码里有个细节值得说冲突检测那一步mark_superseded不是删除旧值而是打标记。查询的时候默认过滤掉被标记的但如果有 query 明确问“之前是什么”可以放开过滤。这个设计在 LoCoMo 的跨会话问题上很关键。4.3 检索与融合的代码骨架检索侧的核心是MemoryRetriever三条轨并行查然后融合class MemoryRetriever: def retrieve(self, query, top_n5): # 并行查三条轨 fact_results self.fact_store.search(query, k5) temporal_results self.temporal_store.search(query, k15) inference_results self.inference_store.search(query, k2) # 加权 for r in fact_results: r.score * 0.9 if r.match_type slot else 0.7 for r in temporal_results: r.score * 0.8 for r in inference_results: r.score * 0.6 # 时效性衰减 now time.time() for r in fact_results temporal_results inference_results: age_days (now - r.timestamp) / 86400 decay self.decay_curve(r.type, age_days) r.score * decay # 合并去重 all_results fact_results temporal_results inference_results all_results.sort(keylambda x: x.score, reverseTrue) deduped semantic_dedup(all_results) return deduped[:top_n]衰减曲线decay_curve我用的是一组经验参数事实类exp(-age/180)时序类exp(-age/7)推理类exp(-age/3)。这些数字不是理论最优是我调了几轮之后觉得比较稳的。你可以根据自己的场景调比如客服场景时序衰减可以更慢因为用户的问题周期可能更长。4.4 记忆卡片的生成与注入检索出来的结果要转成模型能读的卡片格式def format_memory_cards(results): cards [] for r in results: if r.type fact: cards.append(f[事实] {r.key}: {r.value} (置信度 {r.score:.2f})) elif r.type temporal: cards.append(f[时序] {r.time_str} {r.event} (置信度 {r.score:.2f})) else: cards.append(f[推理] {r.conclusion} (置信度 {r.score:.2f})) return \n.join(cards)注入 prompt 的时候把卡片放在 system message 或者 user message 的前面加一句“以下是相关记忆供参考”。实测下来卡片放在 user message 里比放在 system message 里效果好因为模型对 user message 的关注度更高。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查顺序我一般是这样先看实体抽取有没有错。如果 query 里的关键实体没抽出来后面全白搭。中文场景下人名和地名的抽取最容易出错。我的做法是维护一个领域词典把常见实体加进去抽取时优先匹配词典。再看时间归一化对不对。“下周三”这种相对时间如果归一化错了时序轨整个跑偏。建议写个单元测试把各种时间表达都覆盖一遍。最后看融合权重。如果事实轨的结果总是被时序轨挤掉说明时序轨的权重给高了。调权重的时候一次只调一个参数不然你分不清是哪个改动起了作用。5.2 记忆冲突怎么处理冲突分两种真冲突和假冲突。真冲突是用户确实改了信息比如“我换工作了”。这种按时序保留新的旧的标记过期。假冲突是抽取错误导致的比如把“我朋友的车是 Model 3”抽成了“用户的车是 Model 3”。这种要靠实体消歧来解决。我的做法是在槽位抽取时加一个主语判断只有主语是“我”或者用户 ID 的才写入用户槽位其他的一律走普通记忆存储。5.3 写入延迟太高怎么优化写入延迟主要来自实体抽取和推理规则。优化手段实体抽取用更小的模型或者做 batch 处理推理规则只保留高频的长尾规则异步跑写入走队列对话响应不等待我实测下来把写入异步化之后对话的 P99 延迟从 800ms 降到了 200ms 左右。代价是写入有最多几秒的延迟但大多数场景可以接受。5.4 记忆库越来越大怎么办这是所有记忆系统的终极问题。我的策略是分层存储层级存储内容保留策略热层最近 7 天记忆全量保留内存缓存温层7 天到 90 天保留事实和重要时序推理结论压缩冷层90 天以上只保留事实轨时序和推理归档冷层的记忆不参与实时检索但如果 query 明确指向很久以前可以触发冷层查询。这样既控制了检索规模又不丢历史信息。5.5 常见问题速查表现象可能原因排查动作检索结果全是无关记忆实体抽取失败检查 NER 输出补充领域词典同一信息反复出现去重逻辑失效检查 semantic_dedup 的阈值时序推理错误时间归一化有误单元测试覆盖相对时间表达写入后查不到异步队列积压检查队列长度和消费者数量推理轨从不命中规则覆盖不足统计规则触发率补充高频规则记忆卡片太长top_n 太大减小 k 值加强压缩6. 这套架构的边界与我的实际体会榜单分数好看不代表所有场景都能直接套。我在实际项目里踩过的坑有几个值得单独说。第一领域迁移不是免费的。Agent Zero Memory 的实体抽取和推理规则都是领域相关的。你在客服场景调好的规则换到医疗场景可能一半都失效。迁移的时候实体词典和规则库要重新过一遍工作量不小。第二多轨并行带来的是工程复杂度。三条轨意味着三套存储、三套检索逻辑、一个融合层。调试的时候一个问题可能出在任意一条轨上。我的建议是先把事实轨跑通再加时序轨最后加推理轨。一次性上三条轨出了问题你根本不知道从哪查。第三榜单分数和用户体验之间有 gap。LongMemEval 和 LoCoMo 考的是特定类型的记忆问题但真实用户的问法千奇百怪。我遇到过用户问“你还记得我上次说的那个吗”这种指代极其模糊的 query任何检索系统都很难处理。这时候与其硬检索不如让模型直接反问“您指的是哪件事”体验反而更好。第四推理轨的置信度阈值要谨慎。推理轨的结论是推导出来的不是用户明说的。如果置信度阈值设太低模型会把推导结论当事实用容易出错。我一般把推理轨的结论在卡片里明确标注“推理”让模型知道这是推导的不是用户原话。最后分享一个我在调这套架构时觉得最有用的技巧给每条记忆加一个“来源”字段。来源可以是“用户明说”“系统推导”“外部导入”。检索的时候来源影响置信度权重。用户明说的权重最高系统推导的次之外部导入的最低。这个字段看起来不起眼但在排查“为什么模型用了错误信息”的时候能帮你快速定位是哪个环节引入的。这套架构后续还能扩展的方向我比较看好的是记忆的主动遗忘。现在所有方案都在做“怎么记住”但真实的人类记忆是会遗忘的而且遗忘本身是一种智能。哪些记忆该忘、什么时候忘、忘了之后怎么恢复这些问题目前还没有好的答案。如果你在做相关的东西这块值得深挖。