1. 为什么单靠大模型上下文撑不起一个真正的 AI Agent做过 AI Agent 的人大概都有过这种体验第一轮对话效果惊艳聊到第十轮开始答非所问到第二十轮直接忘了自己是谁、用户之前交代过什么。这不是模型变笨了而是上下文窗口的物理上限在作祟。哪怕现在动辄 128K、200K token 的窗口一旦你把工具调用结果、历史对话、系统提示、检索文档全塞进去很快就会触顶而且 token 成本是线性甚至指数级往上飙的。我最早做 Agent 的时候天真地以为窗口够大就能记住一切。结果一个客服场景的 Agent用户来回问了七八轮订单问题模型开始把上一单的物流信息安到这一单头上。排查了半天才发现是历史消息被截断后模型只能靠猜来补全缺失的上下文。这就是无状态对话的典型症状——每次请求对模型来说都是失忆重启。mem0这类外挂记忆系统要解决的核心问题就是把记忆从模型的上下文窗口里剥离出来做成一个独立、可检索、可持久化的外部存储层。它的思路很像给 Agent 装了一个笔记本模型不需要把所有东西都记在脑子里而是需要的时候去笔记本上翻。这个笔记本就是记忆系统翻的动作就是记忆检索retrieval写笔记的动作就是记忆写入memory add。具体来说一个完整的 Agent 记忆系统要处理四件事写入Add从对话中抽取值得记住的信息比如用户偏好、事实、任务状态存进向量库或图数据库。检索Search新一轮对话时根据当前 query 找出相关记忆注入到 prompt 里。更新Update用户改了口径比如我现在改用邮箱联系旧记忆要能被覆盖或失效。遗忘Delete过期、错误、敏感的记忆要能清理否则记忆库会变成垃圾场。mem0的价值就在于它把这四件事封装成了相对统一的 API你不用自己从零搭一套向量检索 冲突消解的逻辑。它的MemoryClient和Memory两个核心类分别对应托管服务和本地自托管两种用法这个设计对个人开发者和团队都很友好。提示记忆系统不是存得越多越好。我见过有人把每轮对话原封不动全存进去结果检索时噪声极大模型反而被无关记忆带偏。记忆的关键是抽取和压缩不是堆砌。2. mem0 的记忆抽象MemoryClient 与 Memory 到底怎么选mem0对外暴露的两个入口很多人第一次看文档会懵MemoryClient和Memory长得像功能也像到底用哪个我把它俩的差异拆开讲清楚你就不会再纠结了。2.1 MemoryClient托管服务的省心路线MemoryClient走的是托管服务路线你注册拿到 API Key所有记忆的存储、向量化、检索都在服务端完成。代码层面极其干净from mem0 import MemoryClient client MemoryClient(api_keyyour-api-key) # 写入记忆 messages [ {role: user, content: 我偏好用中文回复而且我住在杭州}, {role: assistant, content: 好的我记住了} ] client.add(messages, user_iduser_001) # 检索记忆 results client.search(用户住在哪里, user_iduser_001) print(results)它的优势是零运维不用自己搭向量数据库、不用管 embedding 模型部署、不用操心扩容。对于快速验证想法、做 MVP、或者团队里没有专门的基础设施人手的情况这是最省事的选择。缺点是数据要出你的服务器对数据合规敏感的场景要慎重而且长期用量大了成本要算清楚。2.2 Memory自托管路线的完全掌控Memory类是自托管方案底层可以接多种向量库如 Qdrant、Chroma、PGVector和图存储。你需要自己配置 LLM、embedder、vector store 三件套from mem0 import Memory config { llm: { provider: openai, config: {model: gpt-4o-mini} }, embedder: { provider: openai, config: {model: text-embedding-3-small} }, vector_store: { provider: qdrant, config: { host: localhost, port: 6333, collection_name: agent_memory } } } m Memory.from_config(config) m.add(用户喜欢喝美式咖啡不加糖, user_iduser_001) hits m.search(用户喝什么咖啡, user_iduser_001)自托管的好处是数据完全在自己手里可以深度定制抽取逻辑、换任意 embedding 模型、接自己的向量库。代价是运维成本你得保证向量库稳定、embedding 服务可用、还要处理版本升级。2.3 选型对照表维度MemoryClient托管Memory自托管部署成本几乎为零需自建向量库与依赖数据位置服务端自己的基础设施定制能力有限跟随官方高可换任意组件适合场景MVP、快速验证、小团队数据敏感、深度定制、规模化成本结构按用量付费基础设施 人力我的建议是先用 MemoryClient 把业务逻辑跑通验证记忆确实带来效果提升再决定要不要迁到自托管。很多人一上来就搭自托管结果卡在向量库配置上业务逻辑一行没写本末倒置。注意无论用哪个user_id这个字段一定要设计好。它是记忆隔离的边界多用户场景下如果 user_id 混了A 用户的记忆会污染 B 用户的对话这是最危险也最容易犯的错。3. 把 mem0 接进 Agent 主循环写入与检索的时机设计光会调add和search不够真正难的是什么时候写、什么时候读、读多少。这三个时机设计不好记忆系统不但不帮忙还会拖后腿。3.1 写入时机不是每轮都写新手最常见的做法是每轮对话结束就add一次。实测下来问题很大一是写入频繁导致成本高二是大量无意义对话嗯好的谢谢被存进去检索时全是噪声。我的做法是按信息密度触发写入。具体判断逻辑可以这样设计用户明确表达了偏好、事实、约束我不吃辣我下周出差——立即写。任务状态发生变化订单已提交文件已上传——立即写。纯寒暄、确认类对话——跳过。长对话可以攒几轮后做一次批量抽取让 LLM 判断哪些值得记。mem0的add内部其实已经带了一层 LLM 抽取它会自动判断哪些信息值得存。但你仍然可以通过传入metadata来标记记忆类型方便后续过滤client.add( messages, user_iduser_001, metadata{category: preference, source: onboarding} )3.2 检索时机在拼 prompt 之前检索必须发生在构造最终 prompt 之前。典型流程是拿到用户当前输入 → 用输入去search相关记忆 → 把命中的记忆拼进 system prompt 或作为独立上下文块 → 再调 LLM。def build_prompt(user_input, user_id): memories client.search(user_input, user_iduser_id, limit5) memory_text \n.join([m[memory] for m in memories]) system_prompt f你是一个助手。以下是关于该用户的历史记忆请参考 {memory_text} return system_prompt, user_input这里limit参数很关键。设太大噪声多、token 贵设太小可能漏掉关键记忆。我的经验值是3 到 8 条具体看记忆的平均长度。如果单条记忆很长limit 要相应调小。3.3 检索的相关性阈值mem0的 search 返回结果通常带score字段。我强烈建议加一个相关性阈值过滤比如 score 低于 0.5 的直接丢弃。原因很简单向量检索总会返回 top-k哪怕库里根本没有相关内容它也会硬凑几条出来。这些低相关记忆注入 prompt 后模型可能被误导。results client.search(query, user_iduser_id, limit8) filtered [r for r in results if r.get(score, 0) 0.5]阈值具体设多少要靠实测调。不同 embedding 模型的分数分布不一样别照搬别人的数字自己拿一批标注数据跑一下最靠谱。提示检索 query 不一定要用用户的原始输入。有时候把最近两三轮对话拼起来做 query检索效果更好因为单句输入可能信息量不足。这个技巧在多轮任务型对话里特别管用。4. 记忆冲突、过期与污染那些文档不会告诉你的坑记忆系统跑起来容易跑得久不出问题难。下面这几个坑我都是踩过之后才明白的。4.1 记忆冲突用户改主意了怎么办用户上周说我住在北京这周说我搬到上海了。如果两条记忆都存着检索时可能同时命中模型就懵了。mem0的add内部有一定的冲突消解能力它会尝试判断新信息和旧记忆是否矛盾矛盾时更新而非新增。但这个能力不是万能的尤其是当新旧信息表述差异很大时。我的补救办法是在 metadata 里加时间戳和状态检索后自己做一层排序优先用最新的client.add( 用户已搬到上海, user_iduser_001, metadata{category: fact, ts: 2025-01-15, status: active} )对于明确失效的记忆主动调delete清掉别指望系统自动处理。4.2 记忆污染错误信息一旦写入就麻烦这是最隐蔽的坑。如果某轮对话里模型产生了幻觉而这条幻觉又被当成事实写进了记忆库后续所有对话都会被这条错误记忆影响形成错误累积。我遇到过 Agent 把用户随口说的玩笑话当成真实偏好记下来之后一直按这个错误偏好推荐用户一脸问号。防范手段有两个一是写入前做一次校验对关键事实类记忆可以让 LLM 再确认一遍这条信息是否明确由用户陈述二是定期审计记忆库把明显不合理的记忆清理掉。生产环境里我建议给记忆加一个confidence字段低置信度的记忆在检索时降权。4.3 记忆膨胀库越来越大检索越来越慢跑几个月后记忆库可能积累几万条。这时候检索延迟上升而且老记忆和新记忆混在一起相关性下降。解决办法分层存储高频访问的近期记忆放快库冷记忆归档。定期压缩把多条相关记忆合并成一条摘要比如把喜欢美式不加糖早上喝合并成早上喝不加糖的美式。TTL 机制给临时性记忆设过期时间比如用户今天心情不好这种几天后自动失效。4.4 多用户隔离的边界前面提过user_id的重要性这里再强调一个细节如果你的 Agent 支持群组对话比如一个群里多个用户记忆隔离就不能只按 user_id还要考虑agent_id和run_id。mem0支持这几个维度的组合过滤设计时要提前想清楚隔离粒度不然后期改起来很痛苦。隔离维度用途典型场景user_id区分不同用户个人助手agent_id区分不同 Agent 实例多角色系统run_id区分单次会话临时任务5. 从 Demo 到生产性能、成本与可观测性Demo 跑通只是起点真正上线要考虑的东西多得多。5.1 检索延迟的优化记忆检索是同步阻塞在对话链路里的它的延迟直接叠加到用户等待时间上。向量检索本身通常几十毫秒但如果 embedding 服务要走网络加上向量库查询整体可能到几百毫秒。优化手段embedding 缓存相同 query 的 embedding 结果缓存起来避免重复计算。异步预取在用户还在输入时就根据部分输入预判并预取记忆。本地 embedding 模型用小型本地模型替代远程 API省掉网络往返。5.2 成本控制记忆系统的成本主要来自三块embedding 调用、LLM 抽取调用、向量库存储。其中 LLM 抽取是大头因为每次add都可能触发一次 LLM 调用。控制方法批量写入减少调用次数。用便宜的小模型做抽取比如 gpt-4o-mini 这类。对明显不值得记的内容在客户端就过滤掉别送到服务端。5.3 可观测性你得知道记忆系统在干什么生产环境一定要有日志和指标。我关注这几个写入量每天新增多少条记忆突增可能意味着抽取逻辑出问题。检索命中率多少比例的检索返回了有效结果长期偏低说明记忆库和实际需求脱节。检索延迟 P99尾延迟最能反映问题。记忆库大小增长曲线斜率异常要警惕膨胀。把这些指标接进你现有的监控体系出问题时能快速定位是写入端还是检索端的问题。注意别在记忆系统里存敏感个人信息尤其是托管方案。如果业务必须处理这类数据优先选自托管并且做好加密和访问控制。这是合规底线不是可选项。6. 一个可复现的最小 Agent 记忆闭环讲了这么多原理和坑最后给一个能直接跑起来的最小闭环把前面说的写入时机、检索阈值、冲突处理串起来。这个例子用Memory自托管方便你本地验证。from mem0 import Memory config { llm: {provider: openai, config: {model: gpt-4o-mini}}, embedder: {provider: openai, config: {model: text-embedding-3-small}}, vector_store: { provider: qdrant, config: {host: localhost, port: 6333, collection_name: agent_mem} } } m Memory.from_config(config) def should_write(user_input): # 简单启发式包含偏好/事实关键词才写 keywords [我喜欢, 我偏好, 我住在, 我的, 记住, 以后] return any(k in user_input for k in keywords) def chat(user_input, user_id): # 1. 检索 hits m.search(user_input, user_iduser_id, limit5) valid [h for h in hits if h.get(score, 0) 0.5] memory_ctx \n.join(h[memory] for h in valid) # 2. 拼 prompt这里省略实际 LLM 调用 prompt f已知用户信息\n{memory_ctx}\n\n用户说{user_input} # 3. 按需写入 if should_write(user_input): m.add(user_input, user_iduser_id, metadata{ts: now}) return prompt # 模拟多轮 print(chat(我住在杭州喜欢喝美式, u1)) print(chat(推荐个咖啡, u1))跑起来后你会看到第二轮推荐个咖啡时检索命中了第一轮写入的喜欢喝美式prompt 里带上了这条记忆。这就是记忆闭环的最小形态。实际项目里你还需要把should_write换成更智能的判断比如让 LLM 判断把阈值调优加上错误处理和日志。但骨架就是这个骨架先跑通再优化比一上来追求完美架构靠谱得多。我在多个项目里用下来mem0最大的价值不是它多先进而是它把记忆系统里那些琐碎但必要的活儿抽取、去重、检索标准化了让你能把精力放在业务逻辑上。至于它内部的抽取 prompt 怎么写的、冲突消解的具体策略官方文档没细说我的建议是别过度依赖黑盒关键场景自己加一层校验心里才有底。
1. 为什么单靠大模型上下文撑不起一个真正的 AI Agent做过 AI Agent 的人大概都有过这种体验第一轮对话效果惊艳聊到第十轮开始答非所问到第二十轮直接忘了自己是谁、用户之前交代过什么。这不是模型变笨了而是上下文窗口的物理上限在作祟。哪怕现在动辄 128K、200K token 的窗口一旦你把工具调用结果、历史对话、系统提示、检索文档全塞进去很快就会触顶而且 token 成本是线性甚至指数级往上飙的。我最早做 Agent 的时候天真地以为窗口够大就能记住一切。结果一个客服场景的 Agent用户来回问了七八轮订单问题模型开始把上一单的物流信息安到这一单头上。排查了半天才发现是历史消息被截断后模型只能靠猜来补全缺失的上下文。这就是无状态对话的典型症状——每次请求对模型来说都是失忆重启。mem0这类外挂记忆系统要解决的核心问题就是把记忆从模型的上下文窗口里剥离出来做成一个独立、可检索、可持久化的外部存储层。它的思路很像给 Agent 装了一个笔记本模型不需要把所有东西都记在脑子里而是需要的时候去笔记本上翻。这个笔记本就是记忆系统翻的动作就是记忆检索retrieval写笔记的动作就是记忆写入memory add。具体来说一个完整的 Agent 记忆系统要处理四件事写入Add从对话中抽取值得记住的信息比如用户偏好、事实、任务状态存进向量库或图数据库。检索Search新一轮对话时根据当前 query 找出相关记忆注入到 prompt 里。更新Update用户改了口径比如我现在改用邮箱联系旧记忆要能被覆盖或失效。遗忘Delete过期、错误、敏感的记忆要能清理否则记忆库会变成垃圾场。mem0的价值就在于它把这四件事封装成了相对统一的 API你不用自己从零搭一套向量检索 冲突消解的逻辑。它的MemoryClient和Memory两个核心类分别对应托管服务和本地自托管两种用法这个设计对个人开发者和团队都很友好。提示记忆系统不是存得越多越好。我见过有人把每轮对话原封不动全存进去结果检索时噪声极大模型反而被无关记忆带偏。记忆的关键是抽取和压缩不是堆砌。2. mem0 的记忆抽象MemoryClient 与 Memory 到底怎么选mem0对外暴露的两个入口很多人第一次看文档会懵MemoryClient和Memory长得像功能也像到底用哪个我把它俩的差异拆开讲清楚你就不会再纠结了。2.1 MemoryClient托管服务的省心路线MemoryClient走的是托管服务路线你注册拿到 API Key所有记忆的存储、向量化、检索都在服务端完成。代码层面极其干净from mem0 import MemoryClient client MemoryClient(api_keyyour-api-key) # 写入记忆 messages [ {role: user, content: 我偏好用中文回复而且我住在杭州}, {role: assistant, content: 好的我记住了} ] client.add(messages, user_iduser_001) # 检索记忆 results client.search(用户住在哪里, user_iduser_001) print(results)它的优势是零运维不用自己搭向量数据库、不用管 embedding 模型部署、不用操心扩容。对于快速验证想法、做 MVP、或者团队里没有专门的基础设施人手的情况这是最省事的选择。缺点是数据要出你的服务器对数据合规敏感的场景要慎重而且长期用量大了成本要算清楚。2.2 Memory自托管路线的完全掌控Memory类是自托管方案底层可以接多种向量库如 Qdrant、Chroma、PGVector和图存储。你需要自己配置 LLM、embedder、vector store 三件套from mem0 import Memory config { llm: { provider: openai, config: {model: gpt-4o-mini} }, embedder: { provider: openai, config: {model: text-embedding-3-small} }, vector_store: { provider: qdrant, config: { host: localhost, port: 6333, collection_name: agent_memory } } } m Memory.from_config(config) m.add(用户喜欢喝美式咖啡不加糖, user_iduser_001) hits m.search(用户喝什么咖啡, user_iduser_001)自托管的好处是数据完全在自己手里可以深度定制抽取逻辑、换任意 embedding 模型、接自己的向量库。代价是运维成本你得保证向量库稳定、embedding 服务可用、还要处理版本升级。2.3 选型对照表维度MemoryClient托管Memory自托管部署成本几乎为零需自建向量库与依赖数据位置服务端自己的基础设施定制能力有限跟随官方高可换任意组件适合场景MVP、快速验证、小团队数据敏感、深度定制、规模化成本结构按用量付费基础设施 人力我的建议是先用 MemoryClient 把业务逻辑跑通验证记忆确实带来效果提升再决定要不要迁到自托管。很多人一上来就搭自托管结果卡在向量库配置上业务逻辑一行没写本末倒置。注意无论用哪个user_id这个字段一定要设计好。它是记忆隔离的边界多用户场景下如果 user_id 混了A 用户的记忆会污染 B 用户的对话这是最危险也最容易犯的错。3. 把 mem0 接进 Agent 主循环写入与检索的时机设计光会调add和search不够真正难的是什么时候写、什么时候读、读多少。这三个时机设计不好记忆系统不但不帮忙还会拖后腿。3.1 写入时机不是每轮都写新手最常见的做法是每轮对话结束就add一次。实测下来问题很大一是写入频繁导致成本高二是大量无意义对话嗯好的谢谢被存进去检索时全是噪声。我的做法是按信息密度触发写入。具体判断逻辑可以这样设计用户明确表达了偏好、事实、约束我不吃辣我下周出差——立即写。任务状态发生变化订单已提交文件已上传——立即写。纯寒暄、确认类对话——跳过。长对话可以攒几轮后做一次批量抽取让 LLM 判断哪些值得记。mem0的add内部其实已经带了一层 LLM 抽取它会自动判断哪些信息值得存。但你仍然可以通过传入metadata来标记记忆类型方便后续过滤client.add( messages, user_iduser_001, metadata{category: preference, source: onboarding} )3.2 检索时机在拼 prompt 之前检索必须发生在构造最终 prompt 之前。典型流程是拿到用户当前输入 → 用输入去search相关记忆 → 把命中的记忆拼进 system prompt 或作为独立上下文块 → 再调 LLM。def build_prompt(user_input, user_id): memories client.search(user_input, user_iduser_id, limit5) memory_text \n.join([m[memory] for m in memories]) system_prompt f你是一个助手。以下是关于该用户的历史记忆请参考 {memory_text} return system_prompt, user_input这里limit参数很关键。设太大噪声多、token 贵设太小可能漏掉关键记忆。我的经验值是3 到 8 条具体看记忆的平均长度。如果单条记忆很长limit 要相应调小。3.3 检索的相关性阈值mem0的 search 返回结果通常带score字段。我强烈建议加一个相关性阈值过滤比如 score 低于 0.5 的直接丢弃。原因很简单向量检索总会返回 top-k哪怕库里根本没有相关内容它也会硬凑几条出来。这些低相关记忆注入 prompt 后模型可能被误导。results client.search(query, user_iduser_id, limit8) filtered [r for r in results if r.get(score, 0) 0.5]阈值具体设多少要靠实测调。不同 embedding 模型的分数分布不一样别照搬别人的数字自己拿一批标注数据跑一下最靠谱。提示检索 query 不一定要用用户的原始输入。有时候把最近两三轮对话拼起来做 query检索效果更好因为单句输入可能信息量不足。这个技巧在多轮任务型对话里特别管用。4. 记忆冲突、过期与污染那些文档不会告诉你的坑记忆系统跑起来容易跑得久不出问题难。下面这几个坑我都是踩过之后才明白的。4.1 记忆冲突用户改主意了怎么办用户上周说我住在北京这周说我搬到上海了。如果两条记忆都存着检索时可能同时命中模型就懵了。mem0的add内部有一定的冲突消解能力它会尝试判断新信息和旧记忆是否矛盾矛盾时更新而非新增。但这个能力不是万能的尤其是当新旧信息表述差异很大时。我的补救办法是在 metadata 里加时间戳和状态检索后自己做一层排序优先用最新的client.add( 用户已搬到上海, user_iduser_001, metadata{category: fact, ts: 2025-01-15, status: active} )对于明确失效的记忆主动调delete清掉别指望系统自动处理。4.2 记忆污染错误信息一旦写入就麻烦这是最隐蔽的坑。如果某轮对话里模型产生了幻觉而这条幻觉又被当成事实写进了记忆库后续所有对话都会被这条错误记忆影响形成错误累积。我遇到过 Agent 把用户随口说的玩笑话当成真实偏好记下来之后一直按这个错误偏好推荐用户一脸问号。防范手段有两个一是写入前做一次校验对关键事实类记忆可以让 LLM 再确认一遍这条信息是否明确由用户陈述二是定期审计记忆库把明显不合理的记忆清理掉。生产环境里我建议给记忆加一个confidence字段低置信度的记忆在检索时降权。4.3 记忆膨胀库越来越大检索越来越慢跑几个月后记忆库可能积累几万条。这时候检索延迟上升而且老记忆和新记忆混在一起相关性下降。解决办法分层存储高频访问的近期记忆放快库冷记忆归档。定期压缩把多条相关记忆合并成一条摘要比如把喜欢美式不加糖早上喝合并成早上喝不加糖的美式。TTL 机制给临时性记忆设过期时间比如用户今天心情不好这种几天后自动失效。4.4 多用户隔离的边界前面提过user_id的重要性这里再强调一个细节如果你的 Agent 支持群组对话比如一个群里多个用户记忆隔离就不能只按 user_id还要考虑agent_id和run_id。mem0支持这几个维度的组合过滤设计时要提前想清楚隔离粒度不然后期改起来很痛苦。隔离维度用途典型场景user_id区分不同用户个人助手agent_id区分不同 Agent 实例多角色系统run_id区分单次会话临时任务5. 从 Demo 到生产性能、成本与可观测性Demo 跑通只是起点真正上线要考虑的东西多得多。5.1 检索延迟的优化记忆检索是同步阻塞在对话链路里的它的延迟直接叠加到用户等待时间上。向量检索本身通常几十毫秒但如果 embedding 服务要走网络加上向量库查询整体可能到几百毫秒。优化手段embedding 缓存相同 query 的 embedding 结果缓存起来避免重复计算。异步预取在用户还在输入时就根据部分输入预判并预取记忆。本地 embedding 模型用小型本地模型替代远程 API省掉网络往返。5.2 成本控制记忆系统的成本主要来自三块embedding 调用、LLM 抽取调用、向量库存储。其中 LLM 抽取是大头因为每次add都可能触发一次 LLM 调用。控制方法批量写入减少调用次数。用便宜的小模型做抽取比如 gpt-4o-mini 这类。对明显不值得记的内容在客户端就过滤掉别送到服务端。5.3 可观测性你得知道记忆系统在干什么生产环境一定要有日志和指标。我关注这几个写入量每天新增多少条记忆突增可能意味着抽取逻辑出问题。检索命中率多少比例的检索返回了有效结果长期偏低说明记忆库和实际需求脱节。检索延迟 P99尾延迟最能反映问题。记忆库大小增长曲线斜率异常要警惕膨胀。把这些指标接进你现有的监控体系出问题时能快速定位是写入端还是检索端的问题。注意别在记忆系统里存敏感个人信息尤其是托管方案。如果业务必须处理这类数据优先选自托管并且做好加密和访问控制。这是合规底线不是可选项。6. 一个可复现的最小 Agent 记忆闭环讲了这么多原理和坑最后给一个能直接跑起来的最小闭环把前面说的写入时机、检索阈值、冲突处理串起来。这个例子用Memory自托管方便你本地验证。from mem0 import Memory config { llm: {provider: openai, config: {model: gpt-4o-mini}}, embedder: {provider: openai, config: {model: text-embedding-3-small}}, vector_store: { provider: qdrant, config: {host: localhost, port: 6333, collection_name: agent_mem} } } m Memory.from_config(config) def should_write(user_input): # 简单启发式包含偏好/事实关键词才写 keywords [我喜欢, 我偏好, 我住在, 我的, 记住, 以后] return any(k in user_input for k in keywords) def chat(user_input, user_id): # 1. 检索 hits m.search(user_input, user_iduser_id, limit5) valid [h for h in hits if h.get(score, 0) 0.5] memory_ctx \n.join(h[memory] for h in valid) # 2. 拼 prompt这里省略实际 LLM 调用 prompt f已知用户信息\n{memory_ctx}\n\n用户说{user_input} # 3. 按需写入 if should_write(user_input): m.add(user_input, user_iduser_id, metadata{ts: now}) return prompt # 模拟多轮 print(chat(我住在杭州喜欢喝美式, u1)) print(chat(推荐个咖啡, u1))跑起来后你会看到第二轮推荐个咖啡时检索命中了第一轮写入的喜欢喝美式prompt 里带上了这条记忆。这就是记忆闭环的最小形态。实际项目里你还需要把should_write换成更智能的判断比如让 LLM 判断把阈值调优加上错误处理和日志。但骨架就是这个骨架先跑通再优化比一上来追求完美架构靠谱得多。我在多个项目里用下来mem0最大的价值不是它多先进而是它把记忆系统里那些琐碎但必要的活儿抽取、去重、检索标准化了让你能把精力放在业务逻辑上。至于它内部的抽取 prompt 怎么写的、冲突消解的具体策略官方文档没细说我的建议是别过度依赖黑盒关键场景自己加一层校验心里才有底。
