夜雨聆风1月底，一个叫 OpenClaw 的 GitHub 项目上线了。
图标是一只龙虾——OpenClaw，谐音 open claw，张开的爪子。作者的介绍是"Any OS. Any Platform. The lobster way. 🦞"
一个礼拜拿了十万颗 Star。
这是什么概念？GitHub 史上破十万 Star 最快的项目之一。两个月前，这只赛博龙虾被所有人捧成了"开源 AI 代理的正确打开方式"。Medium、Hacker News、微博、即刻，铺天盖地都是"我用 OpenClaw 做了 X"。
然后，2月初，Nous Research 悄悄上线了一个叫 Hermes Agent 的项目。
Hermes，希腊神话里的信使神。
两个月后的今天——4月10日——Hermes 累积了三万三千颗 Star，速度比不上 OpenClaw 的凶猛，但势头非常不一样。Reddit、X、YouTube 上开始出现大量的标题：
"I ditched OpenClaw for Hermes."
（我把 OpenClaw 扔了，换成 Hermes。）
更微妙的是——Hermes 官方直接提供了一个迁移命令：
hermes claw migrate一键把你的 OpenClaw 配置、记忆、技能、API key 全部搬过来。
连迁移工具都是官方做的。 这个动作很坏，也很聪明。它不是在说"我们是竞品"，它是在说："你用完龙虾了，接下来用信使。"
今天这篇文章，想聊聊这场交接——以及为什么在 OpenClaw 和 Hermes 之外，我自己每天还是在用 Claude Code。
⬥ ⬥ ⬥
OpenClaw 到底是个什么东西
先说 OpenClaw，因为很多人其实没搞懂它。
它不是一个聊天机器人。也不是一个写代码的 IDE 插件。它是一个"个人 AI 代理"——住在你自己电脑上，通过你每天都在用的通讯软件（WhatsApp、Telegram、Slack、Signal）跟你对话，然后替你干活。
比如你在 Telegram 里发一句"帮我看一下昨晚的服务器日志，有没有 error"，它就会自己去 SSH 到你的服务器，cat 一下日志文件，grep 出错误行，整理好发回给你。
再比如你发一句"每天早上九点给我 summarize 一下今天的 GitHub 通知"，它会记下来，然后真的每天九点做这件事。
OpenClaw 的核心设计有三个很重要的选择：
1. Local-first（本地优先）。 所有的记忆都存在你本机的 Markdown 文件里。不是数据库，不是云。你可以直接用文本编辑器打开看它"记住"了什么——这在隐私敏感的场景下非常重要。
2. Messaging-first（通讯优先）。 它不做自己的 UI。因为你每天已经在看 Telegram 和 Slack 了，再多一个窗口只会增加你的认知负担。它寄生在你已有的通讯习惯上。
3. Heartbeat scheduler（心跳调度器）。 它有一个后台守护进程，每隔一段时间"醒来"一次，检查有没有需要执行的定时任务。这让它不是一个"被动响应"的机器人，而是一个"主动工作"的代理。
架构上，OpenClaw 分成三层：
Channel（通道层） — 处理各种消息协议的适配 Brain（大脑层） — 负责推理、决策、调用工具Body（身体层） — 实际执行动作：shell 命令、浏览器、文件、邮件
所有东西都汇总到一个叫 Gateway 的进程里。官方文档管它叫"单一事实来源"。
这是一个教科书级别的 AI 代理架构。简洁、清晰、可扩展。
它的问题也正好藏在这个简洁里。
⬥ ⬥ ⬥
OpenClaw 的天花板：它不会变聪明
用过 OpenClaw 一段时间的人会慢慢意识到一件事：
它今天的样子，和一个月前的样子，几乎一模一样。
你教过它的东西，它不会真的"学会"。你让它执行过一个复杂流程，下次再遇到类似的场景，它还是要从头想一遍。
为什么？
因为 OpenClaw 的"技能"系统是静态的。你想让它掌握某个工作流，你得自己写一个 Markdown 文件，放到 skills/ 目录下，告诉它"遇到 X 情况，按 Y 步骤执行"。
这听起来很合理——直到你意识到：你在用自己的时间，去给一个号称"AI 代理"的东西写说明书。
更讽刺的是，每个用户都在重复这件事。你写的 skill 文件不会自动同步给别人，别人写的也不会同步给你。一万个 OpenClaw 用户，在重复写一万份大同小异的工作流文档。
这不是 AI 代理。这是一个"脚本管理器"穿了个 AI 的外套。
Nous Research 的工程师们显然早就看穿了这件事。他们没有去做"OpenClaw 2.0"——他们做了一个结构上完全不一样的东西。
⬥ ⬥ ⬥
Hermes 的核心升级：一个真正的学习闭环
Hermes Agent 的 tagline 是一句话：
"The agent that grows with you."（和你一起成长的代理。）
这句话听起来像是营销话术。但 Hermes 真的做到了一件 OpenClaw 做不到的事：它会自己写 skill 文件。
具体机制是这样的：
第一步：你让 Hermes 做一个复杂任务——比如"帮我部署这个项目到 Modal 上，配好环境变量，跑一下 smoke test"。
第二步：Hermes 跑完之后，会自己判断："我刚才做的这件事是不是一个可以被复用的工作流？" 如果是，它会自动生成一个 skill 文档，总结这次的步骤、遇到的坑、关键的判断点。
第三步：下次你再说"部署 X 到 Y"，它会先去 skill 库里检索有没有类似的经验。如果有，它不是按 skill 的 step-by-step 执行，而是用这个 skill 作为上下文参考，结合当前的具体情况来调整。
第四步（这个是关键）：执行过程中，如果这次的情况和上次不一样——比如多了一个步骤、少了一个依赖——Hermes 会更新这个 skill。不是覆盖，是迭代。就像一个同事在自己的工作笔记本上划掉一行，加上新的一行。
官方的说法是"skills self-improve during use"——技能在使用中自我改进。
这就是 OpenClaw 和 Hermes 最本质的区别。OpenClaw 的技能是一块石头，你怎么刻它就是什么样；Hermes 的技能是一块橡皮泥，越用越贴合你的手型。
⬥ ⬥ ⬥
记忆系统：从 Markdown 到 FTS5
Hermes 还做了一件 OpenClaw 没做的事：跨会话记忆。
OpenClaw 的记忆是按会话切分的——每次你和它的对话结束，那段记忆就"归档"成一个 Markdown 文件。下次新开对话，它不会主动去翻那些旧文件。你得明确告诉它"去看看上次我们聊 X 的时候说了什么"，它才会去找。
Hermes 用了一个完全不同的方案：
所有历史会话都存进 SQLite 数据库，用 FTS5 做全文索引，同时用 LLM 做滚动摘要。
FTS5 是 SQLite 自带的全文搜索扩展——非常快，毫秒级返回结果。LLM 摘要则负责把长的对话压缩成要点。这两者结合起来的效果是：
你三个礼拜前随口跟它提过一句"我比较讨厌 black 这个 formatter，更喜欢 ruff"——今天你新开一个项目让它帮你配 CI，它会主动说"按你之前的偏好，我用 ruff 了"。
这不是魔法。这只是一个聪明的工程决策：把"记忆"从 Markdown 文件升级成了可检索的数据库。
同一个问题的两种解法，产出的体验天差地别。
⬥ ⬥ ⬥
部署灵活性：六种后端
还有一个容易被忽略但非常重要的差异。
OpenClaw 基本上假设你在自己的机器上跑。你可以用 SSH 让它去操作远程服务器，但 OpenClaw 进程本身是跑在 local 的。
Hermes 支持六种 terminal backend：
local — 本地执行（和 OpenClaw 一样）Docker — 沙盒化执行，不污染本机环境SSH — 在远程机器上运行 Hermes 本身Daytona — 云开发环境Singularity — HPC 高性能计算集群Modal — serverless，按需启动
这意味着你可以让 Hermes "住在"一个 Docker 容器里，它的每一次 shell 命令都被沙盒隔离；也可以让它跑在 Modal 上，平时不消耗资源，有任务时自动起来。
这种架构上的灵活性，是 OpenClaw 在设计时根本没考虑的。因为 OpenClaw 的初衷是"个人助理"，Hermes 的初衷是"可以长期驻留、自主演化的工作伙伴"。
一字之差，产品形态完全不同。
⬥ ⬥ ⬥
还有一个细节：Honcho
Hermes 里集成了一个叫 Honcho 的东西。这是一个"dialectic user modeling"框架——人话说就是：它会偷偷给你建模。
不是建你的代码风格的模型，是建你这个人的模型。
你说话的方式、你的节奏、你做决定时的偏好、你容易焦虑的点、你擅长什么不擅长什么——Honcho 会在后台持续更新这个模型。Hermes 在执行任务时，会把这个模型当作背景上下文传给 LLM。
这让 Hermes 的输出开始有了一种"这人懂我"的感觉。
当然也让一些人觉得毛骨悚然。这是两个月前我们聊过的另一个话题——蒸馏。被 Hermes 长期使用的用户，实际上在一边使用它，一边被它"读"。读到的东西是你的思维方式、决策偏好、工作节奏。
技术上这一切都在你本机，数据不上传。但"不上传"和"不存在"是两回事。有一天你换一个 LLM 后端，那个模型就会接管这份 profile。
这是 Hermes 的承诺，也是 Hermes 的暗面。
⬥ ⬥ ⬥
然后是 Claude Code
聊了这么多，得说一下我自己为什么每天还是在用 Claude Code。
Claude Code 和 OpenClaw/Hermes 不是一个物种。
OpenClaw 和 Hermes 是"个人代理"——住在后台，通过消息跟你对话，替你跑杂活。它们是通用助手。
Claude Code 是"编码伙伴"——住在你的终端里，你打开项目就在那里，你关掉终端它就走。它只做一件事：和你一起写代码。
但 Claude Code 最近加了一个让我彻底上瘾的功能，叫 Agent Teams。
⬥ ⬥ ⬥
Agent Teams：十六个 Claude 一起干活
Agent Teams 是 Claude Code 的实验性功能，默认关闭，需要你在 settings.json 里加一行：
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": true打开之后，你可以同时启动多个 Claude Code 会话，它们共享一个任务列表。
怎么理解这个"共享"？
传统的多 agent 方案是层级式的：一个 orchestrator（总指挥）下面带一堆 worker（执行者）。总指挥分任务给下面，下面做完了汇总给总指挥。
Claude Code 的 Agent Teams 不是这样的。它是扁平的 peer model——所有 agent 地位平等，没有总指挥。协调机制是一张共享的任务清单：
每个 agent 自己从清单里认领一个未认领的任务 认领之后在上面标记"我在做这个" 做完了把它标记为 done，然后去认领下一个
这就像真实世界里一个施工队：没有工头站在中间指挥，只有一块白板，上面写着今天要做的事。每个工人看哪件事没人做，就去做哪件。做完了回来划掉，再看下一件。
协调发生在白板上，不是某个人的脑子里。
⬥ ⬥ ⬥
十六个 Claude 写了一个 C 编译器
Anthropic 自己做过一个 demo——让 Agent Teams 去写一个 Rust 实现的 C 编译器，要求能编译 Linux 内核。
他们启动了十六个 Claude Code agent，让它们共享一个任务列表，自己去协调。
最后的结果：一个十万行的 C 编译器，跑了将近两千个 Claude Code session，真的能编译 Linux 内核。
没有人写过一行架构设计。没有人做过任务分解。只有一个初始的目标和一块共享的白板。
我第一次看到这个 demo 的时候，想的是：这是编程工具的形态转变，不是性能提升。
以前我们用 IDE，一个人敲代码。然后我们用 Copilot，一个 AI 帮你补全。然后我们用 Claude Code，一个 AI 和你对话。
现在是：十六个 Claude 和你一起，在一张共享的白板前工作。
你不再是"一个敲代码的人"，你变成了"一个项目的产品经理"。你的工作不是写每一行代码，而是定义要做什么、审核做得对不对、在架构层面做决定。
这是一个非常奇怪的体验。我现在每天用 Claude Code 的时候，经常要同时看三四个终端窗口，每个窗口里有一个 Claude 在跑。它们自己在认领任务，自己在完成，偶尔有一个会停下来问我"这里需要你确认"。
大部分时候我只是个观众。
⬥ ⬥ ⬥
三种形态，三种哲学
所以现在我们有三个东西：OpenClaw、Hermes、Claude Code Agent Teams。
它们代表了 AI 代理的三种哲学：
OpenClaw 是"静态脚本代理"。 你写规则，它执行。它很忠诚，很透明，很可控，但它永远不会变得比你教它的更聪明。它适合那种希望"一切都在我手里"的人——懂技术、不信任黑盒、愿意花时间维护自己的工具链。
Hermes 是"自演化代理"。 你用它，它学你。你教它一次，它自己记住下次。它会主动把复杂流程压缩成 skill，再根据新的情况迭代那个 skill。它适合那种希望"工具能随着我一起变聪明"的人——懒得写文档、但愿意持续使用同一个工具。
Claude Code Agent Teams 是"并行协作代理"。 你不是在使用一个代理，你是在监督一群代理。它们彼此协调，共享任务，像一个小团队一样工作。它适合那种"已经不是一个人在写代码，而是在运营一个项目"的人。
三者不是谁取代谁的关系。它们回答的是不同的问题：
OpenClaw 问的是："AI 怎么帮我处理日常杂事？" Hermes 问的是："AI 怎么在帮我的过程中变得更懂我？" Claude Code 问的是："AI 怎么和我一起，完成一件我一个人完不成的事？"
⬥ ⬥ ⬥
为什么我选择 Claude Code
我得承认一件事——写这篇文章之前，我就知道我不会换掉 Claude Code。
不是因为 Hermes 不好。Hermes 很好。self-improving 的概念在技术上非常吸引人，架构也漂亮。如果我要找一个"长期驻留、帮我管琐事"的代理，我大概会选 Hermes。
但我现在做的工作的写代码写脚本完全用Claude Code，写文章的时候用 Claude Code搜集信息，做音乐的时候用 Claude Code交流灵感，做视频的时候用Claude Code编排，自己开发的IOS App也都是 Claude Code，当然也可能因为运维出身，对终端命令行本身就喜欢，一用就高潮得不行。
它已经变成了我的"第二只手"。不是打辅助，而是真的承担了一半的工作量。
而 Agent Teams 这个功能出来之后，这种感觉被放大了几倍。
上个礼拜我让三个 Claude 同时开工处理一个项目——一个负责读文档、一个负责写测试、一个负责实现功能。它们互相交接，共享 task list，遇到冲突自己沟通。我只需要每隔二十分钟看一眼它们的进度，偶尔回答一下"这个接口你想怎么设计"。
两个小时，完成了过去我要写一整天的活。
不是因为我变快了。是因为我不再是那个在写代码的人。
这个转变一旦你体验过，就很难回去。
⬥ ⬥ ⬥
最后
这篇文章本来想写成一个技术对比——OpenClaw vs Hermes vs Claude Code，三者的架构、特性、优劣。
写到最后发现不是这么回事。
它们对应的是三种工作方式的想象：
OpenClaw 想象的是"每个人都应该有一个私人助理"。 Hermes 想象的是"这个助理应该越用越懂你"。 Claude Code 想象的是"你不该一个人工作"。
我最喜欢 Claude Code 是因为它对应的那个想象，正好是我现在需要的。
但我也知道，六个月后、一年后、两年后，我可能会换。因为工作的形态一直在变，工具的形态也在变。今天的 Claude Code，未来也会被某个"我们现在还没想到的东西"取代。
这就是 2026 年的节奏。一个礼拜一只龙虾火了，两个月后一个信使出来了，然后十六个 Claude 在白板前开会。
你能做的不是挑一个"最好的"。你能做的是让自己保持一种可以随时被改变工作方式的状态。
别和工具结婚。约会就好。
⬥ ⬥ ⬥
*本文事实信息主要来源于 GitHub（OpenClaw、Hermes Agent 仓库）、Nous Research 官方文档、The New Stack、DEV Community、Medium、Anthropic 官方工程博客（C 编译器 demo）、Claude Code 官方文档（Agent Teams）、MindStudio 及 Codegen 的对比评测文章。*
