Honcho

Honcho 是 Plastic Labs 出的 AI agent 个性化身份平台，给 LLM agent 提供持久跨会话的"用户理解"能力。在 TeamOS 里 Honcho 是当前的记忆后端（替代之前的 mem0 + Zilliz Cloud Milvus）。

一句话：mem0 是"事实记忆"，Honcho 是"用户理解" — 详见 Why Honcho over mem0。

核心定位

它是什么	它不是什么
Memory Agent + Dreaming Agent + Dialectic Agent	简单的向量数据库
LLM-native（结果是推理结论，不是 fact 列表）	文档/对话存储
多租户 SaaS（也支持自托管）	Identity Provider（不做登录鉴权）
给单个 peer 建持久画像	多 user / cross-tenant 共享

TeamOS 里的实施

维度	配置
模式	托管（cloud, https://api.honcho.dev）
Workspace	teamos-prod（3 hermes 共享）
Hermes 集成	NousResearch/hermes-agent v0.9.0 内置 honcho 插件，4 工具：honcho_profile / honcho_search / honcho_context / honcho_conclude
Key 数	3 把（每 hermes 一把 admin scope，按 hermes 拆分审计）
配置文件位置（每容器）	/opt/data/honcho.json（含 apiKey + workspace + hosts.hermes block）
安全护栏	SDK delete_workspace 已 monkey patch 屏蔽（admin scope 必备）
上线日期	2026-04-17

Honcho 的核心原语

原语	含义	在 TeamOS 里映射
Workspace	顶层多租户隔离	1 个团队 = 1 workspace（teamos-prod）
Peer	对话参与者（user / assistant / 任何 entity）	admin / guohua / linjun 是 user peer；hermes-admin 等是 ai peer
Session	一次对话上下文	每个对话/任务一个 session，命名按 session_strategy=per-directory
Message	单条消息	飞书/Multica 消息 → 进 session
chat() 端点	用自然语言问 Honcho 关于某 peer 的综合理解，含 5 级 reasoning_level	hermes 通过 honcho_context 工具调用
Dreaming Agent	后台异步推理整合知识	自动跑，不需要 hermes 触发

核心差异（vs mem0）

mem0: 你存事实 → 按 query 检索事实
Honcho: 你存对话 → 后台推理 user representation → chat() 端点查综合理解

举例（quickstart 真实数据）：

• 输入 14 条消息（用户聊 CI debug + 个人理财 app side project）
• 问 Honcho "What should I know about this user?"
• 答："this person developing personal finance app, getting real demand from friends; notably thoughtful about UX (known vs surveilled tension); business-minded calculating unit economics early; wishes for more time"

mem0 做不到这种综合推理，只能给"提取出的事实条"。

价格

项	价格
注册免费额度	$100 / 新 tenant（送）
之后按 reasoning token	$2 / 1M token
Storage / Retrieval	免费（不像 mem0 / 向量库按存储量收）
当前 5 hermes 估算月费	~$18-30 USD
Free credit 够用	~5 个月

详见 ../syntheses/Why Honcho over mem0#价格再算一次。

责任边界

它管	它不管
多租户隔离（workspace_id）	用户登录 / OAuth / 密码（飞书 / Multica 管）
API key 鉴权	"peer_id 真的是这个真人吗"（应用层 hermes 必须保证）
reasoning + 后台 dreaming	跨 peer 访问控制（同 workspace 内默认能跨 peer，应用层拦）

详见 ../system/隐私规则/HERMES_HONCHO_RETRIEVAL_GUARDRAILS。

当前已知踩坑（实施时遇到的）

详见 ../syntheses/Why Honcho over mem0#踩坑记录。简略：

1. HONCHO_WORKSPACE_ID env 不被 SDK 读 → 必须写到 /opt/data/honcho.json
2. SDK _ensure_workspace 每次 init 都 POST /v3/workspaces → workspace-scope key 401，需要 admin scope
3. API key SCOPE = Global 实际是只读 → 干不了业务，必须 admin scope
4. admin scope 能调 delete_workspace → 必须 monkey patch 屏蔽
5. HONCHO_WORKSPACE_ID env 默认 fallback 到 "hermes" 不是 "default" → 跟 docs 不符
6. dashboard UI 上 SCOPE=Workspace 字段实际保存为 Global → 必须用 admin

关联

• Honcho memory — Honcho 范式的概念页
• mem0 — SUPERSEDED，被 Honcho 替代
• Why Honcho over mem0 — 决策依据
• Honcho 接入指南 — 怎么接（含 monkey patch）
• HERMES_HONCHO_RETRIEVAL_GUARDRAILS — 5 条 Honcho 特有铁律
• Hermes Agents — 主要消费者
• 阿里云百炼 — 不是 Honcho 用的 LLM，hermes 业务对话用
• Zilliz Cloud Milvus — SUPERSEDED，原 mem0 后端