数据库管理460期 2026-08-13胖头鱼的技术专栏-460 输入给 Agent 记忆不是越多越好20260813记住一切可能等于无法使用记忆需要版本而不是直接覆盖图关系让记忆链条可理解整理、压缩和遗忘到底怎么落地记忆与知识的区别数据库解决的是治理问题总结胖头鱼的技术专栏-460 输入给 Agent 记忆不是越多越好20260813作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭本期继续“川序”的介绍https://db4agent.cn要知道最早我做这个系统是想解决 Agent 记忆的问题项目原来名称是oracle-memory。在“川序”的记忆相关能力不断迭代过程越做越发现一个反直觉的事——记忆不是越多越好反而是记太多最后等于什么都没记住。这就好比你家里有一屋子书但全是散乱堆在地上的每次要找一本都得翻遍整个屋子。最后你肯定不是把书扔掉而是得找人或自己动手搞一套编目系统——分类、贴标签、建索引、标记哪些书是新版哪些已经过时了。Agent 的记忆治理说白了就是这个道理。记住一切可能等于无法使用最早的记忆方案都很朴素——把对话、经验、规则往文件里一塞就完事了。一开始确实挺好用毕竟内容少Agent 扫一眼就能找到。但问题是随着内容越堆越多Agent 为了找一条有用信息得把几十上百条无关内容全读进上下文。旧内容、重复内容、过时内容——全混在一起。Token 烧得飞起检索准确率反而蹭蹭往下掉。同时大量的记忆相关内容占用宝贵的上下文空间还容易因为不需要的内容导致上下文污染进而将整个任务带偏。这就像你让一个实习生去档案室翻一份三年前的合同——档案室里堆满了各种草稿、复印件、过期公告他翻了一上午最后拿给你的可能还是错的版本。所以说记忆的价值不在数量而在于当前任务能不能拿到正确、相关、且还有效的那几条。我之前聊 Agent 记忆的时候提过三位一体存储架构——标量、向量和属性图共存。但光有存储不够你还需要一整套治理机制。记忆需要版本而不是直接覆盖这里说个很多人都踩过的坑——直接修改或删除记忆。看起来简单粗暴但带来的问题很致命一是一旦调整了记忆你 / Agent 可能就永远不知道过去发生过什么二是如果调整记忆过程中出了错很难恢复。而且说实话企业环境里还有合规要求——你不能因为“整理一下”就把原始事实给物理删除了。我在“川序”里用了版本化记忆这一套思路——其实借鉴的就是数据库里的版本管理思想每条记忆实体有一个稳定的Family你可以理解为“一家人”的族谱具体内容以不可变的 Version保存通过“当前版本指针”决定运行时默认用哪一版。整理、压缩、修正的时候不是直接改原文而是先生成候选版本经过复核后再发布为当前版本。说白了这就像维基百科的编辑流程——你看到的永远是“当前稳定版”但后台所有编辑历史都在随时可以对比、回退、追责。过期或不适合运行的记忆标记为逻辑不可用或迁移到历史状态不物理删除。这样既不会让历史内容跑进当前上下文中捣乱也保留了复核和恢复的依据。图关系让记忆链条可理解我之前在以前的篇文章里说过——记忆之间不只有相似这一种关系。某条记忆可能来源于一次任务、修正于一次人工复核、又被某个 Agent 引用过。通过图关系你可以查看它的版本谱系、来源链、修正记录和使用路径——就像一本书的借阅记录和修订历史清清楚楚。但这里有个重要的点这些关系是解释和检索的依据不是授权来源。当前运行默认只读取“当前版本”且在授权范围内的记忆历史节点不会因为出现在关系图里就自动跑进上下文——这一点“川序”是通过数据库授权边界来保证的不是靠提示词。整理、压缩和遗忘到底怎么落地说到记忆整理很多人第一反应是“让模型定期清理一下数据库”——这个想法本身就有问题。我实际的做法是把整理拆成预览和执行两个阶段预览阶段根据范围、时间、使用频率、相似度、冲突和来源生成候选版本不改变当前版本执行阶段由持有数据库租约的 Worker 处理按照已批准的策略生成新版本、归档旧版本或标记逻辑不可用。压缩也不是简单截断文本——一个合格的候选结果必须保留来源版本、摘要生成时间、使用范围、置信度和整理原因并且能回指原始内容。遇到相互矛盾的记忆怎么办不能光靠相似度就覆盖掉——得进复核队列由人或专用 Review Agent 处理。在《Agent 上线之后谁来负责它》那篇里聊过 Agent 的生命周期管理其实记忆治理跟它是同一套思路——谁来负责、怎么复核、出了问题怎么回退。还有一个细节很多人容易忽略整理作业的并发控制。两个 Worker 同时整理同一个 Family 时必须用租约、版本号或条件更新防止互相覆盖人工复核已通过后旧的候选不能再替换它。这些规则在“川序”里是通过数据库事务和唯一约束搞定的——把业务约定变成可执行事实而不是靠应用层祈祷别出 bug。记忆与知识的区别说实话这是我见过最容易混淆的地方——很多人把所有东西往一个“知识库”里塞。记忆和知识本质上来源不同、更新策略不同、责任主体也不同记忆来自 Agent 或用户在运行过程中的经验带有主体、时间、使用事件和有效期知识来自企业文档、制度、产品资料和经审核的外部内容带有来源、版本、分类和发布责任。两者都可以用全文、向量和图关系检索——这也是“川序”选择多模融合数据库的多模态数据融合检索的核心能力的核心原因注意这里说的多模态是指结构化过滤、全文、向量、标签和图关系共同参与排序不是图像或音频模型。但更新策略不应该相同——用统一的数据库底座保存它们同时用类型、来源、生命周期和授权范围区分查询与发布流程这才是合理的做法。数据库解决的是治理问题我知道有人要问为什么要用数据库来做这事因为数据库的事务保证可以让当前指针、候选发布和审计记录在同一事务中提交——不会出现“发布了新版本但忘了更新指针”这种半吊子状态。结构化字段负责状态和有效期全文、向量、标签和图关系帮助检索历史表和审计记录让整理行为可复核。所以记忆优化本质上是让 Agent 的长期上下文具备版本、范围、证据、复核和可恢复的生命周期。对于客户来说记忆治理的结果不是数据库里多了多少条摘要——而是 Agent 是不是更少读无关内容了、是不是不再用过期内容了、能不能解释某条记忆的来源、以及错误整理后能不能恢复到上一版。这些才是工程化该关注的东西。总结“川序”让 Agent 获得短且精确的记忆输入。老规矩知道写了些啥。