先关注后阅读，娇姐怕失去上进的你

文末娇姐整理openclaw所有文章链接

想了解娇姐点击文末链接

说一个很多人不敢说出口的感受：我跟不上了。不是跟不上某一个工具的更新日志，而是跟不上「又出了一个新东西，你得看看」这件事本身。

三个月前折腾 OpenClaw，从 npm install 到网关配置，从插件调试到 Telegram 联通，好不容易搭出一套能用的个人 AI 助手工作流——然后 Hermes Agent 来了。Nous Research 出品，GitHub star 数飙涨，社区里一片「这才是终极形态」的声音。

你的第一反应是什么？我的第一反应是疲惫。

但疲惫之后，还是要想清楚这件事。因为「换不换」这个问题，本质上是一个更深的问题：这两个工具到底在解决同一个问题吗？如果不是，那「换」本身就是个伪命题。这篇文章不是产品评测，不是教程，是一次诚实的技术思考，和一个帮你做决策的框架。

一、OpenClaw 到底在做什么

很多人把 OpenClaw 理解成「一个聊天机器人框架」，这个理解太浅了。OpenClaw 的核心不是聊天，是路由。

它的架构是一个 Node.js 网关守护进程（Gateway），通过 WebSocket 管理所有的会话、权限、频道和技能调度。你可以把它想象成一个「AI 交换机」——WhatsApp、Telegram、Discord、Slack、iMessage…… 22 个以上平台的消息进来，经过统一的路由逻辑，分发给不同的 Agent 实例处理。发展到今天，OpenClaw 的社区 skill 数量已经超过 44,000 个，这是真实的生态积累。

这个设计的优势很明显

• 多渠道统一入口：
  一套 Agent 逻辑覆盖你所有的通讯平台，在 Telegram 上让它帮你查东西，切到 Slack 上它还记得上下文。
• 插件生态丰富：
  浏览器控制、定时任务（cron）、Canvas 可视化工作区，甚至语音唤醒（macOS/iOS）应有尽有。
• 模型可插拔：
  换模型提供商不影响网关，这是好的工程解耦。

但三个月用下来，痛点也很真实

插件系统是把双刃剑。社区里有个帖子标题就很说明问题——「You don't need a lot of plugins (and they're bad for your system)」。作者砍掉大部分插件后，启动速度快了 40%，内存降了 60%，四个月没遇到一次 breaking update。插件的问题不是功能不行，而是每一个插件都是一个潜在的故障源。

记忆系统是另一个慢性痛点。OpenClaw 的记忆基于无上限的 Markdown 文件加可选向量嵌入。听起来灵活，但「无上限」意味着你得自己管理。用了三个月，记忆文件膨胀到几万字，里面充满了过时的偏好和重复的上下文——你需要定期手动修剪，否则 Agent 的注意力会被垃圾信息稀释。

安全警示：2026 年 3 月的 Shodan 扫描发现超过 13.5 万个 OpenClaw 实例暴露在公网且无需认证，相关 CVE 漏洞的利用代码在 GitHub 上出现得很快。这是生态扩张过快的代价，自托管用户需要格外注意认证配置。

本质上，OpenClaw 给了你一个非常强大的基础设施，但运维负担落在了用户身上。它更像一个需要你持续维护的服务器，而不是一个越用越省心的助手。

二、Hermes Agent 到底在赌什么

Hermes Agent 由 Nous Research 开发，MIT 协议开源，Python 编写。这个团队同时在做 Hermes 模型系列（Hermes 4 在 2025 年引入了混合推理和大规模合成数据生成）和 Atropos RL 训练框架。Hermes Agent 是他们把「训练更强的模型」和「让模型持续运行并自我进化」这两条线合并的产物。

如果说 OpenClaw 赌的是「路由和控制」，Hermes 赌的是一个完全不同的命题：记忆和自我进化。

持久记忆：有限制才有纪律

Hermes 的记忆系统同样用 SQLite + FTS5 全文检索，但做了一个关键的设计决策：硬性字符上限——Agent 记忆 2200 字符，用户画像 1375 字符，就这么多，不可无限扩展。

这看起来是限制，实际上是个极其聪明的工程选择。因为空间有限，Agent 被迫做「信息优先级排序」——它必须判断什么值得记住、什么可以遗忘，就像人类的工作记忆一样。旧的对话不是简单丢弃，而是被 LLM 压缩提炼成关于你的关键洞察，再写入长期存储。

类比：OpenClaw 的记忆像一个无限容量的笔记本，什么都往里塞，最终你得自己整理。Hermes 的记忆像一个严格限制页数的手账——正因为只有这么几页，每一条都经过深思熟虑。

自动 Skill 生成：Agent 自己写 SOP

这是 Hermes 最有意思的特性。当你完成一个复杂任务（涉及多次工具调用）时，Agent 会自动评估操作流程，把成功的步骤抽象成一个 Markdown 格式的「Skill 文档」存储下来，记录完整的操作步骤、踩过的坑和验证方法。下次遇到类似任务，直接复用，而且每次执行后还会自动优化这个 Skill。

OpenClaw 也有 Skill，但需要用户手动创建和维护。Hermes 的做法更接近一个「会写工作手册的实习生」——你带着它做一遍，它自己把流程记下来，下次不用你教了。值得注意的是，两者的 Skill 文件格式兼容（都遵循 agentskills.io 开放标准），这为迁移留了口子。

用户建模：越用越懂你

Hermes 还有一个最容易被忽视的模块——用户建模（Honcho Dialectic）。它会逐渐建立一个关于你是谁、你怎么工作的模型：你的格式偏好、你常做哪类任务、你在什么情况下会否定它的输出。普通 Agent 把每个用户都当陌生人对待，Hermes 在用真实使用数据建立「你」的画像。

极致的部署灵活性

模型切换是一条命令的事——OpenAI、Anthropic、OpenRouter（200 + 模型）、本地 Ollama/vLLM，随时换，不改代码。执行后端支持六种：本地、Docker、SSH、Daytona、Singularity、Modal。重计算任务可以甩到 Serverless 上跑，空闲时休眠，不烧钱。48 个内置工具开箱即用，原生支持 MCP 协议。消息平台支持 Telegram、Discord、Slack、WhatsApp、Signal、Matrix、飞书、企微等 14 个以上平台，并且强调跨平台会话连续性。

三、正面对比：两种哲学的碰撞

不想做模糊的「各有千秋」式总结。以下是每个关键维度的直接对比：

核心差异一句话：OpenClaw 是一个你配置的工具，Hermes 是一个随你成长的队友。OpenClaw 今天是什么样，六个月后还是那个样子。Hermes 今天是什么样，六个月后取决于你怎么用它。

四、你真正需要想清楚的问题

对比表格好做，但真正的决策不在表格里。你需要回答的不是「哪个更好」，而是：你想要一个「AI 交换机」，还是一个「AI 学徒」？

继续用适合继续用 OpenClaw 的场景

核心诉求是多平台消息自动化，需要接入 10 个以上 IM 渠道

需要 iMessage 或语音唤醒等 Hermes 尚未支持的特定能力

喜欢 Canvas 可视化操作界面，或已建立成熟插件工作流

工作流是一次性、无规律任务，不需要 Agent 积累经验成长

考虑迁移适合迁移到 Hermes 的场景

核心诉求是 Agent 越用越聪明，有重复性的结构化工作流

重度使用 CLI，是开发者或研究者，想频繁切换模型或跑本地模型

对安全性有更高要求，不想花时间运维记忆和插件

需要 Serverless 执行重计算任务，或正在做 AI 模型训练研究

注意：把「更新」等同于「更好」是最常见的误区。Hermes 比 OpenClaw 晚出来、star 涨得快——但这不意味着它对你更好。选工具要选匹配你场景的，而不是选最新的。

五、折腾了几个月，你到底收获了什么

很多人的焦虑本质上是：「我花了这么多时间在一个工具上，现在换了是不是全白费了？」不是。你获得的东西比你以为的多。

• 你理解了 AI Agent 的核心架构。
  网关、路由、会话管理、工具调用、权限控制——这些概念不属于 OpenClaw，它们属于整个 Agent 领域。你在 OpenClaw 上踩过的坑，在 Hermes 上、在未来任何一个框架上都是可复用的经验。
• 你积累了可迁移的资产。
  Skill 文件格式兼容，记忆可以导入，API Key 通用。这不是从零开始，这是在已有地基上盖新楼。
• 你建立了调试 Agent 的直觉。
  什么时候是 prompt 的问题，什么时候是工具调用的问题，什么时候是上下文窗口溢出——这种直觉只有在实际使用中才能长出来，看一百篇教程都不如自己 debug 三天。
• 你知道了自己真正需要什么。
  三个月前你可能觉得「22 个平台全覆盖」很重要，现在你可能发现自己 90% 的使用只在 Telegram 和终端。知道自己不需要什么，本身就是巨大的收获。

六、如果决定迁移，怎么做

好消息是：Hermes 是目前极少数主动为竞争对手用户铺好迁移路的工具之一，这本身说明了态度和自信。

01备份 OpenClaw 数据

迁移工具不会修改 OpenClaw 的文件，但备份是好习惯。

cp -r ~/.openclaw ~/.openclaw_backup_$(date +%Y%m%d)

02一行命令安装 Hermes

自动处理 Python 3.11、依赖和配置，不需要 sudo，约 60 秒完成。

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

03先做 dry-run 预览，不实际执行

重点检查：Skill 文件、MEMORY.md、SOUL.md 人格设定、消息平台配置、API key。

hermes claw migrate --dry-run

04确认后正式执行迁移

导入内容：记忆文件、用户画像、Skill 文档（格式自动转换）、API key、消息平台配置。

hermes claw migrate

05CLI 验证后再接消息平台

先在终端跑几个任务，确认 Skill 加载正常、记忆可以召回，再重新接入 Telegram 等消息平台。问题排查用 hermes doctor。

06不一定要卸载 OpenClaw——并行跑一周

Hermes 用 Python，OpenClaw 用 Node.js，两者在同一台服务器上不冲突。并行跑一周后问自己：我打开哪个更多？答案就是你的答案。

迁移提示：简单 Skill（单步骤操作）几乎无缝转换；复杂 Skill（有条件分支）需手动检查；引用了 OpenClaw 特有 API 的 Skill 需要重写。迁移后不要急着手动优化 Skill——让 Hermes 的 learning loop 自动做这件事。

七、借鉴hermes的设计理念如何优化openclaw

目标：先让 agent 变成会记、会复盘、会巡检，不碰复杂自动化，按顺序执行

第 1 步：给 agent 加「工作规矩」

打开AGENTS.md，在最后追加以下内容：

## 记忆治理协议 每次任务结束前，按这个规则处理记忆：

 1. `MEMORY.md` 只保留长期有效的信息： - 用户长期偏好 - 反复出现的工作方式 - 最近 14 天内仍有效的重要决定  2. 下面这些内容不要长期留在 `MEMORY.md`： - 一次性任务过程 - 临时背景 - 已经过期的信息  3. 一次性内容写到当天文件： - `memory/YYYY-MM-DD.md`  4. 过时但又不想彻底删掉的内容，移动到： - `memory/archive.md`  5. 当一个任务已经完成： - 在当天记忆里写一条结果摘要 - 不要把全部过程塞进 `MEMORY.md`  ## 技能沉淀协议 当一个任务满足下面条件时，整理成 Skill： - 这个任务以后还会反复做 - 步骤比较固定 - 做错的地方比较类似 - 有明确的检查方法  满足条件后，创建文件： - `skills//SKILL.md`  Skill 里必须写清楚 4 件事： 1. 什么时候用 2. 具体步骤 3. 常见失败点 4. 怎么验证有没有成功  下面这些不要做成 Skill： - 一次性探索 - 每次步骤都不一样的任务 - 强依赖临时上下文的任务

第 2 步：准备记忆文件

1）长期记忆文件

文件：MEMORY.md

# MEMORY.md ## 用户长期偏好 - 喜欢直接、简洁、能落地的建议 - 不喜欢空话和大段铺垫 - 优先看可执行步骤和模板  ## 长期工作原则 - 不清楚的需求先问清楚 - 交付前自己验证 - 重要结论尽量多方确认 - 原则性要求要长期记住  ## 当前有效习惯 - 技术问题先查本地资料，再查外部资料 - 做完任务后记录到 `memory/YYYY-MM-DD.md`

2）当天记忆目录

创建目录：memory/

文件：memory/2026-04-09.md

# 2026-04-09 ## 今天做了什么 - 给 agent 增加了记忆治理协议 - 给 agent 增加了技能沉淀协议  ## 今天得到的结论 - 长期记忆要瘦身 - 重复流程适合做成 Skill

3）归档文件

文件：memory/archive.md

# archive ## 已归档 - 2026-04-01：一次性测试过程，已完成 - 2026-04-03：临时讨论内容，已失效

记忆三层结构：

第 3 步：给 agent 一个最小可用的 heartbeat

作用：巡检，只检查异常，不做复杂操作

文件：HEARTBEAT.md

# heartbeat 工作清单 每次收到 heartbeat 时，按顺序检查： 1. 检查 Gateway 是否正常 2. 检查最近日志里有没有新的严重报错 3. 检查 `MEMORY.md` 是否明显变长、变乱 4. 检查最近有没有适合整理成 Skill 的重复任务 5. 如果没有需要处理的事，回复：HEARTBEAT_OK 6. 如果发现异常，直接说清楚： - 问题是什么 - 影响是什么 - 建议怎么处理

第 4 步：创建第一个 Skill 模板

创建目录：skills/review_memory/skills/diagnose_gateway/

模板 1：整理记忆

文件：skills/review_memory/SKILL.md

name: review_memory description: 整理长期记忆、当天记忆和归档内容，避免上下文越来越乱 # 什么时候用 当出现下面情况时使用： - `MEMORY.md` 变长了 - 有很多一次性内容混进长期记忆 - 任务做完后需要整理结论  # 步骤 1. 打开 `MEMORY.md` 2. 找出不适合长期保留的内容 3. 把一次性内容移动到 `memory/YYYY-MM-DD.md` 4. 把过期但还想保留的内容移动到 `memory/archive.md` 5. 保证 `MEMORY.md` 里只剩长期有效的信息  # 常见失败点 - 把任务过程全塞进 `MEMORY.md` - 把已经失效的信息继续长期保留 - 归档了，但没有在当天记忆里写摘要  # 怎么验证 检查这 3 件事： 1. `MEMORY.md` 里只剩长期有效信息 2. 当天发生的事写进了 `memory/YYYY-MM-DD.md` 3. 旧信息被移动到了 `memory/archive.md`

模板 2：排查 Gateway

文件：skills/diagnose_gateway/SKILL.md

name: diagnose_gateway description: 排查 OpenClaw Gateway 是否异常，检查监听、日志和恢复情况 # 什么时候用 当出现下面情况时使用： - 消息没有正常发送 - heartbeat 异常 - cron 没执行 - 用户怀疑 Gateway 挂了  # 步骤 1. 检查 Gateway 端口是否监听 2. 查看最近日志里的 error、fail、exception 3. 判断问题属于哪一类： - 进程没启动 - 配置错误 - 权限或认证问题 4. 给出修复动作 5. 修复后再检查一次  # 常见失败点 - 只看报错表面，不看日志上下文 - 修完后不验证 - 把配置问题误判成服务挂了  # 怎么验证 至少确认下面两件事： 1. 相关端口恢复监听 2. 实际触发一次相关功能，确认恢复

第 5 步：把 heartbeat 配置打开

{   id: "sysmon",   heartbeat: {     every: "30m",     target: "last",     lightContext: true,     isolatedSession: true,     activeHours: {       start: "08:00",       end: "22:00",       timezone: "Asia/Shanghai"     }   } }

第 6 步：加两个每周自动整理任务

任务 1：每周整理记忆

openclaw cron add \ --name "memory-review" \ --cron "30 10 * * 0" \ --session isolated \ --message "检查 MEMORY.md、memory/YYYY-MM-DD.md、memory/archive.md，清理过时内容，只保留长期有效信息，并把结果写入当天记忆。" \ --no-deliver

任务 2：每周整理技能

openclaw cron add \ --name "skill-review" \ --cron "0 10 * * 0" \ --session isolated \ --message "检查 skills 目录，合并重复技能，删除明显过时的技能，补充常见失败点和验证方法，并把结论写入当天记忆。" \ --no-delive

八、关于「跟不上」这件事

2026 年的 AI 工具生态，有点像 2012 年的前端框架大战。每个月都有新的「颠覆性」项目，每个社区都在说「这次不一样」。Backbone、Ember、Angular、React、Vue……当年的前端开发者也经历过完全一样的焦虑。

回头看，那场战争的赢家不是押对了某个框架的人，而是理解了底层模式的人。组件化、单向数据流、虚拟 DOM——这些概念超越了任何一个具体框架，在每一个新框架里都能快速上手。

AI Agent 领域也一样。不管框架怎么换，有些能力是不会过时的：

• Prompt 工程
  ——如何给 Agent 下达精确的指令
• 工具设计
  ——如何定义好的工具接口（MCP 正在成为标准）
• 记忆架构
  ——如何管理上下文、做信息压缩和检索
• Agent 调试
  ——如何定位「Agent 做了蠢事」的根因
• 安全边界
  ——如何让 Agent 有足够权限做事，又不至于失控

这些能力，在 OpenClaw 里锻炼的，在 Hermes 里直接用得上，在未来任何一个 Agent 框架里同样适用。所以我的建议不是「赶紧换 Hermes」，也不是「守住 OpenClaw」，而是：

停止追逐工具，开始投资能力。选一个当前最适合你场景的框架，深度使用它，但把注意力放在那些可迁移的底层能力上。框架会过时，能力不会。

关于openclaw资料包和系列文章