AI Agent开发实战④记忆不只是向量数据库Agent三层记忆架构设计与8个踩坑实录加了向量数据库Agent反而更差了刚查过的内容转头就忘越用越慢卡在记忆检索上这些问题我都踩过。本文讲透三层记忆的设计逻辑以及8个让我debug了整整两天的实际踩坑。一、先搞清楚一个问题为什么Agent记不住一个真实的崩溃时刻项目里的客服Agent上午用户说我的工单号是WO-20240615-001下午Agent完全忘了这回事。用户再问一次Agent还是问请提供工单号。开发者第一反应是向量数据库没起作用。但检查日志发现检索结果是有的——问题出在Agent选择忽略检索到的记忆。这不是向量数据库的问题是三层记忆的协作机制设计错了。先搞清楚三层记忆各自负责什么┌─────────────────────────────────────────────┐ │ 长期记忆 (Long-term Memory) │ │ 存储历史任务经验、知识库、沉淀的通用规则 │ │ 介质向量数据库ChromaDB/Pinecone │ │ 特点持久化、跨会话、检索触发 │ ├─────────────────────────────────────────────┤ │ 短期记忆 (Short-term Memory) │ │ 存储当前会话的所有对话历史 │ │ 介质内存/LLM上下文 │ │ 特点按会话隔离、会话结束清空 │ ├─────────────────────────────────────────────┤ │ 工作记忆 (Working Memory) │ │ 存储当前任务的中间状态、执行步骤、待决策项 │ │ 介质程序变量 │ │ 特点最实时、仅当前任务可见 │ └─────────────────────────────────────────────┘二、三层记忆的协作机制三层不是简单的堆叠是有明确协作规则的classThreeLayerMemory:Agent三层记忆系统def__init__(self,vector_db,llm):self.long_termVectorMemory(vector_db)# 长期记忆self.short_term[]# 短期记忆当前会话self.workingWorkingMemory()# 工作记忆当前任务self.llmllmdefstore(self,content:str,memory_type:str,**metadata):存储记忆——自动路由到正确的层ifmemory_typesession:# 短期记忆直接追加self.short_term.append({role:metadata.get(role,user),content:content,timestamp:datetime.now().isoformat()})elifmemory_typetask:# 工作记忆覆盖同名keyself.working.set(metadata.get(task_id),content,metadata)elifmemory_typeexperience:# 长期记忆向量嵌入后存储self.long_term.add(content,metadata)defretrieve(self,query:str,context_window:int5)-dict:检索记忆——三层各有分工# 1. 工作记忆最优先直接查询working_resultself.working.get_relevant(query)# 2. 短期记忆取最近N条相关性recentself.short_term[-context_window:]# 3. 长期记忆向量检索long_term_resultsself.long_term.search(query,top_k3)# 4. LLM综合判断各层记忆的相关性和权重combinedself.llm.invoke(f 当前查询{query}各层记忆检索结果 - 工作记忆{working_result}- 短期记忆最近{context_window}条{recent}- 长期记忆{long_term_results}请评估各层记忆对当前查询的相关性0-1并给出最重要的一条记忆内容。 )return{working:working_result,short_term:recent,long_term:long_term_results,llm_judgment:combined}三、踩坑实录8个让我debug两天的问题踩坑1向量检索结果太多质量反而下降症状加了长期记忆后Agent回答质量反而下降了经常把不相关的信息混进来。原因向量检索返回了5条结果LLM注意力被分散而且越相关的结果排在越后面。实测数据检索返回条数LLM准确率响应token增加1条87.3%03条91.2%1805条83.7%35010条71.5%720解决方案检索后加一层重排序(Reranker)用更小的模型做相关性评分过滤掉低分结果。classSemanticMemory:带Reranker的语义记忆def__init__(self,vector_db,rerankerNone):self.vector_dbvector_db self.rerankerrerankerorDefaultReranker(threshold0.6)defsearch(self,query:str,top_k:int10,final_k:int3)-list:两阶段检索向量召回 → 重排序 → 精选# 第一阶段向量数据库召回多召回一些candidatesself.vector_db.query(query,n_resultstop_k)# 第二阶段重排序去掉不相关结果rerankedself.reranker.rerank(query,candidates)# 第三阶段取Top-K返回returnreranked[:final_k]经验值向量检索召回10条用Reranker过滤后保留2-3条效果最好。踩坑2短期记忆把对话历史全塞进去了症状对话进行到第30轮Agent开始卡顿第50轮直接超时。原因把整个对话历史都塞进LLM上下文上下文窗口被撑爆了。解决方案实现上下文压缩策略——定期对短期记忆做摘要classCompressedShortTermMemory:带压缩的短期记忆def__init__(self,max_messages:int20,compress_every:int10):self.max_messagesmax_messages self.compress_everycompress_every self.messages[]self.summaries[]# 被压缩掉的摘要defadd(self,role:str,content:str):self.messages.append({role:role,content:content})# 达到压缩阈值时触发iflen(self.messages)self.compress_every:self._compress()def_compress(self):压缩最近N条记忆生成摘要to_compressself.messages[:self.compress_every]self.messagesself.messages[self.compress_every:]summary_promptf 请将以下对话片段压缩为一条简洁摘要保留关键信息 对话{json.dumps(to_compress,ensure_asciiFalse,indent2)}摘要格式 【摘要】...不超过100字 【关键决策】... 【待跟进事项】... summaryself.llm.invoke(summary_prompt)self.summaries.append(summary)defget_context(self)-str:获取压缩后的上下文parts[]# 被压缩的摘要ifself.summaries:parts.append(f【前期摘要({len(self.summaries)}段)】\n\n.join(self.summaries))# 最近的完整对话parts.append(f【近期对话】\n\n.join(f{m[role]}:{m[content]}forminself.messages[-self.max_messages:]))return\n\n.join(parts)踩坑3向量数据库选型不当检索极慢症状每次检索耗时2-3秒用户体验极差。原因用了ChromaDB的默认配置数据量上来后性能断崖式下降。三大向量数据库实测对比100万向量768维数据库检索速度内存占用成本适用场景ChromaDB45ms8GB免费/开源100万向量、单机Qdrant12ms12GB开源/云100万-1亿向量Pinecone8ms托管按量付费企业级、高可用Milvus18ms16GB开源/云超大规模、分布式FAISS5ms9GB免费/开源极低延迟、单机经验10万向量以内ChromaDB够用做好索引配置10万-1000万Qdrant或Milvus1000万以上Pinecone或Milvus分布式# ChromaDB性能优化配置importchromadbfromchromadb.configimportSettings clientchromadb.Client(Settings(anonymized_telemetryFalse,# 关闭遥测allow_resetTrue,))collectionclient.create_collection(nameagent_memory,metadata{hnsw:space:cosine},# 余弦相似度get_or_createTrue)# 关键配置HNSW索引参数collection.modify(metadata{hnsw:construction_ef:200,# 构建精度越高越慢默认100hnsw:search_ef:200,# 搜索精度越高越准越慢hnsw:M:32# 内存/速度权衡默认16})# 经验值# 数据量10万默认配置即可# 数据量10-50万ef100, M16# 数据量50万ef200, M32踩坑4Agent不知道记忆检索什么时候该触发症状明明记忆里有相关信息Agent就是不检索。原因没有在prompt中明确指示Agent何时应该查记忆。解决方案在系统prompt中明确记忆使用规则SYSTEM_PROMPT 你是一个智能客服Agent。请遵循以下记忆使用规则 ## 记忆访问规则 **何时必须检索长期记忆** 1. 用户提到具体的订单号、工单号、账号时 → 先检索该用户的历史记录 2. 用户问之前那个问题或上次说的 → 检索最近相关记忆 3. 用户提到专业术语或缩写 → 检索是否有该用户的偏好设置 **如何解读记忆检索结果** - 如果检索结果confidence 0.8 → 直接使用 - 如果检索结果confidence 0.5-0.8 → 结合当前上下文判断 - 如果检索结果confidence 0.5 → 忽略以当前对话为准 **何时更新记忆** 1. 用户明确表达了偏好或需求 → 记录 2. 完成了一个完整任务 → 记录关键结论 3. 用户表示不满或问题未解决 → 记录为待跟进 ## 输出格式 当检索记忆后在回答开头标注 [记忆] 已检索到{条数}条相关记录主要内容{一句话摘要} 踩坑5记忆存储时没有去重重复内容堆积症状记忆库里同一个内容出现了几十份检索结果重复率高。原因Agent每次回复都存一遍没有做去重检查。解决方案存储前做语义去重classDedupMemory:带去重的记忆存储def__init__(self,base_memory,similarity_threshold0.95):self.basebase_memory self.similarity_thresholdsimilarity_threshold# 95%相似认为重复defadd(self,content:str,metadata:dict)-bool:添加记忆自动去重# 先检索是否有高度相似的内容existingself.base.search(content,top_k3)foriteminexisting:similaritycompute_similarity(content,item[content])ifsimilarityself.similarity_threshold:# 相似内容已存在更新元数据时间补充新标签self.base.update_metadata(item[id],{**item[metadata],last_referenced:datetime.now().isoformat()})returnFalse# 未新增# 没有重复正常存储self.base.add(content,metadata)returnTrue# 新增成功踩坑6不同用户之间记忆串了症状用户A的对话内容出现在了用户B的回复里。原因向量检索没有过滤用户ID所有用户的数据混在一起。解决方案元数据过滤是必须的# ❌ 错误没有用户过滤resultsvector_db.query(query_embeddings[query_emb],n_results5)# ✅ 正确必须带上用户过滤resultsvector_db.query(query_embeddings[query_emb],n_results5,where{user_id:current_user_id}# 关键只查当前用户的记忆)# ✅ 更严谨同时过滤用户ID和数据类型resultsvector_db.query(query_embeddings[query_emb],n_results5,where{$and:[{user_id:current_user_id},{data_type:{$in:[preference,history,feedback]}}]})踩坑7Agent学习了错误经验越用越差症状Agent学了一个错误的规则之后的行为都基于错误经验。原因记忆更新没有质量审核机制“学到就是对的”。解决方案记忆更新前加审核层classReviewedMemory:带审核的记忆系统defadd_with_review(self,experience:str,outcome:dict,llm)-bool:添加经验记忆必须通过审核reviewllm.invoke(f 请审核以下Agent经验决定是否值得存储为长期记忆。 经验{experience}执行结果{outcome}请从以下维度评分1-5分 1. 结果是否正确/正向 2. 这个经验是否可以泛化到其他场景 3. 是否有潜在风险学了之后可能导致错误行为 只有当三个维度都≥3分时才返回通过。 )if通过inreview:self.long_term.add(experience,{outcome:outcome,reviewed:True})returnTruereturnFalse踩坑8忘了给记忆加TTL过期数据堆积症状Agent检索到的记忆已经是两三年前的信息早就过时了。解决方案给记忆加生命周期classTTLEDMemory:带生命周期的记忆def__init__(self,vector_db):self.vector_dbvector_db self.default_ttl90*24*3600# 默认90天defadd(self,content:str,metadata:dict,ttl_days:int90):importtime expires_attime.time()ttl_days*24*3600self.vector_db.add(documents[content],metadatas[{**metadata,created_at:time.time(),expires_at:expires_at}])defsearch(self,query:str,**kwargs):resultsself.vector_db.query(query,**kwargs)# 过滤过期记忆current_timetime.time()valid_results[rforrinresults[documents]ifr.get(metadata,{}).get(expires_at,float(inf))current_time]returnvalid_results四、三层记忆综合配置模板根据不同场景给出配置建议场景短期记忆工作记忆长期记忆简单客服最近20条不需要用户画像偏好1万条复杂顾问最近50条摘要任务状态步骤经验库知识库10万条代码助手最近10条代码上下文项目知识库按仓库隔离数据分析会话历史查询状态数据字典指标定义五、总结记忆系统避坑清单DO一定要做✅ 检索后加Reranker过滤只保留高相关记忆✅ 短期记忆超过阈值就压缩不要无限制追加✅ 向量检索必须过滤user_id防止跨用户数据泄露✅ 记忆存储前做语义去重避免重复堆积✅ 给记忆加TTL定期清理过期数据DON’T千万避免❌ 不要把全部对话历史塞进LLM上下文❌ 不要检索后返回所有结果控制在3条以内❌ 不要让Agent无审核地学习任何经验❌ 不要忘记定期清理长期记忆中失效的信息❌ 不要在不同用户间共享记忆空间下篇文章预告「Agent规划系统深度拆解从简单规划到自反思的演进路径」——没有规划能力的Agent和鹦鹉有什么区别ReAct、Plan-and-Execute、Self-Reflection三种规划模式的实战对比。需要完整三层记忆系统代码和向量数据库配置模板的同学可以看我主页的付费资源专栏。有问题欢迎评论区留言大家一起讨论
AI Agent开发实战④｜记忆不只是向量数据库：Agent三层记忆架构设计与8个踩坑实录
AI Agent开发实战④记忆不只是向量数据库Agent三层记忆架构设计与8个踩坑实录加了向量数据库Agent反而更差了刚查过的内容转头就忘越用越慢卡在记忆检索上这些问题我都踩过。本文讲透三层记忆的设计逻辑以及8个让我debug了整整两天的实际踩坑。一、先搞清楚一个问题为什么Agent记不住一个真实的崩溃时刻项目里的客服Agent上午用户说我的工单号是WO-20240615-001下午Agent完全忘了这回事。用户再问一次Agent还是问请提供工单号。开发者第一反应是向量数据库没起作用。但检查日志发现检索结果是有的——问题出在Agent选择忽略检索到的记忆。这不是向量数据库的问题是三层记忆的协作机制设计错了。先搞清楚三层记忆各自负责什么┌─────────────────────────────────────────────┐ │ 长期记忆 (Long-term Memory) │ │ 存储历史任务经验、知识库、沉淀的通用规则 │ │ 介质向量数据库ChromaDB/Pinecone │ │ 特点持久化、跨会话、检索触发 │ ├─────────────────────────────────────────────┤ │ 短期记忆 (Short-term Memory) │ │ 存储当前会话的所有对话历史 │ │ 介质内存/LLM上下文 │ │ 特点按会话隔离、会话结束清空 │ ├─────────────────────────────────────────────┤ │ 工作记忆 (Working Memory) │ │ 存储当前任务的中间状态、执行步骤、待决策项 │ │ 介质程序变量 │ │ 特点最实时、仅当前任务可见 │ └─────────────────────────────────────────────┘二、三层记忆的协作机制三层不是简单的堆叠是有明确协作规则的classThreeLayerMemory:Agent三层记忆系统def__init__(self,vector_db,llm):self.long_termVectorMemory(vector_db)# 长期记忆self.short_term[]# 短期记忆当前会话self.workingWorkingMemory()# 工作记忆当前任务self.llmllmdefstore(self,content:str,memory_type:str,**metadata):存储记忆——自动路由到正确的层ifmemory_typesession:# 短期记忆直接追加self.short_term.append({role:metadata.get(role,user),content:content,timestamp:datetime.now().isoformat()})elifmemory_typetask:# 工作记忆覆盖同名keyself.working.set(metadata.get(task_id),content,metadata)elifmemory_typeexperience:# 长期记忆向量嵌入后存储self.long_term.add(content,metadata)defretrieve(self,query:str,context_window:int5)-dict:检索记忆——三层各有分工# 1. 工作记忆最优先直接查询working_resultself.working.get_relevant(query)# 2. 短期记忆取最近N条相关性recentself.short_term[-context_window:]# 3. 长期记忆向量检索long_term_resultsself.long_term.search(query,top_k3)# 4. LLM综合判断各层记忆的相关性和权重combinedself.llm.invoke(f 当前查询{query}各层记忆检索结果 - 工作记忆{working_result}- 短期记忆最近{context_window}条{recent}- 长期记忆{long_term_results}请评估各层记忆对当前查询的相关性0-1并给出最重要的一条记忆内容。 )return{working:working_result,short_term:recent,long_term:long_term_results,llm_judgment:combined}三、踩坑实录8个让我debug两天的问题踩坑1向量检索结果太多质量反而下降症状加了长期记忆后Agent回答质量反而下降了经常把不相关的信息混进来。原因向量检索返回了5条结果LLM注意力被分散而且越相关的结果排在越后面。实测数据检索返回条数LLM准确率响应token增加1条87.3%03条91.2%1805条83.7%35010条71.5%720解决方案检索后加一层重排序(Reranker)用更小的模型做相关性评分过滤掉低分结果。classSemanticMemory:带Reranker的语义记忆def__init__(self,vector_db,rerankerNone):self.vector_dbvector_db self.rerankerrerankerorDefaultReranker(threshold0.6)defsearch(self,query:str,top_k:int10,final_k:int3)-list:两阶段检索向量召回 → 重排序 → 精选# 第一阶段向量数据库召回多召回一些candidatesself.vector_db.query(query,n_resultstop_k)# 第二阶段重排序去掉不相关结果rerankedself.reranker.rerank(query,candidates)# 第三阶段取Top-K返回returnreranked[:final_k]经验值向量检索召回10条用Reranker过滤后保留2-3条效果最好。踩坑2短期记忆把对话历史全塞进去了症状对话进行到第30轮Agent开始卡顿第50轮直接超时。原因把整个对话历史都塞进LLM上下文上下文窗口被撑爆了。解决方案实现上下文压缩策略——定期对短期记忆做摘要classCompressedShortTermMemory:带压缩的短期记忆def__init__(self,max_messages:int20,compress_every:int10):self.max_messagesmax_messages self.compress_everycompress_every self.messages[]self.summaries[]# 被压缩掉的摘要defadd(self,role:str,content:str):self.messages.append({role:role,content:content})# 达到压缩阈值时触发iflen(self.messages)self.compress_every:self._compress()def_compress(self):压缩最近N条记忆生成摘要to_compressself.messages[:self.compress_every]self.messagesself.messages[self.compress_every:]summary_promptf 请将以下对话片段压缩为一条简洁摘要保留关键信息 对话{json.dumps(to_compress,ensure_asciiFalse,indent2)}摘要格式 【摘要】...不超过100字 【关键决策】... 【待跟进事项】... summaryself.llm.invoke(summary_prompt)self.summaries.append(summary)defget_context(self)-str:获取压缩后的上下文parts[]# 被压缩的摘要ifself.summaries:parts.append(f【前期摘要({len(self.summaries)}段)】\n\n.join(self.summaries))# 最近的完整对话parts.append(f【近期对话】\n\n.join(f{m[role]}:{m[content]}forminself.messages[-self.max_messages:]))return\n\n.join(parts)踩坑3向量数据库选型不当检索极慢症状每次检索耗时2-3秒用户体验极差。原因用了ChromaDB的默认配置数据量上来后性能断崖式下降。三大向量数据库实测对比100万向量768维数据库检索速度内存占用成本适用场景ChromaDB45ms8GB免费/开源100万向量、单机Qdrant12ms12GB开源/云100万-1亿向量Pinecone8ms托管按量付费企业级、高可用Milvus18ms16GB开源/云超大规模、分布式FAISS5ms9GB免费/开源极低延迟、单机经验10万向量以内ChromaDB够用做好索引配置10万-1000万Qdrant或Milvus1000万以上Pinecone或Milvus分布式# ChromaDB性能优化配置importchromadbfromchromadb.configimportSettings clientchromadb.Client(Settings(anonymized_telemetryFalse,# 关闭遥测allow_resetTrue,))collectionclient.create_collection(nameagent_memory,metadata{hnsw:space:cosine},# 余弦相似度get_or_createTrue)# 关键配置HNSW索引参数collection.modify(metadata{hnsw:construction_ef:200,# 构建精度越高越慢默认100hnsw:search_ef:200,# 搜索精度越高越准越慢hnsw:M:32# 内存/速度权衡默认16})# 经验值# 数据量10万默认配置即可# 数据量10-50万ef100, M16# 数据量50万ef200, M32踩坑4Agent不知道记忆检索什么时候该触发症状明明记忆里有相关信息Agent就是不检索。原因没有在prompt中明确指示Agent何时应该查记忆。解决方案在系统prompt中明确记忆使用规则SYSTEM_PROMPT 你是一个智能客服Agent。请遵循以下记忆使用规则 ## 记忆访问规则 **何时必须检索长期记忆** 1. 用户提到具体的订单号、工单号、账号时 → 先检索该用户的历史记录 2. 用户问之前那个问题或上次说的 → 检索最近相关记忆 3. 用户提到专业术语或缩写 → 检索是否有该用户的偏好设置 **如何解读记忆检索结果** - 如果检索结果confidence 0.8 → 直接使用 - 如果检索结果confidence 0.5-0.8 → 结合当前上下文判断 - 如果检索结果confidence 0.5 → 忽略以当前对话为准 **何时更新记忆** 1. 用户明确表达了偏好或需求 → 记录 2. 完成了一个完整任务 → 记录关键结论 3. 用户表示不满或问题未解决 → 记录为待跟进 ## 输出格式 当检索记忆后在回答开头标注 [记忆] 已检索到{条数}条相关记录主要内容{一句话摘要} 踩坑5记忆存储时没有去重重复内容堆积症状记忆库里同一个内容出现了几十份检索结果重复率高。原因Agent每次回复都存一遍没有做去重检查。解决方案存储前做语义去重classDedupMemory:带去重的记忆存储def__init__(self,base_memory,similarity_threshold0.95):self.basebase_memory self.similarity_thresholdsimilarity_threshold# 95%相似认为重复defadd(self,content:str,metadata:dict)-bool:添加记忆自动去重# 先检索是否有高度相似的内容existingself.base.search(content,top_k3)foriteminexisting:similaritycompute_similarity(content,item[content])ifsimilarityself.similarity_threshold:# 相似内容已存在更新元数据时间补充新标签self.base.update_metadata(item[id],{**item[metadata],last_referenced:datetime.now().isoformat()})returnFalse# 未新增# 没有重复正常存储self.base.add(content,metadata)returnTrue# 新增成功踩坑6不同用户之间记忆串了症状用户A的对话内容出现在了用户B的回复里。原因向量检索没有过滤用户ID所有用户的数据混在一起。解决方案元数据过滤是必须的# ❌ 错误没有用户过滤resultsvector_db.query(query_embeddings[query_emb],n_results5)# ✅ 正确必须带上用户过滤resultsvector_db.query(query_embeddings[query_emb],n_results5,where{user_id:current_user_id}# 关键只查当前用户的记忆)# ✅ 更严谨同时过滤用户ID和数据类型resultsvector_db.query(query_embeddings[query_emb],n_results5,where{$and:[{user_id:current_user_id},{data_type:{$in:[preference,history,feedback]}}]})踩坑7Agent学习了错误经验越用越差症状Agent学了一个错误的规则之后的行为都基于错误经验。原因记忆更新没有质量审核机制“学到就是对的”。解决方案记忆更新前加审核层classReviewedMemory:带审核的记忆系统defadd_with_review(self,experience:str,outcome:dict,llm)-bool:添加经验记忆必须通过审核reviewllm.invoke(f 请审核以下Agent经验决定是否值得存储为长期记忆。 经验{experience}执行结果{outcome}请从以下维度评分1-5分 1. 结果是否正确/正向 2. 这个经验是否可以泛化到其他场景 3. 是否有潜在风险学了之后可能导致错误行为 只有当三个维度都≥3分时才返回通过。 )if通过inreview:self.long_term.add(experience,{outcome:outcome,reviewed:True})returnTruereturnFalse踩坑8忘了给记忆加TTL过期数据堆积症状Agent检索到的记忆已经是两三年前的信息早就过时了。解决方案给记忆加生命周期classTTLEDMemory:带生命周期的记忆def__init__(self,vector_db):self.vector_dbvector_db self.default_ttl90*24*3600# 默认90天defadd(self,content:str,metadata:dict,ttl_days:int90):importtime expires_attime.time()ttl_days*24*3600self.vector_db.add(documents[content],metadatas[{**metadata,created_at:time.time(),expires_at:expires_at}])defsearch(self,query:str,**kwargs):resultsself.vector_db.query(query,**kwargs)# 过滤过期记忆current_timetime.time()valid_results[rforrinresults[documents]ifr.get(metadata,{}).get(expires_at,float(inf))current_time]returnvalid_results四、三层记忆综合配置模板根据不同场景给出配置建议场景短期记忆工作记忆长期记忆简单客服最近20条不需要用户画像偏好1万条复杂顾问最近50条摘要任务状态步骤经验库知识库10万条代码助手最近10条代码上下文项目知识库按仓库隔离数据分析会话历史查询状态数据字典指标定义五、总结记忆系统避坑清单DO一定要做✅ 检索后加Reranker过滤只保留高相关记忆✅ 短期记忆超过阈值就压缩不要无限制追加✅ 向量检索必须过滤user_id防止跨用户数据泄露✅ 记忆存储前做语义去重避免重复堆积✅ 给记忆加TTL定期清理过期数据DON’T千万避免❌ 不要把全部对话历史塞进LLM上下文❌ 不要检索后返回所有结果控制在3条以内❌ 不要让Agent无审核地学习任何经验❌ 不要忘记定期清理长期记忆中失效的信息❌ 不要在不同用户间共享记忆空间下篇文章预告「Agent规划系统深度拆解从简单规划到自反思的演进路径」——没有规划能力的Agent和鹦鹉有什么区别ReAct、Plan-and-Execute、Self-Reflection三种规划模式的实战对比。需要完整三层记忆系统代码和向量数据库配置模板的同学可以看我主页的付费资源专栏。有问题欢迎评论区留言大家一起讨论
