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

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE

10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭


要知道，最早我做这个系统是想解决 Agent 记忆的问题，项目原来名称是 

在“川序”的记忆相关能力不断迭代过程，越做越发现一个反直觉的事——

记忆不是越多越好，反而是记太多，最后等于什么都没记住。

这就好比你家里有一屋子书，但全是散乱堆在地上的，每次要找一本都得翻遍整个屋子。最后你肯定不是把书扔掉，而是得找人（或自己动手）搞一套编目系统——分类、贴标签、建索引、标记哪些书是新版哪些已经过时了。

Agent 的记忆治理，说白了就是这个道理。

最早的记忆方案都很朴素——把对话、经验、规则往文件里一塞就完事了。一开始确实挺好用，毕竟内容少，Agent 扫一眼就能找到。

但问题是，随着内容越堆越多，Agent 为了找一条有用信息，得把几十上百条无关内容全读进上下文。旧内容、重复内容、过时内容——全混在一起。Token 烧得飞起，检索准确率反而蹭蹭往下掉。同时大量的记忆相关内容占用宝贵的上下文空间，还容易因为不需要的内容导致上下文污染，进而将整个任务带偏。

这就像你让一个实习生去档案室翻一份三年前的合同——档案室里堆满了各种草稿、复印件、过期公告，他翻了一上午，最后拿给你的可能还是错的版本。

所以说，记忆的价值不在数量，而在于

当前任务能不能拿到正确、相关、且还有效的那几条

我之前聊 Agent 记忆的时候提过三位一体存储架构——标量、向量和属性图共存。但光有存储不够，你还需要一整套治理机制。

记忆需要版本，而不是直接覆盖

这里说个很多人都踩过的坑——直接修改或删除记忆。

看起来简单粗暴，但带来的问题很致命：一是一旦调整了记忆你 / Agent 可能就永远不知道过去发生过什么，二是如果调整记忆过程中出了错很难恢复。而且说实话，企业环境里还有合规要求——你不能因为“整理一下”就把原始事实给物理删除了。

这一套思路——其实借鉴的就是数据库里的版本管理思想：

整理、压缩、修正的时候，不是直接改原文，而是先生成候选版本，经过复核后，再发布为当前版本。

说白了，这就像维基百科的编辑流程——你看到的永远是“当前稳定版”，但后台所有编辑历史都在，随时可以对比、回退、追责。

过期或不适合运行的记忆，标记为逻辑不可用或迁移到历史状态，不物理删除。这样既不会让历史内容跑进当前上下文中捣乱，也保留了复核和恢复的依据。

我之前在以前的篇文章里说过——记忆之间不只有"相似"这一种关系。

某条记忆可能来源于一次任务、修正于一次人工复核、又被某个 Agent 引用过。通过图关系，你可以查看它的版本谱系、来源链、修正记录和使用路径——就像一本书的借阅记录和修订历史，清清楚楚。

这些关系是解释和检索的依据，不是授权来源。

 当前运行默认只读取“当前版本”且在授权范围内的记忆，历史节点不会因为出现在关系图里就自动跑进上下文——这一点“川序”是通过数据库授权边界来保证的，不是靠提示词。

整理、压缩和遗忘，到底怎么落地

说到记忆整理，很多人第一反应是“让模型定期清理一下数据库”——这个想法本身就有问题。

压缩也不是简单截断文本——一个合格的候选结果，必须保留来源版本、摘要生成时间、使用范围、置信度和整理原因，并且能回指原始内容。

遇到相互矛盾的记忆怎么办？不能光靠相似度就覆盖掉——得进复核队列，由人或专用 Review Agent 处理。在

《Agent 上线之后，谁来负责它》

那篇里聊过 Agent 的生命周期管理，其实记忆治理跟它是同一套思路——谁来负责、怎么复核、出了问题怎么回退。

还有一个细节很多人容易忽略：

 两个 Worker 同时整理同一个 Family 时，必须用租约、版本号或条件更新防止互相覆盖；人工复核已通过后，旧的候选不能再替换它。这些规则在“川序”里是通过数据库事务和唯一约束搞定的——把业务约定变成可执行事实，而不是靠应用层祈祷别出 bug。

说实话，这是我见过最容易混淆的地方——很多人把所有东西往一个“知识库”里塞。

记忆和知识，本质上来源不同、更新策略不同、责任主体也不同：

两者都可以用全文、向量和图关系检索——这也是“川序”选择多模融合数据库的多模态数据融合检索的核心能力的核心原因（注意：这里说的"多模态"是指结构化过滤、全文、向量、标签和图关系共同参与排序，不是图像或音频模型）。

但更新策略不应该相同——用统一的数据库底座保存它们，同时用类型、来源、生命周期和授权范围区分查询与发布流程，这才是合理的做法。

我知道有人要问：为什么要用数据库来做这事？

因为数据库的事务保证，可以让当前指针、候选发布和审计记录在同一事务中提交——不会出现“发布了新版本但忘了更新指针”这种半吊子状态。结构化字段负责状态和有效期；全文、向量、标签和图关系帮助检索；历史表和审计记录让整理行为可复核。

所以记忆优化，本质上是让 Agent 的长期上下文具备

版本、范围、证据、复核和可恢复

对于客户来说，记忆治理的结果不是数据库里多了多少条摘要——而是 Agent 是不是更少读无关内容了、是不是不再用过期内容了、能不能解释某条记忆的来源、以及错误整理后能不能恢复到上一版。这些，才是"工程化"该关注的东西。

“川序”让 Agent 获得短且精确的记忆输入。

要知道，最早我做这个系统是想解决 Agent 记忆的问题，项目原来名称是 oracle-memory。

输入给 Agent 记忆不是越多越好

自由职业

数据库

人工智能

架构设计

Agent记忆并非越多越好，需通过版本化管理、图关系梳理与整理预览执行机制治理，确保正确、相关且有效的记忆输入，区分记忆与知识，实现可复核、可恢复的生命周期管理。

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

输入给 Agent 记忆不是越多越好

输入给 Agent 记忆不是越多越好

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐