跳到主要内容

Honcho 记忆

Honcho 是一个 AI 原生记忆后端,在 Hermes 内置记忆系统之上添加了辩证推理和深度用户建模。Honcho 不是简单的键值存储,而是通过在对话发生后对对话进行推理,维护一个关于用户是谁的持续模型——包括他们的偏好、沟通风格、目标和行为模式。

Honcho 是一个记忆提供商插件

Honcho 集成在记忆提供商系统中。以下所有功能都可通过统一的记忆提供商接口使用。

Honcho 新增的功能

能力内置记忆Honcho
跨会话持久化✔ 基于文件的 MEMORY.md/USER.md✔ 服务器端 API
用户画像✔ 手动 Agent 策管✔ 自动辩证推理
会话摘要✔ 会话范围的上下文注入
多 Agent 隔离✔ 每个对等方独立的画像
观察模式✔ 统一或定向观察
结论(推导洞见)✔ 服务器端模式推理
历史搜索✔ FTS5 会话搜索✔ 对结论进行语义搜索

辩证推理:在每次对话轮次后(受 dialecticCadence 控制),Honcho 分析交流并推导出关于用户偏好、习惯和目标的洞见。这些随着时间积累,使 Agent 对用户的理解不断加深,超越用户明确表达的内容。辩证支持多轮深度(1–3 轮),并自动选择冷启动/暖启动提示——冷启动查询关注一般用户事实,而暖启动查询优先处理会话范围的上下文。

会话范围的上下文:基础上下文现在在用户表示和对等方卡片旁边包含会话摘要。这让 Agent 了解当前会话中已经讨论过的内容,减少重复并实现连续性。

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

设置

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

或手动配置:

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

honcho.dev 获取 API 密钥。

架构

两层上下文注入

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

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

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

冷启动/暖启动提示选择

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

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

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

三个正交配置旋钮

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

旋钮控制默认值
contextCadencecontext() API 调用之间的轮次(基础层刷新)1
dialecticCadencepeer.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(配置文件本地)中配置。设置向导会为你处理这些。

完整配置参考

默认值描述
contextTokensnull(无上限)每轮次自动注入的上下文 token 预算。设置为整数(例如 1200)以限制。在词边界截断
contextCadence1context() API 调用之间的最小轮次(基础层刷新)
dialecticCadence2peer.chat() LLM 调用之间的最小轮次(辩证层)。推荐 1–5。在 tools 模式下不相关——模型显式调用
dialecticDepth1每次辩证调用的 .chat() 轮数。限制在 1–3
dialecticDepthLevelsnull每轮次的可选推理级别数组,例如 ["minimal", "low", "medium"]。覆盖比例默认值
dialecticReasoningLevel'low'基础推理级别:minimallowmediumhighmax
dialecticDynamictruetrue 时,模型可以通过工具参数覆盖每次调用的推理级别
dialecticMaxChars600注入到系统提示中的辩证结果的最大字符数
recallMode'hybrid'hybrid(自动注入 + 工具)、context(仅注入)、tools(仅工具)
writeFrequency'async'何时刷新消息:async(后台线程)、turn(同步)、session(批量在结束时)或整数 N
saveMessagestrue是否将消息持久化到 Honcho API
observationMode'directional'directional(全开)或 unified(共享池)。用 observation 对象覆盖以进行细粒度控制
messageMaxChars25000通过 add_messages() 发送的每条消息的最大字符数。超出则分块
dialecticMaxInputChars10000peer.chat() 的辩证查询输入的最大字符数
sessionStrategy'per-directory'per-directoryper-repoper-sessionglobal

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

  • per-session — 每次 hermes 运行都会获得一个全新会话。干净的开始,通过工具使用记忆。推荐新用户使用。
  • per-directory — 每个工作目录一个 Honcho 会话。上下文在运行间积累。
  • per-repo — 每个 git 仓库一个会话。
  • global — 跨所有目录的单个会话。

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

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

各回调模式的设置:

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

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

观察(定向 vs. 统一)

Honcho 将对话建模为对等方交换消息。每个对等方有两个观察切换,直接映射到 Honcho 的 SessionPeerConfig

切换效果
observeMeHoncho 从此对等方自己的消息构建其表示
observeOthers此对等方观察另一对等方的消息(提供跨对等方推理)

两个对等方 × 两个切换 = 四个标志。observationMode 是一个简写预设:

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

用显式的 observation 块覆盖预设以进行每对等方控制:

"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_reasoningHoncho LLM 综合的答案——传入 reasoning_level(minimal/low/medium/high/max)控制深度
honcho_conclude创建或删除结论——传入 conclusion 创建,传入 delete_id 删除(仅限 PII)

CLI 命令

hermes honcho status # 连接状态、配置和关键设置
hermes honcho setup # 交互式设置向导
hermes honcho strategy # 显示或设置会话策略
hermes honcho peer # 为多 Agent 设置更新对等方名称
hermes honcho mode # 显示或设置回调模式
hermes honcho tokens # 显示或设置上下文 token 预算
hermes honcho identity # 显示 Honcho 对等方身份
hermes honcho sync # 同步所有配置文件的主机块
hermes honcho enable # 启用 Honcho
hermes honcho disable # 禁用 Honcho

hermes honcho 迁移

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

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

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

完整文档

参见记忆提供商 — Honcho 获取完整参考。