当我们谈论 AI Agent 的记忆系统时，大多数讨论集中在上下文窗口管理（Context Window Management）或简单的会话历史缓存。然而，对于需要 7×24 小时持续运行、主动预测用户意图的长期 Agent 而言，这些方案远远不够 —— 它们无法解决记忆的层次化组织、跨会话持久化、以及成本敏感的实时检索问题。memU 作为一个专为主动式 Agent 设计的记忆框架，通过创新的分层架构和双重检索模式，为这一领域提供了值得关注的工程实践。
主动 Agent 对记忆系统的核心挑战
传统的 RAG（检索增强生成）系统通常采用被动工作模式：用户发起查询，系统从知识库中检索相关内容，最后将结果注入 LLM 上下文。这种模式对于问答系统足够有效，但对于需要 “主动出击” 的 Agent 存在三个根本性缺陷。首先，被动检索无法支持 Agent 在用户提出需求之前主动准备上下文 —— 这恰恰是主动 Agent 的核心价值。其次，传统 RAG 缺乏对用户偏好、交互模式等 “软信息” 的持续学习能力，这些信息往往分散在大量非结构化对话中。再者，长期运行的 Agent 需要面对服务重启、容器漂移等运维场景，如果没有可靠的持久化机制，所有积累的用户洞察将付之东流。
memU 的设计正是围绕这三个挑战展开。其核心理念是将记忆视为一个可以像文件系统一样组织、遍历和扩展的结构化系统，而非简单的向量数据库查询。
三层记忆架构的设计逻辑
memU 采用了 Resource（资源层）、Item（条目层）和 Category（分类层）构成的三层记忆架构，这一设计直接借鉴了文件系统的层次结构思想，但在语义层面进行了深度适配。
资源层对应文件系统中的原始文件，存储对话记录、文档、图片等原始数据。在主动 Agent 场景中，这一层的作用是保留 “第一手资料”—— 当需要追溯某个决策的完整上下文时，资源层提供了可追溯的原始来源。资源层的访问通常用于需要高保真还原的场景，例如审计日志回溯或复杂故障排查。
条目层是记忆系统的核心执行层，对应文件系统中的具体文件。在 memU 中，每个条目（Item）代表一个从原始资源中提取的结构化事实、偏好或技能。条目具备丰富的元数据，包括创建时间、关联用户、置信度评分等，这些元数据为后续的精准检索提供了过滤和排序的基础。条目层的关键设计在于其 “即时可用性”—— 通过 memorize () API 处理后的条目会立即进入可用状态，无需等待批量处理完成。
分类层则类似文件系统中的目录结构，提供记忆的宏观组织能力。memU 支持自动分类（Auto-categorization）功能，新摄入的记忆会根据语义内容自动归入相应的主题类别。更重要的是，分类层支持 “上下文组装”—— 当 Agent 需要为特定场景准备上下文时，系统可以自动从多个相关类别中提取素材，形成连贯的背景知识。
这种三层架构的工程价值在于：它同时满足了 “快速检索” 和 “深度追溯” 两种需求。资源层保证信息不丢失，条目层提供高效的点查询能力，分类层则支持广度的上下文覆盖。
双重检索模式：RAG 与 LLM 的协同策略
memU 的 retrieve () API 提供了两种检索模式，分别对应不同的性能与成本权衡。
RAG 模式（method="rag"）基于向量嵌入的相似度计算，实现了毫秒级的快速检索。这种模式适合需要持续监控、实时建议的场景 —— 例如用户在浏览某个主题时，Agent 需要立即推送相关内容。由于只涉及嵌入向量计算，RAG 模式的运营成本极低，可以作为后台常驻任务运行。其局限在于只能发现 “字面相似” 的记忆，无法进行复杂的语义推理。
LLM 模式（method="llm"）则调用大语言模型进行深度推理。当用户的问题涉及隐含意图、多步推理或需要综合多个记忆碎片时，LLM 模式能够进行更智能的上下文组装。例如，当用户询问 “有什么新鲜事吗”，LLM 模式会结合用户的历史兴趣、最近的活动模式以及时事热点，综合判断哪些信息值得主动推送。memU 在此模式下的一个关键优化是 “提前终止”（Early Termination）—— 当模型判断已收集到足够上下文时，会主动停止进一步检索，避免无谓的 Token 消耗。
在实际部署中，一个高效的策略是将 RAG 模式作为 “第一道筛选器”，快速过滤出候选记忆集合，再由 LLM 模式进行精细排序和补充。这种两级检索架构在多个生产级系统中被验证有效，memU 将其产品化为开箱即用的 API。
持久化存储的工程实践
对于需要 7×24 小时运行的 Agent，记忆的持久化不仅是数据安全问题，更是服务连续性的基础。memU 支持多种存储后端，开发者可以根据场景选择合适的方案。
内存存储（In-Memory）适合开发调试和短期任务，其优势在于零配置、零延迟。在测试阶段，开发者可以通过简单的 python test_inmemory.py 快速验证记忆逻辑的正确性。
PostgreSQL 配合 pgvector 向量存储是生产环境的主流选择。memU 官方提供了 docker-compose 快速启动方案，只需一行命令即可启动支持向量检索的数据库实例。对于需要大规模部署的企业场景，PostgreSQL 的成熟生态提供了丰富的运维工具和监控集成。
云端部署方案（memu.so）则面向希望专注应用开发而不愿运维基础设施的团队。memU Cloud API 提供了 memorize、retrieve、categories 等完整接口，支持按调用量计费。值得注意的是，云端服务强调了 “持续学习”（Continuous Learning）的特性 —— 即使应用不主动调用 API，服务也会在后台持续处理已摄入的对话，提取新的记忆模式。
在存储配置方面，以下参数值得关注：向量维度需与嵌入模型匹配（使用 openai/text-embedding-3-small 时为 1536 维）；索引类型建议使用 HNSW 以平衡检索速度与召回率；pgvector 的近似最近邻搜索（ANN）参数 m 和 ef_construction 需要在实际数据量级上进行调优。
性能基准与落地建议
memU 在 Locomo 基准测试中达到了 92.09% 的平均准确率，这一数字涵盖了各类推理任务。对于主动记忆系统而言，准确率不仅关乎检索质量，更直接影响 Agent 主动建议的可靠性 —— 一次错误的主动推送对用户体验的负面影响远大于一次失败的被动查询。
部署建议方面，首先需要明确记忆的 “保质期” 策略：用户偏好类记忆具有较长的有效期（数周至数月），而任务上下文类记忆可能只需要保留数天。其次，监控指标应覆盖记忆项增长率、检索延迟分布、以及 LLM 模式调用频率 —— 后者是成本控制的关键。最后，建议为每个用户或会话设置独立的命名空间（通过 user_id 参数），既保证数据隔离，也便于后续的个性化分析。
综合来看，memU 为长时间运行的主动 Agent 提供了一个架构清晰、API 完善、性能可验证的记忆解决方案。其核心价值不在于某个单一技术的创新，而在于将记忆的摄取、组织、检索三个环节有机整合，并提供了灵活的后端选择。对于正在构建需要持续运行、主动服务能力的 AI Agent 的团队，memU 的三层架构设计值得作为记忆子系统选型的重要参考。
资料来源：memU GitHub 仓库（https://github.com/NevaMind-AI/memU）