用了半个月的OpenViking，我把Hermes记忆系统换成Holographic

📝

OpenViking它什么都记得，但经常记错。如果你也有同样的困扰，可以试下Holographic

原文链接：https://mp.weixin.qq.com/s/nbPnxYrWrnNewesGGD_Epg

OpenViking它什么都记得，但经常记错。如果你也有同样的困扰，可以试下Holographic

它什么都记得，但经常记错。

它记住了，但记错了

上周我在重构 UserService，随口问 Hermes：”这个服务之前用什么方案做的限流来着？”

它说：”用的 Redis 令牌桶。”

我心想不对啊，我记得是 Google 的 Ratelimit header。翻了下 git log——UserService 之前用的是 Nginx 的 limit_req，后来才迁到 Redis 令牌桶。它把方案搞混了。

更气人的是，我又问了一句 “AuthService 的限流呢？”，它回答：”也是 Redis 令牌桶，跟你 UserService 一样。”

结果 AuthService 用的一直是分布式限流中间件，压根没碰过 Redis 令牌桶。它觉得两个服务都在做认证，限流方案”应该”差不多——语义上确实”很像”，但事实完全不同。

Agent 没有撒谎，它只是记了个大概。

记事本 vs 搜索引擎

我后来想明白了，这不是 Agent 的错，是我给它的记忆系统用错了。

想想你问同事两种问题的区别：

“分布式限流有哪些常见方案？” → 找到相关资料就行，意思对了就好。这是搜索。
“UserService 之前用的什么限流方案？” → 必须精确，不能”大概”。这是查账。

写代码时我问 Agent 的，90% 是查账：

“这个函数上次改了什么？”
“这个配置项的值是多少？”
“我之前为什么选了 A 方案不用 B？”
“这个 bug 上次踩过吗？怎么修的？”

这些问题容不得”大概”。答案要么对要么错，没有”意思差不多”。

但 OpenViking 的底层是语义搜索——专门干”意思对了就好”的事。它像一个特别用功的实习生，什么都读过，什么都似曾相识，但你问他具体细节，他总给你一个”差不多对”的答案。写文档可以，写代码不行。

代码里 UserService 和 AuthService 差一个字，差的是整个服务。Nginx limit_req 和 Redis 令牌桶都是限流，但实现、依赖、迁移路径完全不同。语义搜索分不清这些——因为在它看来，”限流”和”限流”太像了。

试了一圈

Hermes 官方给了 8 种记忆后端。我不想拍脑袋选，挨个看了一遍。

先看了 Honcho——辩证推理 + 多 Agent 对齐，听着很高级，但我只有一个 Agent 在写代码，不需要对齐谁。

再看 Mem0——全自动提取记忆，完全免维护，省心。但仔细一看，检索层还是语义搜索那套。免维护没用，查出来的还是”差不多对”的答案，问题没变。

Hindsight 的知识图谱让我眼前一亮——实体关系 + 跨记忆综合反思，这思路对啊。但我已经有 Code Review Graph 在做变更影响分析了，再搞一套图谱会重叠。而且 Hindsight 的亮点是关系推理，我需要的恰恰是另一头——精确事实。

试到这里我有点焦虑了。8 个选项，要么还是语义搜索，要么跟我已有的工具重叠。难道就没有一个记忆系统，专门干”查账”这件事？

直到看到 Holographic。

它的定位跟其他 7 个完全不同——不是”找相似的文本”，而是”记住精确的事实”。底层是 SQLite + FTS5 全文搜索 + HRR 代数查询，没有向量，没有语义，没有”大概”。

不是搜索，是查账。就是我要的。

probe

以前问 OpenViking：”UserService 的限流怎么回事？”，它返回一堆跟 UserService “意思接近”的文本段落，里面混着 AuthService 的、SessionService 的、还有一篇 Stack Overflow 上关于 Redis 限流最佳实践的讨论。你得自己从一锅粥里捞出你要的那一条。

现在用 probe：

-
-

`probe("UserService") →``- UserService 限流从 Nginx limit_req 迁到 Redis 令牌桶（2026-04）``- UserService 的 authenticate 方法在 2026-03 被重构为 JWT``- UserService 依赖 TenantFilter 做租户隔离`

一行一条事实，精确到函数名、日期、依赖关系。不会有 AuthService 的东西混进来——因为 probe 是按实体查的，不是按相似度查的。

这就是写代码时脑子里想的方式：”关于 UserService 的一切”，不是”跟 UserService 意思差不多的东西”。

reason

“和支付相关且有已知 bug 的接口”——这种问题你天天遇到。

纯向量搜索做不到。向量只能找”像的”，不能做”交集”。就像你问一个把整本新华字典背下来的人：”包含’打’字且已经不用的成语有哪些？”他答不上来。他记的是意思，不是结构。

Holographic 的 reason 做的是 AND 逻辑：reason("支付", "已知bug") 直接给出交集结果，不是”跟支付和 bug 意思都挺像的”一堆东西。

contradict

这个最让我惊喜。

我之前那个场景：UserService 的限流到底是 Nginx limit_req 还是 Redis 令牌桶？如果记忆里同时存在两条互相矛盾的事实，OpenViking 会把两条都返回，模型自己选一个——选错了，我还不知道。

Holographic 会在写入时自动发现矛盾，主动标记出来。你不会基于一条过时的事实做出错误决策——因为冲突还没进记忆库就已经被亮红灯了。

我受够了跑 server

还有一个很实际的点。

OpenViking 需要先启动 openviking-server。就这么一个要求，但我已经被坑过好几次：重启电脑忘了启动，Agent 裸奔一上午；server 偶尔挂掉，记忆断了，Agent 开始瞎编；排查问题得先排查 server 是不是活着。

Holographic 底层是 SQLite。一个 .db 文件。没有进程，没有端口，没有网络。打开 Hermes 就能用，关了数据还在。

零运维的记忆才是好记忆。

试探不是决策

Holographic 还有个设计让我觉得”这就对了”——每条事实有信任分（0.0–1.0）：

标记”有用” → +0.05
标记”没用” → -0.10

注意不对称。”没用”的惩罚是”有用”奖励的两倍。因为错误信息的危害远大于遗漏信息——Agent 记住一个错误方案，比忘了一个正确方案更致命。

这事天天发生：Agent 早期记住”试试用 Redis 做缓存？”，后来你选了 Memcached。在传统记忆里，试探性方案和最终决策混在一起，下次 Agent 拿着过期的”试试 Redis”当结论用。在 Holographic 里，被否决的方案信任分会越来越低，最终被过滤掉。

试探不是决策，草稿不是方案。记忆系统应该分得清。

双脑升级

之前写过给 Hermes 装上”第二颗大脑”：当 OpenViking 遇上 GitNexus。

换了 Holographic 之后我才发现，之前那不是双脑，是双检索——OpenViking 找”相似的文本”，由于GitNexus商用要授权，所以我换成了 Code Review Graph。Code Review Graph 追变更的影响链，都在做检索，只是粒度不同。

现在回到开头那个重构场景：

我说”UserService 之前用的什么限流”，Holographic 直接给出”Nginx limit_req 迁到 Redis 令牌桶（2026-04）”——精确事实，不会把方案搞混。Code Review Graph 同时告诉我，改了 UserService 的限流层会影响下游 3 个服务的 7 个调用点——这是影响分析，probe 做不了。contradict 发现记忆里还有一条旧的”Nginx limit_req”的事实，主动标记冲突。

一个记事，一个推理，一个打脸。 之前是两个都在搜，现在是三个各干各的。

OpenViking 不是不好

如果你的 Agent 主要是读文档——“这篇论文说了什么””这个框架的最佳实践是什么”——OpenViking 的语义检索很强。分层加载 L0→L1→L2 还能省 token。

但写代码不是读文档。读文档容许”差不多”，写代码只认”对不对”。

-
-

1	`hermes memory off``hermes config set memory.provider holographic``hermes chat`

三行命令。旧记忆不会自动迁移——但我反而觉得是好事。OpenViking 积攒的那些”相似但不对”的语义噪声，趁换脑清掉，比搬家时把旧家具也搬过来更干净。

从搜索引擎换成记事本，不是降级，是换了场景。写代码这件事，从来就不需要大概。

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。