深度拆解:从 OpenClaw 到 Hermes 的架构迁移实战

大家好，我是 kman。之前写过一篇我用 OpenClaw + 飞书搭的那套 6 个 Agent 分工方案——小墨管调度、墨媒管运营、墨码写 AI、墨微写读书、墨红跑小红书、墨拍做短视频，资讯抓取、编码辅助、公众号和短视频运营全压在这套架子上。

跑了一段时间，架构本身没毛病，”角色化分工”的思路我现在依然认。但实操里有两个问题越来越绕不开：

一是烧 token。 多个 Agent 之间反复传上下文，加上每个角色自带的 SOUL/USER/AGENTS 三件套，一轮任务跑下来 token 哗哗走，两天就开始算账。

二是丢记忆。 长链路任务跨几轮之后，前面铺好的状态经常对不上号，得人工回去捞，”全自动”硬生生跑成了”半自动”。

最近研究了一段时间 Hermes，发现它在上下文管理和成本控制上的设计思路明显更”工程化”——不是堆 Agent 数量，而是把这两件事当成核心问题来解决。

这篇是一次实打实的迁移复盘：把 OpenClaw 那套场景原样搬到 Hermes 上，记录哪些坑没躲过、哪些地方真香、哪些地方还需要再观察。没有跑分数据，只有真实体感，给同样在多 Agent 路上折腾的朋友一点参考。

一、两个心头病，到底硌在哪

光说”烧 token、丢记忆”太虚，举两个我自己每周都会遇到的场景。

场景一：风格记忆”薛定谔更新”

用墨码Agent写读书号的公众号内容，写了一段时间之后，风格和用词习惯基本定下来了。我觉得这些应该沉淀下来，于是把偏好重新整理了一遍——哪些词不能用、句子多长、语气什么感觉——让 OpenClaw 更新到永久记忆。

更新完当场试了试，写得挺好，风格完全对上了。

结果下次开个新对话接着写，它又回到了最早那种味道——好像上次的更新压根没发生过。我只能再贴一遍偏好，再让它更新一次。过几轮，老样子又来了。

这件事本身就违背了我用这套系统的初衷：我不应该每次都当”人肉记忆搬运工”。

场景二：墨拍做短视频脚本

短视频脚本是个典型的多 Agent 协作场景：

这套链路跑起来，每个 Agent 都要把前面所有 Agent 的产出当作上下文塞进去，token 是叠加的。一条 60 秒的脚本，背后可能是几万 token 的内部对话——你为最终那 300 字的脚本，付了整本小说的钱。

而且只要中间任何一个 Agent 上下文截断了，后面就开始胡编。

两件事归根到底是同一个问题： 在多 Agent 系统里，”上下文”和”成本”是绑在一起的。要省 token 就得砍上下文，砍了上下文就丢记忆——OpenClaw 的设计更偏”角色隔离、各管一摊”，把这道题留给了使用者自己解。

二、为啥看上 Hermes

研究下来，Hermes 吸引我的是两个底层设计思路（以下是我作为使用者的理解，具体实现请以官方文档为准）。

1. 记忆是显式管理的资源，不是靠对话历史堆出来的

OpenClaw 的玩法更像”一群人在群里协作”，每个人手里拿着自己的笔记本，需要同步信息就互相喊话。

Hermes 的思路更像”大家手里都有各自的本子，但项目关键信息放在共同可见的地方”——共享状态是显式管理的，Agent 之间传递的是结构化引用，而不是把完整的对话历史再喂一遍。

这意味着：像读书号持续输出这种跨周期的任务，记忆稳不稳定，不再靠”对话历史还没被截断”这种运气。

2. 成本可观测，优化有抓手

多 Agent 系统最坑的不是贵，是你不知道贵在哪。

Hermes 把 token 消耗、调用链路、每个 Agent 的成本贡献做成了可视化。哪个环节在烧钱，一眼能看出来；想优化也有地方下手——而不是像之前那样，月底看账单只能干瞪眼。

这两点，正好对上我那两个心头病。

三、迁移实录：Profile 隔离怎么用

光说概念太虚，直接上迁移过程。

OpenClaw 那套是用”一个 Agent 一个 workspace”做隔离，记忆、SOUL、技能完全独立。Hermes 走的是类似但更轻的路子：用 profile 做隔离单位。

我对着原来 6 个 Agent 的角色，在 Hermes 里建了对应的 profile：

default          日常私人助手（运行中）work             工作项目coding           编程专用research         研究资料wechat-book      读书分享公众号（对应原墨微）wechat-laoma     老码的AI实践公众号（对应原墨码）moss-video       视频内容创作（对应原墨拍）

每个 profile 都用 --clone 从 default 复制出来，自动继承了 config、.env、SOUL.md 和 skills。

也就是说，起步时所有角色共享同一套基线，之后各自独立演化——这比 OpenClaw 那种”从零写一份 SOUL/USER/AGENTS”省事很多，特别适合从一个能用的 default 慢慢分化出专精角色。

启动方式也很轻：

hermes -p wechat-laoma   # 进入交互hermes -p coding chat -q"帮我审查这个项目代码"# 单次调用

每个 profile 还会自动生成一个 wrapper，等于给每个角色发了张名片：

wechat-laoma chatmoss-video chat

有一点必须说清楚： profile 隔离的是记忆、上下文和会话，不是系统权限。如果你启用了 file/terminal 这类工具，它们依然可以访问同一个本机文件系统。

所以，多 Agent 系统的安全边界永远要在工具权限那一层划，不是靠角色隔离。这一点 OpenClaw 也一样。

四、搬迁实录：读书号风格记忆怎么稳住

profile 建好了，最该验证的就是场景一说的那个问题——风格记忆到底能不能真的留住。

改造前（OpenClaw）：

改造后（Hermes / wechat-laoma profile）：

踩到的坑：

体感差异：

新开对话不再需要手动喂风格了，它自己就能对上。偶尔还会飘，但比之前好太多。最大的感受是：我终于不用当”人肉记忆搬运工”了。

五、搬迁实录：墨拍短视频脚本

这条线考的是多 Agent 协作的成本问题。

改造前（OpenClaw）：

改造后（Hermes / moss-video profile）：

这里说明一下实际结构：四个环节仍然是独立的 profile（墨媒、墨码、墨拍各自一个），它们之间不直接传对话历史，而是传结构化的中间产物——选题卡、素材包、脚本草稿、平台适配版。

需要共享的项目状态（比如选题方向、风格约定）单独维护，每个 Agent 按需取用，而不是每次全量传递。

整条链路的 token 消耗在 Hermes 后台是可视化的，哪个环节贵一眼能看见。

踩到的坑：

体感差异：

没有具体数据，但直观感受是同样一条脚本，内部对话量明显瘦身。更重要的是，当某条脚本出问题，我能直接定位是哪个环节出了什么状况——这在 OpenClaw 那套里基本靠猜。

六、阶段性结论

跑了快一个月，给个阶段性判断。

Hermes 真香的地方：

还在观察的地方：

给想跟进的朋友三条建议：

最后说一句：工具的迭代没有终点。OpenClaw 教会我”角色分工”的思路，Hermes 在这个基础上把记忆管理和成本控制做得更工程化。底层思路是延续的，不是推翻。