夜雨聆风
HexClaw vs OpenClaw / Hermes:2026 本地 AI Agent 的三条路径
去年到今年，AI 圈最被大家记住的动物，是一只龙虾。
OpenClaw 把一个原本只能在聊天框里回话的 AI，变成了一个真正可以住进你日常工作流里的”数字同事”。”你养龙虾了吗” 一度是朋友圈和开发者群里的问候语。
但最近一段时间，你如果还在关注这条赛道，会发现大家讨论的动物，悄悄换了一只。
社区里有句流行说法把这件事讲得特别顺：硅谷不养虾了，开始养马了（Hermes 中文名”爱马仕”，梗出”马”）。这句梗能传开，不只是因为谐音：GitHub 星标和 OpenRouter 调用量这两个公开指标，确实都在往上走。
所以借着这阵风，这一篇换个角度——从工程选型的视角，把“龙虾 vs 爱马仕”扩成”第三条路径”，顺便聊一下这三家在设计上各自解决的是什么问题。
如果说第一篇《从养龙虾到养河蟹》回答的是”为什么要做河蟹”，那这一篇回答的是下一个问题：当 OpenClaw 和 Hermes 都在往前跑时，河蟹到底站在哪一层。
本文核心判断
龙虾、爱马仕、河蟹其实不在同一层——一个负责入口分发、一个负责认知自学习、一个负责本地工作台。这篇不是要证明谁比谁强，而是把三条路径放到同一张架构图上讲清楚。
一句话选型：要做多平台 IM / Bot 矩阵，先看 OpenClaw。要做自学习 Agent / 长任务规划，先看 Hermes。要做不折腾部署、数据留本机的桌面工作台，先看 HexClaw。
爱马仕为什么会火
先把爱马仕（Hermes Agent）讲清楚。既然能在短时间里进入开发者讨论中心，它至少抓住了一个足够清晰的卖点。
数据层面，爱马仕是一个现象级的开源项目：
-
2026 年 2–3 月间由 Nous Research 低调开源 -
截至 2026-04-25，GitHub 星标约 116k、Fork 约 17k（ github.com/NousResearch/hermes-agent） -
OpenRouter 应用页显示约 4.4T Total tokens，日榜全球第 3（ openrouter.ai/apps/hermes-agent） -
原生接入微信，通过 iLink Bot API扫码即用
争议说明：Hermes Agent 与 EvoMap / Evolver 近期存在相似性争议。本文不做定性，只基于公开仓库、文档和产品形态讨论工程取舍，相关材料见文末。
让它形成传播势能的，不只是这些数字，而是它把”可写运行时“（Writable Runtime）这套自学习 Agent 叙事推到了台前。
一个被反复引用的概括是：
过去 OpenClaw 更接近一个稳定执行器：流程写清楚，它就能持续跑；问题是它不会”长记性”，复杂任务做完一次，下次还是从头来。Hermes 换了个思路：任务做完自动复盘，把经验提炼成一个可复用的 Skill 文件，下次遇到类似问题，直接调用这个”经验包”。
说白了，就是那句所有 Agent 从业者心里都念了两年的话——”用得越多越聪明“——在 Hermes 身上被包装成了一个足够清晰的产品卖点。
再叠加微信扫码即用这个强入口，它在中文技术圈讨论升温，一点都不意外。
龙虾不是被替代了，只是分工更清楚了
有意思的是，从工程分层看，爱马仕并没有”干掉”龙虾。
这两只动物，其实干的不是同一种活。
-
龙虾的强项，是把 AI 稳定接入你已经在用的聊天入口：二十多个平台、上百个插件、多账号矩阵管理。如果你是 Discord 社群管理员、社群运营、运维 / DevOps 或企业 IT，龙虾通常会是优先考虑的那一个。 -
爱马仕的长项，是让单个 Agent 在持续使用中自己越变越强——写代码、做数据分析、在垂直领域沉淀经验。它更偏向长任务的规划、执行和复盘中枢。
一种常见的工程组合思路是：让 Hermes 负责规划与学习，让 OpenClaw 负责多入口分发。
这个判断我完全同意。但想补一句——这套组合还差一个把能力落到本地工作流里的工作台。
不过我们这边，养的是一只河蟹
认识河蟹的老读者，可以跳到下一节。第一次听说的朋友，我简单讲一句。
HexClaw 河蟹 AI 是一套真实跑起来的开源 AI Agent 栈，也是我按上篇 《Claude Code SOP》 里那套设计驱动 × 测试闭环 × 多 Agent 协作方法打磨出来的工程样本。前几篇讲过它怎么装、怎么用、架构怎么拆；这篇重点讲它在 OpenClaw / Hermes 这条赛道里到底占哪一层。项目 Apache-2 开源、本地部署、数据私有。
能力边界先交代清楚，避免”卖期货”：
- v0.3.12 已发布稳定能力
：聊天、MCP 原生、Markdown Skill、RAG 知识库、多 Agent、IM 通道（后端生态支持 Slack 等更多适配器；桌面端当前聚焦飞书 / 钉钉 / 企微 / 微信 / Discord / Telegram）、语音、图片 / 视频生成 - v0.4.x 路线图（本地验证 / 下一版目标）
：Skills 闭环自学习、Agent 策略模式路由、记忆防注入、错误分类降级、模型工具调用能力检测、MCP 运行时管理——下文有具体说明
它走的路子和另外两位不太一样。
龙虾是 Node.js 栈，部署走 Docker / Fly.io / Render，面向 Bot 运营者；爱马仕是 Python 栈，但官方把它包装成了一键安装（Linux / macOS / WSL2 / Android Termux 都有现成脚本，用户不用自己准备 Python 环境），更适合愿意跑 gateway / server / container 的技术用户。两位走的都是”服务部署”路径。
河蟹从第一天开始押的是另一件事——让 AI Agent 变成一个普通桌面软件：像打开浏览器、微信、WPS 一样，点一下图标就能进入工作状态。为了这个选了 Go + Tauri，DMG / MSI / AppImage 各装各的，没有 Docker、没有虚拟环境、没有 systemd。
这样一对比，三条路径的差别其实很清楚：
龙虾擅长让 AI 住进你的 IM 流里。爱马仕擅长让单个 Agent 自己越用越强。河蟹想做的，是让这一切都装在一个不用懂运维就能跑的本地工作台里。
对外我把核心引擎叫 Hexagon Agent，仓库名仍然是 hexagon。底下是一套 toolkit → ai-core → hexagon → hexclaw → hexclaw-desktop / hexagon-ui 的六仓分层：前四层是 Go 仓库，可独立版本、独立 go get；桌面端和观测 UI 则独立构建发布。细节之前在《架构详解》里讲过，这里不展开。
三条路径，各走各的
严格说，这三家并不是在抢同一块地——放到系统分层里看，它们其实各占一层：
OpenClaw
= 入口层 / 分发层Hermes = 认知层 / 自学习层HexClaw = 本地工作台 / 私有数据底座——三层栈，没人占全；选哪个，取决于你要解决哪一层。
看明白这一层，很多纠结其实就不存在了——它们解决的是栈里不同位置的问题，不是互相替代。下面是具体展开。
如果你懒得看大表：30 秒版
- OpenClaw
：TypeScript / Node.js 栈。擅长”把 AI 塞进现有 IM 入口里”——多平台、多账号、矩阵运营是它的主场。 - Hermes
：Python 栈，但包装成一键安装。擅长”让单个 Agent 在使用中自己越用越准”——Writable Runtime 是它的核心卖点。 - HexClaw
：Go + Tauri 栈，Sidecar 架构，DMG / MSI / AppImage 双击装。擅长”本地常驻、不用懂运维、数据不出本机”——桌面工作台形态。
手机读者看完上面 30 秒版其实就够了。下面按三条路径拆开写，给愿意深入对比的读者做完整参考。
OpenClaw：入口层 / 分发层
路径定位：多平台 IM Bot 基座背后团队：Peter Steinberger / OpenClaw 社区开源协议：MIT主要语言：TypeScript / Node.js部署形态：Docker / Fly.io / Render / PodmanIM 覆盖：Telegram / Discord / Slack / WhatsApp / Signal / iMessage / 飞书 / LINE / Matrix / IRC 等扩展生态：扩展包体系成熟，社区长期迭代典型用户：Bot 运营 / 社群管理 / 企业 IT设计特色：Adapter Capabilities 抽象 + 声明式能力协调工程取舍：配置项多、学习曲线陡
Hermes：认知层 / 自学习层
路径定位：自我进化的 Agent 框架背后团队：Nous Research（AI 研究机构）开源协议：MIT主要语言：Python部署形态：一键安装脚本（Linux / macOS / WSL2 / Android Termux）IM 覆盖：多平台 gateway（含 WeChat 等）扩展生态：多 Provider + 丰富工具模块，官方持续扩充典型用户：AI Engineer / 研究者 / 深度玩家设计特色：Writable Runtime + 动态 Skill 写回工程取舍：长驻 gateway / server 运维心智、Agent 自改 Skill 需审计
HexClaw：本地工作台 / 私有数据底座
路径定位：本地桌面 Agent 工作台背后团队：hexagon-codes开源协议：Apache-2.0主要语言：Go + Tauri部署形态：DMG / MSI / AppImage 双击即装IM 覆盖：桌面端聚焦飞书 / 钉钉 / 企微 / 微信 / Discord / Telegram，后端适配器覆盖 Slack 等更多平台扩展生态：Markdown Skill + MCP 原生；Skill 闭环自学习在 v0.4.x 路线图中典型用户：个人 / 小团队 / 本地常驻设计特色：Sidecar 架构 + Go 单二进制 + Tauri 前端工程取舍：生态规模早期、Skill 数量还在建设中
注：以上”IM 平台覆盖”、”扩展生态”等条目按各项目官方文档与当前仓库口径粗略归类，非严格 benchmark——三家在”平台”、”Provider”、”工具模块”上的量纲并不完全可比，读者自行按实际需要取用。
把上面三段凝成一句人话，大概是：
要运营多账号、多平台、给一大票人发消息，选龙虾。要让一个 Agent 逐渐贴合你的流程和偏好，选爱马仕。要在自己机器上有个不用懂运维、数据不出本机的本地工作台，选河蟹。
三条路径不冲突，也没有替代关系——所以后面那节会专门讲，这三条路径理论上怎么组合。
龙虾和爱马仕，各自值得拆的一件东西
抛开”哪家火、哪家更强”这种排名话题，OpenClaw 和 Hermes 最值得拆开的，其实是两个更基础的设计思想。谁做 Agent 都绕不开。
龙虾：把”能力差异”声明化
飞书、Discord、Slack、Telegram、WhatsApp、Matrix——每个 IM 平台都有自己的脾气：能不能发富文本按钮、能不能编辑已发送消息、单条消息最长多少字、支持不支持线程、卡片协议各一套。过去大家的做法是：每个适配器里各写各的分支，Agent 调用者要自己判断”现在在哪个平台、能做什么”。
龙虾做的事情是——把这些差异全部上移成声明式的”Capabilities”。Adapter 自己声明自己能干啥、不能干啥；引擎拿到这份声明，决定降级策略、选择渲染方式、控制长度。Agent 不用再关心自己在哪里，只管做自己的事。
这套思路抽象得非常干净。它背后其实是一个比”支持多平台”更深的判断：多平台 Agent 的工程难点不在”接入”，而在”能力协调”。想明白这一点，就会知道为什么龙虾在二十多个平台上仍然跑得稳——不是因为它代码多，而是因为抽象层把复杂性挡在了 Agent 外面。
爱马仕：把 Skill 当成”会生长的资产”
“Agent 应该越用越聪明”这句话在圈子里喊了两年。Hermes 值得讨论的地方在于：它把这件事做成了一个足够清晰的产品闭环。
它的思路一句话讲清楚：Skill 不是一次写完就冻结的配置，而是一种会持续迭代的工程资产。Agent 跑任务过程中发现某个 Skill 不够好用，就自己提炼补丁、写回技能库；下次遇到类似场景直接复用。这个循环一旦跑起来，整个 Agent 就从”静态配置”变成”持续迭代的能力库”。
这套机制技术上其实不算复杂——判断、提炼、回写，三步。难的是敢不敢把”Agent 自己修改自己”这件事放进真实项目，并推到大量开发者手上。这种从”大家都知道”到”大规模讨论”的跨度，是它能在短时间里拿到六位数星标的重要原因。
两件事给后来人的启示
把这两件事放一起看，其实是给所有做 Agent 的人指出了两个最容易被忽视的基础层：
- Adapter 的设计哲学
，决定你能不能从容支持 N 个平台，而不是 N 个平台拖死 N 个分支 - Skill 的生命周期
，决定你的 Agent 是越用越顺手，还是越用越冗余
这两点是跨语言、跨栈、跨项目的底层方法论。TypeScript / Python / Go 各自实现方式不一样，但这两层想通了，整个项目的路径就清楚了。
顺便说一句：龙虾是 TypeScript 写的、爱马仕是 Python 写的，河蟹是 Go 写的，底下还有一整套自研的 Go Agent 引擎 Hexagon Agent（仓库名 hexagon，从去年就在动工）。语言栈不同、引擎不同、部署形态也不同——能对照的是工程问题，不能直接搬的是代码和归属。本文不裁决外部项目之间的原创性争议，只讨论公开材料里能看到的架构取舍；真正落到河蟹里，仍然要回到自己的 Go 引擎、桌面形态和安全边界里重新实现。
关于”可写运行时”这件事，河蟹是怎么做的
“Skill 会不会越用越准”这个问题，河蟹这边也一直在沿着自己的路径做，名字叫 Skills 闭环自学习，在 v0.4.x 里逐步落地。
目标很明确：让 Skill 跟着使用越用越准。
但实现上，河蟹选的是一条慢一点、但更稳一点的做法。
爱马仕是 Python 的路子：Agent 运行中遇到不够好的结果，在运行时自己生成补丁代码，写进动态技能库，下次直接调。好处是全自动、学得快，契合 Python 动态语言天然适合”运行时改自己”。
河蟹是 Go 的路子，所以 v0.4.x 更倾向一条朴素但符合 Go 工程哲学的做法：现有 SkillWriter 已经能创建新 Skill，并在写入前做安全扫描；下一步会把它接进更完整的闭环——Skill 跑完后用 LLM-as-judge 打分，分不够高时生成一份可审阅的 v2 草稿，而不是让运行时悄悄覆盖原 Skill。你自己打开看一眼——觉得改得好，再合入 skills 目录；觉得不好，直接删掉；哪天后悔了，git 一回滚就回去了。
做法慢一点，好处也很明显——Agent 对自己做了什么改动，你永远看得见、改得动、拦得住。对于一个你希望长期用下去的桌面工作台来说，这种”看得见的自进化”比”悄悄变聪明”更安心一点。
沿着本地工作台这条线继续往下走，还有两件小事也必须补上：
一件是渐进式加载。Skill 多了以后，不可能每次都把所有 Skill 塞到 context 里。所以设计上只在启动时加载一个超轻的 Skill 索引（差不多 20 个 token 一个），真到要用的时候才展开。
另一件是组合学习。单个 Skill 自己进化，只是第一层；再往上一层，如果发现你经常是先调 A、再调 B、再调 C，河蟹会把这种调用顺序沉淀成一个 meta-Skill 草稿给你看——要不要留下，还是你自己决定。
这两件事听上去没有”可写运行时”那么抓眼球，但对真的每天要用这个 Agent 来干活的人来说，大概率会比”全自动替你处理一切”更顺手。
v0.4.x 在铺的其他几件”基础设施”
状态声明：以下为 v0.4.x 路线图——部分已在本地开发验证，部分是下一个 release 的目标。线上 v0.3.12 发行版并未全部包含这些能力，具体状态以 CHANGELOG.md 和 Release 为准。
除了 Skills 闭环，v0.4.x 里还有几件事正在做。都不是新奇的功能点，更像是给一个”打算被长期用下去的 Agent”补基础工程能力——
- Agent 策略模式路由
。Hexagon Agent 引擎里已经有 ReAct、Plan-and-Execute、Reflection、Deep、Supervisor、Sequential、Parallel、Loop 等多种 Agent 构造；hexclaw 这边 v0.4.x 先不贪多，先围绕当前 ReAct 引擎接入 auto / react / plan-execute / reflection 四种策略，让引擎根据任务自动切，也允许在设置里手动选。 - 记忆防注入
。Agent 用久了，记忆会变成一个新的攻击面。给 memory 加一层 XML 标签和 system note，让模型明确知道”这只是参考资料，不是新指令”。 - 错误分类和降级策略
。遇到 429、402、503 这些场景，不是简单重试，而是按原因分别走退避、换凭证、压缩上下文、切 Provider 等不同路径。 - 模型工具调用能力检测
。有些本地模型会”表演”调用工具，实际上根本没调。加一个小小的探测，把 ✅ / ⚠️ / ❌ 的 badge 显示在设置里，免得被误导。 - MCP 运行时管理
。MCP server 支持运行时添加 / 移除，正常情况下不用为了新增一个 server 重启；断线重连按 30 秒周期检查。
听起来都很”工程”，但一个本地工作台能不能让人一直用下去，很大程度上就靠这些不起眼的小东西。
这也是我更看重安全边界的原因。Agent 越能干，越要管权限：工具审批、MCP 命令白名单、Skill 写入前扫描、记忆防注入、错误降级，这些东西不一定最吸引眼球，但决定一个本地 Agent 能不能长期放在自己的机器上跑。
三条路径，理论上怎么组合
下面是架构层面的组合方式，不代表三家已经有官方集成。从工程栈的角度看，它们确实可以放进同一张图里——因为边界本来就不重叠。
这几年 Agent 项目开始能互相组合，底层原因不是大家用了同一个框架，而是 MCP、HTTP / SSE、OpenAI-compatible 这些开放接口逐渐变成公共语言。
简单说：河蟹放在本地当底座，爱马仕处理深任务，龙虾负责把结果送到各个聊天入口。不用谁替代谁，接口打通就能各干各的长项。
一套比较现实的协作方式是：
-
本地常开的一台机器（Mac mini / NUC / 小服务器）上跑 河蟹——作为本地 Go sidecar、Ollama 本地模型、 MCP集线器、知识库与 Skill 的落脚处，对外通过本地 REST / WebSocket / MCP SSE 等开放接口提供能力。 -
对规划和反思要求高的长任务，通过标准 OpenAI-compatible协议委托给 爱马仕，让它负责 Skill 写回和多步推理。 -
多平台分发、多账号矩阵、IM 聊天入口用 龙虾——河蟹把上游结论通过 HTTP 推过去，龙虾走自己的 Adapter Capabilities 做降级和渲染。
三家之间的通信走的都是现成的开放协议（HTTP、WebSocket、SSE、MCP、OpenAI-compatible），没有谁绑谁的锁定关系。边界清楚，各跑各的，出问题也好定位。
写在最后
龙虾接入口，爱马仕长记性，河蟹守本地。
2026 年开源 Agent 这条赛道上，龙虾和爱马仕各自推进了一层基础设施——一层是”多平台能力的声明式抽象”，一层是”Skill 生命周期的动态化”。这两层真正做扎实的项目，目前还不多。
河蟹这条路——桌面工作台、本地常驻、Go 单二进制、Sidecar 架构、六仓分层——解决的是另一个基础问题：让”本地 Agent 工作台”不再需要懂运维就能跑起来。接下来几个版本会往几个具体场景里走得更深，下一篇文章里展开讲。
如果你读到这里，发现自己真正需要的不是 Bot 矩阵，也不是研究型自学习框架，而是一个能长期开在自己电脑上的本地 Agent 工作台，可以先从 GitHub Release 获取对应安装包：
DMG / MSI / AppImage：github.com/hexagon-codes/hexclaw-desktop/releases
macOS 用户也可以用一键脚本安装：
curl -fsSL https://raw.githubusercontent.com/hexagon-codes/hexclaw-desktop/main/install.sh | bash
延伸阅读——河蟹系列前作：
-
Claude Code SOP — 设计驱动 × 测试闭环 × 多 Agent 协作 -
架构详解 — 一个人 × Claude Code × 5 个月 × 6 仓 -
从养龙虾到养河蟹 — 产品发布 / OpenClaw 开题呼应 -
思考过程 — 打通 Qwen / Gemma / DeepSeek-R1 的最后一公里 -
完全指南 — 5 分钟从零到一个能干活的本地 AI Agent -
前 leader Skill — 把 leader 蒸馏成 AI Skill
参考资料
-
OpenClaw 源码与文档： github.com/openclaw/openclaw/docs.openclaw.ai -
Hermes Agent 源码与文档： github.com/NousResearch/hermes-agent/hermes-agent.nousresearch.com -
Nous Research 官网： nousresearch.com -
OpenRouter Hermes Agent 应用页： openrouter.ai/apps/hermes-agent -
MCP 协议规范： modelcontextprotocol.io -
Hermes WeChat 等接入说明：见 Hermes 官方 docs 的 integrations 段落 -
Hermes / Evolver 争议参考：EvoMap 相似性分析、EvoMap/evolver、Hermes Agent 官方仓库、第一财经报道 -
HexClaw 河蟹 AI 源码与文档： github.com/hexagon-codes/hexclaw-desktop/hexclaw.net
文中外部项目数据核验时间：2026-04-25，以上游仓库与官方平台为准。
HexClaw 河蟹 AI本地部署 · 数据私有 · 开源免费官网 hexclaw.net | GitHub github.com/hexagon-codes微博 @HexClaw | X @hexclawapp邮箱：ai@hexclaw.net