ByteNoteByteNote

字节笔记本

2026年6月21日

hermes教程-Honcho 内存

API中转
¥120

Honcho 内存

Honcho 是一个 AI 原生内存后端,它在 Hermes 内置内存系统之上增加了辩证推理和深度用户建模。与简单的键值存储不同,Honcho 通过分析对话后的内容,维护一个关于用户是谁的持续模型——他们的偏好、沟通风格、目标和模式。

信息 — Honcho 是一个内存提供者插件

Honcho 已集成到内存提供者系统中。以下所有功能均可通过统一的内存提供者接口使用。

Honcho 增加的功能

能力内置内存Honcho
跨会话持久化✔ 基于文件的 MEMORY.md/USER.md✔ 带 API 的服务端
用户画像✔ 手动智能体整理✔ 自动辩证推理
会话摘要✔ 会话范围上下文注入
多智能体隔离✔ 每个对等体画像分离
观察模式✔ 统一或定向观察
结论(衍生洞察)✔ 服务端模式推理
跨历史搜索✔ FTS5 会话搜索✔ 基于结论的语义搜索

辩证推理:在每次对话轮次后(由 dialecticCadence 控制),Honcho 分析交流内容并推导出关于用户偏好、习惯和目标的洞察。这些洞察随时间累积,使智能体获得超越用户明确陈述的深入理解。辩证支持多轮深度(1–3 轮),并自动选择冷/热提示——冷启动查询侧重于通用用户事实,而热查询优先考虑会话范围上下文。

会话范围上下文:基础上下文现在包含会话摘要以及用户表示和对等体卡片。这使智能体能够感知当前会话中已经讨论过的内容,减少重复并实现连续性。

多智能体画像:当多个 Hermes 实例与同一用户对话时(例如,一个编码助手和一个个人助手),Honcho 维护独立的“对等体”画像。每个对等体只能看到自己的观察和结论,防止上下文交叉污染。

设置

bash
hermes memory setup    # 从提供者列表中选择 "honcho"

或者手动配置:

yaml
## ~/.hermes/config.yaml
memory:
  provider: honcho
bash
echo 'HONCHO_API_KEY=***' >> ~/.hermes/.env

honcho.dev 获取 API 密钥。

架构

两层上下文注入

在每一轮(hybridcontext 模式),Honcho 组装两层上下文注入到系统提示中:

  1. 基础上下文 — 会话摘要、用户表示、用户对等体卡片、AI 自我表示和 AI 身份卡片。在 contextCadence 时刷新。这是“这个用户是谁”层。
  2. 辩证补充 — LLM 合成的关于用户当前状态和需求的推理。在 dialecticCadence 时刷新。这是“现在什么重要”层。

两层被拼接并截断到 contextTokens 预算(如果设置)。

冷/热提示选择

辩证自动在两种提示策略之间选择:

  • 冷启动(尚无基础上下文):通用查询——“这个人是谁?他们的偏好、目标和工作风格是什么?”
  • 热会话(基础上下文存在):会话范围查询——“考虑到本会话中已经讨论的内容,关于这个用户的哪些上下文最相关?”

这根据基础上下文是否已填充自动发生。

三个正交配置旋钮

成本和深度由三个独立旋钮控制:

旋钮控制默认值
contextCadence两次 context() API 调用之间的轮次(基础层刷新)1
dialecticCadence两次 peer.chat() LLM 调用之间的轮次(辩证层刷新)2(推荐 1–5)
dialecticDepth每次辩证调用的 .chat() 轮数(1–3)1

这些是正交的——你可以频繁刷新上下文但较少进行辩证,或者以低频率进行深度多轮辩证。例如:contextCadence: 1, dialecticCadence: 5, dialecticDepth: 2 每轮刷新基础上下文,每 5 轮运行辩证,每次辩证运行进行 2 轮。

辩证深度(多轮)

dialecticDepth > 1 时,每次辩证调用运行多个 .chat() 轮次:

  • 第 0 轮:冷或热提示(见上文)
  • 第 1 轮:自我审计——识别初始评估中的差距,并从最近会话中综合证据
  • 第 2 轮:调和——检查先前轮次之间的矛盾,并产生最终综合

每轮使用成比例的推理级别(早期轮次较轻,主要轮次使用基础级别)。使用 dialecticDepthLevels 覆盖每轮级别——例如,深度 3 运行时使用 ["minimal", "medium", "high"]

如果前一轮返回了强信号(长、结构化输出),轮次会提前退出,因此深度 3 并不总是意味着 3 次 LLM 调用。

会话启动预热

在会话初始化时,Honcho 在后台以完整配置的 dialecticDepth 触发一次辩证调用,并将结果直接交给第 1 轮的上下文组装。在冷对等体上的单轮预热通常返回较薄输出——多轮深度会在用户发言之前运行审计/调和循环。如果预热在第 1 轮之前尚未完成,第 1 轮将回退到具有有限超时的同步调用。

查询自适应推理级别

自动注入的辩证根据查询长度缩放 dialecticReasoningLevel:≥120 字符时 +1 级,≥400 时 +2,上限为 reasoningLevelCap(默认 "high")。使用 reasoningHeuristic: false 禁用,将每次自动调用固定为 dialecticReasoningLevel。可用级别:minimallowmediumhighmax

配置选项

Honcho 在 ~/.honcho/config.json(全局)或 $HERMES_HOME/honcho.json(配置文件本地)中配置。设置向导会为你处理这些。

自托管 Honcho 带认证

当将 Hermes 指向自托管的 Honcho 服务器时,hermes honcho setup(和 hermes memory setup)会在基础 URL 之后询问本地 JWT / bearer 令牌。粘贴一个使用服务器 AUTH_JWT_SECRET(Honcho compose 环境变量)签名的 JWT 以启用认证访问;对于运行 AUTH_USE_AUTH=false 的服务器留空。本地令牌存储在主机块下(honcho.json 中的 hosts.<host>.apiKey),与任何云 apiKey 分开,因此你可以在之后将 Cloud or local? 提示切换回 cloud,而不会丢失任一凭据。

完整配置参考

默认值描述
contextTokensnull(无上限)每轮自动注入上下文的令牌预算。设置为整数(例如 1200)以限制。在单词边界截断
contextCadence1两次 context() API 调用之间的最小轮次(基础层刷新)
dialecticCadence2两次 peer.chat() LLM 调用之间的最小轮次(辩证层)。推荐 1–5。在 tools 模式下无关——模型显式调用
dialecticDepth1每次辩证调用的 .chat() 轮数。限制在 1–3
dialecticDepthLevelsnull可选数组,每轮推理级别,例如 ["minimal", "low", "medium"]。覆盖比例默认值
dialecticReasoningLevel'low'基础推理级别:minimallowmediumhighmax
dialecticDynamictrue当为 true 时,模型可以通过工具参数每调用覆盖推理级别
dialecticMaxChars600注入系统提示的辩证结果的最大字符数
recallMode'hybrid'hybrid(自动注入 + 工具)、context(仅注入)、tools(仅工具)
writeFrequency'async'何时刷新消息:async(后台线程)、turn(同步)、session(结束时批量)或整数 N
saveMessagestrue是否将消息持久化到 Honcho API
observationMode'directional'directional(全部开启)或 unified(共享池)。使用 observation 对象覆盖以进行精细控制
messageMaxChars25000通过 add_messages() 发送的每条消息的最大字符数。超出时分块
dialecticMaxInputChars10000辩证查询输入到 peer.chat() 的最大字符数
sessionStrategy'per-directory'per-directoryper-repoper-sessionglobal
pinUserPeerfalse仅网关。当为 true 时,每个平台用户都折叠为 peerName
userPeerAliases{}仅网关。运行时 ID 到对等体的映射({"7654321": "alice"})。多对一
runtimePeerPrefix""仅网关。为未知运行时 ID 添加命名空间(telegram_7654321),当没有别名匹配时

会话策略控制 Honcho 会话如何映射到你的工作:

  • per-session — 每次 hermes 运行获得一个新会话。干净启动,通过工具记忆。推荐给新用户。
  • per-directory — 每个工作目录一个 Honcho 会话。上下文跨运行累积。
  • per-repo — 每个 git 仓库一个会话。
  • global — 所有目录共享一个会话。

召回模式控制记忆如何流入对话:

  • hybrid — 上下文自动注入系统提示,并且工具可用(模型决定何时查询)。
  • context — 仅自动注入,工具隐藏。
  • tools — 仅工具,无自动注入。智能体必须显式调用 honcho_reasoninghoncho_search 等。

每个召回模式的设置:

设置hybridcontexttools
writeFrequency刷新消息刷新消息刷新消息
contextCadence控制基础上下文刷新控制基础上下文刷新无关——无注入
dialecticCadence控制自动 LLM 调用控制自动 LLM 调用无关——模型显式调用
dialecticDepth每次调用的多轮每次调用的多轮无关——模型显式调用
contextTokens限制注入限制注入无关——无注入
dialecticDynamic控制模型覆盖不适用(无工具)控制模型覆盖

tools 模式下,模型完全控制——它在需要时调用 honcho_reasoning,使用它选择的任何 reasoning_level。节奏和预算设置仅适用于具有自动注入的模式(hybridcontext)。

网关身份映射

这些设置仅在运行 Hermes 网关 时才有意义——这是用户使用平台原生运行时 ID(Telegram UID、Discord snowflake、Slack 用户)到达的单一入口点。CLI、TUI 和桌面会话没有运行时 ID,并且始终解析为 peerName,因此在网关之外这些键不起作用。

设置向导检测是否连接了网关平台,如果没有则完全跳过此步骤。当运行时,它会问一个问题——谁与这个网关对话?——并推导出键:

答案结果
只有我pinUserPeer: true — 每个非智能体网关用户都折叠为你的对等体。Pin 覆盖所有别名,因此仅当没有用户侧身份需要自己的对等体时才选择此项。如果多个智能体到达网关且每个需要不同的对等体,则不要 pin——保持 pinUserPeer: false 并通过 userPeerAliases[e] 编辑器)映射它们
我 + 其他人(池化)pinUserPeer: false + userPeerAliases 将你的运行时 ID 映射到 peerName — 你保留在共享历史上,其他人获得自己的对等体
只有其他人pinUserPeer: false,可选的 runtimePeerPrefix — 每个用户获得自己的对等体

在提示时选择 [e] 直接设置这三个键。

解析器按从上到下的顺序尝试键,第一个匹配获胜:pinUserPeeruserPeerAliases[id]runtimePeerPrefix + id → 原始运行时 ID → peerName → 会话键回退。

警告 — 取消 pin 会孤立池化内存

pinUserPeertrue 翻转为 false 不会迁移数据——在 peerName 下累积的内存保留在那里,平台用户解析为新的空对等体。为了保持你自己的连续性,选择池化路径,这样你的运行时 ID 别名回 peerName。向导在检测到转换时会自动提供此指导。

注意 — 已弃用的键

pinPeerNamepinUserPeer 的旧别名——仍然为了向后兼容而读取(两者都设置时 pinUserPeer 获胜),从不写入。重新运行设置会将其迁移到规范键。

观察(定向 vs. 统一)

Honcho 将会话建模为对等体交换消息。每个对等体有两个观察开关,它们 1:1 映射到 Honcho 的 SessionPeerConfig

开关效果
observeMeHoncho 从该对等体自己的消息中构建其表示
observeOthers该对等体观察另一个对等体的消息(为跨对等体推理提供输入)

两个对等体 × 两个开关 = 四个标志。observationMode 是一个简写预设:

预设用户标志AI 标志语义
"directional"(默认)me: 开, others: 开me: 开, others: 开完全相互观察。启用跨对等体辩证——“AI 基于用户所说的和 AI 回复的内容,对用户了解什么。”
"unified"me: 开, others: 关me: 关, others: 开共享池语义——AI 仅观察用户的消息,用户对等体仅自我建模。单一观察者池。

使用显式的 observation 块覆盖预设,以实现每对等体控制:

json
"observation": {
  "user": { "observeMe": true,  "observeOthers": true },
  "ai":   { "observeMe": true,  "observeOthers": false }
}

常见模式:

意图配置
完全观察(大多数用户)"observationMode": "directional"
AI 不应从其自己的回复中重新建模用户"ai": {"observeMe": true, "observeOthers": false}
强角色,AI 对等体不应从自我观察中更新"ai": {"observeMe": false, "observeOthers": true}

通过 Honcho 仪表板 设置的服务端开关会覆盖本地默认值——Hermes 在会话初始化时同步它们。

工具

当 Honcho 作为内存提供者激活时,五个工具可用:

工具用途
honcho_profile读取或更新对等体卡片——传递 card(事实列表)以更新,省略以读取
honcho_search基于上下文的语义搜索——原始摘录,无 LLM 合成
honcho_context完整会话上下文——摘要、表示、卡片、最近消息
honcho_reasoning来自 Honcho 的 LLM 的合成答案——传递 reasoning_level(minimal/low/medium/high/max)以控制深度
honcho_conclude创建或删除结论——传递 conclusion 以创建,delete_id 以删除(仅限 PII)

CLI 命令

hermes honcho 子命令仅在 Honcho 是活动内存提供者时注册config.yaml 中的 memory.provider: honcho)。在新安装上,直接使用 hermes memory setup honcho 配置 Honcho(或运行 hermes memory setup 并从列表中选择);然后 hermes honcho 子命令会在下次调用时出现。

bash
hermes memory setup honcho    # 直接配置 Honcho(在激活前工作)
hermes honcho status          # 连接状态、配置和关键设置
hermes honcho setup           # 重定向到 `hermes memory setup`(激活后别名)
hermes honcho strategy        # 显示或设置会话策略(per-session/per-directory/per-repo/global)
hermes honcho peer            # 显示或更新对等体名称 + 辩证推理级别
hermes honcho mode            # 显示或设置召回模式(hybrid/context/tools)
hermes honcho tokens          # 显示或设置上下文和辩证的令牌预算
hermes honcho identity        # 种子或显示 AI 对等体的 Honcho 身份
hermes honcho sync            # 将 Honcho 配置同步到所有现有配置文件
hermes honcho peers           # 显示所有配置文件中的对等体身份
hermes honcho sessions        # 列出已知的 Honcho 会话映射
hermes honcho map             # 将当前目录映射到 Honcho 会话名称
hermes honcho enable          # 为活动配置文件启用 Honcho
hermes honcho disable         # 为活动配置文件禁用 Honcho
hermes honcho migrate         # 从 openclaw-honcho 逐步迁移指南

hermes honcho 迁移

如果你之前使用过独立的 hermes honcho setup

  1. 你现有的配置(honcho.json~/.honcho/config.json)会被保留
  2. 你服务端的数据(记忆、结论、用户画像)完好无损
  3. 在 config.yaml 中设置 memory.provider: honcho 以重新激活

无需重新登录或重新设置。运行 hermes memory setup 并选择 "honcho"——向导会检测到你现有的配置。

完整文档

请参阅内存提供者 — Honcho 以获取完整参考。


分享: