4 个词毁掉 9,284 条记忆：Agent + Hindsight 的标签系统是怎么失效的上一篇讲了 Hindsigh

上一篇讲了 Hindsight 的 consolidation 救不了你。这篇直接动刀——把 9,284 条记忆里的 66% SSH 调试垃圾翻给你看，告诉你 Agent 是怎么在 5 天里把记忆库搞成黑洞的。

四个词：permanent / decision / method / ephemeral。单独看每个词都是合理设计，合在一起就是一场灾难。

4 个词毁掉 9,284 条记忆

一、9,284 条里到底有什么

Hindsight 部署在 Jetson AGX Orin（192.168.1.10:8888）跑了 5 天。某天早上我去查 bank_id=hermes 的内存质量，调了 /v1/default/banks/hermes/memories/list?limit=200&offset=0 抽样看真实内容。

200 条样本归类：

分类	条数	占比	含金量
SSH 调试步骤	132	66%	🗑️ 垃圾——逐步骤的"密钥被拒""家目录为空""重启 sshd"
商业决策讨论	6	3%	✅ 有价值——DeepSeek 转 Word 痛点、公文排版引擎变现
字体打包 / Vault 诊断	20	10%	⚠️ 低价值但无害
当前对话（诊断本身）	3	1.5%	中性
其他零碎	39	19.5%	多数是中英双语重复

把 200 条这个比例外推到 9,284 条全量：

SSH 调试类 ≈ 6,100 条
真正有长期参考价值的 ≈ 200-300 条
有效率 < 3%

96% 以上的存储空间、向量索引、consolidation 算力，全花在 SSH 调试上。

二、4 个词是怎么毁掉这一切的

我去查 GET /v1/default/banks/hermes/tags，看到 85 个不同标签。挑出我手动打过的 4 个：

permanent    → 253 条
method       → 252 条
decision     → 248 条
ephemeral    → 237 条

253/252/248/237 四个数字几乎一样。这不是巧合。

灾难一：所有数据被打上全部 4 个标签

我每次 hindsight_retain 都传了同一套标签。Hindsight 把传入的 tags 当成必须打的标签（不是"打哪个"），于是每条记忆都同时拿到 permanent + ephemeral + decision + method 四个标签。

后果：

❌ 按标签筛选=筛选全库
❌ 按标签隔离 consolidation=无法隔离
❌ "临时"和"永久"是同一个标签——临时内容直接污染永久层

我去 ephemeral 标签下看，236 条 ephemeral 同时是 permanent、decision、method。一条 5 分钟就失效的"重启 sshd"，被打成"永久决策方法论"。

灾难二：永久标签 = 永远不清理

permanent 的本意是"用户明确说这条要长期保留"。我用它当兜底——没想清楚该打什么标签时打 permanent。结果 253 条全是这个来源。

这些"永久"记忆里包含：

字体打包路径（7 天后毫无意义）
加密保险库误判为空的中间状态（已修复）
各种 SSH 调试中间步骤（半小时就过时）

半年后这些"永久"会继续占据 253 个 vector 位置、479K 链接条目、占用 consolidation 算力。Hindsight 永远不会自动清理 permanent。

灾难三：临时标签被滥用 = 永远不临时

ephemeral 是官方推荐的"7 天后归档"标签。我原本想用它隔离 SSH 调试这类过程性内容。

但同时打了 decision + method 之后，Hindsight 内部基于 stage 字段的清理逻辑失效（因为 stage 字段显示是 decision，决策不能归档）。237 条 ephemeral 实质上变成了 237 条"决策"，永远留存。

灾难四：方法论标签通胀

method 的本意是"记录可复用的工作流"。但 Agent retain 时没有按内容判断"这算不算方法论"，只按对话阶段判断。

结果 252 条 method 里：

✅ 真方法论 ≈ 30 条（公文排版引擎实现、Chrome 扩展变现路径）
🗑️ "SSH 密钥被拒"也是方法论
🗑️ "家目录设置为 C:\Users\jarvis"也是方法论
🗑️ "两个密钥都被拒"也是方法论

method 标签从一个内容分类标签，退化成了"我聊过的每一件事"。

三、SSH 调试那 132 条到底存了什么

我把 132 条 SSH 调试的样本捞出来，按时间排列：

10:16:12  SSH 根因：Match Group administrators 规则导致 sshd 子进程崩溃
10:18:36  发现第一次给错了公钥（主密钥 id_ed25519 而非 win_laptop）
10:18:36  用户执行了修复步骤
10:23:04  Hermes 提议创建 hermes 账户部署密钥
10:25:15  用户将 jarvis 公钥复制到 administrators_authorized_keys
10:25:15  两个密钥都被拒
10:26:04  sshd 找不到 jarvis 用户的 authorized_keys（家目录空）
10:26:33  Hermes 设置家目录为 C:\Users\jarvis 并重启 sshd
10:26:33  问题未解决
10:27:15  尝试设置 jarvis 密码为 Jarvis#2026（密码策略拒绝）
10:27:44  创建本地用户 hermes，密码 Hermes#2026，加入管理员组
10:28:19  Hermes 密码认证失败
10:29:21  用户创建 jarvis 和 devlop 替代 zjx
10:30:03  Hermes 指导添加 PubkeyAuthentication yes 和 DefaultShell
10:31:21  用户决定删除 jarvis、devlop、hermes

25 分钟的调试，132 条记忆。 平均每 11 秒一条。每条比上一条多 1 个新事实。

更可怕的是 consolidation：Hindsight 会把 132 条合并成 1 条 observation——合并后是：

"用户在 Windows 笔记本上折腾 SSH 连不上，期间测试了多种配置和账户。"

这条 observation 零价值。 它没告诉未来的我：根因是什么、修复方案是什么、下次怎么预防。只是一句"他折腾过"。

四、retail 模式是怎么让 SSH 调试被存进去的

Hindsight 默认 retain_every_n_turns=1，意思是每一轮对话结束都自动触发 retain。

25 分钟的 SSH 调试，按正常节奏是 50-60 轮对话。每一轮都被 retain 触发：

用户：密钥被拒
  ↓ retain
agent：检查家目录
  ↓ retain
用户：重启了
  ↓ retain
agent：还是失败
  ↓ retain
...（每轮都触发）

加上 Agent 内部"为防止上下文丢失，session 结束前把对话总结成 observation"的逻辑：

每轮 retain 1 次 → 25 分钟 132 次 retain
每次 retain 触发 LLM extractor → 132 次 LLM 调用
每次 LLM 提取 3-5 个 fact → 132 × 4 ≈ 500 个 fact 节点
fact 节点间自动建语义/时序/因果链接 → 链接数从 9K 涨到 479K

一次 SSH 调试吃掉了 5.7% 的总节点数和 35% 的链接数。

五、3 个配置把 66% 噪声干掉

我直接给能跑的配置，照着改就行（Hindsight 0.7.x+，bank-level config 改完立即生效）：

5.1 维度一：topic 分类（替代过去的扁平标签）

把 Hindsight 看作"记忆需要分领域"，按主题打标签——consolidation 只能合并同一 topic 的观察：

# Bank API 配置
curl -X PATCH http://192.168.1.10:8888/v1/default/banks/hermes/config \
  -H "Content-Type: application/json" \
  -d '{
    "entity_labels": {
      "topic": ["business", "infra", "dev_tools", "code", "content", "research"],
      "stage": ["decision", "process", "reference"]
    }
  }'

entity_labels 是 Hindsight 0.7 引入的双维度分类机制。topic 决定这条记忆属于哪个领域，stage 决定它处于什么生命周期。consolidation 任务按 topic 分组，跨 topic 不合并。

5.2 维度二：stage 生命周期（取代 permanent/ephemeral）

之前 4 标签全堆同一层（混用语义 + 时效），现在按 stage 严格分层：

stage 值	含义	例子	保留时长
decision	长期决策/偏好	"用户偏好 Python"	永久
process	7 天内的过程/进度	"正在迁移网关到 v0.51.325"	7 天后自动归档
reference	可清理的参考/历史	"今天 18:18 SSH 登录失败 3 次"	30 天后自动清理

SSH 调试 132 条全部应该是 reference 或 process，绝不该是 decision。下次回看时只看 stage=decision 的，永久层从 253 条压到 30 条以内。

5.3 维度三：retain_mission 写时过滤

retain_mission 是直接发给 extractor LLM 的指令，告诉它"什么值得存"。之前留空，extractor 按默认逻辑判断——默认逻辑不知道"SSH 密钥被拒"是垃圾：

curl -X PATCH http://192.168.1.10:8888/v1/default/banks/hermes/config \
  -H "Content-Type: application/json" \
  -d '{
    "retain_mission": "You are the memory extractor for an autonomous AI Agent. Only retain information that has durable reference value: explicit user preferences, irreversible decisions, project-level configuration changes, or method/workflow discoveries. Ignore: transient debugging steps, intermediate command outputs, failed attempts, restarts, and any information that becomes irrelevant after the current task completes. If unsure, mark the fact as ephemeral and assign a topic.",
    "observations_mission": "Group consolidation strictly by topic. Observations from different topics must never be merged. Prefer many narrow observations over few broad ones."
  }'

改完这一条，132 条 SSH 调试从源头压成 3-5 条根因："根因是 Match Group 规则 + DefaultShell 缺失 + 给了错公钥"。下次检索"SSH 配置"能直接拿到解决方案，不是 132 步流水账。

5.4 顺手关掉每轮 retain

retain_every_n_turns=1 是默认值，把它调高：

# 改 ~/.hermes/hindsight/config.json
{
  "retain_every_n_turns": 20
}

从每轮触发改成每 20 轮触发。日常对话 99% 不会漏掉重要事实；只有长任务、SSH 调试这类多轮场景会被 retain 完整捕获。API 调用成本直接降 95%。

六、改完之后发生了什么

改完 3 个配置，重启 Hindsight（docker restart hindsight），让它跑 24 小时自动整理：

总节点数：9,284 → 6,210（-33%）
decision 标签记忆：248 → 31（-87%）
process 标签记忆：新增 198 条，都是带 topic 分类的进度信息
reference 标签记忆：新增 580 条，30 天后会自动清理
consolidation 失败次数：58 → 4（剩余 4 条是历史 embed 512-token 错误，需要切到 bge-m3 才能彻底修）
consolidation 队列：1,972 → 0（跑完了）

最重要的变化——我下次问 "Hindsight 配置"，recall 出来的前 3 条都是真正的决策和配置变更，没有 SSH 调试噪声。

七、给 Agent 团队的血泪清单

如果你也在 Agent + Hindsight 架构里踩过同样的坑，这 5 条是必做项：

立刻改 entity_labels：用 topic × stage 双维度代替扁平标签。最少也要加 topic。
retain_mission 不要留空：把"什么值得存"用自然语言明确告诉 extractor。中文也行，Hindsight 内部会自动翻译。
retain_every_n_turns ≥ 10：默认 1 太激进。20 是我的甜点，调试类任务不漏、闲聊类不爆。
永久层最多 50 条：decision 标签的记忆超过 50 就该 review 了。Hindsight 不会帮你清理——你必须自己定期 review。
不要给同一批数据打 4 个标签：Hindsight 的 tag 是合集不是互斥，4 标签 = 0 区分度。

如果你的 Hindsight 也跑出 4 位数节点数 + 两位数失败 consolidation，先看 /tags 接口下的标签分布——4 个标签数一样基本可以确诊。

参考

Hindsight 官方文档：合并内存扇出调优指南 hindsight.vectorize.io/guides/2026…
Hindsight 项目地址：github.com/vectorize-i…
上一篇：你的 AI 记忆正在腐烂——Hindsight 的 consolidation 不会救你
Bank config API：PATCH /v1/default/banks/{bank_id}/config

我是闪大夫，国网 OPC 研究 Leader。这个系列会持续写 Agent 落地实战——Hindsight / Hermes / 多 Agent 协作 / 变现路径。下一篇是 #3："Agent 不给 Hindsight 配 retain_mission，记忆系统就是个黑洞"——讲 extractor 内部到底在干什么，以及怎么用 mission 把它调教成你想要的样子。