关于agent记忆设计这件事
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
我认为目前agent的限制不在于模型的能力有多强，而是没有记忆模块没有设计好。
项目地址： GitHub - makenBlous/memCore: Local-first memory core for a single-user long-running conversational agent. · GitHub
目前很多成熟的框架和系统都喜欢用RAG那套，或者是GraphRAG.如果agent的记忆设计只是这样，那充其量就是个大号的电子图书馆和agent没有半毛钱关系。
我思考了一下结合网上查到的资料整理了一份属于我的记忆模块的设计，我打算从记忆衰减与升格、作用域、身份权重（后面想了想废弃了）、多时间维度、记忆来源依据等等：
1.图便利是基础，但是图的点不能是一个单纯的实体，而是有各种属性的记忆对象（没错面向对象开发）。原本我想设计为中学语文的语法结构，后面发现主谓宾定状补时间地点起因经过结果等等这些语法词汇分析出来只能比较好的描述一件事，而不是能很好的描述记忆，所以我该为了记忆对象，同时简化了两个节点之间的9条连线
| 第 1 列 | 第 2 列 | 第 3 列 |
|---|---|---|
| 组成 | 说明 | 为什么重要 |
| 对象 | 经过整理的正式记忆（事实、偏好、约束、事件、观察、技能） | 记忆不再停留在原始对话层，而是进入可管理的结构层 |
| 证据 | 来源、片段、命中依据、支持材料 | 系统需要知道这条记忆凭什么成立 |
| 版本 | 当前版本、历史版本、冲突版本、回退轨迹 | 记忆会变化，变化本身也必须被记录 |
2.记忆也有区别，我们人类是有临时记忆和长期记忆的区别，同理，我把记忆划分为候选记忆和正式记忆，候选记忆在多次事件命中，强有力证据的支持或者用户主动要求记忆的情况下才会升级为正式记忆。这不代表候选记忆会直接删除，只是优先级没有那么高。
| 第 1 列 | 第 2 列 | 第 3 列 |
|---|---|---|
| 作用域 | 说明 | 我的理解 |
| 用户层 | 稳定偏好、长期约束、跨项目成立的习惯与身份信息 | 这是最慢变化的一层 |
| 项目层 | 项目规则、项目知识、交付边界、项目经验 | 这是系统真正进入长期协作的关键一层 |
| 任务层 | 当前目标、过程判断、阶段决策、任务图 | 这是离当前上下文最近的一层 |
| 工具层 | 某类工具的适用性、失败边界、调用经验 | 这是与具体工具绑定的一层 |
生命周期
候选 -> 观察期正式 -> 正式长期 -> 归档 / 休眠 / 回退
3.记忆的迭代，这个进行设计的时候让我想了软件开发，把记忆也进行版本迭代，比如旧时代的电话和新时代的电话是完全两个概念，但是都属于电话这个名称，这就是语言的歧义。所以我设计了一套证据链和时间维度来完成记忆的迭代问题，让记忆进入系统后可以一直优化更新，而不是进入之后停留。
4.检索记忆，这个就是老生常谈了，什么多路召回啊，噢对了，我目前的图设计是以SQLlite为基础的实体联系设计（借鉴软工的ER图），这样就不会消耗性能去专门部署一个引擎了，特别适合轻量化的个人。sql检索，关系检索，时间维度检索等等多种方式检索，向量检索页不会少。
最后我写完才发现Memory Palace项目居然和我的很多想法相合，天崩了啊！不过还好，不是蹭热度啊！哈哈哈，最后可以去看个人记忆架构设计这是我的思路，我比较懒个人记忆架构设计这篇文章是我用AI根据我的项目和我的想法提取的
网友解答：--【壹】--：
GitHub - milla-jovovich/mempalace: The highest-scoring AI memory system ever...
The highest-scoring AI memory system ever benchmarked. And it's free.
今天看到的
可以借鉴一下
--【贰】--：
思路不错，可以尝试一下和agent结合的效果，可以搞个弱智AI专门在后台汇总整理记忆，归纳存放
--【叁】--：
感谢分享，学习学习，我觉的得保证模型能按你想的记忆来做，好几个记忆工具，都因模型不同效果随机
--【肆】--：
佬，记忆系统设计的确是harness的一个重要方向，是为了让智能体系统拿出有用的记忆和约束给到上下文
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
我认为目前agent的限制不在于模型的能力有多强，而是没有记忆模块没有设计好。
项目地址： GitHub - makenBlous/memCore: Local-first memory core for a single-user long-running conversational agent. · GitHub
目前很多成熟的框架和系统都喜欢用RAG那套，或者是GraphRAG.如果agent的记忆设计只是这样，那充其量就是个大号的电子图书馆和agent没有半毛钱关系。
我思考了一下结合网上查到的资料整理了一份属于我的记忆模块的设计，我打算从记忆衰减与升格、作用域、身份权重（后面想了想废弃了）、多时间维度、记忆来源依据等等：
1.图便利是基础，但是图的点不能是一个单纯的实体，而是有各种属性的记忆对象（没错面向对象开发）。原本我想设计为中学语文的语法结构，后面发现主谓宾定状补时间地点起因经过结果等等这些语法词汇分析出来只能比较好的描述一件事，而不是能很好的描述记忆，所以我该为了记忆对象，同时简化了两个节点之间的9条连线
| 第 1 列 | 第 2 列 | 第 3 列 |
|---|---|---|
| 组成 | 说明 | 为什么重要 |
| 对象 | 经过整理的正式记忆（事实、偏好、约束、事件、观察、技能） | 记忆不再停留在原始对话层，而是进入可管理的结构层 |
| 证据 | 来源、片段、命中依据、支持材料 | 系统需要知道这条记忆凭什么成立 |
| 版本 | 当前版本、历史版本、冲突版本、回退轨迹 | 记忆会变化，变化本身也必须被记录 |
2.记忆也有区别，我们人类是有临时记忆和长期记忆的区别，同理，我把记忆划分为候选记忆和正式记忆，候选记忆在多次事件命中，强有力证据的支持或者用户主动要求记忆的情况下才会升级为正式记忆。这不代表候选记忆会直接删除，只是优先级没有那么高。
| 第 1 列 | 第 2 列 | 第 3 列 |
|---|---|---|
| 作用域 | 说明 | 我的理解 |
| 用户层 | 稳定偏好、长期约束、跨项目成立的习惯与身份信息 | 这是最慢变化的一层 |
| 项目层 | 项目规则、项目知识、交付边界、项目经验 | 这是系统真正进入长期协作的关键一层 |
| 任务层 | 当前目标、过程判断、阶段决策、任务图 | 这是离当前上下文最近的一层 |
| 工具层 | 某类工具的适用性、失败边界、调用经验 | 这是与具体工具绑定的一层 |
生命周期
候选 -> 观察期正式 -> 正式长期 -> 归档 / 休眠 / 回退
3.记忆的迭代，这个进行设计的时候让我想了软件开发，把记忆也进行版本迭代，比如旧时代的电话和新时代的电话是完全两个概念，但是都属于电话这个名称，这就是语言的歧义。所以我设计了一套证据链和时间维度来完成记忆的迭代问题，让记忆进入系统后可以一直优化更新，而不是进入之后停留。
4.检索记忆，这个就是老生常谈了，什么多路召回啊，噢对了，我目前的图设计是以SQLlite为基础的实体联系设计（借鉴软工的ER图），这样就不会消耗性能去专门部署一个引擎了，特别适合轻量化的个人。sql检索，关系检索，时间维度检索等等多种方式检索，向量检索页不会少。
最后我写完才发现Memory Palace项目居然和我的很多想法相合，天崩了啊！不过还好，不是蹭热度啊！哈哈哈，最后可以去看个人记忆架构设计这是我的思路，我比较懒个人记忆架构设计这篇文章是我用AI根据我的项目和我的想法提取的
网友解答：--【壹】--：
GitHub - milla-jovovich/mempalace: The highest-scoring AI memory system ever...
The highest-scoring AI memory system ever benchmarked. And it's free.
今天看到的
可以借鉴一下
--【贰】--：
思路不错，可以尝试一下和agent结合的效果，可以搞个弱智AI专门在后台汇总整理记忆，归纳存放
--【叁】--：
感谢分享，学习学习，我觉的得保证模型能按你想的记忆来做，好几个记忆工具，都因模型不同效果随机
--【肆】--：
佬，记忆系统设计的确是harness的一个重要方向，是为了让智能体系统拿出有用的记忆和约束给到上下文