胖头鱼的技术专栏-460 输入给 Agent 记忆不是越多越好（20260813）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

本期继续“川序”的介绍： 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 获得短且精确的记忆输入。

老规矩，知道写了些啥。