agent运行时喂给LLM的内容可以分为两类常驻提示词里的系统提示、工具说明、对话历史、AGENTS.md等每次请求时加载或续用相当于计算机的内存。需要时再去检索的其他对话的历史记录、团队知识库、代码库、网络上的新闻等它们默认不在上下文里这一层相当于计算机的外部存储。它们可能是向量数据库、SQL表也可能是飞书文档这类在线知识库统称记忆系统。记忆系统的问题和常驻提示词里的是不一样的。记忆会腐烂、过期、互相矛盾、被错误检索。下面按记忆的引入、写入、作废、共享、监测这几个环节来讲。一、该不该引入记忆系统“agent又忘了”是开发时最常见的问题。但大部分时候会发现这些“失忆”根本轮不到记忆系统外部存储出场。先看两个例子。agent调用工具失败了报错信息只有一句“调用失败”agent不知道怎么修正只能靠猜。这是工具契约的问题上记忆系统也救不了。agent每次回答都要在上下文里翻找项目规范而规范本应写进AGENTS.md自动加载。如果你用的是claudecode但把规范写在AGENTS.md里是找不到的claudecode只看CLAUDE.md。所以这是配置摆放的问题记忆系统同样救不了。还有一种比较隐蔽的问题上下文过多。复旦大学的论文在SOP-Bench上做过对比给模型注入288 tokens的“原始流程加背景描述”任务成功率66.48%注入165 tokens的“只保留行动规则”成功率同样是66.48%。多出来的描述没有带来任何行为价值。所以在考虑外部存储之前先做一次上下文审计哪些内容是真正影响决策的哪些只是在“说一些正确的废话”。为什么要先做这些而不是直接上记忆系统因为记忆系统有成本要更新要对抗过期和污染。真正值得放进记忆系统外部存储的信息有这些特点动态的、跨会话的、需要被更新或作废。二、什么时候写入确定需要记忆系统之后下一个问题是一条原始对话应该在什么时候被提炼成“记忆”这个选择会影响记忆库的质量因为一旦信息被压缩成结论原始细节就丢了。先看业界三个框架的做法。mem0是在写入时整合。每来一段新对话先从中提取出候选事实再拿这些候选去检索库里已有的相似记忆判断这条信息是新增、修订还是无关。然后让LLM决定add库里没有作为新记忆写入、update库里已有相似的去修订、delete与库里某条记忆矛盾把旧的那条作废还是noop不值得记什么都不做。整条链路的目的是把“提取”和“与旧记忆对账”合成一步避免重复和矛盾同时进入库里。zep的做法是只打时间戳不删除。每条事实带两个时间戳valid_at表示这条事实从何时开始成立expired_at表示从何时起系统认为它作废。出现矛盾事实时旧条目标记作废但数据本身保留。letta把整合搬到后台用户空闲时由一个专门的agent做记忆整理避免在关键对话路径上增加额外操作。相比之下研究性系统的选择更保守voyager中的agent先执行任务等任务完成并通过评估才把学到的技能写进长期记忆reflexion反过来任务失败之后才把反思写进去generative agents会给每次经历打一个重要性分累计到150才做一次总结。这些系统没有一个会在对话进行中即时提炼记忆因为对话刚结束时无法预知未来会问什么此刻的提炼标准只能来自当前上下文而不是未来的查询。原始文本存下来很便宜提前“理解”并提炼成结论反而可能把关键证据丢掉。另外voyager和reflexion都等一个“任务结束”的信号才动手背后的逻辑是只有执行过的信息才有资格被沉淀下来否则记忆库里塞满的只是未经验证的猜测。但这也不是绝对的。有一种例外情况当agent要处理的对话内容非常固定时。比如一个只负责报销单的agent它每次接到的都是同一套字段金额、日期、类别。这种情况下系统是提前知道了未来要查哪些信息的对话结束后立刻提炼记忆就是合理的因为提炼标准是确定的不会漏掉关键内容。反过来如果agent面对的是开放式的对话没法预测下一次用户会问什么那就别急着在对话中总结。原始记录保留下来更可靠等到真正需要的时候再提炼反而能保住细节。三个可落地的要点区分要入库的信息是固定的还是开放的固定的可提前提炼信息入库否则按原始内容记录触发写入选在四个高信号时刻检索没找到答案时、用户纠正了agent时、任务成功收尾时、系统空闲时新信息入库前设一道门禁先通过一次实际执行验证真实性验证通过才允许写入长期记忆。三、怎么让记忆保鲜先区分四种操作删除、过期、降权、撤回。它们的检索行为完全不同。操作检索时的行为谁在用删除不可达审计线索一起没掉mem0的delete过期对“现在”不可达对“当时”可达zep的invalid_at降权依然可达只是排名靠后mem0的memory decay撤回必须不可达目前没有完整实现看一下降权在真实系统里是什么样的。mem0的memory decay会把长期没访问过的记忆压到0.3倍权重频繁访问的记忆获得最高1.5倍加成。这套机制适合处理“优先级”不那么相关的记忆排名往后退。但在实际场景里也有人用它处理“正确性”把已经过时或被推翻的记忆调低权重期望它们不要被检索出来。降权适合处理优先级不适合处理正确性。一条已经被新事实推翻的旧记忆哪怕权重被压到0.1倍在top-K截断或者查询措辞变化时依然可能被重新检索。它被召回时带着的信号是“不太相关”而不是“已被推翻”。模型会把一条已经作废的事实当成一条可信度稍低但仍然成立的当前事实。想让错误记忆真正作废需要让它在检索阶段就不可见而不是到排序阶段才降低权重。具体办法是给每条记忆标上有效时间区间查询时强制过滤掉当前时间落在区间外的条目。zep的数据模型已经为每条事实建了四个时间戳分别是事实成立区间的起点valid_from与终点valid_to以及系统记录它失效的时间invalidated_at、首次被检索到的时间retrieved_at。前两个描述“这条事实在世界上何时为真”后两个描述“系统何时观察到它”。其实这套带时间区间的设计在数据库领域已经存在多年。SQL标准里的“系统版本应用时间表”就是同一套思想agent memory要做的不是发明新机制而是把现成的数据库能力接进LLM的语义记忆管理里。此外还有一个更麻烦的问题级联作废。假设agent的记忆库里有两条“服务器是ubuntu”和“所以应该用apt”。现在发现第一条是错的要作废。那么由它推导出的“应该用apt”也需要作废但很难追踪这条依赖链。落地做法是维护一条provenance链路每条记忆除了内容本身再存一个来源字段记录它是直接从对话提炼的还是从另一条记忆推导出来的。源记忆作废时遍历所有引用了同一个来源的派生记忆递归标记为存疑。如果框架不支持这个字段可以在提炼时让每条新记忆带上原始对话的UUID引用作废时回查所有引用同一段对话的记忆条目至少能做到追溯。自动检测冲突的准确率也有限。曾经看到过有篇论文测过LLM识别记忆冲突的准确率大约60%但要说清具体是哪两条冲突准确率差不多是40%。也就是说系统能察觉到“有矛盾”但指不准矛盾双方。这个问题的做法只能折中了不要追求全自动闭环改成半自动。当检测到可能存在矛盾时把候选对推进一个待审核队列人工做批量点击确认。记忆保鲜的做法用时间戳过滤而不是降权来作废错误记忆查询时强制过滤区间外的条目追踪记忆之间的依赖链源记忆作废时递归标记所有派生记忆为存疑冲突检测别追求全自动改成半自动LLM报候选人工批量确认。四、共享时怎么不互相污染多agent共享记忆错误信息的传播会被成倍放大。目前公开资料里几个代表性系统的选择有明显差别。同一任务内的多agentcognition的建议是共享完整执行轨迹至少要比摘要完整因为只有看到完整轨迹并行agent才能避免基于不完整的上下文做判断。子agent向主agent回报时anthropic的建议是传“产物”加schema也就是最终结果和对应的格式说明避免来回转述造成的失真。跨团队、跨组织协作时google a2a协议干脆规定内部记忆、工具、业务逻辑一概不共享agent之间只交换任务描述和有格式定义的产出物。这样做的好处是跨组织协作时对方只需要能直接使用的结果和双方约定的格式不需要内部推理过程因为暴露内部记忆反而会放大权限和污染风险。这些做法的共同点是共享有边界的显式信息而不是共享一个所有人都能往里写、往里取的公共池子。如果把所有agent的记忆倒进同一个向量库靠语义相似度去检索这样既没有轨迹的因果结构也没有产物的格式边界一条错误记忆进去后所有agent都会学到它一个老鼠屎打烂一锅汤。几个可以落地的约束子agent把产出物写进外部系统文件、数据库表只回传路径引用跨团队协作交换标准化artifact不交换内部prompt和记忆草稿如果必须共享记忆每条记忆都标上来源和权限域写入审计保持开启。五、怎么发现它已经坏了可以通过三个方式来应对记忆系统的逐渐腐化。看冷落程度。mem0已经在跟踪每条记忆的访问频率长期没被用到的会逐渐降权。可以定期筛出一段时间内零访问的记忆来处理它们大多数已经是噪声了。看上下文利用率。AWS Well-Architected框架的AGENTREL08-BP04要求按组件分开统计token消耗系统提示词、检索上下文、对话历史、工具结果。之所以要分开统计是为了定位到底是哪一环在膨胀。如果只记总量超了阈值也无从下手。上下文窗口利用率超过80%就应该告警并触发裁剪。渐进式的膨胀不易察觉也可以主动定期观察增长率不必等阈值触发。做错误注入实验故意往记忆库里塞一条错误事实然后观察它会污染多少份后续决策、需要多久才能被发现、能不能通过历史快照回滚到污染之前。“根据错误记忆执行了破坏性操作”远比“答错一道题”更严重。结语agent的记忆问题和数据库治理很像难处不在写入而在写入之后信息会过时会被推翻会在共享中扩散也会不知不觉变成噪声。如果agent最近越来越不靠谱排查顺序是先确认是不是必须上记忆系统也许改工具错误信息或补配置文件就能解决再确认写入时机有没有在信息还没验证的时候就把猜测固化了下来然后检查作废机制看看“撤回”是真的不可达还是只是降权接着检查共享边界agent之间交换的是结构化产出物还是同一个公共向量池最后定期做健康指标检测让衰败过程可见而不是等出事故再去查日志。