Paper Notes

MIRIX: Multi-Agent Memory System for LLM-Based Agents

作者Yu Wang, Xi Chen
机构MIRIX AI
发表arXiv · 2025
参考GitHub

33分钟阅读

MIRIX: Multi-Agent Memory System for LLM-Based Agents

Paper: arXiv:2507.07957 Code: Mirix-AI/MIRIX Code reference: main @ 905984e (2026-04-27) Evaluation code reference: public_evaluation @ 33e4bde (2025-08-20)

1. 论文要解决什么问题？

MIRIX 的核心问题不是“给 Agent 加一个向量库”，而是让 LLM Agent 在长时间、跨模态、跨任务的真实使用中拥有可维护、可检索、可更新、可解释的长期记忆。作者认为现有系统的瓶颈主要有三类：第一，大量方案把记忆压成扁平事实或文本 chunk，缺少组合式结构，因此同一类检索机制要同时承担偏好、事件、文档、流程、凭据等完全不同的信息形态；第二，许多记忆系统仍以文本对话为默认输入，对屏幕截图、界面布局、地图、文档、语音转写等真实 Agent 场景支持不足；第三，原始输入尤其是高分辨率图像如果直接保存，会带来难以接受的存储和检索成本，而过度摘要又会丢掉后续问答所需的上下文。

这篇论文提出的 MIRIX 是一个面向 LLM Agent 的多 Agent 记忆系统。它把长期记忆拆成六种不同组件：Core Memory、Episodic Memory、Semantic Memory、Procedural Memory、Resource Memory 和 Knowledge Vault，并用 Meta Memory Manager 协调专门的 Memory Managers 来决定写入、更新、检索和组合。这个设计的直觉是：Agent 记忆不是单一数据结构，而是一组不同生命周期、不同访问权限、不同检索粒度、不同语义角色的信息仓库。比如用户名字和偏好应该像 profile 一样持续可见；某天某时发生的活动应该进入事件流；朋友关系和世界知识应该形成较稳定的语义图谱；订餐、报销、会议安排等操作步骤应该成为可复用流程；长文档和项目材料应保留为资源；密码、API key、联系人等敏感信息需要更严格的访问控制。

论文同时给出一个具体应用：桌面个人助手持续观察屏幕，把用户活动转成结构化记忆，并在用户提问时主动检索相关记忆。这个应用不是单纯 demo，而是论文实验 ScreenshotVQA 的来源：模型需要回答基于大量历史屏幕截图的问题。作者用这个设置展示 MIRIX 对多模态长期记忆的目标：不保存海量原图，而是把视觉经历转成可检索的结构化信息，从而在准确率和存储成本之间取得更优折中。

2. 背景定位与主要贡献

2.1 与 MemGPT / Letta / Mem0 / RAG 的差异

MIRIX 和 MemGPT/Letta 的相似点在于都承认上下文窗口有限，需要外部记忆；不同点在于 MIRIX 把“记忆类型”提升为一等公民。Letta 风格的记忆通常包含 core、recall、archival 等块，已经比纯 RAG 更结构化，但 MIRIX 进一步把事件、概念、流程、资源、凭据拆成不同 schema，并交给不同 manager 维护。Mem0 更强调从输入中提炼事实；MIRIX 则强调事实只是记忆的一部分，还需要处理时间序列、工作流、文档、敏感数据和屏幕视觉经历。

与普通 RAG 相比，MIRIX 的关键差异是写入侧的结构化。RAG 通常在查询时从向量库或 BM25 索引中找文本片段，系统本身不一定理解这些片段属于事件、偏好还是流程。MIRIX 先在写入时进行分类、摘要、去重和字段化，因此查询时可以更有针对性地选择组件和检索方法。换句话说，MIRIX 把一部分推理压力从“回答时临时拼上下文”前移到“记录时形成可用记忆”。这也是 LOCOMO 中多跳问题表现好的原因之一：如果写入阶段已经把分散对话中的事实合并成一个更完整的事件或语义项，回答阶段就不必完全依赖模型从长上下文里重新拼接。

2.2 论文贡献

  1. 六组件长期记忆架构：每个组件都有独立语义、字段结构和检索用途，覆盖用户 profile、事件、概念、流程、资源和敏感信息。
  2. 多 Agent 写入与检索工作流：Meta Memory Manager 负责路由和协调，专门 Memory Managers 并行更新各自组件，Chat Agent 在对话时主动检索并可触发更新。
  3. Active Retrieval：系统无需用户显式说“查一下记忆”，而是从当前输入推断主题，自动从各个组件中检索相关内容并注入提示词。
  4. 多模态长期记忆验证：在 ScreenshotVQA 上对比长上下文 Gemini 和 SigLIP 检索基线，在 LOCOMO 上对比现有文本记忆系统，展示准确率和存储效率优势。

3. 方法

3.1 总体架构：六类记忆不是标签，而是不同数据结构

Figure 1 解读：这张图只画出六个组件名称，但它实际上表达了 MIRIX 的主要设计选择：把长期记忆拆成职责不同的“库”。Core Memory 解决持续可见的身份和偏好；Episodic Memory 解决“什么时候发生了什么”；Semantic Memory 解决抽象知识和关系；Procedural Memory 解决可复用流程；Resource Memory 解决完整材料和多模态资源；Knowledge Vault 解决敏感信息。这样做的好处是检索时不必把所有历史混在一起，也方便对不同类型设置不同字段、权限和压缩策略。

Core Memory 存储高优先级、长期有效、对每次交互都可能有用的信息。论文沿用 MemGPT 的 persona/human 思路：persona 描述 Agent 的身份、语气和行为风格；human 描述用户姓名、偏好、稳定属性等。Core Memory 的关键不是大，而是始终可见且可控。论文提到当容量超过阈值时触发受控重写，以压缩表述但保留关键事实。对 Agent 来说，这相当于一个长期 profile，不适合放入普通向量检索中等待“碰巧召回”。

Episodic Memory 存储带时间戳的事件和活动。它面向“用户做过什么、什么时候发生、现在是否需要跟进”这类问题。字段包括事件类型、摘要、细节、actor 和 timestamp/occurred_at。这个组件类似结构化日历或活动日志，可以支持 recency、routine、pending action 等推理。比如“上周用户在研究哪篇论文”“昨天他们是否打开过某个项目文件”都应首先落到 episodic，而不是 semantic。

Semantic Memory 存储不依赖具体时间的抽象事实、概念和关系。它可以是世界知识，也可以是用户社交图谱或长期关系，例如某人是谁、与用户关系如何、有什么偏好。字段包括 name、summary、details、source。它和 episodic 的区别在于：semantic 更像知识库，强调概念稳定性；episodic 更像事件记录，强调发生时间和上下文。这个区分很重要，因为“John 喜欢 jogging”与“John 昨天邀请用户跑步”在检索、更新和过期策略上不同。

Procedural Memory 存储目标导向的流程和操作步骤，如报销流程、订会议、订餐、配置开发环境等。它既不是单次事件，也不是抽象事实，而是可重复调用的行动知识。字段包括 entry_type、summary 和 steps。这个组件让 Agent 可以从记忆中恢复“怎么做”而不仅是“知道什么”。如果把流程塞进普通事实库，后续执行时会丢失顺序、条件和操作粒度。

Resource Memory 存储用户正在处理的文档、转写、图片、PDF 文本、项目材料等。它适合保留较长或较完整的外部内容，使 Agent 能在长任务中引用、摘要和搜索材料。字段包括 title、summary、resource_type 和 content。这个组件与 semantic 的差异在于 Resource Memory 允许保留原始或摘录内容，服务于“这份文档里写了什么”而不是“抽象成一个稳定事实”。

Knowledge Vault 存储敏感或需要访问控制的信息，如凭据、书签、联系人、API key 等。字段包括 entry_type、source、sensitivity、secret_value 和 caption。论文强调高敏感项应避免 casual retrieval，防止在普通对话中泄漏。这个组件把隐私和安全显式纳入记忆架构，而不是让敏感内容与普通记忆混存在同一个向量库。

3.2 Active Retrieval：让检索成为默认行为

Figure 5 解读：Active Retrieval 针对的是很多记忆系统的交互缺陷：用户必须显式提醒模型“去查记忆”。图中示例是 Agent 在回答“Who is the CEO of Twitter”这类问题时，先基于当前输入生成主题，再从各类记忆中检索，之后判断是否需要更细粒度搜索或换用其他检索函数。这个流程的价值在于把检索变成默认动作，减少模型依赖过期参数知识的机会。

论文描述的 active retrieval 分两步。第一步，系统根据当前输入和上下文生成当前 topic；第二步，用 topic 从六类记忆中检索相关条目，并按来源标签注入系统提示词。代码中的 retrieve_memory_with_conversation 会先从对话消息中抽取 topic 和时间表达，再把关键词、时间范围等传给后续检索函数；search_memory 支持指定 memory_type、search_field、search_method 和 limit。这说明论文中的 active retrieval 并非只是一句 prompt，而对应到服务端 API 的 topic extraction、temporal parsing、component filtering 和 multi-method search。

MIRIX 支持多种检索函数：embedding、BM25 和 string match。向量检索适合语义近似问题；BM25 适合关键词明确、字段较短的检索；string match 适合精确名称、标识符、凭据标题等。论文没有把某一种检索方法神化，而是让 Agent 根据上下文选择。这个设计符合多组件架构：不同记忆组件字段不同，单一向量检索不一定总是最佳。

3.3 写入工作流：先粗检索，再路由给专门 manager

Figure 6 解读：更新流程从 User Input 开始，但不是直接把输入保存到数据库。系统先查已有 Memory Base，把检索结果和新输入一起交给 Meta Memory Manager；Meta Memory Manager 判断哪些组件相关，再把任务发给对应 Memory Managers。各 manager 更新自己的 memory base，并把结果汇报给 meta 层。这个流程体现了“写入前先查重、先定位”的思想，避免同一事实在多个组件里重复或互相冲突。

写入工作流的一个核心细节是先检索再写入。没有这一步，系统很容易把“用户更正了一个事实”当成新事实追加，或者把一次事件写成多个重复条目。MIRIX 让 Meta Memory Manager 先看到已有相关记忆，再决定是 create、update、delete 还是忽略。每个 Memory Manager 只负责自己组件内部的一致性，因此系统可以并行处理多种记忆：同一段输入可能同时更新 core preference、生成 episodic event、补充 semantic relationship，并把长文档放入 resource。

3.4 查询工作流：Chat Agent 先粗召回，再决定细查

Figure 7 解读：查询流程中 Chat Agent 收到用户问题后先调用 search_in_memory() 进行跨组件粗检索，得到 memory base 的摘要结果；随后 Chat Agent 判断是否需要针对某些组件做更细的搜索，最后整合结果生成回答。如果用户问题本身包含新事实或更正，Chat Agent 还可以与 Memory Managers 交互进行更新。这使查询不只是“读库”，而是读写闭环的一部分。

这套查询流程的优势在于可控地扩大上下文。全量上下文方法把所有历史塞进 prompt，受窗口和成本限制；普通 RAG 可能只召回若干 chunk，缺少组件语义；MIRIX 先拿 high-level summary 判断方向，再选择更细检索。这样可以把短问题映射到恰当记忆类型，例如“我上次打开的那份 proposal 叫什么”倾向 episodic/resource；“John 和我是什么关系”倾向 semantic；“怎么报销差旅”倾向 procedural；“我的 API key 是什么”倾向 knowledge vault 且需要权限保护。

3.5 应用形态：桌面、可穿戴、记忆市场

Figure 2 解读：Chat Window 展示 MIRIX 作为个人助手的前端形态。论文实现使用 React-Electron 前端和 Uvicorn 后端，目标是让系统持续跟踪屏幕活动并在用户自然语言提问时调用结构化记忆。这里的重点不是 UI，而是把实时屏幕观察、长期记忆写入和聊天检索组合成一个闭环产品。

Figure 3 解读：Semantic Memory 可以以树状结构组织，例如社交网络、收藏、运动、宠物、音乐等类别。这个例子说明 MIRIX 的 semantic 不是无结构文本堆，而是可以被浏览、聚合和维护的知识层。对于个人 Agent，这种结构能让用户检查系统“记住了什么”，也便于纠正错误。

Figure 4 解读：Procedural Memory 的列表视图强调可执行流程的复用。与 semantic tree 相比，procedural 更关注步骤、顺序和行动条件。它适合记录“如何完成某件事”，例如 IDE 配置、内部系统报销、会议预订或特定项目的运行流程。

论文还讨论了两个扩展用例。其一是可穿戴设备：用户每天产生连续视觉和语音经历，MIRIX 可以把这些经历压缩成可查询的结构化记忆，减少原始录制保存成本。其二是 Agent Memory Marketplace：记忆可以成为可迁移、可购买或可共享的知识资产，例如某个领域专家的 workflow memory 或 resource memory。但这也引出隐私和权限问题，尤其是 Knowledge Vault 和个人化 episodic 记录不能无条件共享。

3.6 与代码对应的实现理解

Code reference: main @ 905984e (2026-04-27); evaluation scripts additionally checked on public_evaluation @ 33e4bde (2025-08-20).

Paper ConceptSource FileKey Class/Function
Core Memory / persona / human blocksmirix/schemas/memory.py, mirix/services/block_manager.pyMemory, BasicBlockMemory, ChatMemory, block CRUD
Episodic Memorymirix/schemas/episodic_memory.py, mirix/services/episodic_memory_manager.pyEpisodicEventBase, EpisodicEvent, EpisodicMemoryManager
Semantic Memorymirix/schemas/semantic_memory.py, mirix/services/semantic_memory_manager.pySemanticMemoryItemBase, SemanticMemoryItem, SemanticMemoryManager
Procedural Memorymirix/schemas/procedural_memory.py, mirix/services/procedural_memory_manager.pyProceduralMemoryItemBase, ProceduralMemoryManager
Resource Memorymirix/schemas/resource_memory.py, mirix/services/resource_memory_manager.pyResourceMemoryItemBase, ResourceMemoryManager
Knowledge Vaultmirix/schemas/knowledge_vault.py, mirix/services/knowledge_vault_manager.pyKnowledgeVaultItemBase, KnowledgeVaultManager
Active retrieval APImirix/server/rest_api.pyretrieve_memory_with_conversation, retrieve_memory_with_topic, search_memory
多组件列举 / 前端查看mirix/server/rest_api.pylist_memory_components, list_memory_fields
Client 使用方式mirix/client/client.py, README.mdMirixClient.initialize_meta_agent, add, retrieve_with_conversation
论文实验代码public_evaluations/*.py on public_evaluation branchmain.py, evals.py, agent.py, run_instance.py

从代码看，六种记忆在 schema 层确实被分成不同 Pydantic/SQLAlchemy 风格对象。Episodic 的核心字段是 event_type / summary / details / actor / occurred_at；Semantic 是 name / summary / details / source；Procedural 是 entry_type / summary / steps；Resource 是 title / summary / resource_type / content；Knowledge Vault 是 entry_type / source / sensitivity / secret_value / caption。这些字段与论文方法基本一致，说明论文的组件拆分不是只存在于图示，而是进入了服务端数据模型和 manager 层。

检索实现上，manager 层普遍包含文本清洗、BM25 预处理、embedding 字段解析和 PostgreSQL full-text search 相关逻辑。rest_api.py 的 search_memory 暴露 memory_type、search_field、search_method、limit、时间范围和 filter tags；_precompute_embedding_for_search 避免对每个组件重复计算 query embedding；retrieve_memory_with_conversation 会从对话抽取 topic 与 temporal expression，再调用统一检索路径。也就是说，MIRIX 在工程上不是单个“memory retrieval prompt”，而是 API、schema、manager、embedding、BM25 和客户端配置共同组成的系统。

伪代码（基于论文流程和 rest_api.py / manager 层结构）：

def add_memory(user_id, meta_agent_id, messages):
    existing = retrieve_memories_by_keywords(user_id, topics_from(messages))
    route_plan = meta_memory_manager.decide_components(messages, existing)
    updates = []
    for component in route_plan.components:
        manager = manager_for(component)
        # manager 内部根据已有条目决定 create / update / skip
        updates.append(manager.apply(component.payload, existing[component]))
    return meta_memory_manager.ack(updates)
 
def retrieve_with_conversation(user_id, messages, limit=10):
    topics, temporal_range = extract_topics_and_temporal_info(messages)
    coarse = search_memory(
        user_id=user_id,
        query=topics,
        memory_type="all",
        search_method="embedding",
        limit=limit,
        start_date=temporal_range.start,
        end_date=temporal_range.end,
    )
    refined = []
    for need in chat_agent.decide_refinement(messages, coarse):
        refined.extend(search_memory(
            user_id=user_id,
            query=need.query,
            memory_type=need.memory_type,
            search_field=need.field,
            search_method=need.method,  # embedding / bm25 / string_match
            limit=need.limit,
        ))
    return chat_agent.answer(messages, coarse, refined)

这段伪代码的关键在于：写入时先看旧记忆再更新，查询时先粗检索再细查；Meta/Chat Agent 不直接操作所有数据库细节，而是通过 manager 和统一 API 组织组件。

4. 实验

4.1 ScreenshotVQA：多模态长期记忆压力测试

ScreenshotVQA 是论文自建的多模态数据集，来自三位 PhD 学生活动，序列中包含大量高分辨率电脑截图。任务要求系统根据历史截图回答问题，因此它检验的不是单张图 VQA，而是长期视觉经历的记忆、压缩和检索。这个设置对现有文本记忆系统不友好，因为 Letta、Mem0 等主要处理文本输入；论文因此主要对比两个能处理视觉信息的基线：长上下文 Gemini 和 SigLIP 检索加 Gemini 回答。

长上下文 Gemini 基线把截图缩放到 256×256，以便在上下文中塞入最近约 3600 张图，再由 Gemini 回答。这个方法近似“把原始历史直接给模型”，但受到上下文窗口和图像缩放损失限制。SigLIP@50 则先用 SigLIP 找 top-50 相关原图，再交给 Gemini 回答；它更接近视觉 RAG，但仍需保存大量原始高分辨率图片。MIRIX 使用 Gemini 作为处理骨干，把视觉输入转成结构化记忆，并以 sqlite 数据库大小计算存储。

Table 1 的结果如下：Gemini overall accuracy 为 0.1166，存储 236.70MB；SigLIP@50 overall accuracy 为 0.4410，存储 15.07GB；MIRIX overall accuracy 为 0.5950，存储 15.89MB。按论文解释，MIRIX 相比 SigLIP/RAG 类基线准确率提升约 35%，同时存储减少 99.9%；相比长上下文 Gemini，准确率提升约 410%，存储减少 93.3%。这些数字说明 MIRIX 的主要优势来自“先把视觉经历结构化”，不是靠保留更多原始图像。

对这个实验要谨慎理解：ScreenshotVQA 的规模和来源较小，只有三位参与者活动；LLM-as-a-Judge 依赖 GPT-4.1 判断答案是否正确；MIRIX 用 Gemini 系列作为多模态处理骨干，和基线之间仍可能存在提示词、检索策略、图片预处理等实现差异。但这个任务确实展示了一个重要趋势：如果 Agent 每天要看成千上万张屏幕截图，直接保存和检索原图不是可持续方案，结构化记忆能显著降低存储和上下文成本。

4.2 LOCOMO：文本长期对话记忆

LOCOMO 是长对话记忆评测。论文沿用 Mem0 的设置，包含 10 段对话，每段约 600 轮、平均 26000 tokens，并为每段生成约 200 个问题。问题类型包括 single-hop、multi-hop、temporal、open-domain，论文排除 adversarial 类以与先前工作公平比较。评价指标仍是 LLM-as-a-Judge：用 GPT-4.1 根据问题、标准答案和系统回答判断是否成功回答。

实现细节上，MIRIX 在 LOCOMO 使用 gpt-4.1-mini 作为骨干，因为多 Agent 写入需要大量 function calling，作者认为它比 gpt-4o-mini 更适合。LangMem、RAG-500、Mem0 等基线使用 Mem0 提供的评测代码并设置模型为 gpt-4.1-mini；Zep 使用官方代码并替换骨干模型。MIRIX 和 Full-Context 运行三次取平均，部分 baseline 运行一次。论文还指出完整评测代码和预测结果放在官方仓库 public_evaluation 分支。

Table 2 中 MIRIX 的得分为：Single-Hop 85.11，Multi-Hop 83.70，Open Domain 65.62，Temporal 88.39，Overall 85.38。Full-Context 作为近似上界得到 Overall 87.52；强基线 Zep 在 gpt-4.1-mini 组为 Overall 79.09；LangMem 在 gpt-4o-mini 组为 Overall 78.05；Mem0 为 62.47。MIRIX 接近 Full-Context，同时超过 open-source memory baselines，说明结构化记忆在长对话文本场景也有效。

论文对不同题型的解释值得注意。Single-hop 和 temporal 问题受益于显式字段化和时间戳；multi-hop 问题受益于写入时合并分散信息，例如一个事实需要从“某人四年前离开 hometown”和“hometown 是某地”两处拼接，MIRIX 可能已经把它记录成一个更完整事件；open-domain 问题的优势较小，因为这类问题要求更全局的长期推理，MIRIX 虽然不是普通 RAG，但仍依赖检索得到局部上下文，缺少全局理解仍可能成为瓶颈。

4.3 实验结论的边界

这篇论文的实验证明 MIRIX 在两个方向上有潜力：多模态屏幕记忆的存储效率，以及长文本对话记忆的问答准确率。但它不是严格意义上“所有 Agent 记忆任务的通用胜利”。首先，ScreenshotVQA 数据集较新且规模有限，外部系统很难完全复现；其次，LLM-as-a-Judge 可能对回答风格和证据表述敏感；第三，多 Agent 写入会带来成本和延迟，尤其每段输入可能调用 meta manager 和多个 component managers；第四，结构化写入依赖 LLM 正确分类和抽取，一旦写入错位，后续检索再强也可能召回错误记忆。

5. 个人理解：为什么这个工作重要？

MIRIX 的价值在于把 Agent memory 从“检索增强上下文”推进到“长期信息操作系统”。如果把所有历史都存在一个向量库里，系统只解决了存储位置问题，没有解决信息类型、生命周期、权限、更新冲突和可解释性问题。MIRIX 的六组件划分未必是最终答案，但它给出一个实用框架：不同记忆应有不同 schema，不同 manager，不同检索策略，以及不同用户可见性。

我认为最关键的设计是写入侧结构化。很多 Agent 失败并不是因为检索器找不到东西，而是因为历史从未以适合未来使用的形式被保存。比如屏幕截图中用户打开了某个表格、复制了一段命令、提交了一个表单，如果只保存图片，后续问题需要重新视觉理解；如果只保存 OCR 文本，界面布局和上下文丢失；如果由 memory manager 在当时抽取出事件、资源和流程，后续查询就更便宜、更准确。MIRIX 正是把这个“当时理解并整理”的过程系统化。

另一个值得借鉴的点是 Knowledge Vault。许多个人助手天然会遇到敏感信息，但学术 Agent 论文常把隐私作为一句未来工作。MIRIX 至少在架构层给敏感记忆单独组件、敏感度字段和检索排除逻辑，使“能记住”和“该不该随便说出”分开。实际产品中还需要更强的加密、审计、权限确认和用户可删除机制，但把敏感记忆从普通语义库分离是正确方向。

6. 局限与后续问题

成本与延迟：多 Agent 写入意味着每次输入可能触发 meta manager、0 到 6 个 memory managers、embedding 和数据库写入。对于实时桌面助手，这会增加响应延迟和 API 成本。论文展示了准确率和存储优势，但没有充分量化端到端延迟、token 成本、并发写入冲突和长时间运行稳定性。

写入错误的累积：MIRIX 强调写入时抽取和归类，但 LLM 可能误分类、过度概括或把临时事件写成长期事实。Core Memory 如果错误写入，会对所有后续交互产生持续影响；Knowledge Vault 如果错误处理，会带来安全风险。因此实际系统需要用户可视化审查、撤销、冲突检测和置信度机制。

全局推理仍依赖检索：LOCOMO 中 open-domain 题型差距较小，说明即使结构化记忆能减少局部拼接负担，长程全局推理仍困难。未来可以考虑在 episodic/semantic 之上建立更高层的周期性总结、因果链、任务图或用户状态模型，避免每次都从局部条目开始拼接。

评价覆盖有限：ScreenshotVQA 很贴近桌面助手，但数据来源少；LOCOMO 是文本长对话，不能完全代表生产环境中的多应用、多用户、多权限、多设备记忆。后续需要更大规模、可公开复现、包含隐私与删除需求的 benchmark。

7. 复现与使用要点

官方仓库当前 main@905984e 提供可运行的 MIRIX 服务端、dashboard、client 和 memory managers。README 的最小路径是 Docker 启动 backend/dashboard，在 dashboard 创建 API key，然后用 mirix-client 初始化 meta agent。初始化配置中需要 LLM config、embedding config 和 meta agent 的 agents 列表，通常包括 core memory agent、resource、semantic、episodic、procedural 和 knowledge vault agents。随后客户端通过 add 写入消息，通过 retrieve_with_conversation 按用户和对话上下文检索记忆。

如果目的是复现实验而不是试用产品，应关注 public_evaluation@33e4bde 分支下的 public_evaluations/。论文明确说 LOCOMO 和 ScreenshotVQA 的评测代码与预测结果在该分支。主分支是持续演进的产品代码，可能已经与论文实验版本存在差异；因此结果复现应固定分支、模型版本、评测脚本、judge 模型和环境变量。

最适合从 MIRIX 借鉴的工程模式是：

  • 先定义记忆类型和字段，再选检索器；不要先建一个向量库再把所有历史塞进去。
  • 写入前做已有记忆检索和冲突检查；不要把每次输入都无脑 append。
  • 查询时先粗检索，再由 Agent 判断需要哪个组件、哪个字段、哪种检索函数。
  • 敏感信息独立管理，并在默认检索路径中限制暴露。

8. 速记

MIRIX = 六类结构化长期记忆 + Meta Memory Manager + 专门 Memory Managers + Active Retrieval。它在 ScreenshotVQA 上用 15.89MB sqlite 记忆达到 0.5950 overall accuracy，优于 SigLIP@50 的 0.4410 且存储小几个数量级；在 LOCOMO 上 overall 85.38，接近 Full-Context 87.52。核心启发是：Agent 记忆系统的难点不只是检索，而是把长期经历写成未来可用、可维护、可审查的结构化记忆。