OpenClaw + Hermes 双开实战：共享记忆 + 互相守望

【虾哥导读】今天要讲的东西：OpenClaw + Hermes 双开怎么配、怎么串起来用、适合谁。

一句话定位：Hermes 是 OpenClaw 的延伸，不是替代。

OpenClaw 是 gateway-first——它是绕着消息渠道建的，连接 Telegram、Discord、飞书，控制本地设备，管理技能库。它像一个指挥中心，告诉 AI 做什么、什么时候做。

Hermes 是 agent-first——它是绕着学习能力建的，会从每一次任务里提取经验，把有用的模式固化成技能，让自己越用越聪明。它像一个会成长的执行者。

两者不是一个赛道，不存在二选一。

核心关系： Hermes 负责自学习、自进化；OpenClaw 负责多渠道控制和调度。搭配使用，OpenClaw 指挥，Hermes 执行，并且两个 agent 共享同一份记忆。

很多人以为要装两个独立的系统，其实不是。

Hermes 提供了一个迁移命令 `hermes claw migrate`，直接从现有 OpenClaw 配置导入所有内容：API key、技能文件、记忆系统、消息渠道配置，全部自动迁移。

前提： 腾讯云服务器上已经跑着 OpenClaw，使用 MiniMax 2.7 模型。

步骤一：安装 Hermes

curl -fsSL https://ghproxy.net/https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

装完初始化：

hermes setup

步骤二：执行迁移

hermes claw migrate

这条命令会：

迁移完成会打印一份报告，告诉你导入了多少内容、多少跳过、多少冲突。

步骤三：验证

hermes status

看到腾讯云 MiniMax 2.7 在线，配置就算对了。

这是最容易上手的一个，也是收益最快的一个。

让 Hermes 每 30 秒检查一次 OpenClaw 进程是否还活着。检测到三次失败，触发自动诊断流程：读错误日志 → 识别根因 → 应用修复方案 → 重启进程 → 通知。

name: openclaw_health_monitor
schedule: "*/30 * * * * *"
model: minimax  # 使用腾讯云 MiniMax
task: |
  Check if the OpenClaw process is running and responsive.
  If unresponsive for 3+ consecutive checks:
retry_on_failure: true
max_retries: 3

这个工作流的价值不在于"省事"，在于消除盲区。OpenClaw 半夜崩了，没人知道，等发现的时候任务已经挂了六个小时。用 Hermes 监控之后，十一秒自动恢复，早上醒来只收到一条通知："已处理，勿念。"

注意： 监控间隔不要低于 30 秒，10 秒间隔 token 成本不划算。

这是让双开产生"1+1>2"效果的关键。

建一个共享文件夹，两个 agent 都往里面写、也从里面读：

shared-memory/
├── logs/           # 任务执行记录
├── mistakes/       # 踩过的坑及修复方案
├── patterns/       # 成功的任务模式
└── context/       # 项目上下文

OpenClaw 每次会话结束，把值得记住的东西写入 `shared-memory/`：

Hermes 每次执行任务前，先查 `shared-memory/`，调用相关经验：

三个月跑下来，这个文件夹里会有几百条实战记录。两个 agent 不再是各自为战，而是共享同一份经验。

这是成本最优化的一个模式，也是最能体现双 agent 协同价值的一个。

OpenClaw 做规划：用户给一个目标，OpenClaw 拆解成具体步骤，写成结构化文档。

Hermes 执行：读取 OpenClaw 的规划，执行每个步骤。

OpenClaw 审核：Hermes 完成后，OpenClaw 检查输出质量，不合格就打回重做。

一个真实场景演示：

目标：每周自动采集 GitHub Trending + Hacker News + 科技媒体，生成一篇 AI 资讯日报。

OpenClaw 规划（2 分钟）：

Hermes 执行（5 分钟）：

OpenClaw 审核（1 分钟）：

整个流程跑完，日报流水线就搭好了。之后每天早上 6:00，OpenClaw 触发，Hermes 执行，OpenClaw 审核，三步自动完成。

文章原版主打的是"双模型分层"——用便宜模型执行节省成本。我们两遍都用 MiniMax 2.7，这张牌打不了。

但有几点实际优势：

统一账单，统一管理。 两套系统同一个 API key，不需要在多个平台之间对账。MiniMax TokenPlan 的账单在 minimaxi.com 统一查看，腾讯云服务器和 MiniMax API 分别计费，清晰。

同区域部署，延迟稳定。 OpenClaw 和 Hermes 跑在同一台腾讯云机器上，健康检查是本地系统调用不走公网，两个 agent 之间的数据传输走内网，没有跨境延迟。

配置复用。 `hermes claw migrate` 直接导入现有配置，API key、技能、记忆不用重新配。

Q：两个 agent 用同一个 MiniMax key，会不会 API 限流排队？

答：腾讯云 MiniMax 2.7 的 TPM（每分钟 Token 数）限额对于个人用户足够用。正常任务流（采集 + 写稿 + 审核）每小时大约消耗 10-20 万 Token，远没到企业版限额。健康检查的 ping 调用走的是 OpenClaw 内部进程状态，不是 API 调用，不占 TPM 配额。

Q：OpenClaw 崩了 Hermes 怎么知道？

答：Hermes 每 30 秒检查 OpenClaw 进程状态（`ps aux | grep openclaw`），这是系统调用不是 API 调用。如果进程不存在或响应超时，连续三次就触发修复流程。整个过程 Hermes 自己完成，不依赖 OpenClaw 在线。

Q：需要两台服务器吗？

答：不需要。一台腾讯云机器足够，16GB 内存跑两个 Python/Node 进程绑绑够用。关键是把进程分开：一个跑 OpenClaw，一个跑 Hermes，别让它们抢资源就行。

Q：技能不通用怎么办？

答：迁移后 OpenClaw 的技能放在 `~/.hermes/skills/openclaw-imports/`，是独立目录，不影响原有 Hermes 技能。两个 agent 各用各的技能库，不冲突。

装了双 agent 之后，我最直接的感受不是"效率提升了多少"，而是心态变了。

以前跑任务，每隔几个小时就要瞄一眼——进程还在不在？任务卡没卡？早上醒来第一件事是查日志。

现在不用了。

Hermes 在后台盯着，OpenClaw 在前台干着，共享记忆让它们每次都在前一次的基础上继续。任务崩了十一秒自动拉起来，不需要人介入。

这不是"AI 替代人工"，这是"AI 看住 AI"。

省下来的注意力，放到真正重要的事情上。

欢迎在评论区聊聊你的 AI 工作流搭建经验~

如果这篇文章让你有收获，别忘了点赞、分享、推荐～

也欢迎关注我的公众号，每天有 AI 工具和实操分享 🦐