# 我颠覆了我的认知：OpenClaw 和 Hermes 还真的不一样 > 龙虾AGI通用实验室 · 2026-05-27 ## 前言：我曾经写过一篇文章，说它们本质一样 前天我写了一篇《正本清源说 Agent：OpenClaw 和 Hermes 到底有啥区别？》，逐个拆解了市面上流传的五个"本质区别"：架构不同、Skill 不同、记忆不同、循环不同、进化能力不同。 我的结论是：这五个区别中，四个经不起追问，剩下一个（self-evolution）确实存在但不在 Agent 内部。两者在功能和实现机制层面高度同构，大多数差异只是默认配置的不同。 这个结论我现在依然认为成立。 但后来的一场深度讨论让我意识到，我的分析框架本身有一个盲区——我一直在比"它们能做什么"，而忽略了一个更根本的问题："它们到底是什么？" 功能清单一样，不等于它们是同一种东西。 ## 一、OpenClaw 的核心是网关，Hermes 的核心是 Agent 这不是观点，是可以从代码中直接读出来的事实。 判断方法很简单：**一个团队选择自己从零建造的东西，一定是它认为最重要、最不可让渡的核心资产；选择借用或嵌入的东西，再好用也说明它在团队心中不是核心。** OpenClaw 自己造了什么？整个 Gateway 控制平面——WebSocket 服务、50 多个渠道适配器、会话路由、工具接线、插件生命周期管理、多 Agent 编排。这些全是 OpenClaw 团队一行一行写出来的。 那 Agent 的核心循环呢？用的是第三方 pi-agent-core SDK，通过 createAgentSession() 导入嵌入。SDK 负责完整的 Agent 循环——发送给 LLM、执行工具调用、流式响应。OpenClaw 甚至支持多种 Agent 运行时（pi、Codex 等），Agent 引擎是可插拔的。 Hermes 自己造了什么？run_agent.py——15000 多行的 Agent 核心循环，从 prompt 组装到工具调度到上下文压缩到模型故障转移，全部自己掌控。这是整个项目最核心、最重的一个文件。 那 Gateway 呢？后来加上去的一个可选模式，接了 6 个平台，够用就行。 你自己造的就是你认为的核心。你借来的就是你认为可替换的。 OpenClaw 自己造网关、借用 Agent 引擎——所以网关是核心。Hermes 自己造 Agent 引擎、Gateway 是可选附件——所以 Agent 是核心。 有人可能会问：没有 Agent 的 OpenClaw 有什么价值？确实没有直接的用户价值——没有大脑的基础设施不能对话、不能执行任务。但这恰恰说明了 OpenClaw 的设计立场：它把自己定义为一个平台，Agent 是跑在平台上的"应用"。平台没有应用当然不完整，但应用可以换，平台本身才是持久资产。 反过来，没有 Gateway 的 Hermes 也接触不到用户。但 Agent 的核心循环照样转、记忆照样积累、技能照样被创建和迭代、自进化管线照样能跑。它只是暂时失去了与外界通信的窗口，而不是失去了自己。 ## 二、产品哲学不同——它们对"什么最有价值"的回答截然相反 确定了核心身份之后，两者的产品决策为什么会系统性地分化就很清楚了。 OpenClaw 认为最有价值的是连接层。背后的判断是：AI 的智能正在快速商品化——模型越来越便宜、越来越强、越来越多。今天用 Claude，明天可能用 GPT，后天可能出一个更好的开源模型。既然智能本身是可替换的，那真正稀缺的是什么？是"用户通过什么渠道、以什么方式接触到这个智能"。 谁掌握了用户与 AI 交互的通道，模型换谁的都是平台内部的事。 这有点像微信的逻辑——微信的价值不在于聊天功能本身有多好，而在于它是你数字生活的入口：社交、支付、工作、生活服务全在里面。一旦所有 AI 交互都通过 OpenClaw 的网关，它就成了一个平台级的存在。所以 OpenClaw 花大量精力接通 50 多个平台、打磨路由和会话管理、构建 5700 多个社区技能的生态。它的终局愿景不是"最聪明的 AI"，而是"AI 世界的基础设施入口"。 Hermes 认为最有价值的是 Agent 自身积累的知识和能力。背后的判断完全不同：模型确实在变强，但模型不认识你。你的代码风格、你团队的部署流程、你上次做某个任务时第三步出了什么错然后怎么绕过去的——这些个性化的、通过长期交互才能积累的经验，才是真正不可替代的东西。当你的 Agent 真正"懂你"到一定程度，你根本不想换掉它，入口在哪反而是次要的。 就像你不会因为另一个平台界面更漂亮就换掉一个跟了你三年、完全了解你工作方式的私人助手——重新磨合的成本太高了。 所以 Hermes 把精力花在自研 Agent 核心、打磨学习循环、构建自进化管线上。渠道只接了 6 个，够用就行。它的终局愿景不是"到处都能找到的 AI"，而是"越用越懂你、你根本不想换的 AI"。 两种哲学，赌的是 AI 产业的两个不同终局：OpenClaw 赌"入口为王"，Hermes 赌"深度为王"。 ## 三、同样的功能，在两个系统里承担的角色完全不同 这是我上一篇文章最大的盲区。 上一篇我逐个比较记忆、技能、定时任务，发现实现机制相同就下结论说"没有本质区别"。但我忽略了一个关键问题：同一个功能模块，装在不同哲学的系统里，它服务的目标可以完全不同。 拿记忆来说。OpenClaw 的记忆核心服务于"连接"——让 Agent 记住用户在 WhatsApp 上说的话，在 Telegram 上聊天时也能接得上，保持跨平台体验的一致性。Hermes 的记忆核心服务于"成长"——不只是记住你说了什么，而是从交互中提取模式、发现自己的不足、改进自身行为。 再看技能。OpenClaw 有 5700 多个社区 Skill，核心价值是广度——尽可能覆盖更多场景，让你在任何渠道遇到任何需求都能找到对应的解决方案。Hermes 的技能核心价值是生长性——数量少（起步时只有一百多个），但 Agent 能从每次经验中自己创造和迭代技能，这些技能跟你的具体使用场景深度绑定，别人的 Agent 用不了。 我上一篇说"在 OpenClaw 的 SOUL.md 里加一段话就能实现自动创建技能"。这个说法在技术上没错，但它就好比说"在任何手机上装一个健身 App 就能当运动手表用"——功能确实实现了，但它不是这个系统的设计重心。Hermes 围绕"技能自动创建"构建了一整套支撑体系：自进化管线负责用进化搜索优化技能的措辞和步骤，轨迹导出功能可以把 Agent 的执行记录喂给强化学习管线，GEPA 算法能从失败的执行轨迹中自动诊断问题并生成改进方案。孤立地加一个"做完任务写个技能文件"的指令，和围绕这个行为建一整个进化体系，效果天差地别。 所以我上一篇把"实现机制相同"等同于"没有区别"，这个推理跳跃了。机制相同只说明"能做"，但"为什么做""做了之后怎么用""围绕它建了什么"才决定了这个功能在系统中的实际分量。 ## 四、它们的起点不同，正在向对方扩展 理解了上面三层之后，再看两者的演化轨迹就很清楚了。 OpenClaw 的轨迹是从基础设施向智能层延伸。它的起点是一个消息网关——先解决"怎么把所有渠道接起来"。然后嵌入一个 Agent 引擎让它有了智能，再加上记忆和技能让它像个助手。现在社区在探索 skill-creator skill（让 Agent 学会自动创建技能）、在做更深度的 Agent 能力改造。 Hermes 的轨迹是从智能层向基础设施延伸。它的起点是一个自主 Agent——先解决"怎么让 AI 持续学习和进化"。然后加上 CLI 让它可以在终端里交互，再加上 Gateway 模式让它能通过 Telegram、Discord 等渠道跟用户对话。现在它在做 OGP 联邦化协议、在持续增加更多的平台支持。 两者现在的功能清单越来越像，这不是因为它们本来就一样，恰恰是因为它们在从不同起点向对方的领地扩展。趋同的表象掩盖了起点的不同。 而起点的不同导致了扩展难度的不对称。 Hermes 要增加渠道支持，本质上是写更多的适配器代码——把 iMessage 的消息格式翻译成 Agent 能理解的格式，把 Agent 的回复翻译回 iMessage 的格式。这是累活，但不难，是纯粹的工程量问题。 OpenClaw 要深化 Agent 智能就没这么简单了。它面临的是一个架构选择：继续用借来的 pi-agent-core SDK 在上面修修补补？还是自己从零打造 Agent 核心？前者天花板有限——你想给 Agent 加一个深度学习循环，但 Agent 的"思考过程"不是你写的代码，你只能在 SDK 提供的 hook 点上做拦截，SDK 没暴露的地方你够不着。后者等于重做半个项目，而且意味着承认"Agent 引擎其实也是核心资产"——这跟 OpenClaw 一直以来"Agent 可替换"的设计立场是矛盾的。 ## 五、业界已经开始把两者叠起来用了 既然两者各有短板，一个自然的做法就是让它们协作。事实上这种模式已经出现了。 OpenClaw 做前端层——负责接收各渠道消息、理解用户意图、处理简单任务、把复杂任务打包委派给后端。Hermes 做后端层——接到任务后深度执行、调用积累的技能、做完返回结果、同时把这次经验沉淀为新技能。GitHub 上甚至已经有了专门的桥接项目 SwarmClaw，提供跨两个框架的编排、委派、记忆和技能共享。 这种两层架构有真实的好处。故障隔离——一层崩了不影响另一层。独立演进——各自按自己的节奏迭代，不用互相等。信任边界——OpenClaw 先过滤不可信的用户输入，Hermes 不直接暴露在恶意消息之下。灵活替换——后端今天用 Hermes，明天出了更好的自进化 Agent 可以换掉，用户接入层完全不受影响。 但代价也是真实的。信息在两层之间传递时会损耗——用户原话里的语气、隐含意图、模糊的指代，经过前端层的"理解和重新表述"之后可能丢失。延迟会增加——简单任务也要经过两次 LLM 推理。状态同步是个难题——用户在前端层说"我改主意了，别用 Python 了改用 Go"，这个偏好更新要多久才能传递到后端层？如果后端正在用 Python 执行任务，怎么办？调试复杂度也会急剧上升——出了问题到底是前端层理解错了用户意图，还是后端层执行出了偏差，还是两层之间的传递丢了关键信息？ 两层架构的出现本身就说明了一件事：到今天为止，还没有一个项目把"连接的广度"和"智能的深度"在同一套架构里同时做到极致。 这可能就是终态——基础设施层和智能层本来就该分离。但也可能不是——谁先补齐对方的短板，吃掉两层之间的缝隙，谁就可能定义下一代 AI Agent 的形态。 ## 六、回到我上一篇：到底“错”在哪 没有错在事实判断上。功能机制确实相同，配置确实可以互改，self-evolution 确实是 Agent 外部的工程工具。这些拆解依然成立。 错在分析框架上。我只比了"它们能做什么"，没有追问三个更本质的问题： 第一，它们是什么——一个的核心是网关，一个的核心是 Agent。判断依据不是谁怎么描述自己，而是谁选择自己造什么、借用什么。 第二，它们认为什么最重要——一个认为连接和分发不可替代（所以自己造网关），一个认为 Agent 的智能和成长不可替代（所以自己造 Agent 核心）。 第三，它们从哪来、往哪去——从不同起点出发，正在向对方的领地扩展，功能清单越来越像，但扩展的难度是不对称的。 上一篇文章看到了"功能同构"的表象，就下结论说"本质一样"。这就好比看到菜刀和手术刀都能切东西，就说它们是同一种工具。功能上确实都能切，但设计目的、使用场景、演化方向完全不同。 我上一篇只看到了"都能切"，没有问"为什么而切"。 这一篇算是补上了。 我建了一个AI学习群，目前几十来人，都是在真正动手学AI的人。如果你也在自己跑模型、写代码、做项目，欢迎加我微信，备注"你在做的AI方向"，我拉你进群。纯围观的就不加了，群里大家都在真搞。 ![](images/8f3b94/img_001.jpg)