在构建长时间运行的主动代理系统时，一个核心挑战是如何让代理在无人交互的间隙持续学习和记忆。传统方案依赖会话级别的上下文窗口，每次启动都需要重新加载历史对话，导致高昂的 token 消耗且无法形成真正的长期记忆。MemU 框架针对这一痛点，设计了一套专为 24/7 主动代理服务的持久内存运行时架构，其核心理念是将记忆存储从代理推理流程中解耦，实现后台持续学习与前台低延迟查询的分离。
24/7 主动代理的记忆困境
传统的会话式 AI 架构将记忆管理责任完全交给 LLM 上下文，这种设计在短对话场景下运作良好，但面对需要「始终在线、主动服务」的代理时暴露出明显的局限性。当代理进入空闲状态时，所有积累的上下文信息只能随会话终止而丢失，下次启动必须从头开始。更关键的是，即便使用长上下文窗口模型，持续累积的历史对话也会产生高昂的推理成本，使得 24/7 运行模式在经济上不可行。
MemU 的设计思路是建立一个独立于推理流程的持久记忆层。代理的核心职责被简化为处理用户查询和执行任务，而记忆的捕获、理解和预测功能由 MemU 运行时在后端持续运行。这种架构分离带来了三个关键收益：第一，记忆存储不再受限于单次会话的生命周期，代理可以在后台默默观察和学习用户的习惯与偏好；第二，推理时的上下文体积可以显著压缩，因为大量历史信息已经被结构化地存储在记忆层中；第三，系统可以支持多个代理实例共享同一份记忆基础，实现协同式的上下文构建。
三层分层记忆架构的设计权衡
MemU 采用资源（Resource）、项目（Item）和类别（Category）三层记忆结构，这一设计并非简单地将信息按粒度拆分，而是针对不同的访问模式进行了深度优化。资源层存储原始数据，包括对话记录、文档内容、用户上传的文件等，其价值在于提供可追溯的事实来源。类别层则维护抽象程度更高的主题概览，用于快速判断哪些记忆与当前查询相关。项目层是实际检索的主力，存储从原始数据中提取的具体事实、偏好声明和技能模式。
这种分层设计的精妙之处在于它同时服务于反应式查询和主动式上下文加载两种场景。在反应式查询中，系统直接从项目层检索相关事实，必要时回溯到资源层获取原始证据。在主动式上下文中，类别层的自组织特性发挥作用 —— 当新的记忆被写入时，系统会自动将其归类到现有主题下，或者在必要时创建新主题。这种机制消除了手动标签管理的负担，同时确保记忆结构能够随时间有机演进。
从工程实现角度，三层架构还带来了存储成本的优化。原始资源的存储成本最高（通常需要完整的文本或多媒体内容），而项目和类别层可以采用更高压缩率的表示方式。在检索时，系统可以根据场景需求决定访问深度：简单的偏好查询可能只需要项目层的结构化记录，而复杂的推理任务则可以回溯到原始资源获取完整上下文。
记忆写入与增量同步机制
MemU 的 memorize () API 承担了将原始输入转化为结构化记忆的核心职责。该 API 接受资源 URL、模态类型和可选的用户作用域参数，返回包含原始资源元数据、提取的记忆项目和自动更新的类别结构的复合结果。设计的关键约束是零延迟处理 —— 记忆写入后立即可查询，这与传统的批处理式知识库更新形成鲜明对比。
增量同步机制是支撑 24/7 运行的技术基础。当代理持续与用户交互时，MemU 会在后台监控输入输出流，实时提取新的事实和偏好，并将其注入记忆层。整个过程对代理主流程透明，无需显式调用记忆保存操作。系统会自动处理新旧记忆的合并、冲突消解和去重，确保记忆库的一致性不受高频更新的影响。
从实际部署参数来看，PostgreSQL 配合 pgvector 是生产环境的推荐组合。Docker 容器化部署时，需要确保数据库连接池大小与预期并发查询量匹配 —— 在多代理共享记忆的场景下，建议将 max_connections 设置为代理实例数的两倍以上，并为向量检索预留足够的 shared_buffers 内存。embedding 服务的调用频率是另一个需要监控的指标：当记忆写入量较大时，embedding API 的调用成本可能成为主要支出项。
双模式检索的工程权衡
retrieve () API 提供了两种检索策略，分别对应不同的延迟和成本预算。RAG 模式（method="rag"）完全依赖向量相似度进行记忆检索，其优势在于毫秒级的响应速度和仅涉及 embedding 模型的推理成本。该模式适合需要快速响应的实时建议场景，例如在用户输入过程中即时补全相关的历史偏好。
LLM 模式（method="llm"）则引入了大语言模型进行深度推理，能够实现意图预测和查询演化。当用户提出模糊或部分表述的需求时，LLM 模式会主动推断完整的上下文需求，并在检索过程中动态调整搜索策略。该模式还支持提前终止 —— 当收集到的上下文已经足够回答问题时，系统会停止进一步的检索以节省成本。
生产环境中的常见配置策略是采用分层路由：高频、简单的查询走 RAG 模式，确保低延迟体验；低频、复杂的查询走 LLM 模式，获取深度推理能力。系统还支持在 retrieve () 调用中传入多轮对话历史，这对于需要综合考虑多轮上下文的场景尤为重要。where 参数用于限定检索范围，可以按 user_id、agent_id 等维度进行隔离，这在多租户部署时是必备的安全隔离机制。
生产部署的关键参数
自托管部署时，Python 3.13 是官方要求的最低版本，这一限制源于 MemU 对某些现代语言特性的依赖。环境配置需要特别注意 OPENAI_API_KEY 或等效的模型服务密钥。对于使用国内模型服务的场景，MemU 支持通过 llm_profiles 配置自定义 base_url—— 阿里云 DashScope、智谱 AI 等兼容 OpenAI 接口规范的模型服务都可以直接接入。
嵌入模型的选择对检索质量有直接影响。MemU 默认使用 OpenAI 的 text-embedding-3-small，这是一个在成本和效果之间取得平衡的选择。对于需要更高检索精度的场景，可以切换到 text-embedding-3-large 或 Voyage AI 的专用模型。值得注意的是，不同 embedding 模型产生的向量维度不同，这会影响向量数据库的索引配置 ——pgvector 的 ivfflat 索引需要根据实际维度调整 lists 参数以获得最佳的召回率。
性能基准方面，MemU 在 Locomo 评测中取得了 92.09% 的平均准确率，涵盖各种推理任务的主动记忆操作。这一指标可以作为部署时的参考基线，但实际表现会受到记忆库规模、查询复杂度和底层模型能力的共同影响。建议在生产环境建立自己的评估集，定期监控检索命中率和服务延迟。
资料来源：GitHub 仓库 NevaMind-AI/memU。