多智能体系统出问题，往往不是不会推理而是记错了。
每个做智能体的团队大概都碰过类似的问题：演示一切正常，生产环境跑上两周，系统开始说出与历史信息相矛盾的话。
一个多智能体系统在 demo 阶段可能表现得很漂亮。编排器负责路由任务，子智能体执行，返回结果也足够连贯。但是真正运行两周后，问题就出现了：某个智能体否认自己以前说过的话，或者再次询问用户已经提供过两次的信息。这种问题团队通常很难追到具体责任链——究竟哪个智能体出了问题，问题发生在什么时候，又是怎么产生的，都说不清楚。
根源通常在记忆。问题不在有没有记忆，而在系统如何理解和组织记忆。
“有向量数据库”和“有记忆”之间的差距
工程师构建多智能体系统时，一个常见误区是把记忆当成存储问题：选一套向量数据库，把对话历史塞进去，查询时取 top-k 个片段，以为事情就算做完了。
那只是检索不是记忆。
从认知角度看，记忆天然带结构。人不会把所有经历压成一份扁平清单，再靠余弦相似度搜索；经验会按不同用途组织起来。“发生过什么”“知道什么”“某个人与自己的关系是什么”“一件事该怎么做”，本来就是几类性质不同的信息，存储方式和访问方式也不同。
如果智能体系统把这些内容全部压进同一个向量存储，混乱几乎是必然的。事实会和事件竞争排序，流程会和偏好混在同一个检索面里，噪声就会变得越来越大。到了多智能体场景，问题还会继续放大：多个智能体共同读写同一份存储，却往往不知道其他智能体写过什么，更不知道写入的依据是什么。
Mem0 论文在 LoCoMo 基准上正面对比了 10 种不同的记忆方法，LoCoMo 测的是跨多会话对话数据的回忆能力。很多系统默认采用全上下文方法，也就是所谓“把所有内容都塞进上下文窗口”；这种做法每次查询大约消耗 26,000 个 Token。结构合理的选择性记忆方法，只花其中一小部分成本，就能达到相同的回忆质量。真正拉开差距的是记忆架构，并非模型。
四种记忆类型
目前较常见的智能体记忆分类有四类：工作记忆（working memory）、情景记忆（episodic memory）、语义记忆（semantic memory）和程序性记忆（procedural memory）。这个分类方向没错只是在多智能体系统里还不够完整。生产环境里的差异w要看每类记忆具体承担什么职责。
工作记忆就是当前 Prompt 里的内容，速度快、精确，会话结束后也随之消失。每个智能体都有工作记忆，但不能把它当成唯一记忆来源；长期运行的多智能体工作流中，一个 session 并不总能对应一段完整对话。
情景记忆保留的是“发生过什么”。重点不在从对话里抽取事实，记录对象是事件本身：哪个智能体执行了什么动作，用户说过什么，工具在什么时间点返回了什么结果。来源信息（provenance）也落在这一层。多智能体系统要回答“这个决定是谁做的”，靠的就是情景记忆。用户说“我上周已经告诉过你们系统了”，通常就是情景记忆没有发挥作用。
语义记忆属于提炼后的知识层。交互中的事实会被抽取出来，保存成独立断言，例如用户偏好 Python、部署目标是 AWS、客户预算上限是 $50k。很多团队所谓的“智能体记忆”，实际做的就是这一层。它很有用，也很脆弱，原因主要是信息会过时，后文会展开。
程序性记忆记录事情应该怎么做，包括学到的工作流、工具使用模式、审查约定，以及特定项目的部署步骤。一个和团队协作了三个月的编码智能体，应该已经知道团队会在合并前 squash commits、部署前跑集成测试、按特定格式写 changelog。这些内容不属于事实，也不属于事件，它们是一套流程。多数记忆系统至今没有单独存这一类信息。
A-MEM 论文给出了一种组织这些记忆类型的思路。它借鉴 Zettelkasten 方法，为每条记忆生成结构化笔记，再动态建立关联，逐渐形成一张演化中的知识网络。Pipeline 保留了下面几步：
Raw Event
↓
Summary + Keywords + Type tag
↓
Link to related memories (bidirectional)
↓
Knowledge graph node
记忆不该只是互相孤立的片段，记忆之间的关系也应该被保存，而且能够查询。
多智能体特有的三种失败模式
单智能体记忆本身已经很麻烦，多智能体系统又多出三类单智能体环境里没有的问题。
归因问题
假设记忆里有一句“用户需要部署方面的帮助”。谁写下来的？用户是否直接告诉过编排器？监控子智能体是不是根据日志分析推断出的？又或者，规划智能体只是把它当成一个中间假设，而且从未验证？
扁平记忆存储无法体现这些差异，检索阶段看起来都只是一条文本。可实际使用时，几种来源的可信度完全不同。用户直接陈述的事实应该高于智能体自行推断的内容；推断也应该明确打标，后续要么得到确认，要么被丢弃。
Mem0 的生产团队使用显式归因字段处理这件事：用户消息写在
user_id
下，智能体消息写在
agent_id
下。来源信息在写入阶段就被保留下来，检索阶段也能按来源查询。思路本身没有问题，真正的前提是系统里的每个智能体都必须准确填写归因信息。
一条记忆写入至少需要带上几类元数据：作者是谁、作者属于哪类智能体、对应哪个 session 和 run、断言来自用户陈述还是智能体推断或工具结果，以及置信度分数。后续要处理归因和陈旧性，靠的就是这些字段：
entry= {
"content": content,
"memory_type": classify(content), # semantic | episodic | procedural
# Attribution - never omit these
"author_id": context.agent_id,
"author_type": context.agent_type, # user | orchestrator | subagent | tool
"session_id": context.session_id,
"run_id": context.run_id,
# Confidence + scope
"source": context.source, # user_stated | agent_inferred | tool_result
"confidence": context.confidence, # 0.0 – 1.0
"scope": context.scope, # user | org | run | agent
"created_at": now(),
"verified_at": None,
"superseded_by": None,
}
一致性问题
单智能体系统只有一个写入者，多智能体系统却可能有很多。两个智能体可以针对同一个实体各写一条互相冲突的记忆，而且彼此毫不知情。规划智能体写下“用户偏好对批处理作业使用异步处理”，性能智能体又写下“用户希望使用同步处理，以简化调试”。两句话放在各自上下文里都可能准确，可两个写入者不知道另一条记录存在。下一位检索用户处理偏好的智能体会同时拿到两条结果，却没有足够上下文解释它们为何产生，只能临时做冲突消解。
BMAM 论文把这类现象叫作“语义侵蚀（semantic erosion）”。记忆持续累积并彼此竞争后，不同智能体会逐渐对同一个实体给出矛盾答案。论文提出周期性的整合过程，思路借鉴自神经科学：先检测冲突记忆簇，再按访问频率、置信度和新近程度做加权排序。
Detect conflicting memory clusters
↓
Rank each cluster by:
access_count × 0.4
confidence × 0.4
recency × 0.2
↓
Winner → promoted to stable semantic memory
Losers → marked superseded (kept for audit)
Too close to call → both kept, tagged with context
这套整合过程不会在每次查询时运行；系统每晚执行一次，或者等同一实体的写入次数达到某个阈值后再运行。
陈旧性问题
陈旧性往往到系统运行一段时间后才暴露，因为现实中的事实已经发生变化：用户换了工作，部署目标从 AWS 切到 GCP，预算上限也提高了。单智能体系统通常很快会发现旧事实，因为用户可能就在同一次对话里纠正它。多智能体环境不一样，陈旧信息也许只会被某个从不直接和用户对话的子智能体检索到，它随后很有把握地依据旧信息行动而且没有人会来纠正。
Mem0 的《State of AI Agent Memory 2026》把陈旧性列为该领域四个真正尚未解决的问题之一。陈旧性主要不是“信息够不够新”的问题，定期重新抽取也解决不了根本矛盾。从同一个未经认证的来源再次抽取旧记忆，得到的还是旧记忆。真正缺失的是来源和置信度追踪：系统没有足够信息判断，哪一条记忆在什么时候应该受到怀疑。
生产系统实际是什么样
到了 2026 年，处理得比较好的系统往往会出现几种相似的架构模式。
多范围身份
每次记忆写入至少带一个 scope。
user_id
对应某个用户跨所有 session 持续存在的事实，
agent_id
对应特定智能体实例，
run_id
只覆盖一次工作流运行，
org_id
则保存共享的组织上下文。检索时，这些 scope 会组合起来使用。没有明确的范围约束，智能体很容易把本来毫无关联的记忆拼到一起。
多信号检索
回忆基准上表现最好的系统，并不只依赖向量相似度。Mem0 2026 算法会并行跑三轮信号：语义相似度、BM25 关键词匹配、实体匹配，然后用倒数排名融合（reciprocal rank fusion）合并分数。时间衰减放在融合之后，不放在融合之前；陈旧且低置信度的记忆会在查询阶段降权，不会在写入时直接被剪掉。
defretrieve_memories(query, context, limit=20):
scope_filter= {
"user": context.user_id,
"run": context.run_id,
"org": context.org_id,
"agent": context.agent_id,
}
# Three parallel passes
semantic_hits=vector_search(query, scope_filter, top_k=50)
keyword_hits =bm25_search(query, scope_filter, top_k=50)
entity_hits =entity_match(query, scope_filter)
# Reciprocal rank fusion
candidates=fuse_scores(semantic_hits, keyword_hits, entity_hits,
weights=[0.5, 0.3, 0.2])
# Temporal decay - post-fusion
forcincandidates:
ifc.source=="agent_inferred"andage_days(c) >30:
c.score*=DECAY_FACTOR
ifc.superseded_by:
c.score=0.0 # hard filter
returntop_k(candidates, limit)
2026 年的论文报告称，相比上一版算法，这套方法让时间查询提高了 29.6 个百分点，多跳推理提高了 23.1 个百分点；两项改进都直接对应前面提到的失败模式。
异步记忆写入
响应送达后再异步写入记忆更合适，语音智能体尤其如此，因为用户会直接感知延迟。记忆写入不应该阻塞响应路径。
显式程序性记忆
多数框架仍把记忆看作事实和事件的集合。LangChain 团队的 SDK LangMem 在 2025 年初加入了程序性记忆支持，其中包括让智能体依据反馈重写自身 system prompt。智能体学到一套流程后，这套知识应该默认改变它之后的行为方式，而不是只在某次相关查询发生时，以一段被检索出来的上下文重新出现。
范围化访问控制
共享记忆还需要按 scope 做访问控制。用户记忆、run 范围记忆、智能体本地记忆，都不该默认向所有智能体开放。完全连接的图让每个智能体都能读取其他智能体写下的内容，结果是意外污染和蓄意投毒的攻击面都会被放到最大。
还没解决的问题
2026 年的基准成绩已经很高LoCoMo 达到 90 分。但现有基准仍抓不到一些失败模式。
跨会话身份解析（cross-session identity resolution）对于匿名用户、多设备用户和混合认证流程依旧有问题。整个记忆 scope 模型建立在稳定
user_id
之上。如果同一个人分别从 Web 界面和移动 App 进入系统，又使用了不同的 session 标识符，记忆系统会把两边当成两个用户。根因在身份层，不在检索层，单靠记忆系统解决不了。
大规模时间抽象（temporal abstraction at scale）的退化更明显。BEAM 基准会在 100 万和 1000 万 Token 上下文中运行，得分从 1M Token 时的 64.1 降到 10M Token 时的 48.6；上下文体量扩大 10 倍，性能大约损失 25%。如果智能体要持续运行几个月，这个问题不能忽略。现有时间记忆大多依赖衰减或新近程度加权，却没有充分区分三类事实：现在仍然成立的，过去成立但后来变化的，以及从一开始就没有可靠确认过的。
多智能体系统中的记忆投毒（memory poisoning）已经是实际安全问题。只要攻击者能够影响智能体读到的内容，就有机会进一步影响它写进共享记忆的内容，接着污染所有读取同一存储的其他智能体。现阶段可行的缓解手段仍是范围化写入、显式归因，以及限制各智能体能读取哪些记忆 scope 的访问控制。
总结
如果现在要搭一套多智能体系统，可以按下面的顺序落地。
从第一天就建立范围化记忆。不要把 scope 当成以后再补的字段。多个智能体已经往扁平存储里写了几个月数据后再做改造，成本会很高；范围模型应该直接进入初始 schema。
记忆类型也要提前定清楚。哪些智能体写情景记忆，哪些负责语义记忆，程序性知识又怎样积累，都需要明确分工。没有这层设计，默认结果通常是所有智能体都写进同一个扁平存储，检索很快就被噪声淹没。
每次记忆写入都应当作为带来源的事件保存。谁写的、什么时候写的、依据什么来源、置信度多少，这几类字段都要带上。生成元数据有成本，但存下来很便宜；缺少它们，归因和陈旧性问题很难在没有人工介入的情况下处理。
记忆衰减不能一刀切。低置信度、低访问频率的内容应该逐渐衰减；高置信度、频繁被检索的内容不该只因为时间过去就自动降权，但遇到矛盾证据时必须允许它受到质疑并被更新。两个极端都不可取：所有记忆永远有效，或者所有记忆都按同一种规则衰减。
时间查询需要单独测试。很多工程团队只测同一 session 里的回忆能力，这部分并不难。真正值得测的是更难的几类情况：跨 session 发生变化的事实，几个月前发生但现在仍然相关的事件，以及必须连接不同 session 信息才能完成的多跳推理链。最好针对自己的工作负载建立一套基准，github.com/mem0ai/memory-benchmarks 的开源框架可以作为起点。
记忆不是多智能体系统里的最后一个问题，却会放大很多其他问题。推理能力差、记忆可靠的智能体，至少还知道自己掌握了什么；推理能力不错、记忆混乱的智能体，则会拿着陈旧、互相矛盾、没有归因的数据继续自信推理。放进多智能体图里，这种偏差会沿着每个智能体继续叠加。
过去 18 个月，这个领域已经有了实质进展。基准成绩更好，检索方法更复杂，scope 模型也更清晰。尚未解决的问题如今足够具体，工程设计时已经可以提前避开，而不必等生产环境撞上之后才知道它们存在。
记忆仍然必须从系统设计的第一天认真处理。给智能体接一套向量数据库，不等于给了它记忆。能否分清两者，往往就是“demo 能跑”和“生产能跑”之间的差别。
参考文献
Chhikara et al., “Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory,” ECAI 2025, arXiv:2504.19413
Xu et al., “A-MEM: Agentic Memory for LLM Agents,” arXiv:2502.12110, revised October 2025
Packer et al., “MemGPT: Towards LLMs as Operating Systems,” arXiv:2310.08560, 2023
Dong et al., “Memory Injection Attacks on LLM Agents via Query-Only Interaction,” NeurIPS 2025
Mem0 Engineering Team, “State of AI Agent Memory 2026: Benchmarks, Architectures & Production Gaps,” April 2026
BMAM: Brain-inspired Multi-Agent Memory Framework, arXiv:2601.20465
作者：Debjit Dey