Hermes 接入 Honcho：多 Profile 共享长期记忆配置

我有多个 Hermes Agent，分别处理日常助手、编码、研究和运维任务。它们各自需要保留自己的会话和行为边界，但又不应该每个 Agent 都从零认识同一个用户。因此，这次把 Hermes 的外部记忆 Provider 接到了自托管 Honcho。

这篇记录的目标不是把所有记忆都打通，而是建立一个可控的结构：同一位用户共享长期背景，每个 Hermes Profile 使用独立的 AI peer；公开或多人使用的机器人则单独隔离。

本文假设 Honcho 服务已经可用。若还没有部署，可先参考站内的 OpenClaw 接入 Honcho 记忆系统：Docker Compose 自托管与配置。Hermes 与 OpenClaw 的接入命令和配置项不同，不能混用。

为什么多个 Hermes 需要 Honcho

Hermes 的每个 Profile 都有独立的配置、会话、技能和本地记忆。这种隔离适合不同职责的 Agent，但也会带来知识孤岛：我向 coder 说明过基础设施习惯，之后 research 或 ops 并不会天然知道。

Honcho 的数据模型由 workspace、peer、session 和 message 组成。它会在后台处理写入的消息，并为 peer 形成可查询的 representation。落到多 Agent 场景里，可以这样映射：

Workspace: hermes
|
|- User peer: jonah
|
|- AI peer: hermes.heben
|- AI peer: hermes.coder
|- AI peer: hermes.research
`- AI peer: hermes.ops

这样做的含义是：

jonah 是稳定的用户身份，存放长期偏好、项目背景和历史决定。
每个 hermes.<profile> 都是不同的 AI 身份，Honcho 能区分消息由哪个 Agent 产生。
hermes workspace 是这一组私人 Agent 的隔离边界，方便共享与检索。

如果某个 Profile 是客服机器人、公开 Telegram Bot 或员工共用机器人，不应加入这个 workspace。应为它创建单独的 workspace 和用户 peer，避免私人上下文被召回给外部人员。

接入前检查

先在 Hermes 所在机器确认 Honcho API 可访问。假设自托管服务位于 192.168.100.1:8000：

curl http://192.168.100.1:8000/health

这里的地址必须从 运行 Hermes 的环境 测试。若 Hermes 在 Docker 容器中，localhost 指向容器本身，而不是宿主机；应改为容器网络中的服务名或宿主机可访问的地址。

再列出已有 Profile：

hermes profile list

假设结果中包含：

default
heben
coder
research
ops

1. 为第一个 Profile 启用 Honcho

在较新的 Hermes 版本中，首次接入应使用下面的命令：

hermes memory setup honcho

也可以执行 hermes memory setup，然后在 Provider 列表中选择 Honcho。hermes honcho setup 是启用 Honcho 后可用的别名；在还没有选择 Provider 的新安装上，直接使用它可能找不到子命令。

如果使用 Honcho Cloud，需要在对应 Profile 的 .env 中配置 HONCHO_API_KEY。本地部署则选择 local，填入自托管 API 的 Base URL；服务关闭认证时，JWT / bearer token 可以留空。

建议在向导中为主助手填入：

Your name (user peer): jonah
AI peer name:          hermes.heben
Workspace ID:          hermes

AI peer 不要使用 hermes heben 这类包含空格的名称。使用 hermes.heben 作为稳定 ID，后续在 CLI、日志、脚本和 Agent 间寻址时更容易处理。

向导完成后会显示配置文件位置。默认 Profile 通常使用 ~/.hermes/honcho.json；命名 Profile 则使用各自的 Hermes Profile 目录。不要把所有 Profile 指向同一份本地配置文件，应该让每个 Profile 保存自己的 AI peer 设置。

2. Gateway 用户映射怎么选

当 Hermes 发现已配置 Feishu、Telegram、Discord 等 Gateway 时，会询问平台用户如何映射到 Honcho peer。常见选项如下：

选项	适用场景	结果
`1` just me	Bot 只由本人使用	所有非 Agent 用户都映射到指定的 user peer。
`2` me + other people	本人使用，同时偶尔给其他人使用	本人合并到固定 user peer，其他人各自独立。
`3` only other people	完全面向多人或客户	每个平台用户都有自己的 peer。

我的私人 Heben Profile 选择 1，这样无论从哪个关联入口发消息，都会归入 jonah：

Choice: 1
pinUserPeer = true
userPeerAliases = {}
runtimePeerPrefix = (none)

对于多人 Bot，更稳妥的默认选择是 2。它既保证自己的长期记忆不会因为平台 ID 不同而分裂，也不会把其他人的对话折叠进自己的 peer。

3. 多 Profile 的推荐参数

下面是我给个人长期使用的综合助手 hermes.heben 设置的起点。它控制的是 Hermes 调用 Honcho 的节奏，不是 Hermes 模型本身的推理强度。

向导选项	推荐值	原因
Observation mode	`directional`	每个 AI peer 保留自己对用户的观察，适合职责不同的多个 Agent。
Write frequency	`async`	后台写入，不阻塞当前回复；比只在 session 结束时写入更不容易漏记。
Recall mode	`hybrid`	自动注入相关上下文，同时保留 Honcho 工具供 Agent 主动深查。
Context tokens	`2000`	主力综合助手的可用起点；不使用无限制注入。
Dialectic cadence	`2`	每两轮更新一次用户模型，在新鲜度和后端成本间平衡。
Reasoning level	`low`	自动召回以事实与简单综合为主，避免每轮做重推理。
Session strategy	`per-session`	每次运行从干净会话开始，依靠 Honcho 按需注入长期上下文。

coder、research、ops 等任务型 Profile 可以使用更保守的起点：Context tokens = 1200、Dialectic cadence = 3。如果 coder 长期围绕同一个 Git 仓库工作，也可以把它的 Session strategy 改为 per-repo；主助手仍建议使用 per-session，避免无关目录的短期上下文持续堆积。

hybrid 值得保留，因为它把两种召回方式结合起来：

每轮对话
  -> 自动注入有限的相关记忆
  -> 信息不足时，Agent 再调用 Honcho 工具搜索或追问

因此即使 1200 或 2000 token 的自动上下文不包含完整细节，Agent 仍然能按需检索，不必把所有历史消息塞进 Prompt。

4. 让其他 Profile 共享用户记忆

为其他 Profile 重复初始化时，保持 user peer 与 workspace 一致，只更换 AI peer：

hermes -p coder memory setup honcho
hermes -p research memory setup honcho
hermes -p ops memory setup honcho

按下面的规则填写：

Profile	User peer	AI peer	Workspace	建议 Context tokens
`heben`	`jonah`	`hermes.heben`	`hermes`	`2000`
`coder`	`jonah`	`hermes.coder`	`hermes`	`1200`
`research`	`jonah`	`hermes.research`	`hermes`	`1200`
`ops`	`jonah`	`hermes.ops`	`hermes`	`1200`

同 workspace 并不意味着所有内容都毫无边界地公开。它的目标是让用户背景、已确认的项目决定和跨 Agent 协作信息可以被合理找回；敏感项目、客户数据或不同业务线仍应拆到独立 workspace。隔离边界应该按数据访问对象划分，而不是按技术上是否方便配置划分。

5. 配置后验证与维护

先查看当前 Profile 的连接与关键参数：

hermes honcho status
hermes honcho peer
hermes honcho strategy

命名 Profile 使用 -p：

hermes -p coder honcho status
hermes -p coder honcho peer

完成两三轮真实对话后，检查后台日志或状态。Honcho 的长期表示由异步写入与后台推理形成，新事实不会在发出消息的瞬间就稳定地出现在每次召回中。

如需调整常用设置，不必反复手改 JSON，可以使用 CLI：

# 调整当前 Profile 的 AI peer
hermes honcho peer --ai hermes.heben

# 调整自动注入的上下文预算
hermes honcho tokens --context 2000

# 查看或改变当前 Profile 的会话策略
hermes honcho strategy

修改 Profile 的配置或环境变量后，重启对应 Gateway：

hermes -p heben gateway restart

若该 Profile 的 Gateway 是以快捷命令安装的服务，也可以使用：

heben gateway restart

常见问题

`hermes honcho setup` 找不到命令

这是因为 Honcho 还不是当前 Profile 的 active memory provider。先执行：

hermes memory setup honcho

完成选择后，hermes honcho status、hermes honcho peer 等子命令才会出现。

本机能访问 Honcho，Hermes 却连接失败

优先检查 baseUrl 是从 Hermes 的真实运行环境可达的地址。容器中的 localhost 不是宿主机；不同机器还需要确认防火墙、监听地址和路由。最有效的排查方式是在 Hermes 所在环境运行相同的 curl <baseUrl>/health。

为什么不让每个 Profile 使用独立 workspace

独立 workspace 会让每个 Agent 都重新积累用户偏好和项目背景。除非这些 Profile 服务不同的人、不同客户或不同保密边界，否则它会制造不必要的记忆孤岛。私人多 Agent 的合理默认值是「同 workspace、不同 AI peer」。

`MEMORY.md` 还需要保留吗

需要，但应该保持很小。USER.md、MEMORY.md 更适合人工确认过的稳定规则，例如语言偏好和不可违反的工作约束；会变化的项目上下文、对话历史和用户行为偏好交给 Honcho。项目文档、SOP 和需要版本控制的知识库，仍应保留在 Markdown 或其他文档系统中。

总结

Hermes 接入 Honcho 的关键不是给每个 Agent 再部署一套向量数据库，而是先定义好记忆边界：一个可信的私人 workspace，一个稳定的 user peer，以及每个 Profile 独立的 AI peer。这样 coder、research、ops 都能理解同一个用户和项目背景，同时保留各自的会话、职责和观察视角。

先用 async + hybrid + 有上限的 context tokens 跑起来，观察一段时间的命中质量和 token 消耗，再按 Profile 调整 cadence、token 预算与会话策略，会比一开始追求最大召回范围更稳。