号称 "OpenClaw + Hermes 完美合体"的 Mercury，我扒了它的底裤都不剩

最近 AI Agent 圈子冒出来一个叫 Mercury 的项目，宣传攻势挺猛。

官方的原话是这样的："OpenClaw sparked the Idea. Hermes brought the Energy. Mercury now delivers true CONTROL. This is OpenClaw + Hermes, perfected."

翻译一下：OpenClaw 只是起了个头，Hermes 只是带了点劲，真正的完美形态是我 Mercury。

OpenClaw，345K stars，2025 年底以来增长最快的开源 Agent 项目。Hermes Agent，Nous Research 出品，10 周涨到 110K stars，自学习闭环是真有两把刷子。

Mercury 说：我比它们俩加起来还强。

这口气不小。我就想看看，到底是技术自信，还是吹牛不打草稿。

于是我把 Mercury 的源码从头到尾读完了。

结论是：Mercury 的宣传和代码之间的距离，大到可以停一艘航母。

· · ·

先说它是什么

公平起见，Mercury 确实不是一个纯 PPT 项目。它有实际可运行的代码。

Node.js + TypeScript 构建的个人 AI Agent 框架，MIT 开源，后台守护进程，支持 CLI 和 Telegram。核心卖点是一套三层记忆架构：

短期记忆： 对话上下文，存在内存里。进程一崩就没了。

长期记忆（"第二大脑"）： 从对话中自动提取的事实，存在 SQLite 里。每条记忆有置信度、重要性、持久性三维评分，号称有冲突检测、自动衰减、定期清理。

Soul 身份文件： 四个 Markdown 文件定义 Agent 人格，用户可编辑。

架子是搭起来了。每个功能点都有，文档也写得挺好看。

但读代码的过程，让我一次又一次地想起一句话：魔鬼在细节里。

· · ·

记忆评分：LLM 自己给自己打分

Mercury 记忆系统最核心的环节是记忆提取：每次对话结束后，用一个 LLM 调用从对话中提取 0 到 3 条候选记忆，由 LLM 自己评估每条记忆的置信度、重要性和持久性。

这是整个系统的根基。如果这一步不靠谱，后面所有的排序、冲突解决、衰减——全是在沙子上盖楼。

那这一步靠谱吗？

完全不靠谱。

LLM 说"这条记忆的置信度是 0.85"——这个 0.85 是怎么来的？没有客观标准，没有外部校准，没有历史数据锚定，就是模型"感觉"了一下。同一段对话跑两次，可能一次 0.7 一次 0.9。这不是评分，这是占卜。

更要命的是，Mercury 默认用 DeepSeek 做推理。用 DeepSeek 提取记忆和用 Claude Opus 提取记忆，质量差距可能是量级的。但整个项目完全没有讨论这个问题——好像随便换个模型，记忆质量都一样似的。

对比一下 Hermes：Hermes 的技能学习虽然也依赖 LLM 判断，但至少有一个"执行→评估→提取→优化→复用"的闭环。技能好不好用，下次任务会验证。Mercury 的记忆质量呢？提取完就扔进数据库，没有任何后续验证机制。存进去就是"真理"了。

一个基于占卜的记忆系统，你敢信它？

· · ·

JSON 解析失败？没关系，编一个置信度存进去

这是我在代码里发现的、最能说明工程态度的细节。

LLM 返回的记忆提取结果应该是 JSON。但如果 LLM 没有返回合法 JSON——这在实际使用中太常见了——Mercury 的处理方式是：

按行分割文本，硬编码一个 0.75 的置信度，静默写入数据库。

我第一次读到这段代码的时候以为我看错了。

一条因为格式错误而无法正常解析的"记忆"，以一个凭空捏造的中等置信度被塞进了你的长期记忆库。它会参与后续的检索和排序，影响 Agent 未来的每一次决策。

用户完全不知道。没有警告，没有日志提示，没有任何反馈。

还有一个更离谱的：当 token 预算不足 800 时，记忆提取直接 return——不提取、不警告、不记录。你的这次对话，就像从未发生过。

总结一下这套系统的可靠性：

正常情况：LLM 自己给自己打分，可靠性存疑解析失败时：编一个假分数存进去预算不足时：整条对话静默丢弃

这叫 "perfected"？

· · ·

"结构化检索"：听着高级，实际是最朴素的关键词匹配

Mercury 在宣传里反复使用"Structured Retrieval"和"Selective Injection"这样的措辞。你以为是什么向量搜索、语义理解、知识图谱？

不是。

是 SQLite FTS5。按空格分词。用 OR 连接。关键词匹配。

就这？就这。

你问"我上次说的那个关于部署方式的偏好"，系统拿"上次""部署""方式""偏好"去全文匹配。你觉得它能找到数据库里的"User prefers Docker over Kubernetes"吗？

大概率找不到。因为这两句话几乎没有共同的词。

FTS5 后面倒是有一个 post-hoc 排序，用五个维度打分：置信度 30%、重要性 25%、新鲜度 20%、持久性 15%、关键词匹配 10%。

注意最后一项——"跟你的问题有多相关"这个最核心的因素，权重只有 10%，是所有维度里最低的。

也就是说，一条跟你的问题毫不相关但是置信度高、importance 高、比较新的记忆，排名会高于一条真正相关但分数一般的记忆。

而且还有一个致命问题：FTS5 默认返回前 10 条。如果真正相关的记忆排在第 11 名？对不起，后面的评分系统根本看不见它。

再看看被对标的两位。OpenClaw 的记忆虽然是简单的文件存储，但用户可以直接看到和编辑每一条，透明度拉满。Hermes 至少有 LLM 摘要做二次排序，技能系统本身就是结构化的经验索引。

Mercury 呢？既没有 OpenClaw 的透明，也没有 Hermes 的闭环，只有一层用高级术语包装过的 WHERE 语句。

· · ·

冲突解决：三个维度只用了一个

数据结构里明明白白存着三个维度——confidence、importance、durability。

冲突解决只看 confidence。

是的，你没看错。importance 和 durability 在冲突解决中完全不参与。它们就静静地躺在数据库里，像两个摆设。

逻辑极其简单：

新的置信度高 → 新的赢旧的置信度高 → 旧的赢一样高 → 新的赢

一条被反复验证 8 次的旧记忆（confidence=0.75）会被一条首次出现的 LLM 推断（confidence=0.80）直接覆盖——别忘了，这个 0.80 还可能是 JSON 解析失败时硬编码的 0.75。

而且是覆盖式的——旧记忆直接删除，没有历史记录，没有演进轨迹。你三个月前做了一个重要的技术决策，Mercury 覆盖掉了，你永远不知道它存在过。

Hermes 至少有 episodic archive，保留完整的会话历史。Mercury 号称比 Hermes 更好，结果连人家的历史保留都没做到。

· · ·

相似度判断：按空格分词，逐词比较

两条记忆是否应该合并？Mercury 的判断方法：

按空格分词。逐词精确匹配。重叠率超过 0.74 就合并。

"User prefers TypeScript" 和 "User loves TypeScript"——不合并。因为 "prefers" ≠ "loves"。

没有词干还原，没有词形归并，没有任何语义理解。2026 年了。

合并时选哪个版本？选更长的那个。 不是更准确的，不是更新的，不是来源更可靠的——是字数更多的。

我真的不知道该说什么。

· · ·

衰减机制：有 Bug，而且方向就有问题

Mercury 的衰减逻辑：活跃记忆 21 天未检索就清除，持久记忆 120 天未使用则衰减，低于 0.3 自动丢弃。

先说 bug：清理条件写的是 last_seen_at > 0。如果一条记忆从未被检索，last_seen_at 为 0 或 NULL，永远不满足条件，永远不被清理。

从来没被用过的垃圾记忆，反而获得了永生。经常使用的有用记忆，反而可能被过期清理。

这不是边界 case。这是核心逻辑 bug。

然后说方向问题。Mercury 的做法是低于阈值就永久丢弃。数据消失了，跟人脑的遗忘没有区别。

但 AI 记忆相比人脑的核心价值是什么？就是不像人一样遗忘。

正确的做法是分层检索——活跃知识优先返回，沉淀知识永远保留但降低优先级。你 6 个月前"选 PostgreSQL 不选 MongoDB"的决策，不应该被丢弃，而应该安静地待在沉淀层，等你问"我当初为什么选 PG"的时候再浮现。

降低优先级 ≠ 遗忘。Mercury 把这两件事搞混了。

· · ·

工程质量：24 个测试用例撑起的 "perfected"

这是最触目惊心的部分。

整个项目：3 个测试文件，24 个测试用例。

核心 Agent 循环——1914 行代码——零测试。 号称有权限安全？486 行代码零测试。号称有崩溃恢复？零测试。

OpenClaw 345K stars，经过数十万用户实战打磨。Hermes 有 Nous Research 的研究团队背书。Mercury 有什么？一份设计文档和 24 个测试用例。

然后它说自己是"perfected"。

其他工程问题随手就能列一串：

Telegram 异步错误被 .catch(() => {}) 静默吞掉——出了问题你永远不知道

所有 Provider 失败时给用户显示"检测到循环"——完全误导性的错误信息

路径检查不做符号链接解析——/safe/dir/../../etc/passwd 可以绕过

环境变量不展开——rm $SENSITIVE_PATH 不会被拦截

Telegram "Allow All" 不可逆——一旦点了，整个会话零权限检查

崩溃重启后短期记忆和待审批请求全部丢失——进程恢复不等于状态恢复

· · ·

宣传 vs 代码，来对个账

· · ·

Mercury 真正的价值

骂完了，说句公道话。

Mercury 不是一个骗子项目。它有真实的设计思考，架构文档（DECISIONS.md、RESEARCH.md）写得确实不错，三层记忆、Soul 系统、权限分层这些设计方向都是对的。

如果你把它当成一篇用代码写的设计论文来读——"Agent 记忆应该有哪些能力"——它有学习价值。

如果你想做个轻量原型，记忆不超过一百条，用户就你自己，也能凑合用。

但如果你被"OpenClaw + Hermes, perfected"这句话打动了，准备把它用在真实业务里——

请先读一遍代码。

· · ·

最后

Agent 记忆是整个 AI 行业最被低估的难题之一。什么值得记住、记忆粒度该多细、偏好演进怎么处理、大规模检索怎么做——这些问题确实没有人真正解好。

Mercury 提出了这些问题，这是它的贡献。

但提出好问题和解决好问题之间，差着一整条工程的路。而 Mercury 目前的位置，还在路的起点。

所以，在 AI Agent 赛道上，请记住一条朴素的原则：

看到"perfected"这个词，就去读代码。

读它的设计文档，你会觉得它很有想法。 读它的代码，你会感谢自己没有直接用。