沿着 DSH 和 TencentDB Agent Memory 这条线研究下来我对“智能体记忆”的理解发生了一些变化。最初我比较关心能不能接上对话能否沉淀下来换一次会话还能不能找到以前的内容。后来继续使用 Hermes也看了 Mem0、Hindsight 等项目问题逐渐变成了知识库、对话历史和长期记忆究竟应该怎样分工它们都能保存信息也都可能把内容提供给模型。但放到持续工作的智能体里保存什么、什么时候取、由谁使用以及旧结论怎样修正会直接影响下一次任务。前面两篇分别谈项目接续和记忆取用链路。这篇往上看一层把这些研究放在一起整理我目前对记忆体系的理解。先分清模型眼前的内容从哪里来我现在会先看四种东西。当前上下文是模型这次推理实际拿到的信息。当前问题、最近对话、工具返回以及被选中的记忆都可能在里面。上下文窗口再长也仍然要决定把哪些内容放进去。对话历史保留“当时说过什么、做过什么”。它适合回溯过程但里面也有临时猜测、失败尝试和已经放弃的方案。完整留下历史并不能保证下一次拿到的就是有效结论。知识库主要承载可以回到原文核对的资料文档、教程、代码、学习笔记。它帮助智能体回答“这个问题有什么依据”。长期记忆更关注持续交互中形成的偏好、约定、经验和相关事实。它要帮助智能体理解“这次任务与过去有什么关系”。这几类信息可以使用相似的检索技术边界也会重叠。我更在意它们在任务里承担什么责任知识库保留出处历史保留过程长期记忆保留值得再次使用的信息最终由当前上下文把相关部分带到模型面前。例如官方文档说明某个接口怎样调用属于知识依据某个环境曾因特定参数失败、后来怎样解决属于带条件的经验。参数文档更新了这条经验也可能需要重新核对。两者一起使用比单独记住一句“这样配就行”可靠。Hermes从一个实际工作的 Agent 看记忆Hermes 让我比较容易观察这些层次因为它首先是一个处理任务、调用工具的 Agent。它的内置记忆使用USER.md和MEMORY.md前者放用户偏好后者放环境事实、约定和学习要点。它还可以通过session_search查找过去的对话。关键记录与完整历史因此有了不同的取用入口。Hermes 记忆文档内置记忆并不是无限增长的仓库。这两份文件有容量约束在会话开始时以固定快照进入系统提示词会话中写入的更新会在下一次会话开始时进入这块提示词。这个设计让我看到一种分工少量常用信息随会话带入需要细节时再去搜索。大篇幅的知识资料则可以放在独立知识库通过检索工具按任务取用。至于接入外部记忆服务还要继续看客户端怎样调用它什么时候写入什么时候召回返回内容怎样进入当前上下文。配置里出现一个服务名称只说明有了接入配置要判断实际效果还得走完一次写入和下一次取用。Mem0把记忆做成可接入的能力研究 Mem0 时我关注的是另一种位置它把记忆作为一层能力提供给上面的应用或 Agent 使用。官方示例展示了一条很直观的路径先按当前问题和用户范围搜索相关记忆把结果加入模型输入完成对话后再把新内容交给记忆层处理。它提供 SDK 和服务接口也区分开源库、自托管与托管服务。Mem0 项目沿着这个思路Hermes 这样的 Agent 可以负责理解任务和使用工具外部记忆层负责沉淀与召回知识库继续保存原始资料。这里描述的是我理解的职责划分具体组合仍要看实际版本和适配方式。真正需要想清楚的是写入规则。比如“用户明确改了一个长期偏好”和“模型临时猜测用户可能喜欢什么”能不能以相同方式存进去一次成功操作是只记“成功了”还是同时保留适用环境和验证结果如果写入时已经把猜测变成了事实后面的检索再准确也只是更稳定地取出错误内容。因此我看记忆层时会同时看写入和召回不只看它用了什么数据库。Hindsight保存经验以后还能怎样整理Hindsight 是我在 Hermes 相关研究中关注过的另一条线。它把核心操作分成retain、recall、reflect写入时组织信息需要时检索再基于已有记忆进行分析。官方资料还区分外部事实、Agent 的经历以及由多条记忆归纳出的观察。Hindsight 项目我感兴趣的是这里多出来的“整理经验”这一层。多次遇到相似问题之后系统能否从分散记录中提炼出可复用的认识而不是每次都把原始历史重新翻一遍但归纳也会引入新的判断。三次失败都出现在相同环境不代表环境一定是原因一次方法奏效也不代表它适用于所有情况。所以对我来说整理后的经验仍然需要保留依据和适用条件。事实、推断和建议最好能看出区别新的证据出现时也应该有修正旧认识的办法。这和知识库的关系也更清楚了原文与记录提供证据记忆系统帮助组织经验Agent 再结合当前任务使用它们。DSH 与腾讯记忆接入之后继续看分层和取用在 DSH 与 TencentDB Agent Memory 这条线上我实际做过接入和排查。最直接的经验已经写在第 06 篇普通聊天能返回并不能顺带证明主动检索工具也正常。后来继续读源码和整理笔记我开始关注系统内部怎样分工。在我研究的 MemoryCore 实现中L0 保留原始对话L1 提炼原子记忆L2 组织场景信息L3 归纳用户画像。不同层次让原始记录与整理后的信息可以分别承担回溯、检索和上下文组织的任务。MemoryCore 说明同时记忆与知识资料也有不同的服务和索引路径。MemoryCore 管理记忆MemoryKnowledge 处理 Wiki、代码图谱等知识内容。DSH 作为执行任务的客户端需要通过相应入口取用它们。这让我更明确地看到一个知识索引构建完成只完成了其中一段。后面还有资产登记、可见范围、工具发现、请求地址以及结果进入当前上下文这些环节。从记忆体系的角度看这些环节决定了“已有的信息能不能在正确的任务里被使用”。排查时如果只看数据库里有没有内容很容易漏掉消费端的问题。我现在会怎样组织一套记忆体系把这些项目放在一起看我倾向于先画清职责再选择组件。图 1我目前理解的读写分工按任务取用信息再从结果中整理可复用的记忆。第一步保留可以核对的原始资料。文档、代码和历史记录有自己的出处与版本后面形成的结论能够回到来源。第二步确定哪些内容值得成为长期记忆。稳定偏好、明确决定、反复验证的经验比整段聊天更适合长期取用尚未证实的推断可以保留但需要让接手者看得出它的性质。第三步按任务组织当前上下文。常用约定可以提前带入具体问题再检索知识和相关经历并检查来源、时间与适用范围。不是检索到多少就全部交给模型。第四步让任务结果能够反过来修正记忆。新决定替代旧决定时历史可以保留但下次取用时要能辨认当前有效的内容。失败经验也应记录条件避免一条局部结论变成永久禁令。还有一条贯穿其中记忆要有归属。一个用户、角色或项目形成的内容能否被另一个范围读取需要明确规则。用了同一套存储并不代表所有内容都适合互相共享。这里并不要求把 Mem0、Hindsight 和腾讯记忆全部叠在一起。它们有重叠的职责如果多个组件都在自动提炼同一段对话又缺少一致的更新规则反而可能留下多份互相矛盾的结论。先选清楚谁负责哪一段再验证组合是否解决了实际问题。判断有没有用我会看这几件事下一阶段我更想围绕具体行为检查记忆效果。换一个会话能否找回已经明确的偏好和约定问到某个技术结论能否定位到相关原文新信息推翻旧结论后能否采用更新的判断切换到另一个用户或项目时能否守住可见范围。这些检查分别对应持续性、依据、更新和归属。至于哪种方案更适合我的使用方式还需要放到相同任务里继续验证单靠项目介绍和各自的性能数字很难下结论。研究到现在我越来越在意一条完整的路径信息怎样留下怎样整理怎样被找到又怎样在后续任务里得到修正。这条路径清楚了知识库、长期记忆和 Agent 才能各自发挥作用。智能体的连续性也才有可能从“记得一些话”进一步走向“能带着经验继续工作”。我是 Aiclaw记录 AI 工具、智能体接入与工程实践中的学习过程。更多学习笔记Aiclaw 的博客