1. 为什么“更大的上下文窗口”是个伪命题先把结论摆在前面上下文窗口的物理扩容和 Agent 真正“记住事情”之间没有必然关系。我见过太多团队在选型会上拍板“等模型支持 1M token 就好了”结果窗口从 128K 涨到 1MAgent 该忘的还是忘该串的还是串。这不是模型不行是架构思路从一开始就跑偏了。1.1 上下文窗口到底解决了什么问题上下文窗口本质上是模型的工作内存类比一下就是电脑的内存条。你往里面塞多少东西模型在一次推理里就能“看到”多少东西。窗口越大单次能塞进去的原始信息越多这没错。但问题在于三个层面注意力稀释塞进去 50 万字模型对中间部分的召回率会明显下降。业界常说的“lost in the middle”现象就是长上下文里中段信息被忽略。你塞得越多关键信息被淹没的概率越高。成本线性上涨token 是要花钱的。每次对话都把全部历史塞进去输入 token 随轮次线性增长一个跑了几十轮的 Agent单次调用成本能翻十几倍。延迟不可控输入越长首 token 延迟越高。做实时交互的 Agent用户等三秒就开始骂了。所以“更大的上下文窗口”解决的是单次能看多少而 Agent 记忆系统要解决的是该看什么、什么时候看、看完怎么存。这是两个完全不同的问题。1.2 记忆系统的本质不是存储是检索与调度我个人的理解是Agent 记忆系统的核心不是“存”而是在正确的时机把正确的信息以正确的形式喂给模型。存储只是手段检索和调度才是灵魂。打个比方上下文窗口是你的办公桌桌面记忆系统是你的文件柜加秘书。桌面再大你也不可能把所有文件都摊在桌上干活真正高效的做法是秘书根据你当前的任务从文件柜里抽出相关的几页递给你。桌面大小窗口重要但秘书的检索能力记忆系统才是决定效率的关键。MemGPT、Mem0 这些方案之所以火就是因为它们把“秘书”这个角色工程化了。MemGPT 借鉴操作系统的内存分页思想把上下文当“内存”、外部存储当“硬盘”通过函数调用在两者之间搬运信息Mem0 则更聚焦于从对话中自动抽取、去重、更新事实性记忆。两者思路不同但都在回答同一个问题怎么让 Agent 拥有跨会话、跨任务的长期记忆。1.3 一个反直觉的实测结论我做过一组对比测试同一个客服 Agent任务是多轮售后咨询方案上下文策略任务完成率平均单轮 token平均响应延迟方案 A全量历史塞入 128K 窗口71%86004.2s方案 B摘要 向量检索 Top589%21001.8s方案 CMem0 事实抽取 检索93%19001.6s方案 A 用的窗口最大效果反而最差。原因很直接全量历史里充斥着寒暄、重复确认、无关闲聊真正有用的信息订单号、故障现象、用户偏好被稀释了。方案 B 和 C 通过检索把噪声过滤掉模型注意力集中在关键事实上完成率和延迟都更好。提示如果你现在的 Agent 还在用“把历史全塞进去”的策略先别急着换更大的模型先把检索层做起来收益比换模型大得多。2. 记忆系统的四层架构拆解聊完为什么进入正题一个能打的 Agent 记忆系统我习惯把它拆成四层。这个分层不是教科书上的标准答案是我在几个项目里反复调整后觉得最顺手的划分方式。2.1 第一层工作记忆Working Memory工作记忆就是当前这一轮推理直接用到的东西对应上下文窗口里的内容。它的设计要点是精简和结构化。我的做法是把工作记忆分成三个固定区块系统指令区角色设定、工具定义、输出格式约束。这部分基本不变放在最前面。任务状态区当前任务的进度、已完成的步骤、待办事项。这是 Agent 的“短期目标感”来源。检索上下文区从长期记忆里检索出来的相关片段按相关度排序控制在 3-5 条。关键技巧是给每个区块设 token 预算。比如总窗口 32K系统指令占 2K任务状态占 3K检索上下文占 8K剩下的留给对话历史和模型输出。预算一旦定死检索层就知道自己最多能返回多少内容不会失控。2.2 第二层短期记忆Short-term Memory短期记忆是当前会话内的历史但不是原样保留。我的策略是滑动窗口加摘要压缩最近 N 轮对话保留原文保证细节不丢。超出 N 轮的部分用一个小模型做滚动摘要把摘要结果作为一条“会话纪要”插入历史。摘要的 prompt 要明确要求保留实体人名、订单号、时间、决策用户确认了什么、未决问题。这里有个坑摘要模型不能太弱。我试过用 7B 小模型做摘要结果它把“用户说不要红色”摘要成“用户提到了颜色”关键否定信息丢了后面 Agent 就推了红色。摘要模型至少要和主模型同代或者用规则小模型混合。2.3 第三层长期记忆Long-term Memory长期记忆是跨会话的也是 Mem0 这类方案的主战场。它要解决的是“这个用户上次说过什么、偏好是什么、历史问题是什么”。长期记忆的存储我一般分两类事实型记忆用户画像、偏好、关键实体。这类用结构化存储KV 或关系表更合适检索快、更新方便。经验型记忆历史对话片段、解决方案、案例。这类用向量库存储靠语义检索召回。Mem0 的聪明之处在于它做了一层记忆抽取和冲突消解。比如用户先说“我住在北京”后来说“我搬到上海了”Mem0 会更新而不是简单追加。这个能力自己实现也不难核心是抽取时带上“操作类型”新增/更新/删除的判断。2.4 第四层记忆调度器Memory Orchestrator这一层最容易被忽略但我觉得它才是记忆系统的“大脑”。调度器决定当前这轮推理该从哪些记忆层取什么、取多少、以什么优先级拼进上下文。我的调度器逻辑大致是这样解析当前用户输入提取查询意图和关键实体。并行发起检索向量库语义检索 结构化记忆精确匹配 会话摘要召回。对召回结果做重排序可以用 cross-encoder 或简单的规则打分。按 token 预算裁剪拼装进工作记忆的检索上下文区。推理结束后判断本轮是否产生新的长期记忆触发写入。这个调度器用 LangGraph 或自己写状态机都行关键是把检索和推理解耦不要让模型自己去决定“要不要查记忆”而是由调度器在推理前就准备好。3. 核心组件选型与参数实操架构讲完落地时每个组件怎么选、参数怎么调才是真正花时间的地方。这部分我按组件拆开讲都是踩过坑之后的经验值。3.1 向量库选型别一上来就上重型方案向量库的选择我见过两种极端一种是无脑上 Milvus 集群一种是用 FAISS 硬扛生产。都不太对。我的选型逻辑是按数据量和并发来场景数据量推荐方案理由原型验证 10万条FAISS / Chroma零运维本地跑够用中小生产10万-500万Qdrant / Weaviate单机可扛支持过滤运维简单大规模 500万Milvus / Pgvector 分片需要分布式和水平扩展我个人的偏好是Qdrant原因是它的过滤检索做得好。Agent 记忆检索经常要带条件比如“只查这个用户的记忆”“只查最近30天的”纯向量相似度不够必须结合元数据过滤。Qdrant 的 payload filter 在这个场景下很顺手。参数上embedding 维度我一般用 1024 或 1536HNSW 的m设 16、ef_construct设 100 是通用起点。检索时ef设 64-128召回率和延迟比较平衡。这些值不是死的数据量大了要往上调。3.2 记忆抽取什么时候写、写什么记忆抽取的触发时机有两种每轮都抽和会话结束时抽。我倾向每轮都抽但加个轻量判断。每轮都抽的好处是实时性好用户刚说完偏好下一轮就能用上。坏处是调用频繁、成本高。我的优化是先用规则过滤如果这轮对话没有出现新实体、没有否定词、没有明确偏好表达就跳过抽取。规则命中率大概能过滤掉 40% 的无效轮次。抽取的 prompt 我固定要求输出 JSON字段包括{ should_remember: true, memory_type: fact, content: 用户偏好顺丰快递, entities: [快递, 顺丰], operation: add, confidence: 0.92 }operation字段是关键取值 add/update/delete。有了它写入时才能做冲突消解。confidence低于 0.7 的我直接丢弃避免噪声污染记忆库。3.3 检索策略混合检索比纯向量稳纯向量检索在 Agent 记忆场景下有个明显问题对精确匹配不敏感。用户问“我的订单 A12345 到哪了”向量检索可能召回一堆“订单相关”的泛泛内容但真正要的是那个精确订单号。所以我的检索策略是混合检索向量检索负责语义相似召回 Top 20。关键词检索BM25 或简单的倒排负责精确匹配召回 Top 10。两路结果合并去重再用重排序模型打分取 Top 5。重排序模型我用的是 bge-reranker 系列本地部署延迟增加 50ms 左右但召回准确率提升明显。如果不想加重排序用 RRFReciprocal Rank Fusion做简单融合也行效果比单路好。3.4 上下文拼装顺序和格式都有讲究检索出来的记忆片段怎么拼进 prompt直接影响模型的使用效果。我的经验是相关度高的放前面因为模型对开头和结尾的注意力更强。每条记忆加来源标注比如[用户偏好] 用户偏好顺丰快递让模型知道这是什么类型的信息。控制条数3-5 条足够多了反而干扰。加时间戳尤其是事实型记忆模型需要知道信息的时效性。一个拼装示例[相关记忆] 1. [偏好, 2024-05-10] 用户偏好顺丰快递不接受其他快递。 2. [历史问题, 2024-05-08] 用户上次反馈订单 A12345 物流延迟已补偿优惠券。 3. [实体, 2024-05-10] 当前咨询订单号 A12345。这种结构化格式模型理解起来比一堆自然语言段落高效得多。4. 常见问题与排查实录记忆系统上线后问题往往不是“不工作”而是“工作得不对”。我整理了几个高频问题和排查思路。4.1 记忆污染错误信息被反复强化现象Agent 反复提到一个用户从没说过的偏好。排查先查记忆库看这条错误记忆是什么时候、从哪轮对话抽取的。大概率是抽取模型把模型的推测当成了用户事实。解决抽取 prompt 里明确要求“只抽取用户明确表达的信息不要抽取你的推测”。另外写入时加一个二次校验用另一个模型判断这条记忆是否真的来自用户原话。这个校验成本不高但能挡掉大部分污染。4.2 检索召回率低明明存了却查不到现象用户问之前提过的事Agent 说不知道。排查分三步。第一确认记忆确实写入了查库。第二用同样的 query 手动跑检索看召回结果。第三检查 embedding 模型是否一致——写入和检索用了不同的 embedding 模型是新手常犯的错。解决如果 embedding 一致但召回差考虑换 embedding 模型或加混合检索。如果 query 太短比如“那个呢”需要做 query 改写结合对话历史补全语义再检索。4.3 延迟飙升检索拖慢了整体响应现象加了记忆系统后Agent 响应从 1.5s 涨到 5s。排查打点看各阶段耗时。常见瓶颈是向量检索和重排序。解决向量检索加缓存相同 query 短时间内直接返回缓存结果。重排序改成异步或批量不要每条记忆单独打分。检索和推理并行在模型开始生成的同时就发起检索等模型需要时结果已经就绪。4.4 记忆膨胀库越来越大检索越来越慢现象跑了一个月记忆库几十万条检索延迟明显上升。排查看记忆的重复率和过期率。解决写入时做去重相似度超过 0.95 的直接合并。给记忆加 TTL事实型记忆设长一点比如 90 天临时性记忆设短一点7 天。定期做记忆压缩把同一主题的多条记忆合并成一条摘要。下面这张表可以贴在工位上当速查问题首要排查点快速修复记忆污染抽取来源加二次校验召回率低embedding 一致性统一模型 混合检索延迟高检索耗时缓存 并行记忆膨胀重复率去重 TTL上下文超限token 预算裁剪 摘要5. 从零搭一个最小可用记忆系统理论说再多不如动手搭一个。这部分我给一个最小可用的实现路径用 Python Qdrant 一个 LLM API 就能跑起来。5.1 环境与依赖pip install qdrant-client openai tiktokenQdrant 用 Docker 起一个单机版就够docker run -p 6333:6333 qdrant/qdrant5.2 记忆写入流程核心就三步抽取、判断操作、写入。def extract_memory(dialogue): prompt f从以下对话中抽取值得长期记住的信息输出JSON 对话{dialogue} 要求只抽取用户明确表达的事实、偏好、实体。 输出格式{{should_remember: bool, content: str, operation: add/update/delete, confidence: float}} result llm_call(prompt) return json.loads(result) def write_memory(memory, user_id): if not memory[should_remember] or memory[confidence] 0.7: return vector embed(memory[content]) if memory[operation] add: client.upsert(collection, points[{ id: gen_id(), vector: vector, payload: {user_id: user_id, content: memory[content], ts: now()} }]) elif memory[operation] update: # 先检索相似记忆再更新 similar search_similar(memory[content], user_id) if similar: client.set_payload(collection, payload{content: memory[content]}, points[similar[0].id])5.3 记忆检索与拼装def retrieve_and_build(query, user_id, token_budget2000): vector embed(query) hits client.search(collection, query_vectorvector, query_filter{must: [{key: user_id, match: {value: user_id}}]}, limit10) # 按 token 预算裁剪 memories [] used 0 for hit in hits: text f[{hit.payload[type]}] {hit.payload[content]} tokens count_tokens(text) if used tokens token_budget: break memories.append(text) used tokens return \n.join(memories)5.4 接入 Agent 主循环def agent_step(user_input, user_id, history): memory_context retrieve_and_build(user_input, user_id) prompt f你是客服助手。 [相关记忆] {memory_context} [对话历史] {history} [用户输入] {user_input} response llm_call(prompt) # 异步写入记忆不阻塞响应 async_write_memory(user_input response, user_id) return response这套代码不到 100 行但已经具备了记忆系统的核心能力抽取、存储、检索、拼装。生产环境要加的东西包括错误重试、并发控制、监控打点、记忆去重但骨架就是这个。注意async_write_memory一定要异步否则每轮都等写入完成延迟会很难看。写入失败也不要影响主流程记日志后续补偿即可。6. 几个容易踩的认知误区最后聊几个我在和同行交流时反复听到的误区这些认知偏差比技术问题更耽误事。6.1 误区一记忆越多越好不是。记忆系统的价值在于信噪比不在于绝对数量。存了一万条记忆检索出来五条全是噪声还不如只存一百条精准的。我见过团队为了“显得记忆能力强”把所有对话都存进去结果检索质量一塌糊涂。宁缺毋滥是记忆系统的第一原则。6.2 误区二记忆系统可以完全自动完全自动的记忆抽取和更新目前还做不到生产级可靠。我的做法是自动为主人工兜底关键记忆比如用户身份、金额相关加人工审核队列普通记忆自动处理。另外提供记忆管理界面让运营能手动修正错误记忆。这个投入是值得的因为一条错误记忆可能影响后续几十轮对话。6.3 误区三换更强的模型就能解决记忆问题模型能力提升确实能改善记忆的使用效果但解决不了存储和检索的问题。模型再强你不在 prompt 里给它相关信息它也变不出来。记忆系统的工程投入和模型选型是两条独立的优化路径不能互相替代。6.4 误区四记忆系统一次搭好就不用管记忆系统是活的。用户的偏好会变业务的知识会更新记忆的分布会漂移。我建议至少每月做一次记忆质量审计抽样检查记忆准确率、检索召回率、过期记忆占比。发现指标下降就及时调整抽取 prompt 或检索策略。把它当成一个需要持续运营的系统而不是一次性的工程交付。我个人在实际项目里的体会是记忆系统带来的效果提升往往比换一个更大的模型更明显成本也更低。一个精心设计的检索层配合适度的上下文预算能让一个中等规模的模型跑出接近大模型的效果。这个投入产出比值得每个做 Agent 的团队认真对待。
1. 为什么“更大的上下文窗口”是个伪命题先把结论摆在前面上下文窗口的物理扩容和 Agent 真正“记住事情”之间没有必然关系。我见过太多团队在选型会上拍板“等模型支持 1M token 就好了”结果窗口从 128K 涨到 1MAgent 该忘的还是忘该串的还是串。这不是模型不行是架构思路从一开始就跑偏了。1.1 上下文窗口到底解决了什么问题上下文窗口本质上是模型的工作内存类比一下就是电脑的内存条。你往里面塞多少东西模型在一次推理里就能“看到”多少东西。窗口越大单次能塞进去的原始信息越多这没错。但问题在于三个层面注意力稀释塞进去 50 万字模型对中间部分的召回率会明显下降。业界常说的“lost in the middle”现象就是长上下文里中段信息被忽略。你塞得越多关键信息被淹没的概率越高。成本线性上涨token 是要花钱的。每次对话都把全部历史塞进去输入 token 随轮次线性增长一个跑了几十轮的 Agent单次调用成本能翻十几倍。延迟不可控输入越长首 token 延迟越高。做实时交互的 Agent用户等三秒就开始骂了。所以“更大的上下文窗口”解决的是单次能看多少而 Agent 记忆系统要解决的是该看什么、什么时候看、看完怎么存。这是两个完全不同的问题。1.2 记忆系统的本质不是存储是检索与调度我个人的理解是Agent 记忆系统的核心不是“存”而是在正确的时机把正确的信息以正确的形式喂给模型。存储只是手段检索和调度才是灵魂。打个比方上下文窗口是你的办公桌桌面记忆系统是你的文件柜加秘书。桌面再大你也不可能把所有文件都摊在桌上干活真正高效的做法是秘书根据你当前的任务从文件柜里抽出相关的几页递给你。桌面大小窗口重要但秘书的检索能力记忆系统才是决定效率的关键。MemGPT、Mem0 这些方案之所以火就是因为它们把“秘书”这个角色工程化了。MemGPT 借鉴操作系统的内存分页思想把上下文当“内存”、外部存储当“硬盘”通过函数调用在两者之间搬运信息Mem0 则更聚焦于从对话中自动抽取、去重、更新事实性记忆。两者思路不同但都在回答同一个问题怎么让 Agent 拥有跨会话、跨任务的长期记忆。1.3 一个反直觉的实测结论我做过一组对比测试同一个客服 Agent任务是多轮售后咨询方案上下文策略任务完成率平均单轮 token平均响应延迟方案 A全量历史塞入 128K 窗口71%86004.2s方案 B摘要 向量检索 Top589%21001.8s方案 CMem0 事实抽取 检索93%19001.6s方案 A 用的窗口最大效果反而最差。原因很直接全量历史里充斥着寒暄、重复确认、无关闲聊真正有用的信息订单号、故障现象、用户偏好被稀释了。方案 B 和 C 通过检索把噪声过滤掉模型注意力集中在关键事实上完成率和延迟都更好。提示如果你现在的 Agent 还在用“把历史全塞进去”的策略先别急着换更大的模型先把检索层做起来收益比换模型大得多。2. 记忆系统的四层架构拆解聊完为什么进入正题一个能打的 Agent 记忆系统我习惯把它拆成四层。这个分层不是教科书上的标准答案是我在几个项目里反复调整后觉得最顺手的划分方式。2.1 第一层工作记忆Working Memory工作记忆就是当前这一轮推理直接用到的东西对应上下文窗口里的内容。它的设计要点是精简和结构化。我的做法是把工作记忆分成三个固定区块系统指令区角色设定、工具定义、输出格式约束。这部分基本不变放在最前面。任务状态区当前任务的进度、已完成的步骤、待办事项。这是 Agent 的“短期目标感”来源。检索上下文区从长期记忆里检索出来的相关片段按相关度排序控制在 3-5 条。关键技巧是给每个区块设 token 预算。比如总窗口 32K系统指令占 2K任务状态占 3K检索上下文占 8K剩下的留给对话历史和模型输出。预算一旦定死检索层就知道自己最多能返回多少内容不会失控。2.2 第二层短期记忆Short-term Memory短期记忆是当前会话内的历史但不是原样保留。我的策略是滑动窗口加摘要压缩最近 N 轮对话保留原文保证细节不丢。超出 N 轮的部分用一个小模型做滚动摘要把摘要结果作为一条“会话纪要”插入历史。摘要的 prompt 要明确要求保留实体人名、订单号、时间、决策用户确认了什么、未决问题。这里有个坑摘要模型不能太弱。我试过用 7B 小模型做摘要结果它把“用户说不要红色”摘要成“用户提到了颜色”关键否定信息丢了后面 Agent 就推了红色。摘要模型至少要和主模型同代或者用规则小模型混合。2.3 第三层长期记忆Long-term Memory长期记忆是跨会话的也是 Mem0 这类方案的主战场。它要解决的是“这个用户上次说过什么、偏好是什么、历史问题是什么”。长期记忆的存储我一般分两类事实型记忆用户画像、偏好、关键实体。这类用结构化存储KV 或关系表更合适检索快、更新方便。经验型记忆历史对话片段、解决方案、案例。这类用向量库存储靠语义检索召回。Mem0 的聪明之处在于它做了一层记忆抽取和冲突消解。比如用户先说“我住在北京”后来说“我搬到上海了”Mem0 会更新而不是简单追加。这个能力自己实现也不难核心是抽取时带上“操作类型”新增/更新/删除的判断。2.4 第四层记忆调度器Memory Orchestrator这一层最容易被忽略但我觉得它才是记忆系统的“大脑”。调度器决定当前这轮推理该从哪些记忆层取什么、取多少、以什么优先级拼进上下文。我的调度器逻辑大致是这样解析当前用户输入提取查询意图和关键实体。并行发起检索向量库语义检索 结构化记忆精确匹配 会话摘要召回。对召回结果做重排序可以用 cross-encoder 或简单的规则打分。按 token 预算裁剪拼装进工作记忆的检索上下文区。推理结束后判断本轮是否产生新的长期记忆触发写入。这个调度器用 LangGraph 或自己写状态机都行关键是把检索和推理解耦不要让模型自己去决定“要不要查记忆”而是由调度器在推理前就准备好。3. 核心组件选型与参数实操架构讲完落地时每个组件怎么选、参数怎么调才是真正花时间的地方。这部分我按组件拆开讲都是踩过坑之后的经验值。3.1 向量库选型别一上来就上重型方案向量库的选择我见过两种极端一种是无脑上 Milvus 集群一种是用 FAISS 硬扛生产。都不太对。我的选型逻辑是按数据量和并发来场景数据量推荐方案理由原型验证 10万条FAISS / Chroma零运维本地跑够用中小生产10万-500万Qdrant / Weaviate单机可扛支持过滤运维简单大规模 500万Milvus / Pgvector 分片需要分布式和水平扩展我个人的偏好是Qdrant原因是它的过滤检索做得好。Agent 记忆检索经常要带条件比如“只查这个用户的记忆”“只查最近30天的”纯向量相似度不够必须结合元数据过滤。Qdrant 的 payload filter 在这个场景下很顺手。参数上embedding 维度我一般用 1024 或 1536HNSW 的m设 16、ef_construct设 100 是通用起点。检索时ef设 64-128召回率和延迟比较平衡。这些值不是死的数据量大了要往上调。3.2 记忆抽取什么时候写、写什么记忆抽取的触发时机有两种每轮都抽和会话结束时抽。我倾向每轮都抽但加个轻量判断。每轮都抽的好处是实时性好用户刚说完偏好下一轮就能用上。坏处是调用频繁、成本高。我的优化是先用规则过滤如果这轮对话没有出现新实体、没有否定词、没有明确偏好表达就跳过抽取。规则命中率大概能过滤掉 40% 的无效轮次。抽取的 prompt 我固定要求输出 JSON字段包括{ should_remember: true, memory_type: fact, content: 用户偏好顺丰快递, entities: [快递, 顺丰], operation: add, confidence: 0.92 }operation字段是关键取值 add/update/delete。有了它写入时才能做冲突消解。confidence低于 0.7 的我直接丢弃避免噪声污染记忆库。3.3 检索策略混合检索比纯向量稳纯向量检索在 Agent 记忆场景下有个明显问题对精确匹配不敏感。用户问“我的订单 A12345 到哪了”向量检索可能召回一堆“订单相关”的泛泛内容但真正要的是那个精确订单号。所以我的检索策略是混合检索向量检索负责语义相似召回 Top 20。关键词检索BM25 或简单的倒排负责精确匹配召回 Top 10。两路结果合并去重再用重排序模型打分取 Top 5。重排序模型我用的是 bge-reranker 系列本地部署延迟增加 50ms 左右但召回准确率提升明显。如果不想加重排序用 RRFReciprocal Rank Fusion做简单融合也行效果比单路好。3.4 上下文拼装顺序和格式都有讲究检索出来的记忆片段怎么拼进 prompt直接影响模型的使用效果。我的经验是相关度高的放前面因为模型对开头和结尾的注意力更强。每条记忆加来源标注比如[用户偏好] 用户偏好顺丰快递让模型知道这是什么类型的信息。控制条数3-5 条足够多了反而干扰。加时间戳尤其是事实型记忆模型需要知道信息的时效性。一个拼装示例[相关记忆] 1. [偏好, 2024-05-10] 用户偏好顺丰快递不接受其他快递。 2. [历史问题, 2024-05-08] 用户上次反馈订单 A12345 物流延迟已补偿优惠券。 3. [实体, 2024-05-10] 当前咨询订单号 A12345。这种结构化格式模型理解起来比一堆自然语言段落高效得多。4. 常见问题与排查实录记忆系统上线后问题往往不是“不工作”而是“工作得不对”。我整理了几个高频问题和排查思路。4.1 记忆污染错误信息被反复强化现象Agent 反复提到一个用户从没说过的偏好。排查先查记忆库看这条错误记忆是什么时候、从哪轮对话抽取的。大概率是抽取模型把模型的推测当成了用户事实。解决抽取 prompt 里明确要求“只抽取用户明确表达的信息不要抽取你的推测”。另外写入时加一个二次校验用另一个模型判断这条记忆是否真的来自用户原话。这个校验成本不高但能挡掉大部分污染。4.2 检索召回率低明明存了却查不到现象用户问之前提过的事Agent 说不知道。排查分三步。第一确认记忆确实写入了查库。第二用同样的 query 手动跑检索看召回结果。第三检查 embedding 模型是否一致——写入和检索用了不同的 embedding 模型是新手常犯的错。解决如果 embedding 一致但召回差考虑换 embedding 模型或加混合检索。如果 query 太短比如“那个呢”需要做 query 改写结合对话历史补全语义再检索。4.3 延迟飙升检索拖慢了整体响应现象加了记忆系统后Agent 响应从 1.5s 涨到 5s。排查打点看各阶段耗时。常见瓶颈是向量检索和重排序。解决向量检索加缓存相同 query 短时间内直接返回缓存结果。重排序改成异步或批量不要每条记忆单独打分。检索和推理并行在模型开始生成的同时就发起检索等模型需要时结果已经就绪。4.4 记忆膨胀库越来越大检索越来越慢现象跑了一个月记忆库几十万条检索延迟明显上升。排查看记忆的重复率和过期率。解决写入时做去重相似度超过 0.95 的直接合并。给记忆加 TTL事实型记忆设长一点比如 90 天临时性记忆设短一点7 天。定期做记忆压缩把同一主题的多条记忆合并成一条摘要。下面这张表可以贴在工位上当速查问题首要排查点快速修复记忆污染抽取来源加二次校验召回率低embedding 一致性统一模型 混合检索延迟高检索耗时缓存 并行记忆膨胀重复率去重 TTL上下文超限token 预算裁剪 摘要5. 从零搭一个最小可用记忆系统理论说再多不如动手搭一个。这部分我给一个最小可用的实现路径用 Python Qdrant 一个 LLM API 就能跑起来。5.1 环境与依赖pip install qdrant-client openai tiktokenQdrant 用 Docker 起一个单机版就够docker run -p 6333:6333 qdrant/qdrant5.2 记忆写入流程核心就三步抽取、判断操作、写入。def extract_memory(dialogue): prompt f从以下对话中抽取值得长期记住的信息输出JSON 对话{dialogue} 要求只抽取用户明确表达的事实、偏好、实体。 输出格式{{should_remember: bool, content: str, operation: add/update/delete, confidence: float}} result llm_call(prompt) return json.loads(result) def write_memory(memory, user_id): if not memory[should_remember] or memory[confidence] 0.7: return vector embed(memory[content]) if memory[operation] add: client.upsert(collection, points[{ id: gen_id(), vector: vector, payload: {user_id: user_id, content: memory[content], ts: now()} }]) elif memory[operation] update: # 先检索相似记忆再更新 similar search_similar(memory[content], user_id) if similar: client.set_payload(collection, payload{content: memory[content]}, points[similar[0].id])5.3 记忆检索与拼装def retrieve_and_build(query, user_id, token_budget2000): vector embed(query) hits client.search(collection, query_vectorvector, query_filter{must: [{key: user_id, match: {value: user_id}}]}, limit10) # 按 token 预算裁剪 memories [] used 0 for hit in hits: text f[{hit.payload[type]}] {hit.payload[content]} tokens count_tokens(text) if used tokens token_budget: break memories.append(text) used tokens return \n.join(memories)5.4 接入 Agent 主循环def agent_step(user_input, user_id, history): memory_context retrieve_and_build(user_input, user_id) prompt f你是客服助手。 [相关记忆] {memory_context} [对话历史] {history} [用户输入] {user_input} response llm_call(prompt) # 异步写入记忆不阻塞响应 async_write_memory(user_input response, user_id) return response这套代码不到 100 行但已经具备了记忆系统的核心能力抽取、存储、检索、拼装。生产环境要加的东西包括错误重试、并发控制、监控打点、记忆去重但骨架就是这个。注意async_write_memory一定要异步否则每轮都等写入完成延迟会很难看。写入失败也不要影响主流程记日志后续补偿即可。6. 几个容易踩的认知误区最后聊几个我在和同行交流时反复听到的误区这些认知偏差比技术问题更耽误事。6.1 误区一记忆越多越好不是。记忆系统的价值在于信噪比不在于绝对数量。存了一万条记忆检索出来五条全是噪声还不如只存一百条精准的。我见过团队为了“显得记忆能力强”把所有对话都存进去结果检索质量一塌糊涂。宁缺毋滥是记忆系统的第一原则。6.2 误区二记忆系统可以完全自动完全自动的记忆抽取和更新目前还做不到生产级可靠。我的做法是自动为主人工兜底关键记忆比如用户身份、金额相关加人工审核队列普通记忆自动处理。另外提供记忆管理界面让运营能手动修正错误记忆。这个投入是值得的因为一条错误记忆可能影响后续几十轮对话。6.3 误区三换更强的模型就能解决记忆问题模型能力提升确实能改善记忆的使用效果但解决不了存储和检索的问题。模型再强你不在 prompt 里给它相关信息它也变不出来。记忆系统的工程投入和模型选型是两条独立的优化路径不能互相替代。6.4 误区四记忆系统一次搭好就不用管记忆系统是活的。用户的偏好会变业务的知识会更新记忆的分布会漂移。我建议至少每月做一次记忆质量审计抽样检查记忆准确率、检索召回率、过期记忆占比。发现指标下降就及时调整抽取 prompt 或检索策略。把它当成一个需要持续运营的系统而不是一次性的工程交付。我个人在实际项目里的体会是记忆系统带来的效果提升往往比换一个更大的模型更明显成本也更低。一个精心设计的检索层配合适度的上下文预算能让一个中等规模的模型跑出接近大模型的效果。这个投入产出比值得每个做 Agent 的团队认真对待。
