Hermes 的记忆系统一直有个让人纠结的地方:想用 Mem0 做跨会话记忆,就得把数据发到 Mem0 的云端。
对大部分人来说这没什么,但如果你像我一样,有些项目的数据不太想经过第三方服务器——比如公司内部代码、私人文档、或者就是单纯不想多一个外部依赖——那就只能不用 Mem0,退回到 Hermes 自带的内置记忆。
这个问题其实从 2024 年就有人提了,GitHub 上陆续开了 8 个 issue 都在请求同一个功能:支持自托管 Mem0。今天终于合进来了,PR #50479,teknium 亲自合并的。
Mem0 是什么
先简单说一下 Mem0 是干嘛的,老用户可以跳过这段。
Mem0 是一个专门给 AI Agent 用的记忆层。它不是简单的“把对话存下来”,而是会在服务端用 LLM 自动提取你对话里的事实、偏好、习惯,然后做语义搜索和去重。下次你跟 Agent 聊天的时候,它能自动调出相关记忆,不用你重复说。
Hermes 接入 Mem0 之后,跨会话记忆的质量会比内置记忆好不少——提取更准,召回更相关,而且有自动去重。
这次改了什么
改动很小,但很关键。核心就两个:
1. 新增 MEM0_HOST 环境变量
之前 Mem0 插件只认 MEM0_API_KEY,硬编码连 api.mem0.ai。现在加了 MEM0_HOST,你可以指定自己的 Mem0 服务器地址。
2. mem0.json 配置文件加了 host 字段
除了环境变量,也可以在 ~/.hermes/mem0.json 里写 host。
改完之后有四种情况:
| MEM0_HOST | MEM0_API_KEY | 结果 |
|---|---|---|
| 有 | 有 | 连自托管 + 带认证 |
| 有 | 没有 | 连自托管 + 无认证(适合本地开发) |
| 没有 | 有 | 连 Mem0 云端(跟之前一样) |
| 没有 | 没有 | 不可用 |
这个设计很合理——对云端用户完全无感,对自托管用户只需要多加一行配置。
第一步:部署自托管 Mem0
如果你已经有 Mem0 服务了,直接跳到第二步。
前置条件:
- Docker 和 Docker Compose
- 一个
OPENAI_API_KEY(Mem0 内部用它做事实提取和向量化) - 空闲端口:8888(API)和 3000(Dashboard)
开始部署:
# 克隆 mem0 仓库
git clone https://github.com/mem0ai/mem0.git
cd mem0/server
配置环境变量:
cp .env.example .env
编辑 .env,填入以下内容:
OPENAI_API_KEY=sk-你的key
JWT_SECRET=你的随机密钥
POSTGRES_PASSWORD=数据库密码
注意⚠️: OPENAI_API_KEY 没有的话可以用 ANTHROPIC_API_KEY 或者 GOOGLE_API_KEY,如果这仨都没有的话就不用安装了,我也不理解 mem0 的骚操作
JWT_SECRET 用这个命令生成一个:
openssl rand -hex 32
启动服务:
make up
等容器跑起来之后:
- API 地址:
http://localhost:8888 - Dashboard:
http://localhost:3000

初始化管理员:
首次打开 Dashboard 会跳转到设置向导,按步骤走就行:
1、创建管理员账号(名字、邮箱、密码)

2、确认 LLM 配置(这里我使用 Gemini,因为好歹还送点免费次数)

注意⚠️:如果要使用 gemini 的话,在 requirement.txt 文件中增加 google-genai>=1.0.0 重新编译
3、生成 API Key——只显示一次,立刻复制保存

4、可选:描述你的用途,Mem0 会自动生成记忆策略
如果你不想用浏览器,也可以命令行一键搞定:
make bootstrap
它会自动创建管理员并打印 API Key,不用开浏览器。
验证服务正常:
curl -X POST http://localhost:8888/v1/memories \
-H "Content-Type: application/json" \
-H "Authorization: Bearer m0sk_你的API_Key" \
-d '{"messages": [{"role": "user", "content": "我喜欢用深色主题"}], "user_id": "test"}'
看到返回成功就说明没问题。
第二步:配置 Hermes 连接自托管 Mem0
安装 mem0 Python 包:
pip install mem0ai
设置 Hermes 的记忆 provider:
hermes config set memory.provider mem0
写入连接信息:
# 指向你的自托管地址
echo "MEM0_HOST=http://localhost:8888" >> ~/.hermes/.env
# 如果你的 Mem0 开了 auth(默认是开的),还需要 API Key
echo "MEM0_API_KEY=m0sk_你的key" >> ~/.hermes/.env
如果你不想用环境变量,也可以直接编辑 ~/.hermes/mem0.json:
{
"host": "http://localhost:8888",
"api_key": "m0sk_你的key",
"user_id": "hermes-user",
"agent_id": "hermes",
"rerank": true
}
host 和 api_key 二选一或者都填都行。只填 host 不填 api_key 的话,适用于你把 Mem0 的 auth 关掉了(本地开发场景,.env 里设 AUTH_DISABLED=true)。
验证连接:
hermes memory status
应该能看到 mem0 provider 已激活,并且显示连接的 local 而不是 cloud。

之后正常用 Hermes 就行,它会自动把对话中的事实提取到你的 Mem0 服务器里。
如果你之前已经在用云端 Mem0
不需要做任何改动。不设 MEM0_HOST 的话,行为跟之前完全一样,还是连 api.mem0.ai。
想迁移到自托管的话,流程是:
- 部署自托管 Mem0
- 加上
MEM0_HOST - 重启 Hermes
记忆数据不会自动迁移——云端和自托管是两个独立的存储。不过 Mem0 的记忆是自动提取的,用几天就会在新服务器上积累起来。
几个注意事项
-
Mem0 自托管需要 OpenAI API Key——它内部用 LLM 做事实提取,这不是 Hermes 的要求,是 Mem0 自己的。如果你不想给 OpenAI 花钱,可以在 Mem0 的 Dashboard 里换成其他支持的 provider(Anthropic、Google Gemini 都行)。
-
端口别搞混——Mem0 自托管的 API 默认是 8888,Dashboard 是 3000。Hermes 的
MEM0_HOST要填 API 的端口,不是 Dashboard 的。 -
局域网访问——如果你的 Mem0 部署在 NAS 或者另一台机器上,
MEM0_HOST要写局域网 IP,比如http://192.168.1.100:8888,不能用localhost。 -
auth 默认开启——新版 Mem0 自托管默认启用认证,不设
AUTH_DISABLED=true的话,不带 API Key 的请求会被 401 拒绝。
说句实话
这个 PR 改动量不大,但解决的是一个存在了一年多的实际痛点。
我个人的看法是:如果你只是一个人用 Hermes,走云端 Mem0 完全没问题,省事。但如果你的数据有合规要求,或者你就是想把所有东西都控在自己手里——现在终于可以了,而且配置成本就两行环境变量。
Mem0 自托管的 Docker 部署也比较成熟了,Dashboard、API Key 管理、审计日志都有,不是那种“开源了但只能当玩具用”的状态。
值得更新。
PR 地址:https://github.com/NousResearch/hermes-agent/pull/50479 Mem0 自托管文档:https://docs.mem0.ai/open-source/setup Hermes Agent:https://github.com/NousResearch/hermes-agent