Agent记忆去重与更新策略实战指南-育师

我实测过太多次Agent记忆出问题的场景了——刚聊完“下周三开会”，转头又问“会议时间定好了吗”；用户明确说“我不吃香菜”，下一轮却推荐了香菜拌牛肉；更离谱的是，同一段对话被存了三次，每次timestamp差200ms，内容几乎一样，但其中一条把“张工”错记成“章工”。这不是模型幻觉，是记忆系统本身在漏油。

核心关键词就四个：Agent、记忆、去重、更新策略。不是讲LLM怎么生成，而是聚焦在——当一个Agent每天要处理几十轮对话、调用上百次工具、积累上千条记忆片段时，它的记忆库如何不变成一锅越搅越浑的粥？这个问题在真实落地中比“怎么调大模型参数”更致命：参数错了还能重训，记忆乱了，Agent就彻底失忆+撒谎+反复犯错。

我过去三年带过7个Agent产品从0到1，覆盖客服、编程助手、企业知识助理三类场景，所有项目都卡在记忆质量这一关。不是没试过方案：早期直接用Redis List硬存，结果查历史时翻出5条重复会议记录；后来上向量库做相似度去重，召回率掉到63%；再后来引入时间戳+版本号双控，又发现旧记忆删不干净，导致“张工”和“章工”长期共存……最终我把所有踩过的坑、压测的数据、可复用的代码逻辑，全部沉淀下来，横向对比了6种策略，从纯内存操作到混合存储架构，从SQL去重到语义指纹校验，测出每种方案的真实开销、适用边界和失效条件。这篇文章不讲理论推导，只讲我在生产环境里亲手跑通、上线、压测、迭代过的实操路径。适合正在做Agent开发、已经遇到记忆混乱问题、或者正准备设计记忆模块的工程师、产品经理、技术负责人。如果你还在用“先存再说，后面加个去重脚本”这种思路，这篇就是给你省三个月返工时间的避坑指南。

1. 记忆混乱的本质不是模型问题，而是数据流设计缺陷

1.1 所有重复和矛盾，都源于三个底层断裂点

很多人第一反应是“是不是embedding不准？”、“是不是rerank阈值设低了？”，其实90%以上的记忆矛盾，根本不在LLM侧，而在数据流的三个关键断裂点上：

写入断裂：Agent执行链中多个节点（tool call返回、user input解析、system prompt注入）各自独立触发记忆写入，没有统一入口和事务控制。比如用户说“把会议改到周四”，tool调用日历API成功后写了一条“会议已改至周四”，但Agent自身推理又补了一条“用户要求调整会议时间”，两条记录语义重叠但结构不同。
读取断裂：检索时只按向量相似度排序，不校验时间新鲜度、来源可信度、状态有效性。我见过最典型的情况：用户刚说“取消原定会议”，系统却召回三天前那条“会议定于周三14:00”的记录，因为它的向量相似度更高——它没意识到“取消”这个动作本身，就是对旧记忆的显式否定。
更新断裂：没有原子化的“更新”操作，只有“新增+标记删除”或“覆盖写入”。前者导致旧记录残留（比如“张工”没删干净），后者导致版本丢失（比如覆盖时把“张工负责前端”和“张工兼任测试”两条信息合并成“张工负责前端兼任测试”，丢失了职责变更的时间线）。

这三点不是孤立问题，而是环环相扣的系统性缺陷。你优化向量检索，解决不了写入时的多源头冲突；你加时间衰减因子，解决不了“取消会议”这类否定型指令的语义覆盖；你换更贵的向量库，解决不了旧记忆残留引发的逻辑矛盾。必须从数据流设计层面重建记忆生命周期。

1.2 真实业务场景中的矛盾类型，远比demo复杂

网上教程常拿“用户姓名/电话”举例，但实际Agent记忆矛盾要棘手得多。我整理了线上系统近半年报出的TOP5矛盾类型，每种都附真实日志片段（已脱敏）：

矛盾类型	典型表现	发生频率	根本原因	修复难度
语义等价重复	“张伟”、“张工”、“张老师”指向同一人，但被存为三条独立记忆	38%	实体识别未归一化，NER模型未对指代词做消歧	★★★☆
时间倒置矛盾	后续对话中用户说“不要发邮件”，但系统仍召回并执行了前序“请发会议纪要邮件”的指令	27%	写入时未绑定操作状态（pending/executed/cancelled），检索时不过滤已撤销指令	★★★★
上下文漂移重复	同一段会议描述，在A对话中记为“需求评审会”，在B对话中记为“UI走查会”，因上下文窗口不同导致分类偏差	19%	记忆切片未携带原始对话ID和上下文快照，导致跨会话语义漂移	★★★★
数值精度矛盾	“预算5万” vs “预算50000元” vs “约5万元”，数字表达不一致导致无法合并	12%	数值标准化缺失，未做单位归一、精度截断、口语化转标准格式	★★☆
否定覆盖失败	用户说“上次说的方案不用了”，但系统未删除或降权原方案记忆，后续仍主动引用	4%	缺乏否定意图识别模块，且记忆库无“被否决”状态字段	★★★★★

注意看最后一列“修复难度”：最难的不是技术实现，而是定义清楚什么算“有效更新”。比如“张工”和“张伟”要不要合并？如果用户在不同对话中刻意使用不同称呼（对上级称“张工”，对平级称“张伟”），强行归一反而破坏沟通习惯。所以策略选择的第一步，不是写代码，而是画清业务边界——你的Agent服务的是谁？容忍什么程度的冗余？哪些矛盾必须零容忍？

1.3 为什么传统数据库思维在这里失效？

很多工程师第一反应是“上MySQL，加唯一索引”。但Agent记忆不是用户注册表，它有三个反数据库特性：

高动态性：一条记忆可能每小时被更新5次（状态变更、补充细节、关联新事件），而传统数据库主键设计假设实体稳定。
弱结构化：记忆内容是自然语言片段，不是固定schema的字段。“会议时间”可能出现在“下周三下午”、“3天后14:00”、“2024-06-12T14:00:00”三种格式，无法用CHECK约束统一。
读写不对称：写入频次是读取的3~5倍（每轮对话至少写2条：user utterance + agent action），而数据库优化通常针对读多写少场景。

我曾在一个客服Agent项目里强行用PostgreSQL+GIN全文索引，结果写入QPS超300时，WAL日志暴涨，主从同步延迟达47秒——用户刚修改完地址，查询时还返回旧地址。后来换成内存+LSM Tree混合架构，写入延迟从120ms降到8ms，代价是牺牲了ACID，换来最终一致性。这不是妥协，而是对业务本质的尊重：Agent记忆不需要银行级强一致，但需要毫秒级写入和亚秒级检索。

2. 六种去重与更新策略的实测对比：成本、效果、适用场景全拆解

2.1 策略0：不做任何处理（Baseline）

这是90%早期项目的默认状态——所有输出直接append进数组或list。表面看最简单，实测在1000轮对话后，记忆库膨胀率达320%，重复率41.7%，矛盾率18.3%（基于人工抽检200条）。

典型问题：
- 同一会议被记录5次，每次只差一个标点或空格
- “张工”出现12次，“张伟”出现7次，“张老师”出现3次，全部未关联
- 用户说“别提醒我”，系统仍按原计划推送3次
适用场景：仅限POC验证阶段，或单轮对话、无状态Agent（如一次性图片生成Agent）。一旦进入多轮交互，必须淘汰。

提示：千万别用“后期加个定时去重脚本”来安慰自己。我见过团队在上线后第3周才加去重，结果发现已有2.3万条重复记忆，清洗耗时17小时，期间Agent持续输出错误信息，客户投诉激增。记忆治理必须前置，不能当补丁打。

2.2 策略1：字符串哈希去重（低成本入门版）

原理：对记忆文本做MD5或SHA256哈希，用哈希值作唯一键存入Map。相同文本必得相同哈希，实现精确去重。

实测数据（10万条记忆）：
- 去重率：63.2%（仅消除完全相同的字符串）
- 内存占用：增加12MB（哈希值存储）
- 写入延迟：+0.8ms（单核CPU）
- 矛盾率下降：仅2.1%（因无法处理“张工/张伟”类语义重复）
关键改进点：
- 预处理标准化：去除首尾空格、统一换行符、小写转换、过滤不可见字符（\u200b等零宽空格）
- 哈希范围控制：不用全文本哈希，而是提取关键字段哈希（如{type: "meeting", time: "2024-06-12", participants: ["zhang"]}），避免无关描述影响
代码片段（Python）：

import hashlib import json def get_dedup_key(memory_dict): # 只取核心字段，忽略自由描述 key_fields = { "type": memory_dict.get("type"), "time": memory_dict.get("time"), # 标准化为ISO格式 "participants": sorted(memory_dict.get("participants", [])), "action": memory_dict.get("action", "").strip().lower() } key_str = json.dumps(key_fields, sort_keys=True) return hashlib.md5(key_str.encode()).hexdigest() # 使用示例 memories = {} new_mem = {"type": "meeting", "time": "2024-06-12", "participants": ["zhang", "li"], "action": "review requirements"} key = get_dedup_key(new_mem) if key not in memories: memories[key] = new_mem # 存入字典

经验心得：
这个策略最大的价值不是去重本身，而是强制你定义记忆的核心schema。很多团队卡在第一步，就是因为没想清楚“什么才算同一条记忆”。我建议用此策略跑一周，然后人工抽检哈希碰撞率——如果1000条里有3条以上不同内容却哈希相同，说明你的key_fields设计太粗放，需要加入更多判别字段（如加入context_id对话ID）。

2.3 策略2：语义指纹+阈值去重（平衡版）

原理：用轻量级sentence-transformer模型（如all-MiniLM-L6-v2）生成128维向量，计算余弦相似度，高于阈值（如0.85）则视为重复。

实测数据（10万条记忆）：
- 去重率：79.5%（覆盖“张工/张伟”、“5万/50000”等语义重复）
- 内存占用：增加1.2GB（向量存储）
- 写入延迟：+18ms（GPU加速下）/+85ms（CPU）
- 矛盾率下降：12.6%（显著改善指代词矛盾）
关键配置技巧：
- 阈值不是固定值：对“人名/地名”类记忆用0.92，对“会议描述”类用0.78，对“否定指令”类用0.95（宁可漏判，不可误判）
- 增量更新：不每次全量计算，只与最近100条记忆比对（LRU缓存），降低O(n²)复杂度
- 双模校验：先字符串哈希快速过滤，再语义相似度精筛，综合延迟降至+12ms
代码片段（使用faiss加速）：

import faiss import numpy as np from sentence_transformers import SentenceTransformer model = SentenceTransformer('all-MiniLM-L6-v2') index = faiss.IndexFlatIP(128) # 内积即余弦相似度 memory_vectors = [] memory_texts = [] def add_memory(text: str): vec = model.encode([text])[0] # 只与最近100条比对 recent_vecs = np.array(memory_vectors[-100:]) if memory_vectors else np.empty((0,128)) if len(recent_vecs) > 0: similarities = np.dot(recent_vecs, vec) # 余弦相似度 if np.max(similarities) > 0.85: return False # 重复，不存 memory_vectors.append(vec) memory_texts.append(text) index.add(np.array([vec])) return True

经验心得：
别迷信“更高维向量=更好效果”。我对比过384维的paraphrase-multilingual-MiniLM-L12-v2，去重率只提升1.2%，但延迟翻倍。MiniLM系列在精度和速度间找到了最佳平衡点。另外，阈值调优必须结合业务抽检：设0.85时漏掉3条重要重复，设0.86时多删2条有效记忆，这时就要看哪类错误代价更高——对客服Agent，漏掉重复可能导致重复打扰用户；对编程Agent，多删可能丢失关键代码上下文。

2.4 策略3：时间窗口+状态机更新（高可靠版）

原理：不追求“绝对去重”，而是构建记忆状态机，每条记忆有active/deprecated/archived状态，通过时间窗口和操作类型自动流转。

状态定义：
- active：当前有效，参与检索
- deprecated：被新记忆否定或覆盖，保留7天供回溯
- archived：归档，只读，不参与检索
状态流转规则：
- 当新记忆含否定词（“取消”、“不要”、“忽略”）且指向旧记忆ID，则旧记忆→deprecated
- 当新记忆与旧记忆type+key_fields匹配度>0.9，则旧记忆→deprecated，新记忆→active
- deprecated记忆7天后自动→archived
实测数据（10万条记忆）：
- 矛盾率下降：16.8%（几乎消灭时间倒置和否定覆盖失败）
- 检索准确率：+22.3%（因deprecated记忆不参与召回）
- 存储开销：+15%（状态字段+时间戳）
- 写入延迟：+5.2ms（纯逻辑判断，无向量计算）
代码片段（状态机核心）：

from datetime import datetime, timedelta class MemoryState: ACTIVE = "active" DEPRECATED = "deprecated" ARCHIVED = "archived" def update_memory_state(old_mem, new_mem): # 规则1：否定指令 if is_negation_instruction(new_mem.get("content", "")): if old_mem.get("id") == new_mem.get("ref_id"): return MemoryState.DEPRECATED # 规则2：高匹配覆盖 if calculate_similarity(old_mem, new_mem) > 0.9: return MemoryState.DEPRECATED return MemoryState.ACTIVE def is_negation_instruction(text): neg_words = ["取消", "不要", "忽略", "撤回", "作废", "停用"] return any(word in text for word in neg_words) # 使用示例 old_mem = {"id": "m1001", "state": "active", "content": "发送会议纪要"} new_mem = {"ref_id": "m1001", "content": "不要发邮件"} new_state = update_memory_state(old_mem, new_mem) # 返回 "deprecated"

经验心得：
这个策略的威力在于把“更新”变成可审计的操作。上线后我们能清晰看到：哪条记忆被谁在何时因何原因废弃。某次客户投诉“Agent反复提醒已取消的会议”，我们5分钟内定位到是ref_id传递错误，而非模型问题。状态机不是银弹，但它让问题变得可追踪、可修复。建议所有中大型Agent项目从这个策略起步。

2.5 策略4：双网络记忆模型（长短期分离版）

原理：借鉴人类记忆机制，拆分为短期记忆（working memory）和长期记忆（long-term memory），二者独立更新、协同检索。

短期记忆（Working Memory）：
- 容量：固定20条（LRU淘汰）
- 更新：每轮对话实时刷新，不持久化
- 作用：支撑当前对话连贯性（如指代消解：“他”是谁）
长期记忆（Long-term Memory）：
- 存储：向量库+关系图谱（Neo4j）
- 更新：仅当短期记忆中某条信息稳定存在>3轮，且被用户确认/工具执行成功，才晋升为长期记忆
- 检索：先查短期记忆（毫秒级），再查长期记忆（百毫秒级）
实测数据（10万条记忆）：
- 重复率下降：52.1%（因短期记忆天然去重）
- 矛盾率下降：19.4%（长期记忆经多轮验证，质量更高）
- 检索延迟：P95 < 120ms（短期记忆占85%查询）
- 架构复杂度：+40%（需维护两套存储+同步逻辑）
关键设计点：
- 晋升阈值：不是简单计数，而是加权。用户说“对”+1分，工具执行成功+2分，主动追问+1分，满5分晋升
- 降级机制：长期记忆若30天未被检索，自动降为“冷存档”，移出向量库，只保文本
经验心得：
这个模型最反直觉的点是：短期记忆不存，反而提升质量。因为短期记忆只服务于当前上下文，存多了反而干扰（比如把上轮对话的“张工”错误带到本轮）。我们做过AB测试：A组用传统单库，B组用双网络，B组在多轮对话任务中F1提升14.7%。但要注意，双网络不是堆资源，而是用架构设计规避问题——就像高速公路修辅道，不是让所有车挤主路。

2.6 策略5：Hindsight记忆库（事后修正版）

原理：不依赖实时判断，而是定期（如每小时）扫描全量记忆，用更强模型做全局分析，识别并修正矛盾。

工作流程：
1. 抽样：随机抽取5%记忆（含所有active状态）
2. 聚类：用UMAP降维+HDBSCAN聚类，发现语义簇
3. 仲裁：对每个簇，用GPT-4 Turbo生成“权威摘要”，覆盖矛盾点
4. 更新：将摘要存为新记忆，原簇内记忆标为deprecated
实测数据（10万条记忆）：
- 矛盾率下降：23.1%（最高，尤其擅长处理上下文漂移）
- 运维成本：每小时CPU占用12%，内存峰值+800MB
- 延迟影响：零（异步后台运行）
- 适用规模：>50万条记忆时ROI最高
关键配置：
- 抽样策略：不是随机，而是按last_accessed_at倒序，优先修正高频访问记忆
- 仲裁提示词：必须包含业务约束，如“若出现人名不一致，以用户首次输入为准”
- 回滚机制：每次修正生成diff日志，支持一键回退
经验心得：
Hindsight不是替代实时策略，而是兜底。就像汽车的ABS系统——平时不用，但关键时刻救命。我们把它部署在生产环境后，每周自动生成《记忆健康报告》，列出TOP10矛盾簇和修正建议。某次发现“项目预算”相关记忆有7个不同数值，Hindsight自动聚类并生成摘要：“客户确认最终预算为¥480,000，含税，分三期支付”，运营同学直接采纳发布。这种“让AI自己修AI”的模式，大幅降低人工治理成本。

3. 实操落地：从选型到上线的完整链路

3.1 如何选择最适合你的策略？一张决策树说清

别被6种策略吓到。实际选型只需回答3个问题：

你的Agent日均对话量是多少？
- < 100轮 → 策略1（字符串哈希）足够
- 100~1000轮 → 策略2（语义指纹）+ 策略3（状态机）组合
- 1000轮 → 必须上策略4（双网络）或策略5（Hindsight）
你的业务对“矛盾”的容忍度有多高？
- 零容忍（如医疗咨询、金融交易）→ 直接上策略3+策略4
- 可接受少量（如客服问答、内容生成）→ 策略2+策略3足矣
- 仅需基础去重（如内部工具Agent）→ 策略1+预处理
你的工程资源是否充足？
- 单人开发 → 策略1或策略2（开源模型+faiss）
- 小团队（3人） → 策略3（状态机）+ 策略4（短期记忆用内存，长期用PGVector）
- 大团队 → 策略4 + 策略5（Hindsight异步运行）

注意：策略不是非此即彼，而是分层叠加。我们当前主力项目用的是“策略2（语义指纹）+ 策略3（状态机）+ 策略4（双网络）”，但不是同时启用，而是按模块分工：语义指纹管写入去重，状态机管更新逻辑，双网络管存储架构。这样既保证效果，又控制复杂度。

3.2 一套可直接抄作业的最小可行方案（MVP）

如果你明天就要上线，没时间全量重构，这套方案实测3天可落地：

存储层：SQLite（单机）或PostgreSQL（分布式）
- 表结构：memories(id, content, type, key_fields_json, state, created_at, updated_at, ref_id)
- 索引：(type, state, created_at)复合索引
去重层：策略2（语义指纹）轻量版
- 模型：all-MiniLM-L6-v2（128维，CPU友好）
- 比对范围：只与同type的最近50条比对
- 阈值：meeting=0.82，person=0.90，instruction=0.88
更新层：策略3（状态机）简化版
- 仅实现两个状态：active/deprecated
- 仅响应两类操作：ref_id匹配（覆盖）、含否定词（废弃）
部署方式：
- 写入API：POST /memory，内置去重+状态机逻辑
- 检索API：GET /memory?query=...&type=meeting，自动过滤deprecated
监控指标：
- dedup_rate：每千条写入中去重数量
- deprecated_ratio：deprecated记忆占总量比例（健康值<5%）
- avg_retrieval_latency：检索P95延迟

这套方案在我们一个20人团队的内部知识助手项目中，用2天完成开发，3天压测，上线后重复率从38%降至9.2%，客户投诉下降76%。关键是它不依赖外部服务、不增加运维负担、所有代码可审计。

3.3 避坑清单：那些文档里不会写的实战教训

教训1：别在写入时做heavy embedding
我们最早用text-embedding-ada-002，单次写入200ms，QPS卡在5。换成MiniLM后，QPS升到85。记住：写入链路必须快，检索可以慢一点。
教训2：时间戳必须用UTC，且带毫秒
本地时区+秒级精度会导致“同一秒内多条记忆”无法排序。某次跨时区部署，上海和旧金山同事同时写入，时间戳相同，状态机判定失败。现在所有时间戳强制datetime.utcnow().strftime("%Y-%m-%d %H:%M:%S.%f")。
教训3：ref_id不是可选字段，是必填
初期我们让ref_id可空，结果否定指令无法关联旧记忆。后来强制所有写入必须带ref_id（新记忆填null，更新填目标ID），配合数据库NOT NULL约束。
教训4：向量库的nprobe参数比k更重要
Faiss中nprobe=32比k=5对延迟影响更大。我们压测发现，nprobe从16升到64，延迟涨300%，但召回率只升0.7%。最终锁定nprobe=24为黄金值。
教训5：定期清理deprecated不是可选项
我们设了7天自动清理，但忘了加监控。某次磁盘告警才发现deprecated占了82%空间。现在加了SELECT COUNT(*) FROM memories WHERE state='deprecated'每日巡检。

3.4 性能压测实录：不同策略在真实流量下的表现

我们用真实对话日志（脱敏后127万条）做了72小时压测，模拟峰值QPS 200，结果如下：

策略	写入P95延迟	检索P95延迟	内存峰值	磁盘占用	矛盾率	是否推荐
策略0（无处理）	3.2ms	8.7ms	1.2GB	4.8GB	18.3%	❌
策略1（字符串哈希）	4.1ms	9.2ms	1.3GB	4.1GB	16.2%	⚠️ 小项目可用
策略2（语义指纹）	22.4ms	48.6ms	3.8GB	5.2GB	5.7%	✅ 中小项目主力
策略3（状态机）	8.9ms	12.3ms	1.5GB	4.5GB	5.1%	✅ 必选基础层
策略4（双网络）	6.3ms	112.4ms*	2.1GB	6.3GB	3.2%	✅ 大型项目标配
策略5（Hindsight）	4.7ms	15.2ms	4.2GB	7.1GB	2.1%	✅ 百万级记忆必备

*注：双网络的检索延迟是“短期+长期”总和，但92%查询命中短期记忆，实际感知延迟<15ms。

关键发现：策略3（状态机）是性价比最高的单点突破。它增加的延迟最小（+5.7ms），却把矛盾率从18.3%压到5.1%，且代码量最少（不到200行）。所有项目都应该把它作为第一层防护。

4. 常见问题与排查技巧实录

4.1 问题诊断：如何快速定位记忆矛盾根源？

别一上来就调模型。按这个顺序排查，90%问题5分钟内定位：

查写入日志：找矛盾记忆的created_at，看是否同一秒内多次写入（写入断裂）
查ref_id字段：矛盾记忆是否有相同ref_id？如果没有，说明更新链路断了
查状态字段：矛盾记忆是否都是active？如果是，说明状态机未生效
查向量相似度：用策略2的代码手动计算两条记忆的similarity，看是否低于阈值
查时间窗口：如果是时间倒置，看created_at和updated_at是否倒置

我们封装了一个memory-debug命令行工具，输入两条记忆ID，自动输出：

文本差异对比
向量相似度
状态流转路径
关联的ref_id链

提示：在所有写入API里加X-Trace-ID，让日志可追溯。某次发现“张工/张伟”矛盾，顺藤摸瓜发现是前端传参时把name字段错传为nick_name，修复后矛盾率直降。

4.2 典型问题速查表

现象	可能原因	排查命令	解决方案
同一会议存了5次	写入无统一入口，多个模块各自save	`grep "INSERT INTO memories" logs`	收口到统一MemoryService，加分布式锁
“取消会议”后仍执行	`ref_id`未传递或为空	`SELECT * FROM memories WHERE content LIKE '%取消%' AND ref_id IS NULL`	强制所有否定指令必须带`ref_id`，前端SDK校验
检索不到最新记忆	新记忆状态为`deprecated`	`SELECT * FROM memories WHERE state='deprecated' ORDER BY created_at DESC LIMIT 10`	检查状态机规则，确认`ref_id`匹配逻辑
向量检索慢	`nprobe`过大或索引未优化	`faiss_index.get_stats()`	重建索引，调小`nprobe`，加IVF量化
内存暴涨	`deprecated`未清理	`SELECT COUNT(*) FROM memories WHERE state='deprecated'`	加定时任务，每日清理7天前记录

4.3 独家调试技巧：用“记忆快照”还原现场

当线上出现诡异矛盾时，我们不用重启服务，而是用这个技巧：

步骤1：拿到矛盾记忆ID（如m1001,m1002）
步骤2：查它们的ref_id链，向上追溯3层
步骤3：用created_at范围，拉取该时间段所有写入日志
步骤4：用Python重放写入链路，打印每一步的状态变化

我们写了个replay_memory_chain.py，输入ID，自动输出：

m1001: active → (ref_id=m1001, content="会议周三") m1002: active → (ref_id=m1001, content="取消会议") → deprecated m1003: active → (ref_id=m1001, content="会议改周四") → deprecated m1004: active → (ref_id=m1003, content="确认周四会议")

一眼看出问题：m1002和m1003都指向m1001，但m1003没处理m1002的废弃状态。修复状态机规则即可。

4.4 那些你以为是Bug，其实是设计缺陷

“Agent记不住两件事”：不是模型容量不够，是短期记忆容量设太小（默认20条），用户聊到第21轮，第一轮的“张工”就被挤掉了。解决方案：按对话深度动态扩容，或加sticky标记（如“张工”设为sticky，永不淘汰）。
“否定指令不生效”：不是NLP没识别，是ref_id传递链断了。比如用户说“取消上条”，但前端没把上条ID传给后端。解决方案：在SDK层强制cancel_last方法自带ID回溯。
“跨对话记忆混乱”：不是向量不准，是没存conversation_id。两条不同对话里的“会议”，向量相似但语义无关。解决方案：所有记忆必须带conv_id，检索时加WHERE conv_id IN (...)。

最后分享个小技巧：我们给每条记忆加了个confidence_score字段（0~1），由写入模块根据来源打分（user input=0.95，tool output=0.85，model generated=0.7），检索时按分数加权。上线后，低