Memory Providers(记忆提供者)
Hermes Agent 附带 8 个外部记忆提供者插件,为代理提供超越内置 MEMORY.md 和 USER.md 的持久跨会话知识。一次只能激活一个外部提供者——内置记忆始终与其一同激活。
快速开始
hermes memory setup # 交互式选择器 + 配置
hermes memory status # 检查活动的提供者
hermes memory off # 禁用外部提供者您也可以通过 hermes plugins → Provider Plugins → Memory Provider 选择活动的记忆提供者。
或者手动在 ~/.hermes/config.yaml 中设置:
memory:
provider: openviking # 或 honcho、mem0、hindsight、holographic、retaindb、byterover、supermemory工作原理
当记忆提供者激活时,Hermes 会自动:
- 将提供者上下文注入到系统提示(提供者知道的内容)
- 预取相关记忆每次轮次前(后台,非阻塞)
- 同步对话轮次到提供者每次回复后
- 在会话结束时提取记忆(对于支持的提供者)
- 将内置记忆写入镜像到外部提供者
- 添加提供者特定的工具,以便代理可以搜索、存储和管理记忆
内置记忆(MEMORY.md / USER.md)继续完全像以前一样工作。外部提供者是补充性的。
可用提供者
Honcho
AI 原生跨会话用户建模,具有辩证推理、会话作用域上下文注入、语义搜索和持久结论。基础上下文现在包括会话摘要以及用户表示和对等体卡片,为代理提供了对已讨论内容的感知。
| 最佳用途 | 具有跨会话上下文的多代理系统、用户-代理对齐 |
| 需要 | pip install honcho-ai + API key 或自托管实例 |
| 数据存储 | Honcho Cloud 或自托管 |
| 成本 | Honcho 定价(云端)/ 免费(自托管) |
工具(5 个): honcho_profile(读/更新对等体卡片)、honcho_search(语义搜索)、honcho_context(会话上下文——摘要、表示、卡片、消息)、honcho_reasoning(LLM 综合)、honcho_conclude(创建/删除结论)
架构: 双层上下文注入——基础层(会话摘要 + 表示 + 对等体卡片,在 contextCadence 时刷新)加上辩证补充(LLM 推理,在 dialecticCadence 时刷新)。辩证自动根据是否存在基础上下文选择冷启动提示(一般用户事实)vs. 热提示(会话作用域上下文)。
三个正交配置旋钮独立控制成本和深度:
contextCadence—— 基础层刷新频率(API 调用频率)dialecticCadence—— 辩证 LLM 触发频率(LLM 调用频率)dialecticDepth—— 每次辩证调用的.chat()传递次数(1–3,推理深度)
设置向导:
hermes memory setup # 选择 "honcho"——运行 Honcho 特定的后置设置旧版 hermes honcho setup 命令仍然有效(现在重定向到 hermes memory setup),但仅在 Honcho 被选为活动记忆提供者后注册。
配置: $HERMES_HOME/honcho.json(配置本地)或 ~/.honcho/config.json(全局)。解析顺序:$HERMES_HOME/honcho.json > ~/.hermes/honcho.json > ~/.honcho/config.json。参见配置参考和Honcho 集成指南。
完整配置参考(可折叠):
| 键 | 默认值 | 描述 |
|---|---|---|
apiKey | — | 来自 app.honcho.dev 的 API 密钥 |
baseUrl | — | 自托管 Honcho 的基础 URL |
peerName | — | 用户对等体身份 |
aiPeer | 主机键 | AI 对等体身份(每配置一个) |
workspace | 主机键 | 共享工作区 ID |
contextTokens | null(无上限) | 每轮自动注入上下文的令牌预算。按单词边界截断 |
contextCadence | 1 | context() API 调用之间的最小轮数(基础层刷新) |
dialecticCadence | 2 | peer.chat() LLM 调用之间的最小轮数。建议 1–5。仅适用于 hybrid/context 模式 |
dialecticDepth | 1 | 每次辩证调用的 .chat() 传递次数。限制 1–3。第 0 轮:冷/热提示,第 1 轮:自我审计,第 2 轮:协调 |
dialecticDepthLevels | null | 可选的每轮推理级别数组,例如 ["minimal", "low", "medium"]。覆盖按比例的默认值 |
dialecticReasoningLevel | 'low' | 基础推理级别:minimal、low、medium、high、max |
dialecticDynamic | true | 为 true 时,模型可以通过工具参数覆盖每次调用的推理级别 |
dialecticMaxChars | 600 | 注入系统提示的辩证结果的最大字符数 |
recallMode | 'hybrid' | hybrid(自动注入 + 工具)、context(仅注入)、tools(仅工具) |
writeFrequency | 'async' | 何时刷新消息:async(后台线程)、turn(同步)、session(结束时批量)或整数 N |
saveMessages | true | 是否将消息持久化到 Honcho API |
observationMode | 'directional' | directional(全部开启)或 unified(共享池)。使用 observation 对象覆盖 |
messageMaxChars | 25000 | 每次消息的最大字符数(超过时分块) |
dialecticMaxInputChars | 10000 | 辩证查询输入到 peer.chat() 的最大字符数 |
sessionStrategy | 'per-directory' | per-directory、per-repo、per-session、global |
最小化 honcho.json(云端)示例:
{
"apiKey": "your-key-from-app.honcho.dev",
"hosts": {
"hermes": {
"enabled": true,
"aiPeer": "hermes",
"peerName": "your-name",
"workspace": "hermes"
}
}
}最小化 honcho.json(自托管)示例:
{
"baseUrl": "http://localhost:8000",
"hosts": {
"hermes": {
"enabled": true,
"aiPeer": "hermes",
"peerName": "your-name",
"workspace": "hermes"
}
}
}:::tip 从 hermes honcho 迁移
如果您之前使用过 hermes honcho setup,您的配置和所有服务端数据完好无损。只需通过设置向导重新启用,或手动设置 memory.provider: honcho 以通过新系统重新激活。
:::
多对等体设置:
Honcho 将会话建模为对等体交换消息——每个 Hermes 配置一个用户对等体加一个 AI 对等体,所有对等体共享一个工作区。工作区是共享环境:用户对等体跨配置是全局的,每个 AI 对等体有自己独立的身份。每个 AI 对等体从自己的观察构建独立的表示/卡片,因此 coder 配置保持面向代码,而 writer 配置针对同一用户保持编辑风格。
映射关系:
| 概念 | 是什么 |
|---|---|
| 工作区(Workspace) | 共享环境。同一工作区下的所有 Hermes 配置看到相同的用户身份 |
用户对等体(User peer,peerName) | 人类。跨配置在工作区中共享 |
AI 对等体(AI peer,aiPeer) | 每个 Hermes 配置一个。主机键 hermes → 默认;hermes.<profile> 用于其他配置 |
| 观察(Observation) | 每对等体开关,控制 Honcho 从谁的消息中建模什么。directional(默认,全部开启)或 unified(单观察者池) |
新配置,新 Honcho 对等体:
hermes profile create coder --clone--clone 在 honcho.json 中创建 hermes.coder 主机块,带有 aiPeer: "coder"、共享 workspace、继承的 peerName、recallMode、writeFrequency、observation 等。AI 对等体会在 Honcho 中主动创建,因此它在第一条消息之前就已存在。
现有配置,回填 Honcho 对等体:
hermes honcho sync扫描每个 Hermes 配置,为没有主机块的配置创建主机块,从默认 hermes 块继承设置,并主动创建新的 AI 对等体。幂等——跳过已有主机块的配置。
每配置观察:
每个主机块可以独立覆盖观察配置。示例:一个面向代码的配置,AI 对等体观察用户但不自我建模:
"hermes.coder": {
"aiPeer": "coder",
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": false, "observeOthers": true }
}
}观察开关(每对等体一组):
| 开关 | 效果 |
|---|---|
observeMe | Honcho 从此对等体自己的消息中构建该对等体的表示 |
observeOthers | 此对等体观察另一个对等体的消息(提供跨对等体推理) |
通过 observationMode 的预设:
"directional"(默认) —— 全部四个标志开启。完全相互观察;启用跨对等体辩证"unified"—— 用户observeMe: true,AIobserveOthers: true,其余 false。单观察者池;AI 建模用户但不建模自己,用户对等体仅自我建模
通过 Honcho 仪表盘设置的服务端开关会覆盖本地默认值——在会话初始化时同步回来。
参见 Honcho 页面获取完整观察参考。
完整 honcho.json 示例(多配置)已省略,详见原文。
参见配置参考和Honcho 集成指南。
OpenViking
来自字节跳动的上下文数据库,具有文件系统式知识层次结构、分层检索和自动提取到 6 个类别的记忆。
| 最佳用途 | 具有结构化浏览的自托管知识管理 |
| 需要 | pip install openviking + 运行中的服务器 |
| 数据存储 | 自托管(本地或云端) |
| 成本 | 免费(开源,AGPL-3.0) |
工具: viking_search(语义搜索)、viking_read(分层:摘要/概览/完整)、viking_browse(文件系统导航)、viking_remember(存储事实)、viking_add_resource(获取 URL/文档)
设置:
# 先启动 OpenViking 服务器
pip install openviking
openviking-server
# 然后配置 Hermes
hermes memory setup # 选择 "openviking"
# 或手动:
hermes config set memory.provider openviking
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env关键特性:
- 分层上下文加载:L0(约 100 令牌)→ L1(约 2k)→ L2(完整)
- 会话提交时的自动记忆提取(画像、偏好、实体、事件、案例、模式)
- 用于分层知识浏览的
viking://URI 方案
Mem0
服务端 LLM 事实提取,具有语义搜索、重新排序和自动去重。
| 最佳用途 | 无需动手的记忆管理——Mem0 自动处理提取 |
| 需要 | pip install mem0ai + API 密钥 |
| 数据存储 | Mem0 Cloud |
| 成本 | Mem0 定价 |
工具: mem0_profile(所有存储的记忆)、mem0_search(语义搜索 + 重新排序)、mem0_conclude(存储逐字事实)
设置:
hermes memory setup # 选择 "mem0"
# 或手动:
hermes config set memory.provider mem0
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env配置: $HERMES_HOME/mem0.json
| 键 | 默认值 | 描述 |
|---|---|---|
user_id | hermes-user | 用户标识符 |
agent_id | hermes | 代理标识符 |
Hindsight
具有知识图谱、实体解析和多策略检索的长期记忆。hindsight_reflect 工具提供其他提供者无法提供的跨记忆综合。自动保留完整的对话轮次(包括工具调用),带有会话级文档追踪。
| 最佳用途 | 基于知识图谱的实体关系回忆 |
| 需要 | 云端:来自 ui.hindsight.vectorize.io 的 API 密钥。本地:LLM API 密钥(OpenAI、Groq、OpenRouter 等) |
| 数据存储 | Hindsight Cloud 或本地嵌入式 PostgreSQL |
| 成本 | Hindsight 定价(云端)或免费(本地) |
工具: hindsight_retain(存储,带实体提取)、hindsight_recall(多策略搜索)、hindsight_reflect(跨记忆综合)
设置:
hermes memory setup # 选择 "hindsight"
# 或手动:
hermes config set memory.provider hindsight
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env设置向导自动安装依赖项,并且只安装所选模式所需的(云端的 hindsight-client,本地的 hindsight-all)。需要 hindsight-client >= 0.4.22(如果过时,在会话启动时自动升级)。
本地模式 UI: hindsight-embed -p hermes ui start
配置: $HERMES_HOME/hindsight/config.json
| 键 | 默认值 | 描述 |
|---|---|---|
mode | cloud | cloud 或 local |
bank_id | hermes | 记忆库标识符 |
recall_budget | mid | 召回彻底性:low / mid / high |
memory_mode | hybrid | hybrid(上下文 + 工具)、context(仅自动注入)、tools(仅工具) |
auto_retain | true | 自动保留对话轮次 |
auto_recall | true | 每次轮次前自动召回记忆 |
retain_async | true | 在服务器上异步处理保留 |
retain_context | conversation between Hermes Agent and the User | 保留记忆的上下文标签 |
retain_tags | — | 应用于保留记忆的默认标签;与每次调用工具标签合并 |
retain_source | — | 附加到保留记忆的可选 metadata.source |
retain_user_prefix | User | 自动保留转录中用户轮次前的标签 |
retain_assistant_prefix | Assistant | 自动保留转录中助手轮次前的标签 |
recall_tags | — | 召回时过滤的标签 |
参见插件 README 获取完整配置参考。
Holographic
本地 SQLite 事实存储,具有 FTS5 全文搜索、信任评分和用于组合代数查询的 HRR(全息约简表示)。
| 最佳用途 | 仅本地记忆,无外部依赖,高级检索 |
| 需要 | 无(SQLite 始终可用)。NumPy 可选用于 HRR 代数 |
| 数据存储 | 本地 SQLite |
| 成本 | 免费 |
工具: fact_store(9 个操作:添加、搜索、探针、相关、推理、矛盾、更新、移除、列表)、fact_feedback(有帮助/无帮助评分,训练信任分数)
设置:
hermes memory setup # 选择 "holographic"
# 或手动:
hermes config set memory.provider holographic配置: config.yaml 中 plugins.hermes-memory-store 下
| 键 | 默认值 | 描述 |
|---|---|---|
db_path | $HERMES_HOME/memory_store.db | SQLite 数据库路径 |
auto_extract | false | 会话结束时自动提取事实 |
default_trust | 0.5 | 默认信任评分(0.0–1.0) |
独特能力:
probe—— 实体特定的代数回忆(关于某个人/事物的所有事实)reason—— 跨多个实体的组合 AND 查询contradict—— 矛盾事实的自动检测- 具有不对称反馈的信任评分(+0.05 有帮助 / -0.10 无帮助)
RetainDB
具有混合搜索(Vector + BM25 + 重新排序)、7 种记忆类型和增量压缩的云端记忆 API。
| 最佳用途 | 已在使用 RetainDB 基础设施的团队 |
| 需要 | RetainDB 账户 + API 密钥 |
| 数据存储 | RetainDB Cloud |
| 成本 | $20/月 |
工具: retaindb_profile(用户画像)、retaindb_search(语义搜索)、retaindb_context(任务相关上下文)、retaindb_remember(存储,带类型 + 重要性)、retaindb_forget(删除记忆)
设置:
hermes memory setup # 选择 "retaindb"
# 或手动:
hermes config set memory.provider retaindb
echo "RETAINDB_API_KEY=your-key" >> ~/.hermes/.envByteRover
通过 brv CLI 实现的持久记忆——具有分层检索(模糊文本 → LLM 驱动搜索)的层次化知识树。本地优先,可选云端同步。
| 最佳用途 | 想要可移植、本地优先、带 CLI 的记忆的开发者 |
| 需要 | ByteRover CLI(npm install -g byterover-cli 或安装脚本) |
| 数据存储 | 本地(默认)或 ByteRover Cloud(可选同步) |
| 成本 | 免费(本地)或 ByteRover 定价(云端) |
工具: brv_query(搜索知识树)、brv_curate(存储事实/决策/模式)、brv_status(CLI 版本 + 树统计)
设置:
# 先安装 CLI
curl -fsSL https://byterover.dev/install.sh | sh
# 然后配置 Hermes
hermes memory setup # 选择 "byterover"
# 或手动:
hermes config set memory.provider byterover关键特性:
- 自动预压缩提取(在上下文压缩丢弃之前保存洞察)
- 知识树存储在
$HERMES_HOME/byterover/(配置作用域) - SOC2 Type II 认证的云端同步(可选)
Supermemory
具有画像回忆、语义搜索、显式记忆工具和通过 Supermemory 图形 API 进行会话结束对话获取的语义长期记忆。
| 最佳用途 | 具有用户画像和会话级图构建的语义回忆 |
| 需要 | pip install supermemory + API key |
| 数据存储 | Supermemory Cloud |
| 成本 | Supermemory 定价 |
工具: supermemory_store(保存显式记忆)、supermemory_search(语义相似性搜索)、supermemory_forget(按 ID 或最佳匹配查询遗忘)、supermemory_profile(持久画像 + 最近上下文)
设置:
hermes memory setup # 选择 "supermemory"
# 或手动:
hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env配置: $HERMES_HOME/supermemory.json
| 键 | 默认值 | 描述 |
|---|---|---|
container_tag | hermes | 用于搜索和写入的容器标签。支持 {identity} 模板用于配置作用域的标签 |
auto_recall | true | 轮次前注入相关记忆上下文 |
auto_capture | true | 每次回复后存储清理过的用户-助手轮次 |
max_recall_results | 10 | 格式化到上下文中的最大召回条目数 |
profile_frequency | 50 | 在第一轮和每 N 轮包含画像事实 |
capture_mode | all | 默认跳过微小或琐碎的轮次 |
search_mode | hybrid | 搜索模式:hybrid、memories 或 documents |
api_timeout | 5.0 | SDK 和获取请求的超时 |
环境变量: SUPERMEMORY_API_KEY(必需)、SUPERMEMORY_CONTAINER_TAG(覆盖配置)
关键特性:
- 自动上下文隔离——从捕获的轮次中剥离回应的记忆,以防止递归记忆污染
- 会话结束对话获取,用于更丰富的图级知识构建
- 在第一轮和可配置间隔注入画像事实
- 琐碎消息过滤(跳过”ok”、“thanks”等)
- 配置作用域容器——在
container_tag中使用{identity}(例如hermes-{identity}→hermes-coder)以按 Hermes 配置隔离记忆 - 多容器模式——启用
enable_custom_container_tags并添加custom_containers列表,让代理跨命名容器读/写。自动操作(同步、预取)保留在主容器上
多容器示例:
{
"container_tag": "hermes",
"enable_custom_container_tags": true,
"custom_containers": ["project-alpha", "shared-knowledge"],
"custom_container_instructions": "Use project-alpha for coding context."
}支持: Discord · support@supermemory.com
提供者对比
| 提供者 | 存储 | 成本 | 工具 | 依赖 | 独特特性 |
|---|---|---|---|---|---|
| Honcho | 云端 | 付费 | 5 | honcho-ai | 辩证用户建模 + 会话作用域上下文 |
| OpenViking | 自托管 | 免费 | 5 | openviking + 服务器 | 文件系统层次结构 + 分层加载 |
| Mem0 | 云端 | 付费 | 3 | mem0ai | 服务端 LLM 提取 |
| Hindsight | 云端/本地 | 免费/付费 | 3 | hindsight-client | 知识图谱 + 反射综合 |
| Holographic | 本地 | 免费 | 2 | 无 | HRR 代数 + 信任评分 |
| RetainDB | 云端 | $20/月 | 5 | requests | 增量压缩 |
| ByteRover | 本地/云端 | 免费/付费 | 3 | brv CLI | 预压缩提取 |
| Supermemory | 云端 | 付费 | 4 | supermemory | 上下文隔离 + 会话图获取 + 多容器 |
配置隔离
每个提供者的数据按配置隔离:
- 本地存储提供者(Holographic、ByteRover)使用
$HERMES_HOME/路径,每配置不同 - 配置文件提供者(Honcho、Mem0、Hindsight、Supermemory)在
$HERMES_HOME/中存储配置,因此每个配置有自己的凭据 - 云端提供者(RetainDB)自动派生配置作用域的项目名称
- 环境变量提供者(OpenViking)通过每个配置的
.env文件配置
构建记忆提供者
请参见开发者指南:记忆提供者插件了解如何创建自己的提供者。