记忆拓展：独立部署Mem0服务，打通多Agent共享记忆

    上篇我们通过Dify的Mem0插件+pgSQL，跑通了跨会话的持久化记忆，让一个Dify应用拥有了“长期记忆”。但如果是多个Dify应用，或者架构中还混用了OpenClaw、Hermes等不同Agent框架，问题就来了：

    每个应用各记各的，数据割裂，互不相通。

    试想下，早上在Dify客服助手那儿说“我喜欢简洁的回答”，下午在OpenClaw的周报助手里又得重复一遍——这种体验，算不上真正的智能。有没有办法让所有Agent共享一个记忆库？

    答案是：独立部署Mem0服务。

    💡 Dify现成的插件模式是让一个AI认得你；私有化部署是让所有AI都认得你。前者是“记忆”，后者是“人格”。

1. Mem0私有部署的核心优势

    ⚡ 速度提升91%：相比OpenAI原生的Memory方案，检索延迟大幅降低

    🚀 准确率提升26%：在权威基准测试中表现优异

    💰 Token消耗减少90%：智能提取与更新机制，不浪费每一个Token

    🔐 数据完全自主：私有化部署，记忆数据不出内网

    此外，Mem0还支持：Reranker模型——实现更精准的检索召回；Neo4j图数据库——构建记忆关系网络，支持“A和B是什么关系？”这类复杂查询，适用于企业级知识图谱和推荐系统。

2. Mem0四层标识体系

    真正让“跨应用共享”成为可能的，是其底层设计的四层标识体系。它通过四个维度精确控制记忆的归属与访问范围：

    写入记忆：每条记忆同时携带四个标识，形成多维归属关系，精准写入。

     查询记忆：灵活组合任意标识，实现从“全量共享”到“精确隔离”的自由检索。

    🌰 一个完整的场景：小明吃火锅

    我们以用户"小明"在不同餐饮相关应用中的使用场景为例，直观感受四层标识如何运作。他在美食助手和门店推荐两个应用中的记忆流转如下：

用户小明 (user_id: "xiaoming_001")│├── Dify美食助手应用 (app_id: "dify_food_assistant")│   ││   ├── 菜谱查询助手 (agent_id: "recipe_agent")│   │   ├── 会话A (run_id: "session_A")│   │   │   └── 记忆：小明查询麻辣火锅底料配方，说自己爱吃特辣│   │   └── 会话B (run_id: "session_B")│   │       └── 记忆：小明询问毛肚涮多久最嫩，表示不喜欢吃羊肉│   ││   └── 该应用下小明的汇总记忆：│       ├── 口味偏好：特辣、重油│       ├── 禁忌：不吃羊肉│       ├── 必点菜：毛肚、鸭肠、黄喉│       └── 锅底偏好：牛油麻辣锅│└── Dify门店推荐应用 (app_id: "dify_store_recommend")    │    └── 门店推荐助手 (agent_id: "store_agent")        ├── 会话C (run_id: "session_C")        │   └── 记忆：小明在地铁2号线附近，想吃正宗重庆老火锅        └── 会话D (run_id: "session_D")            └── 记忆：小明反馈某家火锅店排队太久，希望推荐不用排队的

    结合这个案例，可以推演出3种典型的记忆查询情景：

    💡 四层标识体系，让记忆在“共享”与“隔离”之间自由穿梭，即独立部署Mem0的灵魂所在！

    💡 硅基流动平台提供丰富的模型选择，可按需替换模型，比如embedder模型bge-large-zh-v1.5也可以换为bge-m3。

• 克隆官方仓库

git clone https://github.com/mem0ai/mem0.git mem0-main

    ⚠️ 注意：如果GitHub访问慢，可使用代理，但可能同步的不是最新版本，关注本公众号，后台【私信】里回复“手抄报”可获取本项目代码（6月25日下载）。

https://gitclone.com/github.com/mem0ai/mem0.git mem0-main

• 编辑mem0启动配置

    进入mem0的服务目录，并关注以下4个文件。

cd mem0-main/server

    （1）文件docker-compose.yaml（保持默认）

    笔者曾尝试将服务端口从8888改为其他端口号，但Dashboard疑似硬编码依赖8888端口，故放弃修改，保持默认。

    （2）文件.env

    复制模板文件并编辑。

cp .env.example .env

    关键配置如下：

# === 鉴权配置 ===ADMIN_API_KEY=mem0-local-dev-keyJWT_SECRET=super-secret-jwt-key-for-local-dev-1234567890AUTH_DISABLED=false
# === 硅基流动 API 配置 (兼容 OpenAI 接口) ===OPENAI_API_KEY=sk-***（填自己的秘钥）OPENAI_BASE_URL=https://api.siliconflow.cn/v1
OPENAI_TIMEOUT=120# === 模型选择 ===MEM0_DEFAULT_LLM_MODEL=Qwen/Qwen2.5-72B-InstructMEM0_DEFAULT_EMBEDDER_MODEL=BAAI/bge-large-zh-v1.5

    💡 JWT_SECRET可用命令 openssl rand -base64 32 生成，简单起见也可直接自定义字符串。

    （3）文件env.Dockerfile

    由于docker-compose.yaml中指定使用该Dockerfile构建，建议修改以加速依赖安装：

FROM python:3.12WORKDIR /app# 从清华TUNA镜像站下载Poetry，绕开PyPI国内访问不稳的问题ENV POETRY_INSTALLER_REPO=https://mirrors.tuna.tsinghua.edu.cn/python-poetry/RUN curl -sSL https://install.python-poetry.org | python3 -# ... 其余保持不变

    （4）文件main.py

    笔者选用BAAI/bge-large-zh-v1.5作为Embedding模型，向量维度为1024。但Mem0项目默认使用OpenAI的text-embedding-ada-002模型，维度为1536，且未提供环境变量映射。因此需在main.py的DEFAULT_CONFIG中指定维度1024。

DEFAULT_CONFIG = {"version": "v1.1","vector_store": {"provider": "pgvector","config": {"host": POSTGRES_HOST,"port": int(POSTGRES_PORT),"dbname": POSTGRES_DB,"user": POSTGRES_USER,"password": POSTGRES_PASSWORD,"collection_name": POSTGRES_COLLECTION_NAME,"embedding_model_dims": 1024,  # ← 新增：指定向量维度# ... 其余保持不变

• 启动Mem0服务

    在mem0-main/server下执行：

docker compose up -d --build

    等待镜像拉取和容器启动完成。

    验证服务状态：

docker compose ps

    看到3个服务均为Up状态，表示启动成功。

• Mem0接口测试

    Mem0采用懒建表模式——只有在第一次写入记忆时，才会自动触发memories表的创建，并验证LLM提取记忆的能力。

curl -X POST http://localhost:8888/memories \  -H "Content-Type: application/json" \  -H "X-API-Key: mem0-local-dev-key" \  -d '{    "messages": [      {"role": "user", "content": "我喜欢吃火锅，尤其是麻辣锅底。"},      {"role": "assistant", "content": "好的，记住了。"}    ],    "user_id": "user_001"  }'

    返回结果中，记忆内容是以英文写入的——这是REST API默认行为，稍后我们会解决这个问题。

    先确认向量维度是否为1024：

docker exec mem0-dev-postgres-1 psql -U postgres -d mem0_app -c "\d memories"

    查看落库数据：

docker exec mem0-dev-postgres-1 psql -U postgres -d mem0_app -c "SELECT id, payload->>'user_id' AS user_id, vector_dims(vector) AS dim FROM memories LIMIT 5;"

    可以看到刚才写入的记忆已成功存储。

curl -X POST http://localhost:8888/search \-H "Content-Type: application/json" \-H "X-API-Key: mem0-local-dev-key" \-d '{"query": "我喜欢吃什么？","user_id": "user_001"}'

    返回结果中的记忆内容与写入时一致（虽然仍是英文），至此功能验证通过。

    💡 补充：如何让记忆存储为中文？

    测试发现写入的是中文，存储和检索出来的却是英文。原因在于：

    - REST API（curl方式）：默认不指定语言参数，Mem0会以英文存储记忆

    - Python SDK方式：支持通过参数指定语言

    如果希望在REST API方式下也存储中文，可以在main.py的DEFAULT_CONFIG中增加custom_instructions字段：

DEFAULT_CONFIG = {    "version": "v1.1",    "vector_store": {        "provider": "pgvector",        "config": {            # ...            "embedding_model_dims": 1024,            }        },    "llm": { ... },    # ↓↓↓ 与 llm、vector_store 平级添加 ↓↓↓    "custom_instructions": "请始终用中文提取和存储记忆，保留用户的原始语言和表达习惯。",}

    重启服务即可生效：

docker compose restart mem0

    之后Mem0提取的记忆就会老老实实是中文了。

    ⚠️  调试小贴士：如需彻底重置环境（删除所有数据），执行：

docker compose down -v # 删除容器+数据卷docker compose up -d # 重新启动

• Mem0可视化管理控制台

    启动的容器中包含一个Dashboard服务（端口3000），提供可视化记忆管理功能，包括请求日志查看、记忆删除、系统健康状态监控、API Key管理等。

    浏览器访问http://localhost:3000，首次启动会进入初始化向导，需要填写管理员名称、邮箱、密码等，设置模型提供商：选择OpenAI（笔者采用硅基流动兼容OpenAI接口规范，可直接使用其API地址）。最后需要保存生成的API Key。

    完成向导后进入工作台，可以查看所有记忆操作的历史记录、按条件搜索和删除记忆、监控服务健康状态等。

4. 记忆写入的3种方式

方式	说明
REST API	通过/memories接口，本文已演示
Python SDK	更便捷的编程方式，推荐有开发能力的读者尝试
Swagger UI	访问http://localhost:8888/docs，页面直接填写参数并执行，适合快速调试，如下图

    至此，我们已经完整搭建了独立部署的Mem0服务，实现了跨应用、跨Agent的记忆共享基础！

🔥 小结

    我们从Dify内置的上下文记忆、会话变量，一路走到Mem0插件接入，再到独立部署跨应用共享记忆层——一条完整的Agent记忆能力进阶之路已经铺展在你面前。

    但如果你以为这就是终点，那就太小看“记忆”这两个字了。

    不妨把脑洞再开大一点：如果记忆不仅能被AI读取，还能被AI主动反思和归纳呢？

    想象这样一个场景——AI发现你三个月来反复搜索“Dify记忆”和“Mem0部署”，它主动总结：“用户正在系统学习Agent记忆能力。”然后在你下次提问时，它会说：“根据你之前的探索路径，我猜你可能对图记忆感兴趣，要不要深入聊聊？”

    这不再是简单的记忆存储，而是记忆的自我进化。如果你也想继续深挖，以下3个方向值得你重点关注：

• 图记忆（Mem0ᴳ）：让AI理解记忆之间的关系。不只是“用户喜欢火锅”，而是“用户喜欢火锅”和“用户是四川人”之间的关联——这才是真正的“理解”。

• 记忆的自动归纳与洞察：从“记住事实”到“理解模式”。AI不再只是回放你说过的话，而是能从碎片中拼出完整的你。

• 记忆的跨Agent同步：多个AI如何共享并维护同一套“人格”。你的Dify、OpenClaw、Hermes，在记忆层面真正融为一体。

    技术的终点从来不是“做完”，而是“想到还能做什么”。希望这三篇文章不只是给了你一套可运行的方案，更能点燃你对“AI记忆”这个方向的持续热情。