★ FEATURED ARTICLE 1. 从四条真实 issue 说起agent 记忆层写入期不变量的工程价值agent 记忆层这个话题过去一年在开发者圈子里被讨论得很多但大多数内容集中在“怎么存”“怎么检索”“用向量库还是图数据库”这些层面。真正落到写入路径上的工程约束讨论得并不多。我最近在跟进几个 agent 项目的过程中集中处理了四条来自真实使用场景的 issue它们表面上各不相同但排查到最后根因都指向同一类问题记忆层在写入期缺少明确的不变量约束。所谓写入期不变量说白了就是不管 agent 在运行中怎么折腾只要一次记忆写入被判定为成功那么某些性质必须永远成立。比如“同一条记忆不会出现两个互相矛盾的版本”“写入的因果顺序不会被后续操作打乱”“被标记为已删除的记忆不会在检索时复活”。这些约束如果不在写入路径上强制保证而是指望读取时去补救那基本等于把问题往后拖拖到某次线上事故才爆发。这四条 issue 分别来自四个不同形态的项目一个做多轮对话助手一个做代码仓库里的长期任务 agent一个做电商场景的自动化运营 agent还有一个是做个人知识管理的本地 agent。它们的共同点是都用了某种形式的记忆层都在写入环节踩了坑。我把这四条 issue 的排查过程、根因分析和修复方案整理出来不是为了讲某个具体框架怎么用而是想说明一件事记忆层的可靠性八成取决于写入期不变量的设计而不是检索算法的花哨程度。如果你正在搭 agent或者正在给现有 agent 加记忆能力这篇文章里的每一条经验都值得对照检查。尤其是那些已经上线、开始有真实用户写入数据的项目写入期不变量的缺失往往不会立刻暴露但一旦数据量上来、并发写入变多问题就会集中出现。下面我按 issue 的类型拆开讲每条都会说清楚现象、排查路径、根因和修复方式最后再给出一套可以直接抄的写入期不变量清单。2. 四条 issue 的完整拆解与根因分析2.1 issue 一同一条记忆被并发写入覆盖导致上下文自相矛盾第一个 issue 来自一个多轮对话助手项目。用户反馈的现象是在连续几轮对话里agent 对同一个事实的表述会来回跳。比如用户先说“我住在杭州”几轮之后 agent 又说“你之前提到你在南京”再问一次又变回杭州。用户觉得 agent “失忆”或者“精神分裂”。排查的时候先看了检索层发现检索返回的结果里确实同时存在“住在杭州”和“住在南京”两条记忆而且两条的置信度都很高。再往上追写入日志发现这两条记忆的写入时间戳只差了几十毫秒。进一步看代码问题清楚了这个 agent 在每轮对话结束时会把本轮抽取到的“用户事实”写入记忆层写入方式是“先查有没有同类记忆有就更新没有就插入”。这个“查-改-写”三步在并发场景下不是原子的。当两轮对话的处理几乎同时到达写入环节时两个进程都查到了“没有杭州这条记忆”于是都执行了插入结果就是两条并存的记忆。而其中一条的内容因为某次模型抽取偏差写成了“南京”就造成了后续的矛盾。根因不是检索算法也不是模型抽取不准而是写入路径缺少“同一实体同一属性唯一”这个不变量。修复方式有两种一种是在存储层加唯一约束用实体 ID 加属性名做联合唯一键写入时用 upsert 语义另一种是在应用层加分布式锁把同一实体的写入串行化。我倾向于第一种因为约束放在存储层更可靠应用层的锁一旦有节点异常就容易出问题。修复之后同类问题没有再复现。注意如果你的记忆层用的是“追加写”模型也就是每次写入都新增一条记录、靠时间戳取最新那并发写入不会造成覆盖但会造成“同一时刻两条最新”的歧义。这种情况下不变量应该定义为“同一实体同一属性在任一时刻最多只有一条有效记录”靠版本号或者逻辑时钟来保证。2.2 issue 二写入顺序与因果顺序不一致导致 agent 推理链断裂第二个 issue 来自一个代码仓库里的长期任务 agent。这个 agent 会记录自己在仓库里做过的每一步操作形成一条操作记忆链后续推理时依赖这条链来判断“哪些文件已经改过”“哪些依赖已经装过”。用户反馈的现象是agent 偶尔会重复执行已经做过的操作比如重复安装同一个依赖或者重复修改同一个文件导致冲突。排查发现记忆层里记录的操作顺序和实际执行顺序不一致。具体来说agent 的执行是并行的多个子任务同时跑每个子任务完成后再写记忆。但写入的时候用的是“完成时间”作为排序依据而实际因果顺序应该按“开始时间”或者“依赖关系”来排。结果就是一个后开始但先完成的操作在记忆里排在了前面后续推理时 agent 以为它是最新的就重复执行了它后面的操作。这个问题的根因是写入期没有保证“因果顺序单调”这个不变量。修复方案是给每个操作分配一个逻辑时钟或者单调递增的序列号在操作开始时就分配写入时带上这个序号读取时按序号排序而不是按完成时间。这样即使完成顺序乱掉因果顺序也是对的。另外还加了一条约束任何依赖前置操作的操作在写入前必须确认前置操作的记忆已经落盘否则等待或拒绝写入。2.3 issue 三删除标记被后续写入绕过已删除记忆在检索时复活第三个 issue 来自一个电商场景的自动化运营 agent。这个 agent 会记录用户的偏好和禁忌比如“用户对某类商品不感兴趣”“用户明确说过不要推荐某品牌”。用户反馈的现象是明明已经让 agent 记住“不要再推荐某品牌”过了一段时间 agent 又开始推荐了。排查发现记忆层里确实有一条“不要推荐某品牌”的记录状态是已删除。但检索的时候这条记录又被返回了。再查写入日志发现删除操作之后有一条新的写入操作内容是“用户浏览了某品牌的商品”这条新写入的记录在写入时没有检查“该品牌是否已被标记为禁忌”而且它的写入把之前那条删除标记的“有效版本号”给覆盖了。结果就是删除标记失效旧记忆复活。根因是写入期没有保证“删除是单调的”这个不变量。删除一旦发生后续任何写入都不能让被删除的内容重新变为有效除非显式地执行“恢复”操作。修复方案是在存储层引入“墓碑”机制删除不是物理删除而是写入一条墓碑记录墓碑记录的版本号永远高于同实体的其他记录。任何新写入在落盘前都要检查是否存在同实体的墓碑如果存在且没有显式恢复指令就拒绝写入或者把新写入标记为“待确认”。这样删除就不可逆了除非走专门的恢复路径。2.4 issue 四写入内容未做规范化同一事实以多种形式重复存储第四个 issue 来自一个个人知识管理的本地 agent。这个 agent 会把用户日常记录的内容抽取成结构化记忆比如“用户喜欢喝美式咖啡”“用户偏好美式”。用户反馈的现象是记忆层里关于咖啡偏好的记录越来越多检索时返回一堆重复内容而且有时候因为表述差异agent 会给出不一致的建议。排查发现写入路径上没有做任何规范化。用户每次提到咖啡agent 就抽取一条新记忆表述可能是“喜欢美式”“偏好美式咖啡”“常喝美式”等等。这些在语义上是一回事但在存储层是四条不同的记录。检索时它们都被返回占用了上下文窗口还可能导致模型判断混乱。根因是写入期没有保证“同一语义事实归一化”这个不变量。修复方案是在写入前加一层规范化先做实体识别和属性抽取把“美式”“美式咖啡”归一到同一个实体 ID把“喜欢”“偏好”“常喝”归一到同一个关系类型然后用 upsert 语义写入。如果已有同实体同关系的记录就更新而不是新增。另外还加了一条写入前先做一次相似度检查如果和已有记忆的语义相似度超过阈值就合并而不是新增。3. 写入期不变量的设计原则与落地清单3.1 为什么写入期不变量比读取期补救更可靠很多人设计记忆层的时候习惯把约束放在读取路径上。比如“检索的时候去重”“检索的时候过滤已删除”“检索的时候按时间排序取最新”。这种做法在数据量小、并发低的时候没问题但一旦数据量上来读取路径的每次补救都是一次性能开销而且补救逻辑本身可能出错。更关键的是读取期的补救是“事后”的它无法阻止脏数据被写入。脏数据一旦落盘就会一直存在每次读取都要处理它而且可能被其他写入操作引用造成连锁问题。写入期不变量的思路是在数据落盘之前就把所有该保证的性质保证掉。落盘之后的数据读取路径可以假设它是干净的不需要做额外的过滤和修正。这样做的好处是读取路径简单、快、不容易出错脏数据根本进不来不需要事后清理不变量的检查集中在写入路径容易测试和验证。当然写入期检查会增加写入延迟。但这个延迟是可控的而且可以通过批量写入、异步校验等方式优化。相比之下读取期补救的延迟是不可控的因为读取频率通常远高于写入频率而且读取路径往往在关键路径上延迟敏感。3.2 四条核心不变量及其实现方式结合上面四条 issue我整理出四条最核心的写入期不变量。这四条覆盖了大多数 agent 记忆层的写入问题建议在项目里逐条对照实现。不变量含义实现方式对应 issue唯一性同一实体同一属性在任一时刻最多一条有效记录存储层联合唯一键 upsert 语义issue 一因果单调写入顺序与因果顺序一致不因并发而乱序逻辑时钟或单调序列号写入时携带issue 二删除单调删除不可逆除非显式恢复墓碑机制 版本号比较issue 三语义归一同一语义事实只存一条表述差异被归一实体识别 属性抽取 相似度合并issue 四这四条不变量不是孤立的它们之间有依赖关系。比如“删除单调”依赖“唯一性”因为如果同一实体有多条记录删除哪一条就成了问题。“语义归一”也依赖“唯一性”因为归一之后要用 upsert 写入。所以实现的时候建议按顺序来先做唯一性再做因果单调然后删除单调最后语义归一。3.3 写入路径的完整检查流程把上面四条不变量串起来一次记忆写入的完整检查流程大概是这样的接收写入请求请求里包含实体、属性、值、来源、时间戳、因果序号等元信息。语义归一对实体和属性做归一化映射到标准 ID。如果无法归一走人工确认或标记为待归一。检查墓碑查询同实体是否存在墓碑记录。如果存在且请求没有携带显式恢复指令拒绝写入。检查唯一性查询同实体同属性是否存在有效记录。如果存在比较版本号或因果序号决定是更新还是拒绝。分配版本号为本次写入分配一个单调递增的版本号或逻辑时钟值。落盘以原子操作写入确保唯一性约束和墓碑检查在同一个事务里完成。写后校验写入成功后异步校验一次确认不变量仍然成立。如果发现异常触发告警和修复。这个流程看起来步骤多但每一步都很轻量。实测下来单次写入的额外开销在毫秒级对于大多数 agent 场景完全可以接受。如果写入量特别大可以把语义归一和相似度检查做成异步的先落盘再归一但唯一性和墓碑检查必须在同步路径上。提示如果你的存储层不支持事务比如用的是某些对象存储或者简单的 KV 存储那唯一性和墓碑检查需要靠应用层的锁或者乐观并发控制来实现。这种情况下建议把同一实体的写入路由到同一个处理节点用单线程串行化避免并发问题。4. 实操从零搭建带写入期不变量的记忆层4.1 存储选型与表结构设计存储选型上如果追求强一致性和事务支持关系型数据库是最稳妥的选择。PostgreSQL 或者 SQLite 都支持唯一约束、事务和行级锁足够支撑大多数 agent 场景。如果数据量特别大可以考虑分布式数据库但要注意跨节点事务的开销。如果追求轻量和本地部署SQLite 加 WAL 模式也能撑住不小的写入量。表结构设计上核心是一张记忆表加一张墓碑表。记忆表的关键字段包括实体 ID、属性名、值、版本号、因果序号、来源、创建时间、更新时间、状态。墓碑表的关键字段包括实体 ID、墓碑版本号、创建时间、原因。唯一约束建在“实体 ID 属性名 状态”上状态为有效时才参与唯一性检查。CREATE TABLE memory ( id INTEGER PRIMARY KEY, entity_id TEXT NOT NULL, attribute TEXT NOT NULL, value TEXT NOT NULL, version INTEGER NOT NULL, causal_seq INTEGER NOT NULL, source TEXT, created_at INTEGER NOT NULL, updated_at INTEGER NOT NULL, status TEXT NOT NULL DEFAULT active ); CREATE UNIQUE INDEX idx_memory_unique ON memory (entity_id, attribute) WHERE status active; CREATE TABLE tombstone ( entity_id TEXT PRIMARY KEY, tombstone_version INTEGER NOT NULL, created_at INTEGER NOT NULL, reason TEXT );这个设计里唯一索引带条件只对 active 状态的记录生效这样已删除的记录不会阻塞新写入。墓碑表用实体 ID 做主键保证一个实体最多一条墓碑。版本号用整数每次写入递增墓碑的版本号永远高于同实体的其他记录。4.2 写入逻辑的代码实现写入逻辑用 Python 写一个示例核心是“检查墓碑、检查唯一性、分配版本号、落盘”四步在一个事务里完成。import sqlite3 import time def write_memory(conn, entity_id, attribute, value, causal_seq, sourceNone): now int(time.time() * 1000) with conn: cur conn.cursor() # 检查墓碑 cur.execute(SELECT tombstone_version FROM tombstone WHERE entity_id ?, (entity_id,)) row cur.fetchone() if row: tombstone_version row[0] # 没有显式恢复指令拒绝写入 raise ValueError(fentity {entity_id} is tombstoned, write rejected) # 检查唯一性并获取当前版本号 cur.execute( SELECT id, version FROM memory WHERE entity_id ? AND attribute ? AND status active, (entity_id, attribute) ) existing cur.fetchone() if existing: new_version existing[1] 1 cur.execute( UPDATE memory SET value ?, version ?, causal_seq ?, updated_at ?, source ? WHERE id ?, (value, new_version, causal_seq, now, source, existing[0]) ) else: new_version 1 cur.execute( INSERT INTO memory (entity_id, attribute, value, version, causal_seq, source, created_at, updated_at, status) VALUES (?, ?, ?, ?, ?, ?, ?, ?, active), (entity_id, attribute, value, new_version, causal_seq, source, now, now) ) return new_version这段代码的关键点整个操作在一个事务里唯一索引保证并发写入时只有一个能成功另一个会触发唯一约束冲突需要重试。墓碑检查在事务内保证删除和写入不会交错。版本号在事务内递增保证单调。4.3 删除逻辑与墓碑写入删除逻辑比写入简单但要注意墓碑的版本号必须高于同实体的所有记录。def delete_memory(conn, entity_id, reasonNone): now int(time.time() * 1000) with conn: cur conn.cursor() # 获取当前最大版本号 cur.execute(SELECT MAX(version) FROM memory WHERE entity_id ?, (entity_id,)) row cur.fetchone() max_version row[0] if row and row[0] else 0 tombstone_version max_version 1 # 写入墓碑 cur.execute( INSERT OR REPLACE INTO tombstone (entity_id, tombstone_version, created_at, reason) VALUES (?, ?, ?, ?), (entity_id, tombstone_version, now, reason) ) # 标记所有有效记录为已删除 cur.execute( UPDATE memory SET status deleted, updated_at ? WHERE entity_id ? AND status active, (now, entity_id) ) return tombstone_version墓碑写入用 INSERT OR REPLACE保证一个实体只有一条墓碑且版本号是最新的。标记删除用 UPDATE把同实体的所有有效记录状态改为 deleted。这样后续写入检查墓碑时会拒绝检索时也不会返回已删除的记录。4.4 因果序号的分配与使用因果序号用来保证写入顺序和因果顺序一致。最简单的做法是用一个全局单调递增的计数器每次操作开始时分配一个序号。如果 agent 是分布式的可以用逻辑时钟比如 Lamport 时钟或者混合逻辑时钟。class CausalClock: def __init__(self): self.counter 0 self.lock threading.Lock() def next(self): with self.lock: self.counter 1 return self.counter在操作开始时调用clock.next()获取序号写入时带上。读取时按 causal_seq 排序而不是按 created_at 或 updated_at。这样即使完成顺序乱掉因果顺序也是对的。如果操作之间有依赖关系可以在写入前检查前置操作的 causal_seq 是否已经落盘没有就等待或拒绝。5. 常见问题与排查技巧实录5.1 写入冲突频繁重试次数过多怎么办如果并发写入很高唯一约束冲突会频繁触发重试次数多了会影响性能。解决办法有两个一是把同一实体的写入路由到同一个处理节点用单线程串行化避免并发冲突二是用乐观并发控制写入时带上版本号版本号不匹配就拒绝让调用方决定是重试还是放弃。实测下来路由到同一节点的方式更简单可靠尤其适合实体数量不多但写入频繁的场景。5.2 墓碑表越来越大怎么清理墓碑表只增不减时间长了会变大。但墓碑不能随便删因为删了之后已删除的记忆可能复活。解决办法是给墓碑加一个“安全期”如果某个实体的所有记忆都已经物理删除且超过安全期没有新写入就可以把墓碑也删掉。安全期的长度取决于业务场景一般设为一周到一个月。清理的时候要确保没有并发的写入操作最好在低峰期做。5.3 语义归一的阈值怎么定语义归一的相似度阈值是个经验值。阈值太高同一事实的不同表述归不到一起还是会重复存储阈值太低不同事实可能被错误合并。我的经验是先用一批标注数据跑一下看不同阈值下的准确率和召回率选一个平衡点。一般余弦相似度在 0.85 到 0.92 之间比较合适。另外归一之后最好保留原始表述作为元信息方便追溯和人工校验。5.4 写入期检查影响延迟怎么优化写入期检查的延迟主要来自墓碑查询、唯一性查询和相似度计算。墓碑查询和唯一性查询都可以走索引延迟很低。相似度计算如果同步做延迟会比较高。优化方式是把相似度计算做成异步的先落盘标记为“待归一”后台任务再去做归一和合并。这样写入路径的延迟就降下来了归一延迟对用户体验影响不大。5.5 常见问题速查表问题现象可能原因排查方向解决方式同一事实多条记录缺少唯一性约束查写入日志看是否有并发写入加唯一索引 upsert操作顺序错乱因果序号缺失或未使用查记忆的排序字段加逻辑时钟按序号排序已删除记忆复活墓碑被绕过或版本号错误查墓碑表和写入日志墓碑版本号高于所有记录写入前检查重复记忆多缺少语义归一查相似记忆的表述差异加归一化 相似度合并写入冲突频繁并发高唯一约束冲突查冲突率和重试次数路由到同一节点或乐观并发控制5.6 几个容易踩的坑第一个坑是把唯一性约束建在错误的字段上。比如建在“实体 ID 值”上而不是“实体 ID 属性”上。这样同一属性的不同值会被当成不同记录唯一性失效。正确的做法是建在“实体 ID 属性”上值可以更新。第二个坑是墓碑版本号和记录版本号不在同一个序列里。如果墓碑版本号是独立生成的可能比记录版本号小导致删除被后续写入绕过。正确的做法是墓碑版本号从同实体的最大记录版本号递增。第三个坑是因果序号在重试时重新分配。如果写入失败重试因果序号应该保持不变否则因果顺序会乱。正确的做法是在操作开始时分配一次重试时复用。第四个坑是语义归一在写入后才做。如果先落盘再归一中间会有一段时间存在重复记录检索时可能返回重复内容。正确的做法是归一在写入前做或者落盘时标记为“待归一”检索时过滤掉。6. 写入期不变量的测试与验证方法6.1 并发写入测试并发写入测试是验证唯一性不变量的关键。用多线程或多进程同时写入同一实体同一属性看最终是否只有一条有效记录。测试的时候要注意写入的值要不同这样才能检测出覆盖问题并发数要足够高至少几十个并发才能触发竞态条件。import threading def concurrent_write_test(conn, entity_id, attribute, num_threads50): errors [] def worker(i): try: write_memory(conn, entity_id, attribute, fvalue_{i}, causal_seqi) except Exception as e: errors.append(e) threads [threading.Thread(targetworker, args(i,)) for i in range(num_threads)] for t in threads: t.start() for t in threads: t.join() # 检查最终记录数 cur conn.cursor() cur.execute(SELECT COUNT(*) FROM memory WHERE entity_id ? AND attribute ? AND status active, (entity_id, attribute)) count cur.fetchone()[0] assert count 1, fexpected 1 active record, got {count} return errors这个测试跑下来如果最终只有一条有效记录说明唯一性不变量生效了。如果有冲突异常说明唯一约束在起作用但调用方需要处理重试。6.2 删除后写入测试删除后写入测试验证删除单调性。先写入一条记忆然后删除再尝试写入同实体同属性看是否被拒绝。如果写入成功说明墓碑机制失效。def tombstone_test(conn, entity_id, attribute): write_memory(conn, entity_id, attribute, original, causal_seq1) delete_memory(conn, entity_id) try: write_memory(conn, entity_id, attribute, new_value, causal_seq2) raise AssertionError(write after tombstone should be rejected) except ValueError: pass # 预期行为这个测试跑通说明删除不可逆。如果业务需要恢复可以加一个显式的恢复接口恢复时删除墓碑并写入新记录。6.3 因果顺序测试因果顺序测试验证写入顺序和因果顺序一致。模拟并发操作每个操作分配不同的因果序号写入后按序号排序看顺序是否正确。def causal_order_test(conn, entity_id): # 模拟三个操作因果序号分别为 3, 1, 2完成顺序打乱 write_memory(conn, entity_id, attr_a, value_a, causal_seq3) write_memory(conn, entity_id, attr_b, value_b, causal_seq1) write_memory(conn, entity_id, attr_c, value_c, causal_seq2) cur conn.cursor() cur.execute(SELECT attribute FROM memory WHERE entity_id ? ORDER BY causal_seq, (entity_id,)) order [row[0] for row in cur.fetchall()] assert order [attr_b, attr_c, attr_a], funexpected order: {order}这个测试跑通说明因果顺序正确。如果顺序不对检查写入时是否正确携带了因果序号读取时是否按序号排序。6.4 语义归一测试语义归一测试验证同一语义的不同表述被归一到同一条记录。准备几组语义相同但表述不同的输入写入后检查记录数。def normalization_test(conn, entity_id): variants [喜欢美式, 偏好美式咖啡, 常喝美式] for i, v in enumerate(variants): write_memory(conn, entity_id, coffee_preference, v, causal_seqi) cur conn.cursor() cur.execute(SELECT COUNT(*) FROM memory WHERE entity_id ? AND attribute coffee_preference AND status active, (entity_id,)) count cur.fetchone()[0] assert count 1, fexpected 1 normalized record, got {count}这个测试需要归一化逻辑配合如果归一化没做好记录数会大于 1。测试的时候要注意归一化本身可能有误差所以断言可以放宽到“记录数不超过 2”然后人工检查是否合理。7. 从 issue 到不变量一套可复用的排查思路7.1 遇到记忆层问题时的排查顺序遇到 agent 记忆层的问题我一般按这个顺序排查先看现象是“多了”还是“少了”还是“乱了”。多了通常是唯一性或归一化问题少了通常是删除或墓碑问题乱了通常是因果顺序问题。然后查写入日志看问题记录是怎么写进去的写入时的元信息是否完整。再查存储层的约束看唯一索引、墓碑表、版本号是否按预期工作。最后查读取路径看是否有过滤或排序逻辑把问题掩盖了。这个顺序的好处是从现象到根因逐层缩小范围。大多数问题在查写入日志这一步就能定位因为写入日志里能看到写入时的实体、属性、值、版本号、因果序号对照不变量一查就知道哪条没满足。7.2 如何判断一个记忆层是否可靠判断一个记忆层是否可靠我一般看几个指标写入冲突率、删除复活率、重复记录率、因果乱序率。写入冲突率高说明并发控制有问题删除复活率高说明墓碑机制有问题重复记录率高说明归一化有问题因果乱序率高说明因果序号有问题。这几个指标都可以通过日志统计出来建议做成监控面板持续观察。另外还可以做混沌测试随机注入并发写入、删除后写入、乱序写入看系统是否能保持不变量。混沌测试能发现很多正常测试发现不了的问题尤其是竞态条件和边界情况。7.3 写入期不变量的演进方向写入期不变量不是一成不变的随着 agent 能力的发展可能需要增加新的不变量。比如现在很多 agent 支持多模态记忆那可能需要“同一模态同一实体唯一”的不变量。再比如 agent 开始有跨会话的长期记忆那可能需要“跨会话因果一致”的不变量。建议在设计之初就把不变量做成可扩展的用插件或者中间件的方式实现方便后续增加。另外不变量的检查可以做成可配置的不同场景开启不同的检查。比如对一致性要求高的场景开启全部检查对性能要求高的场景只开启核心检查。这样灵活度更高适配不同的业务需求。8. 一些实操中的个人体会这四条 issue 处理下来我最大的体会是记忆层的问题八成不是检索算法的问题而是写入路径的问题。很多人一上来就研究向量检索、混合检索、重排序但真正让 agent 记忆不可靠的往往是写入时没管好。把写入期不变量做扎实检索层用最简单的方案都能跑得很好。另一个体会是不变量的检查要趁早。项目初期数据量小问题不容易暴露但一旦上线有真实用户写入问题就会集中出现。与其等到出问题再补不如一开始就把不变量设计进去。前期多花一天设计后期少花一周排查。还有一点不要指望模型来解决一致性问题。有些团队想用更强的模型来做记忆去重和冲突消解但模型本身有不确定性用它来保证不变量等于把可靠性寄托在概率上。不变量应该由确定性的代码来保证模型只负责抽取和归一化不负责一致性。最后分享一个小技巧在写入路径上加一个“不变量断言”开关测试环境开启生产环境关闭。测试时每次写入都断言不变量成立一旦违反就抛异常能提前发现很多问题。生产环境关闭是为了性能但可以定期抽样开启做在线校验。这个开关成本很低但收益很大建议每个记忆层都加上。
阅读完成 · 觉得有帮助？
