做智能体应用有一段时间的人大概率都遇到过这样的尴尬上一轮刚告诉助手“我叫XX”下一轮它又礼貌地问你贵姓让两个分头协作的智能体处理同一个项目结果它们各自为政重复整理了一堆相同信息。说白了问题出在记忆管理——短期记忆和长期记忆怎么配合、多个智能体之间怎么共享和隔离记忆这些没有想清楚功能越复杂越容易翻车。这篇文章想把我自己梳理的这套原理和落地经验讲清楚短期/长期记忆协同的工作方式多智能体场景下记忆共享与隔离该怎么设计以及一套可以上手的轻量级参考方案。适合正在写智能体框架、做对话式产品、或者被上下文窗口逼疯的开发者产品经理如果想搞懂“为什么智能体总是记不住”也值得读一读。1. 记忆不是缓存而是智能体的行为基础1.1 为什么大模型离不开记忆管理先想一个问题大模型本身有没有记忆严格说没有。一个模型在每次调用时只能看到你给它的上下文上一次对话的内容并不会自动保留。你感觉它有记忆是因为框架帮你把历史消息拼到了新的请求里。前端的对话列表、后端的会话数据、最近几轮的摘要这些都属于“临时记忆”。这种临时方案在小场景下够用但一旦涉及到持续服务、个性化推荐、多角色协作问题立刻暴露。比如用户两周前定制过一个报表格式这周又来了系统如果找不到这份偏好就会重新问一遍一个负责数据采集的智能体把结果存放在自己的会话里另一个负责分析的智能体完全读不到中间的沟通成本全落在开发者头上。更麻烦的是当一个任务跨越多个会话时如果没有记忆沉淀每次开工都要从零开始之前形成的判断和结论全部丢失。所以记忆管理不是附加功能而是智能体能不能在真实业务里存活的基础。它决定了三件事记得住也就是存储的完整度找得到也就是检索的准确度用得好也就是注入提示词的时机和格式。这三个能力环环相扣任何一个环节缺失都会让智能体表现出“间歇性失忆”。1.2 短期与长期不是时间长短而是职责不同很多资料把短期记忆和长期记忆简单理解成“存多久”我觉得不对。它们的本质差异是职责。短期记忆对应“工作台”。它保存当前任务正在使用的信息比如本次对话最近几轮、临时计算结果、当前步骤的中间状态。它的特点是易变、需要频繁读写、对响应速度敏感。你正在写一段文章刚才改的标题、当前段落的大纲这些都在工作台上不需要立刻存进档案库。长期记忆对应“档案柜”或者“经验笔记本”。它保存会跨会话复用的信息用户偏好、项目事实、历史结论、领域规则。它的特点是稳定、更新频率低、需要被检索定位。比如“客户公司的报表必须用PDF格式”“这个项目的技术栈是Python”这些信息今天用得到下周仍然用得到。在设计时我会把两者看作一个分层存储系统短期是高性能热区长期是低成本冷区中间靠写入和回填动作联动。只做短期记忆智能体永远活在当下只做长期记忆智能体缺乏对当前进展的感知。两者协同才像一个有经验的助手而不是一台失忆的问答机。2. 短期记忆的工程化先解决“上下文窗口不够用”2.1 短期记忆的三种常见实现先讲短期记忆因为它更接近工程也更容易被理解。第一种是“原样缓存”。把每次的对话消息按顺序存下来新一轮请求时取出最近N条拼进去。实现简单、信息不失真但会快速撑爆上下文窗口。如果用户的对话里夹杂着大段代码、长日志往往五六轮之后就没法再塞新内容了。第二种是“滑窗截断”。只保留最近K轮更早的直接丢弃。很多框架的默认做法就是这样但问题在于如果用户在第1轮说了关键需求第10轮才用到它早被踢出去了。这个方案适合一次性短任务一旦对话变长关键信息丢失几乎必然发生。第三种是“滑动摘要”。窗口内保留最近几轮原文窗口外更早的内容压缩成摘要挂在提示词开头。这种方式能保留更多历史脉络但摘要会丢失细节对摘要模型能力也有要求。摘要是“压缩损失”的过程压缩得越狠越容易丢失用户原话里的微妙措辞。实际中我是组合用的近3轮原文保留更早的压缩成逐轮摘要全局只保留一份用户画像级别的长期摘要。这相当于工作台上层是“当前能看到的纸”下层是“几张写满要点的便签”再下层才是档案柜。短期记忆不是越多越好而是要在保留细节和节约空间之间找平衡。2.2 短期记忆的容量怎么算这里给一个可复用的估算方法。假设模型上下文窗口是8K token你至少要留出3K token给系统提示词、工具定义和生成本轮回答那给历史消息的预算就是5K token。如果单轮对话平均消耗0.6K token那5K大约能容纳8轮。但真实情况还有长文本、工具调用结果我不会卡满上限会取60%-70%作为水位线也就是保留最近5-6轮原文超出部分的旧内容要么摘要要么转成长期记忆。提示短期记忆不能简单“越多越好”。上下文越长模型对中段内容的注意力衰减越严重有时候保留10轮啰嗦对话效果反而比压缩成3条要点差。宁可让模型看到的少而精也不要让它淹没在无关历史里。2.3 短期记忆的写入与清除时机短期记忆的写入时机通常是每一次模型输入前和输出后输入前加载当前任务的上下文输出后把新的消息追加到工作区。这个工作区可以在内存里也可以在键值存储中按会话ID或者任务ID作为键。还需要记录每一条消息的角色、时间和内容类型方便后续决定哪些内容值得晋升到长期记忆。清除时机有三个任务完成、会话超时、窗口溢出。任务完成时把工作区标记为可归档需要长期保留的内容落库到长期记忆不需要的直接清空会话超时可以根据业务定比如30分钟没有新消息就释放内存窗口溢出就是我们上面说的摘要转存。一定要给每个记忆条目打上时间戳和来源否则后面做遗忘和排查都会很头痛。3. 长期记忆的设计从“能存”到“能想起来”3.1 长期记忆里到底该存什么长期记忆里不是所有信息都值得进。我的经验是只存三类事实性信息、偏好性信息、经验性信息。事实性信息比如用户的名字、项目截止日期、某个系统的接口地址。这类信息准确、可校验适合结构化存储。偏好性信息比如用户习惯先看结论再看细节、周报喜欢表格、代码风格用空格不用tab。这类信息来自对行为的归纳通常带不确定性需要长期观察修正。经验性信息比如上次处理类似故障时发现“重启前置服务比直接重启主服务更有效”。这类信息是智能体自己的“成长记录”在多智能体场景下特别有价值。分类的意义在于决定后续的检索策略和更新策略。事实类可以直接查表偏好和经验类更适合向量化之后做相似度检索。如果你把所有内容塞进一个向量库看起来省事但大杂烩的检索质量会很差。我见过不少项目长期记忆库里什么都有结果检索时返回一堆风格相似但方向无关的内容模型被带偏。3.2 写入长期记忆的触发规则长期记忆不是每轮对话都写否则库里很快堆满垃圾。我通常会设置几个触发条件新事实出现用户给出了关于自身或项目的新信息比如“我们公司明年搬到南城”。明确偏好表达用户说“以后这类邮件都抄送给财务”。重要结论达成智能体帮助用户完成了一个多步骤推理最终结论值得保留。反常行为用户突然修改了既往设置这往往说明偏好变了需要更新而不是新增。每个触发条件都对应一个“收益评估”这条信息如果不存下次会不会造成重复沟通会不会导致决策错误如果是就值得写。如果没有触发条件我会给每条候选记忆打一个重要性分评分低于阈值的直接丢弃。宁愿漏存一些边缘信息也不能让库里塞满噪声。3.3 检索与注入长期记忆怎么被用起来存得好不如取得好。我常用的检索策略是“混合检索 重排”。混合检索先用关键词或结构化条件缩小范围比如最近30天、类型是偏好、与当前会话角色相关再做向量相似度检索取Top K。这样可以避免纯向量检索在罕见词、编号、人名上失忆的问题。很多人以为向量检索是万能的但在专有名词和数字面前混合检索明显更稳。重排把混合检索召回的记忆条目按“相关性、时效性、来源可信度”综合打分。相关性解决“是不是这件事”时效性解决“这个信息是否过时”来源可信度解决“来自用户本人还是智能体猜测”。三者加权比如0.6/0.3/0.1实际权重可以按业务调。重排后取前3-5条拼接到系统提示词里。注入的时机也很关键。我的做法是偏好在系统提示词固定位置注入事实类在对话开始前注入经验类只在触发相关任务时注入。全部塞在最前面会让模型分不清主次反而削弱了对当前指令的注意力。4. 多智能体场景记忆共享与隔离的博弈4.1 单智能体方案为什么不能直接搬单智能体场景下记忆围绕着一个“自我”组织所有信息都归同一个主人。多智能体场景完全不同每个智能体有自己的角色、目标和知识边界。比如一个项目里调研智能体负责搜集资料写作智能体负责输出文章审核智能体负责检查事实错误。如果它们共享同一份长期记忆调研智能体写下的中间草稿会被写作智能体当作最终结论如果完全隔离写作智能体得不到调研结果任务无法推进。所以多智能体记忆设计的核心不是“让所有智能体记住一切”而是“在正确的层次共享正确的信息”。我会把记忆分成三个层次个体记忆、团队记忆、全局记忆。个体记忆只有自己读写存放角色擅长的私有经验团队记忆面向同一个任务组组内可见全局记忆是整个系统共享的常识和规则任何智能体都能读。4.2 三种共享模式怎么选第一种是广播模式。写一条记忆所有智能体都同步一份适合播报系统级状态比如“底层数据库已经切换到新环境”所有人都应该知道。它的缺点是没有过滤智能体会被无关信息干扰时间一长每个智能体的上下文里都堆满了和自己工作无关的状态信息。第二种是订阅模式。每个智能体维护一个感兴趣的主题列表比如财务智能体只订阅“预算”“报销”“合同金额”相关记忆只有当写入的记忆命中了它的订阅规则才会推送给它。这种模式适合在智能体数量多、职责区分明确的场景。订阅模式相当于让每个智能体自己决定“我要关心什么”能把干扰降到最低。第三种是黑板模式。所有任务相关的过程信息都写到一个共享区域每个智能体只往自己的格子写需要时再去读别人的格子。黑板模式适合复杂的阶段性任务比如调研智能体把原始材料放到“inputs”区写作智能体从中读取再把草稿放到“drafts”区审核智能体只看“drafts”。整个过程有空间结构权限容易控制。我实践下来最稳的组合是全局广播只用于极少数关键状态任务流程用黑板模式长期经验用订阅模式。这样既保证关键信息不遗漏又不至于让每个智能体都被无关信息淹没。4.3 权限、命名空间与冲突处理多智能体记忆一定要有权限意识和命名空间。最简单的做法是给每条记忆加读写标签readers和writers。默认情况下一个智能体创建的记忆只有同任务组的智能体可以读其他智能体必须显式授权。命名空间可以从粗到细全局空间、团队空间、个体空间。每一层都有独立的读写规则不能越权。冲突处理是最容易踩坑的地方。两个智能体可能同时更新同一条事实比如一个智能体从客户邮件推断出“交付日期是周五”另一个智能体从项目计划里读到“交付日期是下周一”两份记忆写入时会打架。我的方案是给每条可变记忆加version字段写入时带上基于更新版本号的条件更新如果版本冲突不盲目覆盖而是把两条都保留交给冲突处理策略。可以保留最近的、保留来源优先级高的、或者生成需要人工确认的待办。具体选哪种取决于业务对准确性的敏感度。5. 我踩过的坑常见问题排查实录5.1 记忆污染不该记的记了一大堆记忆污染是我见过最多的问题。只要每轮对话都写入长期记忆用不了几天库里全是“用户今天说了句早上好”“智能体回复了收到”这类垃圾。排查时先看长期记忆库里无关条目的比例如果超过30%基本是写入触发条件没设置。解决思路很直接写入前加一道重要性评分给我用的一条规则是——如果这条信息在24小时内再次被用到分数1如果被用到三次以上才真正进入长期记忆。这就把一次性信息挡在了门外。同时给记忆条目标记来源类型后续可以做统计和清洗。定期跑一次清理任务把低重要性、长时间未命中的旧条目归档或删除能让检索质量长期维持稳定。5.2 检索命中率低问题不一定在向量模型很多人觉得检索差就是向量模型不好其实我遇到的大部分检索问题出在前处理和后处理。前处理是查询意图没有拆解用户问“上次那个表格后来怎么样了”如果直接用整句去检索不如先抽取关键词“表格”“上次”和实体“项目名”再构造检索请求。后处理是召回后没有重排向量召回的结果里混着时序不对、来源不对的内容硬塞给模型当然效果差。排查顺序我一般是这样先看召回阶段有没有命中目标记忆如果召回为空检查文本切分长度、查询改写如果召回了但模型没用检查注入位置和格式是否清晰。两个环节分开排查比盲目换模型有效得多。我见过一个项目向量模型换了好几个都没解决问题最后发现是旧记忆没有清理库里全是过时信息。5.3 多智能体重复记忆与互相覆盖多智能体协作里我碰到过调研智能体和写作智能体同时把“项目代号为Pilot”写入长期记忆两条内容几乎一样。如果不做去重检索时返回两个相似结果白白占用上下文如果直接按“最后写入覆盖”处理又可能出现旧数据覆盖新数据的情况。我的处理是写入时先做相似度检查与已有条目的向量相似度超过0.92就直接做更新而不是新增低于0.92但语义相近保留两条但用归组ID关联。更新时带上版本号不满足版本条件的写入被拒。再配合命名空间隔离能规避一大部分互相覆盖。注意相似度阈值不是拍脑袋定的。我在某个业务里用0.92另一个细粒度标签多的场景用的是0.85。阈值需要拿测试集验证建议准备几百条样本自己调。6. 一套轻量级的记忆管理参考方案6.1 最小可运行的结构设计如果从零搭建我不会一上来就引入重框架。一个最小的结构只需要三张表短期记忆表存会话ID、角色、内容、时间戳长期记忆表存记忆ID、智能体ID、类型、内容、向量、版本号、时间戳、重要性共享记忆表存命名空间、读者列表、写者列表、内容。所有记忆都有智能体ID和命名空间这样隔离和共享都能通过字段控制。短期记忆直接用内存或文件缓存长期记忆用嵌入式数据库加本地向量索引完全够个人项目或小团队原型用。等规模上来之后再把存储层替换成独立服务但上层逻辑不需要大改。6.2 核心流程的参考实现写入长期记忆的主流程可以简化成下面这段伪代码async def write_long_term_memory(memory, agent_id): memory.namespace memory.namespace or default_namespace(agent_id) if not should_persist(memory): # 重要性判断 return memory.embedding embed(memory.content) similar vector_search(memory.namespace, memory.embedding, top_k1) if similar and sim_score(similar[0], memory.embedding) 0.92: # 相似条目存在走更新而不是新增 update_memory(similar[0].memory_id, memory, expect_versionsimilar[0].version) else: insert_memory(memory)读取长期记忆的流程也一样async def read_long_term_memory(query, agent_id, namespaceNone): entities extract_entities(query) candidates hybrid_search(query, entities, namespace, top_k20) ranked rerank(candidates, query) # 相关性 0.6, 时效 0.3, 来源 0.1 return ranked[:5]这个实现没法直接跑但结构能把写入、更新、检索、重排四个关键动作拆开方便你替换成自己的存储和模型。6.3 关键参数怎么定有几个参数我建议先不追求完美用经验值起步上下文窗口预留比例60%-70%给历史会话留足输出空间。短期记忆原文保留轮数新手先设5轮验证效果后再调整。长期记忆条数上限初期可以设5000条满了之后优先清理低重要度、超过90天未命中的条目。向量相似度阈值0.85-0.92之间起步用自己的测试集调。重排权重相关性0.6时效性0.3来源可信度0.1这个组合在大多数业务里表现稳。这些参数都要能从配置中心调整因为不同业务差异很大。我在一个法律咨询场景里短期记忆只保留3轮就够因为用户问题通常很短但在长文档写作场景保留10轮原文都嫌少。所以经验值只是起点真正要做的是一边跑一边看数据调参。6.4 扩展方向从“会记住”到“会反思”基础版本能用之后可以往两个方向升级。一是分层记忆把记忆从原始消息、事实、偏好、经验四个层级组织低层自动从高层沉淀高层再反过来指导低层信息的取舍。这样记忆不再是一堆散落的点而是一张有结构的网。二是反思机制定期让一个专门的角色回顾最近一段时间的记忆提炼出新的经验和模式形成“关于记忆的记忆”。比如它发现用户每周五都要汇总本周进展于是自动生成一条偏好记忆“周五自动生成周报摘要”这就是从数据到经验的跃迁。这些扩展都会让系统更像一个真正的助手但每一个都会带来新的成本和复杂度建议等基础流程稳定后再动。这套方案我完全基于开源组件和简单的表结构搭起来后在一套模拟的多人协作智能体项目里跑了三个月。最大的体会是记忆系统的90%问题出在写入端和检索端而不是存储端。与其花大力气调数据库不如先把“什么值得记”和“怎么找回来”想清楚。最后分享一个小技巧每次会话结束时花几秒钟让智能体用两三句话总结这次会话的“可复用信息”把总结写入长期记忆。这个动作成本极低但在长期运行里会带来非常明显的效果提升也是我最推荐先落地的一件事。
