★ FEATURED ARTICLE 1. 为什么需要外挂记忆先看清AI Agent的“失忆”困境干了这么久的Agent开发我越来越觉得市面上大部分“智能助手”其实都算不上真正的智能它们更像一个知识储备很足、但随时失忆的同事。你上午刚告诉它你养了只猫下午它就能一本正经地问你“养宠物了吗”你上次已经明确说过不要推荐含糖饮料下次它照样给你推奶茶。大模型的单次对话能力已经很强了但一旦涉及需要跨轮次、跨会话的场景它就立刻露馅。这个问题的根源不在模型本身而在于大模型本质上是一个无状态的函数。你每发一次请求它都是独立计算的不会自动记住上一轮你们聊了什么。所谓“多轮对话”其实只是开发者把历史消息一条不落地塞进上下文窗口里让模型自己“看”而已。这种方式在小规模、短对话的场景下勉强够用一旦你的Agent要做长期任务、要基于用户偏好做推荐、要跨天甚至跨月维持一致性就彻底没戏了。那怎么办最常见的做法是开发者自己写一个记忆模块把历史聊天记录存进数据库每次请求前捞回来拼到Prompt里。这个方案我早期也用过但踩坑踩得相当痛。首先是“存什么”的问题——你不能把所有原始聊天记录都塞回去上下文窗口很快就会被撑爆而且绝大部分内容对当前任务毫无帮助。其次是“怎么取”的问题——基于关键词去匹配历史记录匹配质量非常差用户的意图稍微拐个弯你就捞不到相关的历史信息。最后是“怎么管”的问题——用户的偏好是会变的旧记忆和新记忆冲突怎么办记错了怎么办很少有人会认真处理这部分逻辑。正当我为这个问题头疼的时候接触到了Mem0它对标的是给AI Agent做“外挂记忆系统”。这个名字的梗来自主流大模型厂商提出的“Model Context”概念Mem0做的事就是在模型之外维护一套结构化记忆层。它会把你和用户之间的对话内容自动做提取、评分、去重、存储然后在你需要的时候把真正相关的记忆片段通过接口返回给Agent。你不需要自己造轮子也不用关心原始文本该怎么清洗、怎么索引只要把对话内容喂给它它就能变成一个越用越懂你的记忆库。这篇内容我不打算只讲概念我会把Mem0的底层机制、接入方式、配置参数以及我实际测试中遇到的各种问题完整地梳理一遍。如果你正在做自定义Agent、私人助理、客服机器人、教育陪伴类产品或者任何需要让AI“记得住人”的项目这篇文章应该能帮你省下不少调研和踩坑的时间。2. Mem0核心机制拆解四条管线带你搞懂它的工作方式很多人第一次看到Mem0下意识会觉得“这不就是一个向量数据库吗”其实完全不是。向量数据库只是它底层的一个存储组件真正值钱的是围绕存储构建起来的四套处理逻辑记忆提取、记忆评分、记忆更新、记忆检索。这四条管线协同工作才让Mem0呈现出“像人一样记住重要事情”的效果。2.1 记忆提取怎么从对话里挑出值得记的内容Mem0接到一段对话消息后并不是把所有内容原封不动地存起来而是会调用一次大模型把这段消息中的“事实性信息”抽取出来变成一条条结构化的记忆条目。比如用户说“我住在杭州在互联网公司做产品经理周末喜欢爬山”Mem0不会把这句话整个存进向量库它会分解成类似这样的几条用户居住在杭州。用户职业是互联网公司的产品经理。用户周末的爱好是爬山。这个提取过程是整条流水线的第一环也是最核心的一环因为后面所有存储和检索都建立在“提取质量”的基础上。如果这里抽出来的信息是错的、冗余的或者不完整的那后面再怎么处理都是垃圾进垃圾出。默认情况下Mem0使用的是你配置的大模型比如通过OPENAI_API_KEY指定的模型来执行提取和后续的评分操作。这也意味着Mem0每一次add操作背后都会消耗一次或多次LLM调用的token这是使用成本和延迟的主要来源。我在后面“成本控制”那一节会专门讲这个问题。这里有一个值得注意的设计细节Mem0支持messages参数但并不要求你一定传完整的多轮历史你完全可以在对话的关键节点只抽取某几条有信息量的消息丢给它做记忆提取。我实际项目中就是这么干的这样能大幅度降低LLM调用次数同时避免了一些无关闲聊污染记忆库。2.2 记忆评分相关度与重要性排序提取出候选记忆后Mem0会再做一次评分筛选。它基于当前对话的上下文计算每一条候选记忆与当前用户意图的相关程度并把分数低于某个阈值的记忆过滤掉。这个机制解决了一个很实际的问题不是每句“今天天气不错”都值得被永久记住。评分环节本质上也是一个LLM调用它让Mem0具备了一定程度上的“常识判断力”。比如用户说“这家店的咖啡不错下次再来”Mem0可能会把它记为一条关于用户口味的偏好而如果用户说“这个报错烦死了”它可能就不会把它当成一种长期偏好去存储。这种看似简单的过滤是我之前手写记忆系统时最头疼的部分因为关键词匹配很难理解语义层面的“重要”和“不重要”。当然评分环节不是凭空猜的它可以结合规则和配置去微调。比如你可以通过threshold参数控制入选记忆的最低相关度分数分数调高记忆会更精炼但可能会漏掉部分低频但重要的信息分数调低记忆会更丰富但噪声也会增多。这块需要针对自己的数据反复试我在第五节会给出具体的调节思路。2.3 记忆更新与去重合并这是Mem0最有价值的地方之一也是我用过之后决定不再自己造轮子的关键原因。当一个新记忆被提取出来后Mem0会先在已有记忆中寻找“同主体、同属性”的旧记忆然后调用大模型判断新旧记忆之间的关系。如果新记忆是对旧记忆的补充或更新Mem0会执行合并或替换而不是简单地把两条都塞进数据库。举个例子第一天用户说“我住在北京”Mem0存了一条记忆用户居住在北京。第三天用户说“我搬到上海工作了”Mem0会识别到“居住城市”这个属性已经变化然后自动把“居住在北京”更新为“居住在上海”而不是留下两条自相矛盾的记录。这个机制非常像人的记忆运作方式——它会主动更新认知而不是机械地叠加事实。对于Agent应用来说这一点能避免很多尴尬的对话场面如果你辛辛苦苦加了一套记忆系统结果它同时记得用户住在北京和上海那这个东西还不如不加。去重合并操作会生成唯一的记忆ID你可以通过这个ID对具体记忆做update或delete操作。当你的应用有后台管理页面时甚至可以开放一个“用户可编辑记忆”的功能让用户自己修改或删除AI记住的关于TA的信息这会极大提升信任感。2.4 记忆检索先搜后重排当Agent需要调用历史记忆时会调用search方法并传入当前的用户查询。Mem0会把查询文本转为向量在向量库中做相似度检索把最相关的记忆片段捞出来。但这里不是简单的“向量相似度排序”它还会经过一层重排结合与当前上下文的语义相关性对召回结果做二次排序返回更符合当下任务需求的记忆。search接口支持user_id和agent_id参数这是Mem0做多用户隔离的基础。你传入不同的user_id它只检索这个用户自己的记忆传入不同的agent_id不同Agent应用之间也能共享或隔离记忆。我在做多租户SaaS产品时这一层隔离几乎是保命级的特性否则用户A的隐私信息会通过共享记忆库泄漏给用户B。另外这里要提醒一个容易忽略的点向量检索天然对“语义相似”敏感但对“精确事实”比较钝。比如用户问“我家猫几岁了”向量检索大概率能捞回“用户养了一只3岁的橘猫”这条记忆但如果用户问“我上次说的过敏原是什么”检索结果可能就没那么精准。所以search返回结果后还是要依赖上下文Prompt的设计去引导模型正确使用这些记忆别指望它百分之百准确。3. 从零接入环境配置与最小可用代码讲了这么多原理现在开始动手。我先带你跑通一个最简流程让你直观地感受一下Mem0到底长什么样然后再逐段解释背后的配置和设计逻辑。3.1 安装与初始化两种运行模式的选择Mem0的Python包直接通过pip安装pip install mem0ai安装完成之后你需要想清楚一个问题你要用Mem0云的API服务还是本地自托管的基础设施模式我建议优先尝试本地模式因为它在开发调试阶段最可控不依赖外部服务也不用预先开通各种云账号。本地模式要跑起来需要几个基础组件先就位。Mem0官方默认支持用MongoDB作为主存储来存放提取出来的记忆结构用Qdrant作为向量数据库来做相似度检索同时还需要配置一个LLM后端默认是OpenAI兼容接口和一个Embedding模型。如果你一时半会不想搭MongoDB和Qdrant也可以直接先试用云托管版本只需要拿一个API Key几分钟就能通。但如果你像我一样喜欢自己掌控数据流转的每个环节还是建议花点时间把本地组件搭起来。我现在的标准配置是MongoDB存结构化记忆Qdrant存向量索引LLM用OpenAI兼容的接口Embedding用开源模型跑本地推理。这套组合在数据安全性和成本上都很理想。初始化逻辑很简单本地模式下Mem0会自动帮你把存储客户端连接好from mem0 import Memory # 本地模式只需在环境变量里配置好 OPENAI_API_KEY # 其它存储组件MongoDB、Qdrant通过环境变量或默认配置自动连接 m Memory.from_config(config_json{ llm: {provider: openai, config: {model: gpt-4o-mini}}, embedder: {provider: openai, config: {model: text-embedding-3-small}}, vector_store: {provider: qdrant, config: {collection_name: my_agent_memory}}, history_db_path: history.db })很多人第一次跑这段代码会卡在连接MongoDB和Qdrant上。你本地的MongoDB如果没启动会直接抛连接异常Qdrant如果是用Docker起的连接地址要对上。我给个最快的本地起服务方式# mongodb docker run -d -p 27017:27017 --name mem0-mongo mongo:7 # qdrant docker run -d -p 6333:6333 --name mem0-qdrant qdrant/qdrant:latesthistory_db_path是Mem0用来存消息历史、方便做时间衰减和记忆更新的一个本地SQLite路径。这个路径你最好固定下来否则重启应用后历史上下文会丢失记忆提取的连贯性会受影响。3.2 第一行记忆代码写入与召回全流程体验初始化完成后最核心的就两个操作写入记忆add和查询记忆search。我先把最简单的用法给你看# 写入记忆 res m.add( messages[ {role: user, content: 我叫阿杰在杭州做后端开发平时喜欢打篮球} ], user_iduser_001, agent_idassistant_001 ) print(res) # 查询记忆 res m.search( query这个用户在哪里工作, user_iduser_001, agent_idassistant_001 ) print(res)add方法执行完之后返回的内容里通常会包含类似memory_id、event类型是add这样的字段以及提取出的记忆文本。你去MongoDB里翻一下还能看到更完整的记录比如记忆内容、相关元数据、创建时间、更新时间等。search方法返回的结构里主要是一个results列表每个元素有memory文本和对应的score相似度分数。我实测下来在同一句话里既包含“杭州”又包含“后端开发”和“篮球”你去搜索其中任何一方面的信息Mem0都能把这条记忆的完整内容捞回来这得益于它提取记忆时做的结构化拆分和向量化索引。这里要特别提醒一个坑messages参数要求的是标准消息列表格式每个元素必须是包含role和content键的字典。有些新手图省事直接传一个字符串进去结果一运行就报错。这个格式问题我后面第五章节还会再提到你别在这上面浪费时间。3.3 记忆类型与个性化配置参数含义全解读add和search看起来只有两个函数但你深入到配置层就会发现Mem0能调节的旋钮相当多。先给一张我整理的核心配置对照表配置项可选值示例含义与建议llm.provideropenai/anthropic/ollama指定谁来做记忆提取、更新、判断。生产环境建议用推理能力强的模型embedder.provideropenai/huggingface/ollama指定谁将文本转成向量。中文场景建议用对中文支持好的向量模型vector_store.providerqdrant/chroma/pgvector向量库选型决定检索性能和部署方式threshold0.0 ~ 1.0检索结果的最低相关度阈值低于此值不返回。调高则更精准但容易漏调低则召回多但噪声大history_db_path本地路径存储消息历史的SQLite路径用于短时记忆和更新判断user_id任意字符串记忆隔离的主维度不同用户之间互不可见agent_id任意字符串记忆隔离的次维度用于区分不同Agent应用关于这些配置我给你的实际建议很简单初期先全用默认参数跑通链路之后再慢慢调节threshold和替换模型。不要一上来就想着把所有旋钮都调成最优因为最优值高度依赖你的具体场景和测试数据没有统一答案。关于记忆类型Mem0还区分了短期记忆short-term memory和长期记忆long-term memory。短期对应会话内部的消息上下文长期则对应持久化的结构化记忆。你可以在add时通过参数控制记忆是否进入长期库这做主动式对话管理的时候非常有用。比如闲聊、临时任务这种内容没必要长期记住而用户明确表达的偏好、身份信息、长期目标才应该正式写入长期记忆。4. 接入AI Agent的完整路径让助理真的“记得你”跑通最小例子之后真正的挑战来了怎么把Mem0无缝嵌进你现有的Agent工作流里。这一节我会先讲整体架构思路再给出一段可以完整运行的LangChain Agent代码最后聊一下多用户场景的隔离策略。4.1 架构设计记忆层应该放在哪里很多人在接入记忆时容易犯一个错误他们只想在组装Prompt时把记忆拼接进去而不去管对话结束后的记忆沉淀。这种“只读不写”的方式会让你的Agent永远停留在上一轮之前的状态用着用着就退化了。正确的架构应该是“读前写后双路并行”用户提问后Agent先调用search获取与该用户相关的历史记忆把记忆片段拼入System Prompt。Agent生成回复、完成任务之后把这一段有信息量的交互内容通过add写入Mem0让它沉淀成长期记忆。一句话总结每次交互既要“想起”过去也要“记住”当下。接收用户问题前先做记忆检索这是“想起”处理完用户问题后做记忆抽取写入这是“记住”。两者缺一不可。这里还要做一个重要区分记忆层应该挂在Agent层而不是模型层。你不需要去改大模型的权重也不应该去微调模型那成本太高。你只需要在模型调用前后增加两个钩子函数——一个负责读记忆一个负责写记忆。这也是Mem0叫“外挂记忆系统”的原因它就像给一个失忆的天才挂了一个工作笔记本动笔和翻本都是外部行为不影响天才本身的核心能力。4.2 完整代码示例基于LangChain的Agent集成下面这段代码是我实际项目里的简化版基于LangChain实现了一个带记忆能力的客服助理。它只处理两种用户意图询问身份信息和查询订单状态。当新用户出现时它通过Mem0先召回该用户的历史记忆然后带着记忆生成回答回答结束后再把关键信息写回Mem0。from langchain.agents import AgentExecutor, create_openai_functions_agent from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.tools import Tool from mem0 import Memory # 初始化Mem0 m Memory.from_config(config_json{ llm: {provider: openai, config: {model: gpt-4o-mini}}, embedder: {provider: openai, config: {model: text-embedding-3-small}} }) user_id test_user_alex agent_id customer_service_bot # 两个工具查询用户信息和查询订单 def get_user_info(query: str) - str: return 张三会员等级金牌会员常驻城市上海喜欢顺丰配送。 def get_order_info(order_id: str) - str: return f订单{order_id}已发货预计明天到达商品为智能手表。 tools [ Tool(nameuser_info, funcget_user_info, description查询用户个人信息), Tool(nameorder_info, funcget_order_info, description查询订单状态需要传入订单号) ] # 构建Prompt prompt ChatPromptTemplate.from_messages([ (system, 你是客服助理请基于已知的用户记忆回答问题。用户记忆{memory_context}), MessagesPlaceholder(variable_namechat_history), (user, {input}), MessagesPlaceholder(variable_nameagent_scratchpad) ]) # 调用LangChain创建Agent llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) agent create_openai_functions_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) def ask(input_text): # 1. 读取记忆 memories m.search(queryinput_text, user_iduser_id, agent_idagent_id) memory_context \n.join([item[memory] for item in memories.get(results, [])]) chat_history [] # 2. 带着记忆去执行Agent result agent_executor.invoke({ input: input_text, memory_context: memory_context, chat_history: chat_history, agent_scratchpad: [] }) # 3. 沉淀记忆 m.add(messages[ {role: system, content: 客服助理和用户的对话已结束请提取用户的长期偏好}, {role: user, content: input_text}, {role: assistant, content: result[output]} ], user_iduser_id, agent_idagent_id) return result[output] # 测试 print(ask(你好我叫Alex帮我查一下订单20240815)) # 第一次Agent不认识Alex但能查到订单 print(ask(我上次问的订单号是多少)) # 第二次通过Mem0成功找回“订单20240815”这个记忆运行这段代码你会看到一个非常有意思的现象第一轮对话后Mem0把“用户自称Alex”和“查询过订单20240815”自动写入了记忆库第二轮用户用模糊的问法“我上次问的订单号”Agent通过search成功找回了精确的订单号然后正确回答了问题。这个能力就是外挂记忆系统带来的核心体验提升。不过这里我也要坦白一个体验问题m.add()的执行时间通常比m.search()长因为记忆提取要调大模型。如果每次对话结束都同步阻塞等待写入完成用户会明显感到“停顿”。我的解决方案是使用异步队列把消息丢给一个后台线程池去执行add主流程直接返回回复。你可以在生产环境用Celery或简单的concurrent.futures解决这个问题。4.3 多用户场景的隔离策略别让你的用户“串记忆”做单用户Demo时user_id传不传区别不大但一旦产品要上线user_id的隔离就是安全红线。Mem0的记忆隔离是依靠传入的user_id和agent_id组合实现的。漏传任何一个参数轻则记忆串味重则用户A的隐私被用户B通过对话套出来。我见过一个很典型的翻车案例某团队做了一个企业内部的AI问答助手没有认真区分user_id结果所有员工共用一个记忆库。有人问“我们部门最近的招聘进度”另一个人紧接着问“刚才说的那个候选人是谁”系统把前者的记忆输出给了后者。这个事故直接导致产品下线整改。现在做多租户隔离我建议的规范是每个用户的user_id使用业务侧全局唯一的ID比如用户数据库主键。每个Agent应用固定使用一个agent_id这样同一个用户使用不同Agent时记忆天然隔离。在产品端增加“记忆管理”页面让用户能查看、删除AI记住的关于自己的信息。这既是合规要求也是体验加分项。上报给Mem0的消息中不要携带与业务无关的敏感字段比如身份证号、银行卡信息因为它会把这些事实也提取成长期记忆。你在做上线前评审时可以把“记忆隔离测试”写进验收标准用两个不同的user_id分别输入敏感信息然后互相查询确认得不到对方数据。5. 常见问题与排查技巧实录这部分是我在实际使用中积攒下来的实战经验。很多问题你在官方文档里不一定能搜到针对性的答案但遇到了确实很耽误事。我把它们梳理成速查表加上详细的排查思路方便你按图索骥。5.1 记忆混乱、噪声过多怎么办症状search返回的内容里有些记忆看起来和查询完全无关或者返回了大量已经过时的信息。Agent基于这些记忆做出的回答经常张冠李戴。排除思路第一检查threshold配置。Mem0的search结果中会返回score你可以先把一批真实查询的score打印出来看看多少分以上的记忆才有用。如果发现很多低分比如0.2以下的内容还在干扰答案就要适当提高threshold。我自己的经验值是从0.3开始试根据测试集表现再微调。第二检查是否有太多“临时型记忆”被写入了长期库。比如“用户今天问了某个报错”这种信息适合停留在短期会话中不适合长期保存。解决办法是调整调用add的时机和消息内容不要每轮对话结束后都无条件写入只在对话出现明确的偏好、身份、目标、关键事实变更时才写入。第三定期做“记忆归档”。Mem0支持对已有记忆做更新和删除你可以在后台写一个定时任务把超过N天没有触发过的记忆标记为过期。这不是一个自动功能所以需要你自己维护。比如每周跑一次清理脚本删除长期未使用的记忆条目。5.2 API Key与成本控制注意点Mem0的记忆提取和记忆更新都依赖LLM调用而且每次add可能会调用多次LLM来完成提取、去重、合并判断。这就意味着它的消耗不是一次API调用而是一个“调用链”。我在早期测试时没有注意结果一天之内测试了几百条对话账单数额上升得非常快。这里给出几个成本控制策略在配置中使用便宜且足够聪明的模型执行提取任务而不是把顶配模型用于所有环节。比如提取用gpt-4o-mini生成用gpt-4o。对add操作做频率限制单用户每小时最多写入N条记忆防止高频对话把预算烧穿。把记忆写入改为异步和批量处理减少线程阻塞带来的重复调用。在测试环境使用本地大模型比如通过Ollama跑一个开源模型来做提取和评分验证整体流程无误后再切回云端高精度模型。一只容易被忽略的隐形账单来自Embedding模型。search每次查询都会把查询文本向量化如果租户基数大、调用频繁Embedding费用会积少成多。中文业务建议选用支持中文的Embedding模型。5.3 中文场景的细节问题Mem0本身对中文的支持没有问题核心差异主要在Embedding模型的选择上。英文的text-embedding-3-small在英文语义召回上表现不错但直接用于中文长文本和同义表达的召回质量会打折扣。我建议中文场景优先替换为中文效果更好的Embedding模型比如基于中文语料训练的向量模型通过Ollama或HuggingFace本地部署。还有一个中文特有的坑标点符号和简繁体。用户输入的记忆内容如果一会儿用简体、一会儿用繁体或者“杭州”和“杭州市”混用Mem0提取出的记忆会呈现碎片化。虽然向量检索能在一定程序上容忍这种差异但如果你希望记忆库更干净可以在喂给add之前先做一轮文本归一化比如统一转简体、统一去除多余空格、统一地名简称与全称。5.4 一些实战中踩过的坑最后分享几条真实的踩坑记录每一条都是我或者身边同行付出过调试时间换来的。消息格式必须严格遵守[{role: user, content: ...}, {role: assistant, content: ...}]的列表结构。传字符串、传纯文本、content为空字典调试时会以各种诡异的报错方式折磨你。建议在调用add的入口写一个消息校验函数提前拦截格式错误。user_id和agent_id别漏传。漏传之后Mem0不会报错但它会把记忆归到默认空间等到你后面想按用户隔离时数据已经搅成一锅粥了。所以这两个参数最好封装在统一方法内部不要在业务代码里散着写。不要在每个turn都调add。早期我做Demo时无论用户说什么都把整段对话丢给add结果记忆库很快被低价值信息塞满。后来改成“只在用户表达明确偏好或关键事件时写入”记忆质量立刻大幅提升。简单判断标准是如果这句话删掉不影响用户长期画像那就别写。不要忽略search结果的重排影响。你直接看search出参的顺序有时会发现最相关的内容不在第一位这是重排模型的干预。在实际Agent应用里建议把前3~5条记忆全部塞进Prompt不要把top1当作唯一真相。我现在的固定做法是给Agent加一个“记忆兜底层”如果search返回的相关度最高分低于0.25就明确告诉大模型“当前没有已知的长期记忆”让它基于常识回答并主动向用户提问。这比强行塞入几条低分记忆更不容易产生幻觉式错误。6. 记忆系统落地后的几点真实体会这块内容不属于官方使用教程但我觉得对准备上生产环境的开发者来说参考价值可能比前面的API介绍更大。先说项目复盘时最深刻的感触接入Mem0之后Agent的产品形态会发生一个微妙的变化——它不再是一个“每次见面都是陌生人”的工具而是开始向“熟悉你的长期助手”方向靠拢。用户能明显感知到AI记得TA说过的话这种体验上的跃升有时候比模型本身变强更能留住用户。不过记忆系统是一把双刃剑。一旦记忆进入长期库它就会持续影响后续每一次对话。如果记忆提取质量不稳定用户的坏印象也会被持续放大。所以我的建议是上生产环境前一定要先准备一套记忆质量评测集。拿一组典型用户对话跑一遍人工检查提取出的记忆是否准确、是否无过时、是否无歧义把评分标准定下来再让团队按标准迭代提示词与阈值。别把记忆系统当成“配好就能躺赢”的组件它需要持续的运营和调优。另外一个容易被忽略的设计点记忆的“遗忘”。Mem0提供了删除和更新能力但你的产品应该在交互层主动暴露这个入口。一个能让用户一键清空记忆的AI助手比一个用户觉得“AI永远记住我不想记的东西”的助手更容易获得信任。我做私人助理类产品时专门加了一个“记忆管理面板”用户能看到AI记住了哪些关于TA的信息随时可以删除或修正。这个面板上线后用户对AI的信任评分明显上升值得你参考。最后如果你打算把这个系统用在自己的个人项目上我建议从小范围、单场景切入。不要一开始就想着做一个无所不知的全能助理先把一个业务场景比如“记住用户订单偏好”“记住学习进度”做透积累一段时间的数据后再扩展到更多场景。记忆系统的价值是随着时间累积的一个月后的Agent和第一天冷启动的Agent完全是两个体验级别。这个特点既是它的魅力也是它的门槛。
阅读完成 · 觉得有帮助？
七种模式详解与生产环境配置实战)
