《Agent记忆错误的100个案例手册》第 91–95 案例
本辑为《Agent记忆错误的100个案例手册》连载内容。
案例 91：记忆架构与系统设计错误｜monolithic-memory-bottleneck-scaling
场景
Agent的所有记忆（短期、长期、情景、语义）存储在单一的数据库实例中。随着用户量增长，该数据库的CPU和I/O达到极限，查询延迟从50ms增加到2s。
错误表现
Agent的响应时间显著增加，用户体验下降。高峰期出现连接池耗尽，请求超时失败。
解决方案
- 记忆分层架构：短期记忆使用Redis（内存型），长期记忆使用向量数据库，语义记忆使用图数据库
- 对长期记忆实施”用户分片”：按用户ID哈希分片到多个数据库实例
- 引入”读写分离”：写操作走主库，读操作走从库，减轻主库压力
原理
不同记忆类型有不同的访问模式和一致性要求。单体架构无法满足多样化的性能需求。分层和分片是应对规模增长的必然选择。
案例 92：记忆架构与系统设计错误｜memory-tier-migration-data-loss
场景
系统架构将30天前的短期记忆自动迁移到长期记忆。迁移脚本将短期记忆的JSON格式转换为长期记忆的向量格式。但JSON中的”用户情绪标签”字段在长期记忆Schema中没有对应字段，被丢弃。
错误表现
用户查询早期对话时，Agent无法感知当时的情绪上下文，回复缺乏共情。情感分析报告显示早期对话的情绪数据缺失。
解决方案
- 迁移前进行”Schema映射校验”：识别源Schema中有但目标Schema中没有的字段，触发人工审核或自动映射
- 使用”Schema演进”策略：目标Schema支持”扩展字段”，未知字段以JSON Blob形式保留
- 迁移后进行”数据完整性审计”：抽样检查迁移前后记录的关键字段一致性
原理
数据迁移是系统工程的高风险环节。Schema不兼容会导致静默数据丢失。严格的迁移前检查和迁移后审计是必要的质量保障。
案例 93：记忆架构与系统设计错误｜backup-restore-point-inconsistency
场景
系统进行备份时，向量数据库的备份时间是T1，关系数据库的备份时间是T2（T2 > T1）。恢复时，向量数据库恢复到T1状态，关系数据库恢复到T2状态。某条记忆在T1-T2之间被更新：向量表示变了，但关系数据库中的元数据仍是旧的。
错误表现
Agent检索到该记忆时，向量与元数据不匹配（如向量表示”喜欢A”，元数据记录”喜欢B”），导致输出混乱。
解决方案
- 实施”一致性快照”：备份时暂停写入或使用分布式快照（如MySQL的FLUSH TABLES WITH READ LOCK）
- 记录”备份时间戳”：恢复时检查各组件的备份时间，不一致时触发告警或手动对齐
- 使用”变更日志”（Changelog）：恢复后通过日志重放将各组件同步到同一时间点的状态
原理
多组件系统的备份如果没有全局一致性保证，恢复后会进入逻辑上不可能的状态。分布式事务和全局快照是解决这一问题的标准方案。
案例 94：记忆架构与系统设计错误｜memory-garbage-collection-overhead
场景
Agent实现了自动垃圾回收（GC）机制：每月清理过期记忆。GC过程需要扫描全部记忆记录，检查过期时间。随着记忆数据增长到1亿条，GC过程耗时6小时，期间CPU和I/O飙升，影响正常查询。
错误表现
GC期间Agent响应延迟增加10倍，用户投诉”系统卡顿”。运维被迫在业务低峰期手动触发GC。
解决方案
- 将GC改为”增量式”：每次只清理一小批（如1万条），分散到多个小任务中
- 使用”TTL索引”：依赖数据库的自动过期机制（如Redis的expire，MongoDB的TTL索引），而非应用层扫描
- 对记忆进行”分区分治”：按时间分区，只清理最老的分区，避免全表扫描
原理
垃圾回收是必要功能，但实现方式决定了对系统的影响。全量扫描式的GC在大数据量下不可持续。利用数据库原生能力和增量策略是更好的设计。
案例 95：记忆架构与系统设计错误｜schema-evolution-memory-corruption
场景
Agent记忆的JSON Schema从v1演进为v2：v1中”用户偏好”是字符串，v2中改为对象（{"theme": "dark", "language": "zh"}）。系统未对旧数据进行迁移，新代码按v2解析旧数据。
错误表现
解析旧记忆时抛出异常，Agent无法读取用户的旧偏好设置，回退到默认值。日志中充满JSON解析错误。
解决方案
- 实施”Schema版本控制”：每条记忆记录存储其Schema版本号，解析时按版本号选择对应的解析逻辑
- “读时迁移”（Read-time Migration）：读取旧版本数据时自动转换为最新版本
- “写时强制升级”：写入时检查数据版本，旧版本数据先升级再写入
原理
Schema演进是长期运行系统的必然需求。没有版本管理机制的系统，在Schema变化后会面临”旧数据无法解析”的困境。
来源：Agent Search