1. 从“金鱼记忆”到“长期记忆”为什么我们需要一个会长记性的 Agent做 AI 应用开发的人都有一个共同的痛点你花了一下午调教好的对话助手关掉窗口再打开它就像被敲了一记闷棍完全不记得你是谁、之前聊过什么、上次那个任务做到哪一步了。这种“金鱼记忆”在单轮问答场景下还能忍一旦涉及多步骤任务、跨会话协作、个性化服务就彻底没法用了。Hermes Agent 这个项目核心要解决的就是这个问题。它不是又一个套壳对话机器人而是一个带持久记忆层的智能体框架。简单说它让 AI Agent 拥有了“记性”——能记住用户偏好、历史交互、任务上下文甚至能从过往的成功和失败中提炼经验在后续任务中主动调用。这个项目适合谁如果你正在做以下事情它值得你花时间研究需要跨会话保持用户画像的客服系统、需要多轮迭代才能完成复杂任务的工作流引擎、需要积累领域知识越用越聪明的垂直助手。哪怕你只是想给自己的个人助理加一个“别每次都问我同样问题”的能力Hermes Agent 的记忆架构设计也能给你不少启发。我花了大概三周时间把这个项目的核心逻辑跑通又花了两周做定制化改造踩了不少坑也总结了一些文档里不会写的经验。下面我把整个拆解过程按模块讲清楚从设计思路到实操细节再到问题排查尽量让不同基础的朋友都能拿走能用的东西。2. 记忆架构的整体设计为什么是“分层存储主动召回”2.1 核心设计思路把记忆当成数据库来管而不是塞进 Prompt很多开发者第一反应是要记忆简单把历史对话拼接到 Prompt 里不就行了。我一开始也这么干过结果就是 Token 消耗爆炸而且模型在超长上下文里会“迷失”该记住的没记住不该关注的细节反而干扰了判断。Hermes Agent 的思路完全不同。它把记忆拆成了三个独立的层每层有不同的存储介质、生命周期和召回策略记忆层级存储内容存储介质生命周期召回方式工作记忆当前会话的即时上下文内存/Redis单次会话全量注入情景记忆历史交互事件、任务执行记录向量数据库长期持久语义检索语义记忆提炼后的用户偏好、领域知识结构化数据库向量库长期持久规则语义混合这个分层设计的精妙之处在于它模拟了人类记忆的工作方式。你和一个老朋友聊天不需要回忆你们认识以来所有的对话只需要记住“他不吃辣”“他最近在学吉他”“上次答应帮他找的资料还没发”——这些就是语义记忆。而具体某次聊天的细节只有在相关话题触发时才会被回忆起来这就是情景记忆。提示不要试图用一个向量库解决所有记忆问题。结构化信息如用户ID、偏好标签用关系型数据库查得更快更准非结构化信息如对话摘要、任务描述才适合向量检索。混在一起用查询效率和准确率都会打折扣。2.2 为什么选择“主动召回”而不是“全量注入”全量注入的问题前面说了Token 成本高、干扰大。但主动召回也有个坑召回什么、召回多少、什么时候召回这三个问题如果处理不好Agent 要么“失忆”要么“过度联想”。Hermes Agent 的做法是引入一个记忆管理器模块它负责在每次用户输入后、模型推理前执行以下判断流程当前输入是否包含需要历史信息的意图如“上次那个方案”“我之前说过”如果包含从情景记忆中检索 Top-K 相关事件从语义记忆中提取与当前任务相关的用户偏好和约束将召回结果压缩成结构化摘要注入到 Prompt 的指定区域这个流程的关键在于压缩。召回的记忆不能原封不动塞进去必须经过摘要和格式化。我实测下来把 10 条相关记忆压缩成 200 字以内的结构化摘要效果比直接塞 2000 字原始记录好得多。2.3 记忆的写入策略什么时候该记什么时候该忘记忆不是越多越好。我见过一个反面案例某开发者把所有对话都存进向量库结果 Agent 变得“神经质”经常引用几个月前无关的对话内容用户体验极差。Hermes Agent 的写入策略有几个触发条件显式触发用户说“记住这个”“以后都这样”时强制写入语义记忆任务完成触发一个多步骤任务成功完成后将任务摘要和关键决策点写入情景记忆偏好推断触发当用户连续多次做出相同选择时如每次都选“简洁模式”自动提炼为偏好写入语义记忆定时衰减情景记忆有 TTL生存时间超过一定时间未被召回的记忆会被降权或归档这个策略的核心逻辑是记忆的价值在于被使用而不是被存储。一条从未被召回的记忆占着存储空间还增加检索噪声不如让它自然衰减。3. 核心模块拆解记忆管理器、召回引擎与反思机制3.1 记忆管理器Agent 的“海马体”记忆管理器是整个系统的大脑它决定了什么信息值得记、以什么形式记、放在哪里。我在实现时把它拆成了三个子模块写入判断模块负责给每条交互打标签。不是所有对话都值得写入长期记忆比如“你好”“谢谢”这类寒暄写进去就是噪声。我的做法是给每条消息计算一个“记忆价值分”综合考虑信息密度、情感强度、任务相关性三个维度。信息密度看是否包含具体事实或决策情感强度看用户是否表达了明确喜好或不满任务相关性看是否与当前进行中的任务有关。分数超过阈值的才进入写入队列。摘要生成模块负责把原始对话压缩成可存储的记忆单元。这里有个经验摘要不能只靠模型生成还要保留原始消息的指针。因为模型摘要可能丢失关键细节当后续需要精确回忆时可以通过指针回溯原始记录。我的做法是摘要存向量库原始记录存对象存储两者用同一个 ID 关联。冲突消解模块负责处理记忆矛盾。用户上周说“我喜欢详细解释”这周说“以后简洁点”两条记忆冲突了怎么办Hermes Agent 的策略是时间优先置信度加权。新记忆默认置信度更高但如果旧记忆被多次召回且用户没有纠正置信度会累积。冲突时取置信度高的同时把旧记忆标记为“待验证”下次相关场景时主动询问用户确认。3.2 召回引擎怎么在正确的时间想起正确的事召回引擎的挑战在于平衡召回率和精确率。召回太少Agent 显得健忘召回太多Agent 显得啰嗦且容易跑偏。我的实现方案是两阶段召回第一阶段用规则过滤快速缩小范围。比如当前对话涉及“代码”就只召回与编程相关的记忆涉及“日程”就只召回时间管理相关的记忆。规则可以基于关键词、意图分类或实体识别来触发。第二阶段用语义检索在缩小后的范围内找最相关的 Top-K。这里有个细节查询向量不能只用当前用户输入还要拼接最近几轮对话的摘要。因为用户说“那个方案再改改”时单看这句话根本不知道“那个方案”是什么必须结合上下文。注意Top-K 的 K 值不要设太大。我实测下来K3 到 K5 效果最好。超过 5 条模型注意力会被分散反而容易忽略最关键的那条记忆。如果确实需要更多信息宁可分多次召回也不要一次性塞太多。3.3 反思机制让 Agent 从经验中学习这是 Hermes Agent 最有意思的部分。它不只是被动地存储和召回还会主动反思。具体来说每次任务完成后Agent 会触发一个反思流程回顾整个任务执行过程分析哪些步骤顺利、哪些步骤卡壳、用户的反馈是正面还是负面。然后生成一条“经验总结”写入语义记忆格式类似“当用户要求做 X 类任务时采用 Y 方法效果更好注意避免 Z 问题。”这个反思机制让 Agent 有了“越用越聪明”的可能性。我拿一个代码生成任务测试过第一周 Agent 生成的代码经常缺少错误处理用户反馈了几次后反思机制生成了“生成代码时必须包含异常捕获”的经验。第二周再测试Agent 主动加上了 try-catch 块用户满意度明显提升。反思的触发频率可以配置。太频繁会浪费计算资源太稀疏又学不到东西。我的建议是任务成功时每 5 次反思一次任务失败时立即反思。4. 实操落地从零搭建一个带记忆的 Agent4.1 环境准备与依赖选型先说我用的技术栈这套组合是我试过几套方案后觉得最稳的向量数据库选了一个轻量级的开源方案支持本地部署单机就能跑不用额外运维关系型数据库用 SQLite 起步数据量大了再迁移到 PostgreSQL缓存层Redis存工作记忆和热点召回结果模型层支持多模型切换我主要用两个一个负责推理一个负责摘要和反思安装过程不复杂核心依赖就几个包。但有个坑要注意向量数据库的索引类型选择会影响召回速度。数据量小于 10 万条时用扁平索引就行超过后再考虑 IVF 或 HNSW。我一开始就上了 HNSW结果小数据量下反而比扁平索引慢因为图构建有开销。# 核心依赖安装示意 pip install vector-db-client pip install redis pip install sqlalchemy pip install openai # 或其他模型 SDK4.2 记忆写入的完整流程与参数配置写入流程我拆成了五步每步都有可调参数第一步消息预处理。把用户输入和 Agent 回复拼接成标准格式去除无关字符提取实体和意图标签。第二步记忆价值评分。我用的评分公式是score 0.4 * info_density 0.3 * sentiment_intensity 0.3 * task_relevanceinfo_density 用命名实体数量除以总词数sentiment_intensity 用情感分类模型的置信度task_relevance 用当前消息与进行中任务的语义相似度。阈值我设的是 0.6低于这个值不写入长期记忆。第三步摘要生成。调用模型生成 50 字以内的摘要同时保留原始消息 ID。摘要的 Prompt 我调了好几版最后定下来的模板是请将以下对话压缩成一条记忆摘要要求 1. 保留关键事实和决策 2. 保留用户偏好和约束 3. 不超过50字 4. 以“用户”或“Agent”开头标明主体第四步冲突检测。用新摘要的向量去语义记忆里检索相似度超过 0.85 的旧记忆如果有触发冲突消解流程。第五步写入存储。摘要和向量写入向量库结构化标签写入关系库原始消息写入对象存储。4.3 召回流程的实现细节与调优召回流程我调了大概两周才稳定下来。核心代码如下伪代码示意def recall_memory(user_input, session_context): # 第一阶段规则过滤 intent classify_intent(user_input) candidate_tags map_intent_to_tags(intent) # 第二阶段语义检索 query_vector embed(user_input session_context[-3:]) candidates vector_db.search( query_vector, filter{tags: {$in: candidate_tags}}, top_k10 ) # 第三阶段重排序 reranked rerank_by_recency_and_confidence(candidates) # 第四阶段压缩注入 memory_summary compress_to_summary(reranked[:5]) return memory_summary调优的关键在第三阶段的重排序。我用的排序公式是final_score 0.5 * semantic_similarity 0.3 * recency_score 0.2 * confidence_scorerecency_score 用指数衰减半衰期设的是 7 天。confidence_score 根据记忆被召回后用户是否纠正来动态调整用户没纠正就加分纠正了就减分。实操心得召回结果一定要做去重。我遇到过同一个事实被多条记忆重复召回的情况因为用户在不同对话里说了类似的话。去重逻辑用语义相似度判断超过 0.9 的只保留置信度最高的那条。4.4 反思机制的触发与经验沉淀反思机制的实现相对独立它是一个定时任务也可以手动触发。核心逻辑是def reflect_on_task(task_record): # 提取任务执行轨迹 trajectory extract_trajectory(task_record) # 分析成功与失败点 analysis analyze_trajectory(trajectory) # 生成经验总结 lesson generate_lesson(analysis) # 写入语义记忆标记为“经验”类型 semantic_memory.write( contentlesson, typelesson, confidence0.8, source_tasktask_record.id )经验总结的 Prompt 我改了很多版关键是让模型输出可操作的规则而不是泛泛而谈。比如“要注意错误处理”这种没用“生成 Python 代码时如果涉及文件操作必须包含 try-except 块”这种才有指导意义。5. 常见问题与排查技巧实录5.1 记忆召回不准确从三个维度排查召回不准确是最常见的问题我总结了一个排查清单问题现象可能原因排查方法解决方案召回无关记忆查询向量质量差检查 embedding 模型是否适合当前领域换领域适配的 embedding 模型该召回没召回规则过滤太严打印过滤前后的候选数量放宽标签匹配逻辑召回重复内容去重阈值太高统计召回结果的相似度分布降低去重阈值到 0.85召回旧记忆时间衰减太慢检查 recency_score 计算缩短半衰期或提高衰减系数我踩过最坑的一次是 embedding 模型选错了。用了一个通用模型结果在代码领域的语义相似度计算完全不准“函数”和“方法”的向量距离很远。换成代码领域微调过的模型后召回准确率从 60% 提升到 85%。5.2 记忆冲突处理当用户改变主意时用户改变偏好是常态但处理不好会让 Agent 显得“精神分裂”。我的处理流程是检测到冲突后不立即删除旧记忆而是把旧记忆标记为“历史偏好”新记忆写入时在元数据里记录“替代了哪条旧记忆”下次召回时如果新旧记忆都被召回优先返回新的但把旧的作为“历史参考”附在后面如果用户再次确认旧偏好则恢复旧记忆的置信度这个流程的好处是保留了偏好演变的历史轨迹对于需要理解用户长期行为的场景很有价值。5.3 性能优化当记忆量增长到十万条以上记忆量大了之后召回延迟会明显上升。我做了几个优化索引优化向量库的索引从扁平换成 IVF查询速度提升 3 倍。但要注意 IVF 需要训练训练数据要覆盖所有聚类中心。缓存热点把最近 7 天被召回过的记忆缓存在 Redis 里命中率大概 40%平均延迟降低 50ms。异步写入记忆写入改成异步队列不阻塞主流程。用了一个简单的生产者-消费者模式写入延迟从 200ms 降到 20ms 以内。分级存储超过 90 天未被召回的记忆迁移到冷存储召回时先查热存储没有再查冷存储。注意异步写入有个坑如果 Agent 在写入完成前就崩溃了记忆会丢失。我的做法是写入队列持久化到磁盘重启后自动恢复未完成的任务。5.4 隐私与安全记忆系统的红线记忆系统存储了大量用户交互数据隐私保护是必须考虑的问题。我做了几件事所有记忆内容加密存储密钥不落盘支持用户一键清除所有记忆清除操作不可逆敏感信息如密码、身份证号在写入前自动脱敏记忆召回时做权限校验确保只能召回当前用户的数据脱敏这块我用的正则模型双重检测正则覆盖常见格式模型检测变体。实测下来正则能拦住 90% 的敏感信息剩下的靠模型兜底。6. 记忆系统的扩展方向与个人体会这个项目的基础架构跑通后我尝试了几个扩展方向有些效果不错有些还在摸索。多 Agent 共享记忆是个有意思的方向。让多个 Agent 共享一个语义记忆库每个 Agent 有自己的情景记忆。这样团队协作时一个 Agent 学到的经验其他 Agent 也能用。我测试了一个客服场景三个 Agent 共享记忆后整体解决率提升了 15%。但挑战在于记忆冲突会更复杂需要引入“记忆所有权”和“记忆投票”机制。记忆可视化对调试帮助很大。我写了一个简单的 Web 界面把记忆的写入时间、召回次数、置信度变化画成图表。有一次发现某条记忆的置信度在持续下降追查后发现是用户每次都被问烦了直接跳过说明这条记忆的召回时机不对。可视化让这种隐性问题变得可见。跨模态记忆是下一步想做的。目前只处理文本但实际场景中图片、语音、文件都是重要的记忆载体。比如用户发了一张设计图说“按这个风格来”这张图就应该被存入记忆下次生成时作为参考。技术上的难点在于跨模态检索文本查询怎么准确召回图片记忆我还在试不同的方案。我个人在实际操作中的体会是记忆系统的核心不是技术而是对用户意图的理解。同样的对话理解不同该记的东西就不同。我见过一个案例用户说“帮我订张票”Agent 记住了“订票”这个动作但没记住用户之前说过的“要靠窗”。后来我把意图理解模块和记忆写入模块做了更紧密的耦合让意图识别结果直接指导记忆提取效果好了很多。最后分享一个小技巧定期做记忆审计。我每个月会抽样 100 条记忆人工检查摘要质量和召回准确性。有一次发现模型把用户的玩笑话当成了真实偏好记了下来导致后续推荐一直跑偏。这种问题不审计根本发现不了。记忆系统就像花园不修剪就会杂草丛生。
1. 从“金鱼记忆”到“长期记忆”为什么我们需要一个会长记性的 Agent做 AI 应用开发的人都有一个共同的痛点你花了一下午调教好的对话助手关掉窗口再打开它就像被敲了一记闷棍完全不记得你是谁、之前聊过什么、上次那个任务做到哪一步了。这种“金鱼记忆”在单轮问答场景下还能忍一旦涉及多步骤任务、跨会话协作、个性化服务就彻底没法用了。Hermes Agent 这个项目核心要解决的就是这个问题。它不是又一个套壳对话机器人而是一个带持久记忆层的智能体框架。简单说它让 AI Agent 拥有了“记性”——能记住用户偏好、历史交互、任务上下文甚至能从过往的成功和失败中提炼经验在后续任务中主动调用。这个项目适合谁如果你正在做以下事情它值得你花时间研究需要跨会话保持用户画像的客服系统、需要多轮迭代才能完成复杂任务的工作流引擎、需要积累领域知识越用越聪明的垂直助手。哪怕你只是想给自己的个人助理加一个“别每次都问我同样问题”的能力Hermes Agent 的记忆架构设计也能给你不少启发。我花了大概三周时间把这个项目的核心逻辑跑通又花了两周做定制化改造踩了不少坑也总结了一些文档里不会写的经验。下面我把整个拆解过程按模块讲清楚从设计思路到实操细节再到问题排查尽量让不同基础的朋友都能拿走能用的东西。2. 记忆架构的整体设计为什么是“分层存储主动召回”2.1 核心设计思路把记忆当成数据库来管而不是塞进 Prompt很多开发者第一反应是要记忆简单把历史对话拼接到 Prompt 里不就行了。我一开始也这么干过结果就是 Token 消耗爆炸而且模型在超长上下文里会“迷失”该记住的没记住不该关注的细节反而干扰了判断。Hermes Agent 的思路完全不同。它把记忆拆成了三个独立的层每层有不同的存储介质、生命周期和召回策略记忆层级存储内容存储介质生命周期召回方式工作记忆当前会话的即时上下文内存/Redis单次会话全量注入情景记忆历史交互事件、任务执行记录向量数据库长期持久语义检索语义记忆提炼后的用户偏好、领域知识结构化数据库向量库长期持久规则语义混合这个分层设计的精妙之处在于它模拟了人类记忆的工作方式。你和一个老朋友聊天不需要回忆你们认识以来所有的对话只需要记住“他不吃辣”“他最近在学吉他”“上次答应帮他找的资料还没发”——这些就是语义记忆。而具体某次聊天的细节只有在相关话题触发时才会被回忆起来这就是情景记忆。提示不要试图用一个向量库解决所有记忆问题。结构化信息如用户ID、偏好标签用关系型数据库查得更快更准非结构化信息如对话摘要、任务描述才适合向量检索。混在一起用查询效率和准确率都会打折扣。2.2 为什么选择“主动召回”而不是“全量注入”全量注入的问题前面说了Token 成本高、干扰大。但主动召回也有个坑召回什么、召回多少、什么时候召回这三个问题如果处理不好Agent 要么“失忆”要么“过度联想”。Hermes Agent 的做法是引入一个记忆管理器模块它负责在每次用户输入后、模型推理前执行以下判断流程当前输入是否包含需要历史信息的意图如“上次那个方案”“我之前说过”如果包含从情景记忆中检索 Top-K 相关事件从语义记忆中提取与当前任务相关的用户偏好和约束将召回结果压缩成结构化摘要注入到 Prompt 的指定区域这个流程的关键在于压缩。召回的记忆不能原封不动塞进去必须经过摘要和格式化。我实测下来把 10 条相关记忆压缩成 200 字以内的结构化摘要效果比直接塞 2000 字原始记录好得多。2.3 记忆的写入策略什么时候该记什么时候该忘记忆不是越多越好。我见过一个反面案例某开发者把所有对话都存进向量库结果 Agent 变得“神经质”经常引用几个月前无关的对话内容用户体验极差。Hermes Agent 的写入策略有几个触发条件显式触发用户说“记住这个”“以后都这样”时强制写入语义记忆任务完成触发一个多步骤任务成功完成后将任务摘要和关键决策点写入情景记忆偏好推断触发当用户连续多次做出相同选择时如每次都选“简洁模式”自动提炼为偏好写入语义记忆定时衰减情景记忆有 TTL生存时间超过一定时间未被召回的记忆会被降权或归档这个策略的核心逻辑是记忆的价值在于被使用而不是被存储。一条从未被召回的记忆占着存储空间还增加检索噪声不如让它自然衰减。3. 核心模块拆解记忆管理器、召回引擎与反思机制3.1 记忆管理器Agent 的“海马体”记忆管理器是整个系统的大脑它决定了什么信息值得记、以什么形式记、放在哪里。我在实现时把它拆成了三个子模块写入判断模块负责给每条交互打标签。不是所有对话都值得写入长期记忆比如“你好”“谢谢”这类寒暄写进去就是噪声。我的做法是给每条消息计算一个“记忆价值分”综合考虑信息密度、情感强度、任务相关性三个维度。信息密度看是否包含具体事实或决策情感强度看用户是否表达了明确喜好或不满任务相关性看是否与当前进行中的任务有关。分数超过阈值的才进入写入队列。摘要生成模块负责把原始对话压缩成可存储的记忆单元。这里有个经验摘要不能只靠模型生成还要保留原始消息的指针。因为模型摘要可能丢失关键细节当后续需要精确回忆时可以通过指针回溯原始记录。我的做法是摘要存向量库原始记录存对象存储两者用同一个 ID 关联。冲突消解模块负责处理记忆矛盾。用户上周说“我喜欢详细解释”这周说“以后简洁点”两条记忆冲突了怎么办Hermes Agent 的策略是时间优先置信度加权。新记忆默认置信度更高但如果旧记忆被多次召回且用户没有纠正置信度会累积。冲突时取置信度高的同时把旧记忆标记为“待验证”下次相关场景时主动询问用户确认。3.2 召回引擎怎么在正确的时间想起正确的事召回引擎的挑战在于平衡召回率和精确率。召回太少Agent 显得健忘召回太多Agent 显得啰嗦且容易跑偏。我的实现方案是两阶段召回第一阶段用规则过滤快速缩小范围。比如当前对话涉及“代码”就只召回与编程相关的记忆涉及“日程”就只召回时间管理相关的记忆。规则可以基于关键词、意图分类或实体识别来触发。第二阶段用语义检索在缩小后的范围内找最相关的 Top-K。这里有个细节查询向量不能只用当前用户输入还要拼接最近几轮对话的摘要。因为用户说“那个方案再改改”时单看这句话根本不知道“那个方案”是什么必须结合上下文。注意Top-K 的 K 值不要设太大。我实测下来K3 到 K5 效果最好。超过 5 条模型注意力会被分散反而容易忽略最关键的那条记忆。如果确实需要更多信息宁可分多次召回也不要一次性塞太多。3.3 反思机制让 Agent 从经验中学习这是 Hermes Agent 最有意思的部分。它不只是被动地存储和召回还会主动反思。具体来说每次任务完成后Agent 会触发一个反思流程回顾整个任务执行过程分析哪些步骤顺利、哪些步骤卡壳、用户的反馈是正面还是负面。然后生成一条“经验总结”写入语义记忆格式类似“当用户要求做 X 类任务时采用 Y 方法效果更好注意避免 Z 问题。”这个反思机制让 Agent 有了“越用越聪明”的可能性。我拿一个代码生成任务测试过第一周 Agent 生成的代码经常缺少错误处理用户反馈了几次后反思机制生成了“生成代码时必须包含异常捕获”的经验。第二周再测试Agent 主动加上了 try-catch 块用户满意度明显提升。反思的触发频率可以配置。太频繁会浪费计算资源太稀疏又学不到东西。我的建议是任务成功时每 5 次反思一次任务失败时立即反思。4. 实操落地从零搭建一个带记忆的 Agent4.1 环境准备与依赖选型先说我用的技术栈这套组合是我试过几套方案后觉得最稳的向量数据库选了一个轻量级的开源方案支持本地部署单机就能跑不用额外运维关系型数据库用 SQLite 起步数据量大了再迁移到 PostgreSQL缓存层Redis存工作记忆和热点召回结果模型层支持多模型切换我主要用两个一个负责推理一个负责摘要和反思安装过程不复杂核心依赖就几个包。但有个坑要注意向量数据库的索引类型选择会影响召回速度。数据量小于 10 万条时用扁平索引就行超过后再考虑 IVF 或 HNSW。我一开始就上了 HNSW结果小数据量下反而比扁平索引慢因为图构建有开销。# 核心依赖安装示意 pip install vector-db-client pip install redis pip install sqlalchemy pip install openai # 或其他模型 SDK4.2 记忆写入的完整流程与参数配置写入流程我拆成了五步每步都有可调参数第一步消息预处理。把用户输入和 Agent 回复拼接成标准格式去除无关字符提取实体和意图标签。第二步记忆价值评分。我用的评分公式是score 0.4 * info_density 0.3 * sentiment_intensity 0.3 * task_relevanceinfo_density 用命名实体数量除以总词数sentiment_intensity 用情感分类模型的置信度task_relevance 用当前消息与进行中任务的语义相似度。阈值我设的是 0.6低于这个值不写入长期记忆。第三步摘要生成。调用模型生成 50 字以内的摘要同时保留原始消息 ID。摘要的 Prompt 我调了好几版最后定下来的模板是请将以下对话压缩成一条记忆摘要要求 1. 保留关键事实和决策 2. 保留用户偏好和约束 3. 不超过50字 4. 以“用户”或“Agent”开头标明主体第四步冲突检测。用新摘要的向量去语义记忆里检索相似度超过 0.85 的旧记忆如果有触发冲突消解流程。第五步写入存储。摘要和向量写入向量库结构化标签写入关系库原始消息写入对象存储。4.3 召回流程的实现细节与调优召回流程我调了大概两周才稳定下来。核心代码如下伪代码示意def recall_memory(user_input, session_context): # 第一阶段规则过滤 intent classify_intent(user_input) candidate_tags map_intent_to_tags(intent) # 第二阶段语义检索 query_vector embed(user_input session_context[-3:]) candidates vector_db.search( query_vector, filter{tags: {$in: candidate_tags}}, top_k10 ) # 第三阶段重排序 reranked rerank_by_recency_and_confidence(candidates) # 第四阶段压缩注入 memory_summary compress_to_summary(reranked[:5]) return memory_summary调优的关键在第三阶段的重排序。我用的排序公式是final_score 0.5 * semantic_similarity 0.3 * recency_score 0.2 * confidence_scorerecency_score 用指数衰减半衰期设的是 7 天。confidence_score 根据记忆被召回后用户是否纠正来动态调整用户没纠正就加分纠正了就减分。实操心得召回结果一定要做去重。我遇到过同一个事实被多条记忆重复召回的情况因为用户在不同对话里说了类似的话。去重逻辑用语义相似度判断超过 0.9 的只保留置信度最高的那条。4.4 反思机制的触发与经验沉淀反思机制的实现相对独立它是一个定时任务也可以手动触发。核心逻辑是def reflect_on_task(task_record): # 提取任务执行轨迹 trajectory extract_trajectory(task_record) # 分析成功与失败点 analysis analyze_trajectory(trajectory) # 生成经验总结 lesson generate_lesson(analysis) # 写入语义记忆标记为“经验”类型 semantic_memory.write( contentlesson, typelesson, confidence0.8, source_tasktask_record.id )经验总结的 Prompt 我改了很多版关键是让模型输出可操作的规则而不是泛泛而谈。比如“要注意错误处理”这种没用“生成 Python 代码时如果涉及文件操作必须包含 try-except 块”这种才有指导意义。5. 常见问题与排查技巧实录5.1 记忆召回不准确从三个维度排查召回不准确是最常见的问题我总结了一个排查清单问题现象可能原因排查方法解决方案召回无关记忆查询向量质量差检查 embedding 模型是否适合当前领域换领域适配的 embedding 模型该召回没召回规则过滤太严打印过滤前后的候选数量放宽标签匹配逻辑召回重复内容去重阈值太高统计召回结果的相似度分布降低去重阈值到 0.85召回旧记忆时间衰减太慢检查 recency_score 计算缩短半衰期或提高衰减系数我踩过最坑的一次是 embedding 模型选错了。用了一个通用模型结果在代码领域的语义相似度计算完全不准“函数”和“方法”的向量距离很远。换成代码领域微调过的模型后召回准确率从 60% 提升到 85%。5.2 记忆冲突处理当用户改变主意时用户改变偏好是常态但处理不好会让 Agent 显得“精神分裂”。我的处理流程是检测到冲突后不立即删除旧记忆而是把旧记忆标记为“历史偏好”新记忆写入时在元数据里记录“替代了哪条旧记忆”下次召回时如果新旧记忆都被召回优先返回新的但把旧的作为“历史参考”附在后面如果用户再次确认旧偏好则恢复旧记忆的置信度这个流程的好处是保留了偏好演变的历史轨迹对于需要理解用户长期行为的场景很有价值。5.3 性能优化当记忆量增长到十万条以上记忆量大了之后召回延迟会明显上升。我做了几个优化索引优化向量库的索引从扁平换成 IVF查询速度提升 3 倍。但要注意 IVF 需要训练训练数据要覆盖所有聚类中心。缓存热点把最近 7 天被召回过的记忆缓存在 Redis 里命中率大概 40%平均延迟降低 50ms。异步写入记忆写入改成异步队列不阻塞主流程。用了一个简单的生产者-消费者模式写入延迟从 200ms 降到 20ms 以内。分级存储超过 90 天未被召回的记忆迁移到冷存储召回时先查热存储没有再查冷存储。注意异步写入有个坑如果 Agent 在写入完成前就崩溃了记忆会丢失。我的做法是写入队列持久化到磁盘重启后自动恢复未完成的任务。5.4 隐私与安全记忆系统的红线记忆系统存储了大量用户交互数据隐私保护是必须考虑的问题。我做了几件事所有记忆内容加密存储密钥不落盘支持用户一键清除所有记忆清除操作不可逆敏感信息如密码、身份证号在写入前自动脱敏记忆召回时做权限校验确保只能召回当前用户的数据脱敏这块我用的正则模型双重检测正则覆盖常见格式模型检测变体。实测下来正则能拦住 90% 的敏感信息剩下的靠模型兜底。6. 记忆系统的扩展方向与个人体会这个项目的基础架构跑通后我尝试了几个扩展方向有些效果不错有些还在摸索。多 Agent 共享记忆是个有意思的方向。让多个 Agent 共享一个语义记忆库每个 Agent 有自己的情景记忆。这样团队协作时一个 Agent 学到的经验其他 Agent 也能用。我测试了一个客服场景三个 Agent 共享记忆后整体解决率提升了 15%。但挑战在于记忆冲突会更复杂需要引入“记忆所有权”和“记忆投票”机制。记忆可视化对调试帮助很大。我写了一个简单的 Web 界面把记忆的写入时间、召回次数、置信度变化画成图表。有一次发现某条记忆的置信度在持续下降追查后发现是用户每次都被问烦了直接跳过说明这条记忆的召回时机不对。可视化让这种隐性问题变得可见。跨模态记忆是下一步想做的。目前只处理文本但实际场景中图片、语音、文件都是重要的记忆载体。比如用户发了一张设计图说“按这个风格来”这张图就应该被存入记忆下次生成时作为参考。技术上的难点在于跨模态检索文本查询怎么准确召回图片记忆我还在试不同的方案。我个人在实际操作中的体会是记忆系统的核心不是技术而是对用户意图的理解。同样的对话理解不同该记的东西就不同。我见过一个案例用户说“帮我订张票”Agent 记住了“订票”这个动作但没记住用户之前说过的“要靠窗”。后来我把意图理解模块和记忆写入模块做了更紧密的耦合让意图识别结果直接指导记忆提取效果好了很多。最后分享一个小技巧定期做记忆审计。我每个月会抽样 100 条记忆人工检查摘要质量和召回准确性。有一次发现模型把用户的玩笑话当成了真实偏好记了下来导致后续推荐一直跑偏。这种问题不审计根本发现不了。记忆系统就像花园不修剪就会杂草丛生。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
