# 号称 "OpenClaw + Hermes 完美合体"的 Mercury，我扒了它的底裤都不剩 > 龙虾AGI通用实验室 · 2026-04-30 最近 AI Agent 圈子冒出来一个叫 Mercury 的项目，宣传攻势挺猛。 官方的原话是这样的：**"OpenClaw sparked the Idea. Hermes brought the Energy. Mercury now delivers true CONTROL. This is OpenClaw + Hermes, perfected."** 翻译一下：OpenClaw 只是起了个头，Hermes 只是带了点劲，真正的完美形态是我 Mercury。 ![](images/c79a8c/img_001.png) 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 行 0 权限系统 486 行 0 生命周期管理 ~200 行 0 守护进程/Watchdog ~200 行 0 Telegram 通道 ~800 行 3 个（仅用户审批流程） 记忆系统 ~700 行 13 个 Provider 模型 ~400 行 8 个 **核心 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 代码，来对个账 官方声称 代码实际 判定 选择性注入，只注入相关记忆 硬编码 5 条、900 字符上限，不动态调整 半真半假 结构化检索 FTS5 关键词匹配 + 硬编码权重后置排序 夸大 记忆评分 LLM 自评 + 解析失败时编造分数 不可靠 冲突解决 只比 confidence 一个维度，三选一 过度简化 衰减机制 有 bug，从未检索的记忆永远不会被清理 有缺陷 Token-aware 有日预算，但记忆注入不根据预算调整 半真半假 OpenClaw + Hermes, perfected 没有 OpenClaw 的生态和透明，没有 Hermes 的学习闭环 大话 · · · ## Mercury 真正的价值 骂完了，说句公道话。 Mercury 不是一个骗子项目。它有真实的设计思考，架构文档（DECISIONS.md、RESEARCH.md）写得确实不错，三层记忆、Soul 系统、权限分层这些设计方向都是对的。 如果你把它当成**一篇用代码写的设计论文**来读——"Agent 记忆应该有哪些能力"——它有学习价值。 如果你想做个轻量原型，记忆不超过一百条，用户就你自己，也能凑合用。 但如果你被"OpenClaw + Hermes, perfected"这句话打动了，准备把它用在真实业务里—— ## 请先读一遍代码。 · · · ## 最后 Agent 记忆是整个 AI 行业最被低估的难题之一。什么值得记住、记忆粒度该多细、偏好演进怎么处理、大规模检索怎么做——这些问题确实没有人真正解好。 Mercury 提出了这些问题，这是它的贡献。 但提出好问题和解决好问题之间，差着一整条工程的路。**而 Mercury 目前的位置，还在路的起点。** 所以，在 AI Agent 赛道上，请记住一条朴素的原则： ## 看到"perfected"这个词，就去读代码。 读它的设计文档，你会觉得它很有想法。 读它的代码，你会感谢自己没有直接用。