基准驱动的 Agent 记忆选型：LoCoMo、LongMemEval 与 BEAM 的量化决策框架

2025 年之前，Agent 记忆系统的评估几乎完全依赖主观报告。 团队声称"我们的记忆系统很好用"，但无法回答：在多轮对话后还能准确召回多少信息？在百万级上下文中性能如何衰减？时间推理和多跳推理的准确率是多少？

这种模糊性导致三个工程问题：

第一，无法横向对比。 一个基于向量检索的系统 vs 一个基于知识图谱的系统，哪个更好？没有标准化测试集，只能靠 Demo 演示和轶事证据。

第二，无法预测生产表现。 实验室里"感觉不错"的系统，部署后面对真实用户的复杂查询（跨会话引用、时间推理、知识更新）时，性能可能断崖式下跌。

第三，无法量化优化收益。 团队花了两周优化记忆提取算法，但无法证明性能提升了多少——因为没有基准线。

2026 年 7 月，三个标准化基准测试改变了这个局面：LoCoMo、LongMemEval 和 BEAM。 它们覆盖了从单会话到跨会话、从千级到百万级上下文的完整评估谱系，让 Agent 记忆系统的选型从"凭感觉"转向"看数据"。

Mem0 在 2026 年发布的基准报告中给出了关键数据点：LoCoMo 92.5 分、LongMemEval 94.4 分、平均每次查询消耗约 6,900 tokens。这些数字的意义不在于绝对值，而在于它们建立了可比较的基线——其他系统可以用同样的测试集评估，形成真正的横向对比。

边界说明：本文聚焦基准测试驱动的量化选型，不涉及记忆架构的概念分层（已在 agent-memory-arch-001 和 agent-062 中覆盖），也不讨论 RAG 检索策略（已在 rag-001 中覆盖）。

LoCoMo（Long-Context Conversational Memory） 是当前最广泛使用的 Agent 记忆基准，由 Mem0 团队在 ECAI 2025 论文中提出。它包含 1,540 个问题，覆盖四类记忆任务：

• 单跳记忆（Single-hop）：直接从对话中提取单一事实。例如："用户上次提到的项目名称是什么？"
• 多跳记忆（Multi-hop）：需要关联多个对话片段。例如："用户提到的那个使用 Python 的项目，它的部署环境是什么？"（需要先找到项目，再找到部署环境）
• 开放域记忆（Open-domain）：答案不在对话中明确提及，需要推理。例如："用户可能喜欢哪种数据库？"（基于用户提到的技术栈推断）
• 时间记忆（Temporal）：涉及时间顺序和时间推理。例如："用户是先提到 Kubernetes 还是先提到 Docker？"

LoCoMo 的核心价值在于它测试的是真实对话场景中的记忆能力，而不是孤立的问答对。多跳和时间推理是最难的两类任务，也是区分记忆系统质量的关键指标。

LongMemEval 是 2026 年提出的更全面的基准，包含 500 个问题，覆盖六类场景：

• 单会话用户记忆（Single-session user recall）：记住用户在同一次会话中提到的信息
• 单会话助手记忆（Single-session assistant recall）：记住助手自己在同一次会话中生成的内容
• 单会话偏好记忆（Single-session preference recall）：记住用户的偏好设置
• 知识更新（Knowledge update）：当用户修正之前的信息时，系统能否正确更新。例如：用户先说"我用 Python 2"，后来说"我升级到 Python 3 了"，系统能否记住最新版本？
• 时间推理（Temporal reasoning）：与 LoCoMo 类似，但测试更复杂的时间关系
• 多会话记忆（Multi-session recall）：跨多次会话的记忆能力

LongMemEval 的独特价值在于知识更新测试——这是生产环境中最常见的需求。用户的信息会变化（换工作、搬家、改偏好），记忆系统必须能正确更新而不是保留过时信息。

BEAM（Benchmark for Evaluating Agent Memory） 是 2026 年最激进的基准，测试系统在百万级和千万级上下文中的表现。它的核心问题是：当上下文规模从几千 tokens 扩展到 1M 甚至 10M tokens 时，记忆系统的性能如何衰减？

BEAM 包含十类任务：

• 偏好遵循（Preference following）
• 指令遵循（Instruction following）
• 信息提取（Information extraction）
• 知识更新（Knowledge update）
• 多会话推理（Multi-session reasoning）
• 摘要（Summarization）
• 时间推理（Temporal reasoning）
• 事件排序（Event ordering）
• 弃权（Abstention）：系统能否识别"我不知道"而不是瞎编
• 矛盾解决（Contradiction resolution）：当不同来源的信息矛盾时，系统如何处理

BEAM 的意义在于它测试的是生产级规模的表现。真实的企业 Agent 可能需要处理数月甚至数年的对话历史，上下文规模轻松达到百万级。BEAM 揭示了哪些系统能在大规模下保持性能，哪些会崩溃。

Mem0 在 2026 年 4 月发布的新算法在基准测试中取得了显著提升：时间推理 +29.6 分，多跳推理 +23.1 分。 这两个提升来自两个关键架构变化：单遍 ADD-only 提取和多信号检索。

单遍 ADD-only 提取（Single-pass ADD-only extraction） 解决了 Agent 生成信息的记忆覆盖问题。

传统记忆系统只提取用户明确陈述的事实。例如：用户说"我用 Python"，系统记住"用户偏好：Python"。但如果 Agent 在对话中说"基于你的需求，我推荐使用 FastAPI"，这个推荐不会被记住——因为它是 Agent 生成的，不是用户陈述的。

单遍 ADD-only 提取将 Agent 生成的事实视为与用户陈述同等重要。系统会同时提取：

• 用户陈述："我用 Python" → 记住"用户偏好：Python"
• Agent 推荐："推荐使用 FastAPI" → 记住"Agent 推荐：FastAPI（基于用户需求）"
• Agent 确认："是的，FastAPI 适合你的场景" → 记住"Agent 确认：FastAPI 适合"

这种设计的价值在于记忆覆盖率的提升。当用户下次问"你上次推荐我用什么框架？"时，系统能准确召回 Agent 的推荐，而不是只能说"我不记得了"。

ADD-only 的含义是"只增不删"——新提取的记忆不会覆盖旧记忆，而是并存。这避免了错误的覆盖（例如：用户说"我用 Python 2"，后来又说"我用 Python 3"，系统不应该删除 Python 2 的记录，而应该保留两个版本并标记时间）。

多信号检索（Multi-signal retrieval） 解决了单一检索信号的局限性。

传统的向量检索只使用语义相似度（Semantic similarity）——将查询和记忆都编码为向量，计算余弦相似度。但语义相似度有盲区：

• 关键词匹配盲区：用户问"FastAPI"，向量检索可能返回"Web 框架"（语义相近），但错过了精确包含"FastAPI"的记忆
• 实体匹配盲区：用户问"张三的项目"，向量检索可能返回"李四的项目"（语义相近），但错过了包含"张三"这个实体的记忆

多信号检索并行运行三个评分通道：

1. 语义相似度（Semantic similarity）：基于向量余弦相似度
2. 关键词匹配（Keyword matching）：基于 BM25 或 TF-IDF
3. 实体匹配（Entity matching）：基于命名实体识别（NER）

三个通道的分数通过加权融合（通常是 0.5 × 语义 + 0.3 × 关键词 + 0.2 × 实体），最终按融合分数排序。

这种设计的价值在于召回精度的提升。单一信号可能在某个维度上表现优异但在其他维度上失败，多信号融合可以互补。例如：

• 用户问"FastAPI 的部署环境"
• 语义相似度返回"Web 框架部署"（相关但不精确）
• 关键词匹配返回包含"FastAPI"的记忆（精确）
• 实体匹配返回包含"FastAPI"实体的记忆（精确）
• 融合后，精确匹配的记忆排名更高

Mem0 的基准数据显示，多信号检索在 LoCoMo 上比单一语义检索提升了 15-20 分，在多跳推理任务上提升更显著（因为多跳需要精确匹配中间实体）。

from mem0 import MemoryClient

client = MemoryClient(api_key="your-key")

# 添加记忆（自动触发单遍 ADD-only 提取）
client.add(
    messages=[
        {"role": "user", "content": "我用 Python 做后端"},
        {"role": "assistant", "content": "推荐使用 FastAPI"},
        {"role": "user", "content": "好的，我用 FastAPI"}
    ],
    user_id="xueshuai"
)

# 检索记忆（自动触发多信号检索）
memories = client.search(
    query="我上次推荐用什么框架？",
    user_id="xueshuai",
    # 可配置检索信号权重
    retrieval_config={
        "semantic_weight": 0.5,
        "keyword_weight": 0.3,
        "entity_weight": 0.2,
        "top_k": 5
    }
)

for mem in memories:
    print(f"记忆: {mem['content']}, 分数: {mem['score']}")

Mem0 在 2026 年 7 月的基准报告中给出了关键性能数据：LoCoMo 92.5 分、LongMemEval 94.4 分、BEAM (1M) 64.1 分、BEAM (10M) 48.6 分，平均每次查询消耗约 6,900 tokens。

这些数字需要放在正确的上下文中理解：

LoCoMo 92.5 分的含义： 在 1,540 个多会话记忆问题中，Mem0 正确回答了 92.5%。这是一个很高的分数，但需要注意 LoCoMo 的问题难度分布——单跳问题相对简单，多跳和时间推理问题更难。Mem0 在这两类难题上的提升（+23.1 和 +29.6）比总分更有意义。

LongMemEval 94.4 分的含义： 在六类记忆场景中，Mem0 的综合准确率达到 94.4%。其中知识更新场景是最难的——用户修正信息后，系统能否正确更新？94.4 分意味着 Mem0 在大多数情况下能正确处理知识更新，但仍有 5.6% 的失败率。在生产环境中，这 5.6% 可能导致用户看到过时信息，需要通过人工审核或置信度阈值来控制风险。

BEAM (1M) 64.1 分的含义： 在百万级上下文中，Mem0 的性能下降到 64.1%。这是一个重要的信号——即使是最先进的记忆系统，在大规模下也会显著衰减。64.1 分意味着在百万级场景下，系统只能正确回答约 2/3 的问题。

BEAM (10M) 48.6 分的含义： 在千万级上下文中，性能进一步下降到 48.6%——接近随机猜测。这揭示了一个重要的工程约束：当前最好的记忆系统也无法可靠地处理千万级上下文。 如果你的场景需要处理数年的对话历史，必须设计分层记忆架构（近期记忆 + 摘要记忆 + 关键事件记忆），而不是依赖单一的记忆库。

平均每次查询 6,900 tokens 的含义： 这是检索和生成阶段的总 token 消耗。相比 2025 年的全上下文方案（约 26,000 tokens/对话），新算法将 token 消耗降低了 73%。这对成本控制至关重要——token 消耗直接决定了 API 调用成本。

但需要注意，6,900 tokens 是平均值，实际消耗会根据查询复杂度波动。简单查询（如"用户叫什么名字？"）可能只需要 1,000 tokens，复杂查询（如"用户过去三个月提到的所有项目及其技术栈"）可能需要 20,000+ tokens。

2026 年上半年，两个重要产品改变了 Agent 记忆的竞争格局：Anthropic 的 Memory and Dreaming 和 Redis 的 Agent Memory。 它们代表了两种不同的设计哲学：内建记忆 vs 外挂记忆基础设施。

Anthropic Memory and Dreaming 是 Claude 模型的原生记忆能力，于 2026 年 5 月在 Managed Agents API 中发布。它的核心设计是将记忆能力直接整合到模型中，而不是依赖外部记忆系统。

技术实现上，Memory and Dreaming 包含两个机制：

• Memory（记忆）：模型在对话过程中自动提取关键信息并持久化。与 Mem0 等外部系统不同，Anthropic 的记忆提取是在模型训练阶段就内建的，不需要额外的 LLM 调用。这意味着更低的延迟和更少的 token 消耗。
• Dreaming（梦境）：模型在空闲时会"回顾"最近的对话，整合碎片化记忆为结构化知识。这类似于人类睡眠时的记忆整合过程。Dreaming 机制可以自动将多次对话中的碎片信息整合为连贯的知识图谱。

Memory and Dreaming 的优势在于零集成成本——开发者不需要接入外部记忆系统，只需要在 API 调用时启用记忆功能。但它也有局限：记忆存储在 Anthropic 的服务器上，无法自定义存储策略；记忆提取逻辑是黑盒，无法针对特定场景调优。

Redis Agent Memory 是 Redis 于 2026 年 6 月发布的记忆基础设施产品。它的设计哲学与 Anthropic 完全相反：提供高性能的记忆存储和检索基础设施，让开发者自己实现记忆逻辑。

Redis Agent Memory 的核心能力：

• 亚毫秒级读写：基于 Redis 的内存数据库，记忆读写延迟低于 1ms。这对实时对话场景至关重要——用户不希望等待记忆检索。
• 向量 + 关键词 + 实体混合检索：与 Mem0 的多信号检索类似，但 Redis 将检索逻辑下推到数据库层，应用层只需要声明检索需求。
• 灵活的存储策略：开发者可以自定义记忆的 TTL、过期策略、压缩策略。例如：可以设置"用户偏好"类记忆的 TTL 为 1 年，"任务状态"类记忆的 TTL 为 1 周。
• 多 Agent 共享记忆：Redis 的发布/订阅机制支持多个 Agent 共享同一个记忆库，实现跨 Agent 的知识同步。

Redis Agent Memory 的优势在于灵活性和性能——开发者可以完全控制记忆逻辑，同时享受亚毫秒级延迟。但它也有局限：需要开发者自己实现记忆提取、评分、融合逻辑，集成成本较高。

两种设计哲学的选型建议：

• 如果你的场景是快速原型验证或非关键业务，选择 Anthropic Memory and Dreaming。零集成成本，开箱即用。
• 如果你的场景是生产级企业应用或需要高度定制化，选择 Redis Agent Memory 或 Mem0。虽然集成成本高，但提供了完全的控制权。
• 如果你的场景是超大规模（百万级用户、千万级对话），选择 Redis Agent Memory。Redis 的分布式架构可以水平扩展，而 Anthropic 的方案受限于单点性能。

基于三大基准测试和 2026 年新产品，我们可以构建一个量化驱动的选型决策框架。 这个框架分为三步：场景分类、基准匹配、候选评估。

第一步：场景分类。 根据你的业务需求，确定记忆系统的核心场景：

• 场景 A：单会话助手（如客服机器人）。核心需求是短期记忆和偏好记忆，不需要跨会话能力。
• 场景 B：长期协作助手（如个人助理）。核心需求是跨会话记忆、知识更新和时间推理。
• 场景 C：企业知识管理（如团队知识库）。核心需求是多 Agent 共享记忆、大规模检索和合规审计。
• 场景 D：超大规模应用（如百万级用户的 SaaS）。核心需求是水平扩展、亚毫秒延迟和成本优化。

第二步：基准匹配。 根据场景选择最相关的基准测试：

• 场景 A：优先关注 LoCoMo 的单跳记忆分数。单跳准确率 > 95% 即可满足需求。
• 场景 B：优先关注 LongMemEval 的知识更新分数和 LoCoMo 的时间推理分数。知识更新准确率 > 90%，时间推理准确率 > 85%。
• 场景 C：优先关注 BEAM (1M) 的大规模表现。BEAM 分数 > 60 才能满足百万级上下文需求。
• 场景 D：优先关注 BEAM (10M) 的超大规模表现和 token 消耗。BEAM 分数 > 45，平均 token 消耗 < 7,000。

第三步：候选评估。 根据基准匹配结果，评估候选产品：

• Mem0：适合场景 B 和 C。LoCoMo 92.5、LongMemEval 94.4，在中等规模下表现优异。但 BEAM (1M) 只有 64.1，超大规模表现有限。
• Redis Agent Memory：适合场景 C 和 D。亚毫秒延迟和水平扩展能力，但需要自己实现记忆逻辑。基准数据需要自己测试。
• Anthropic Memory and Dreaming：适合场景 A 和 B。零集成成本，但记忆逻辑是黑盒，不适合场景 C 和 D 的合规要求。
• Letta（原 MemGPT）：适合场景 B。支持多种存储后端，但基准数据不如 Mem0 透明。
• Zep：适合场景 C。支持图谱存储和事实提取，但基准数据不完整。

决策矩阵示例（场景 B：长期协作助手）：

在这个场景下，Mem0 是最佳选择——基准数据透明，性能优异，集成成本适中。

在将记忆系统部署到生产环境之前，必须完成以下量化验证清单。 这个清单基于 2026 年的最佳实践，覆盖了性能、成本和可靠性三个维度。

性能验证：

1. 基准测试复现：在你的真实数据上运行 LoCoMo、LongMemEval 或 BEAM 测试集。不要直接使用厂商提供的基准数据——你的场景可能有独特的查询模式。
2. 延迟测试：测量 P50、P95、P99 延迟。生产环境的 P99 延迟应该 < 500ms（包括记忆检索和 LLM 生成）。
3. 并发测试：模拟真实并发量（如 100 QPS），观察性能衰减。Redis Agent Memory 应该能轻松处理 1000+ QPS，Mem0 的并发能力取决于后端存储。
4. 大规模测试：如果你的场景需要处理长期对话，必须在百万级上下文下测试。BEAM (1M) 分数应该 > 60。

成本验证：

1. Token 消耗测试：测量平均每次查询的 token 消耗。生产环境应该 < 10,000 tokens/查询，否则成本会失控。
2. 存储成本测试：测量每用户每月的存储成本。Mem0 的存储成本取决于后端（向量数据库 vs 关系数据库），Redis 的存储成本取决于内存用量。
3. API 调用成本测试：如果使用第三方 API（如 Mem0 Cloud），测量每月的 API 调用成本。

可靠性验证：

1. 知识更新测试：模拟用户修正信息的场景，验证系统能否正确更新。失败率应该 < 5%。
2. 矛盾解决测试：模拟不同来源信息矛盾的场景（如用户在不同会话中提到不同的偏好），验证系统如何处理。
3. 遗忘测试：模拟用户要求删除信息的场景（如 GDPR 被遗忘权），验证系统能否完全删除。
4. 审计测试：验证记忆变更是否有完整的审计日志。生产环境必须能追溯每条记忆的创建、更新、删除历史。

验证通过标准：

• 所有性能指标的 P99 延迟 < 500ms
• 平均 token 消耗 < 10,000 tokens/查询
• 知识更新失败率 < 5%
• 遗忘功能 100% 可靠（如果有合规要求）
• 审计日志完整，可追溯每条记忆的历史

如果任何一项不达标，必须在部署前优化。记忆系统的性能问题在生产环境中会被放大——一个在测试环境中"勉强能用"的系统，在面对真实用户的复杂查询时可能会完全崩溃。

import time
from mem0 import MemoryClient

client = MemoryClient(api_key="your-key")

# 1. 基准测试复现
test_questions = [
    "用户上次提到的项目名称是什么？",  # 单跳
    "用户提到的那个 Python 项目的部署环境是什么？",  # 多跳
    "用户是先提到 Kubernetes 还是先提到 Docker？",  # 时间推理
]

correct = 0
for q in test_questions:
    start = time.time()
    memories = client.search(query=q, user_id="test_user")
    latency = time.time() - start
    
    # 验证答案正确性（需要人工标注 ground truth）
    if verify_answer(memories, ground_truth[q]):
        correct += 1
    
    print(f"查询: {q}, 延迟: {latency*1000:.2f}ms, 正确: {correct}")

accuracy = correct / len(test_questions)
print(f"准确率: {accuracy*100:.1f}%")

# 2. Token 消耗测试
total_tokens = 0
for q in test_questions:
    memories = client.search(query=q, user_id="test_user")
    total_tokens += count_tokens(memories)

avg_tokens = total_tokens / len(test_questions)
print(f"平均 token 消耗: {avg_tokens:.0f}")

# 3. 知识更新测试
client.add(messages=[{"role": "user", "content": "我用 Python 2"}], user_id="test_user")
client.add(messages=[{"role": "user", "content": "我升级到 Python 3 了"}], user_id="test_user")
memories = client.search(query="用户用什么版本的 Python？", user_id="test_user")
if "Python 3" in memories[0]["content"] and "Python 2" not in memories[0]["content"]:
    print("知识更新测试通过")
else:
    print("知识更新测试失败")

尽管 2026 年的基准测试和新算法取得了显著进展，Agent 记忆领域仍有三个核心开放问题尚未解决。 这些问题决定了记忆系统的下一步演进方向。

第一个开放问题：跨会话身份识别（Cross-session identity）。

当前记忆系统假设"用户 ID"是稳定的——同一个用户在不同会话中使用相同的 ID。但真实场景中，用户可能：

• 在不同设备上使用不同的账号
• 匿名访问后注册账号
• 多个用户共享同一个账号（如家庭账号）

这些场景下，记忆系统如何识别"这是同一个用户"？如果无法正确识别，记忆就会出现碎片化（同一用户的记忆分散在多个 ID 下）或污染（不同用户的记忆混在一起）。

Mem0 的基准报告将跨会话身份识别列为"最难的开放问题之一"。当前的解决方案包括：

• 基于行为的身份识别：通过分析用户的查询模式、偏好、技术栈等特征，判断不同 ID 是否属于同一用户。但这种方法准确率有限，容易误判。
• 显式身份绑定：要求用户在不同设备上手动绑定账号。但用户体验差，很多用户不会操作。
• 生物特征识别：通过语音、打字节奏等生物特征识别用户。但隐私问题严重，很多用户不接受。

这个问题没有完美的解决方案，只能通过多信号融合（行为 + 显式绑定 + 可选的生物特征）来提高准确率。

第二个开放问题：大规模时间抽象（Temporal abstraction at scale）。

当前记忆系统在时间推理上表现有限——它们能处理"用户先提到 A 还是先提到 B"这样的简单时间问题，但无法处理"用户过去三个月的工作重点是什么"这样的时间抽象问题。

时间抽象需要系统能够：

• 将碎片化的记忆整合为时间段内的主题
• 识别时间模式（如"用户每周一都会提到项目进度"）
• 预测未来趋势（如"基于用户过去的行为，下周可能会关注什么"）

这些能力需要更强的时间序列分析和模式识别能力，当前的记忆系统还做不到。

第三个开放问题：记忆陈旧性（Memory staleness）。

记忆会随时间变得过时——用户的工作、偏好、项目都会变化。但记忆系统如何判断"这条记忆已经过时了"？

当前的解决方案包括：

• 基于 TTL 的过期：为每条记忆设置过期时间。但 TTL 很难设置——太短会丢失有用信息，太长会保留过时信息。
• 基于访问频率的衰减：长期不访问的记忆重要性降低。但有些重要记忆可能长期不访问（如用户的生日），不应该被衰减。
• 基于冲突检测的更新：当新信息与旧记忆矛盾时，标记旧记忆为过时。但矛盾检测本身就是一个难题——"我用 Python 2"和"我用 Python 3"是矛盾，但"我喜欢 Python"和"我喜欢 Java"不是矛盾。

这三个开放问题决定了 Agent 记忆的下一步演进方向。解决这些问题需要跨学科的研究——认知科学（人类如何处理时间抽象和身份识别）、数据库系统（如何高效存储和检索大规模记忆）、机器学习（如何自动判断记忆陈旧性）。

对于工程师来说，这些问题意味着：当前的记忆系统还不够完美，必须在生产环境中保持警惕。 定期审核记忆质量，处理用户投诉，持续优化记忆逻辑。记忆系统不是一次性部署的产品，而是需要持续演进的基础设施。

1. Mem0 Engineering Team. "AI Agent Memory 2026: Progress Benchmark Report Evaluations." Mem0 Blog, 2026. https://mem0.ai/blog/state-of-ai-agent-memory-2026 — 基准测试数据来源：LoCoMo 92.5、LongMemEval 94.4、BEAM 64.1/48.6，以及单遍提取与多信号检索算法细节。

2. Redis Labs. "AI agent memory: types, architecture & implementation." Redis Blog, 2026. https://redis.io/blog/ai-agent-memory-stateful-systems/ — Redis Agent Memory 产品设计：亚毫秒延迟、向量+关键词+实体混合检索、多 Agent 共享记忆。

3. Rampal S, Capper B, Romashko K, et al. "From context to dreams: architecting memory for AI agents." Red Hat Emerging Technologies Blog, June 1, 2026. https://next.redhat.com/2026/06/01/from-context-to-dreams-architecting-memory-for-ai-agents/ — 端到端记忆架构术语、Client-side vs Server-side 分类、Anthropic Memory and Dreaming 产品分析。

4. Mem0 Research. "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory." ECAI 2025. arXiv:2504.19413. https://arxiv.org/abs/2504.19413 — 首个跨 10 种记忆方法的横向对比论文，建立 LoCoMo 基准基线。

5. LongMemEval Authors. "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory." arXiv, 2024. https://arxiv.org/abs/2410.10813 — LongMemEval 基准测试的原始论文，定义六类记忆场景和知识更新评估方法。

6. Mem0 Engineering Team. "BEAM: Million-Token Agent Memory Benchmark." Mem0 Blog, 2026. https://mem0.ai/blog/state-of-ai-agent-memory-2026 — BEAM 基准测试数据来源，测试百万级和千万级上下文下的记忆系统表现（详见 Mem0 基准报告 BEAM 章节）。

7. Anthropic. "New in Claude: Managed Agents." Claude Blog, 2026. https://claude.com/blog/new-in-claude-managed-agents — Anthropic 官方介绍 Claude 原生记忆能力和 Memory and Dreaming 机制。

8. Mem0 AI. "memory-benchmarks." GitHub, 2026. https://github.com/mem0ai/memory-benchmarks — 开源评估框架，支持 LoCoMo、LongMemEval、BEAM 三大基准的可复现测试。