Max
搜索
返回故事会
◆

从 Coding Agent 到 Living Agent：为什么 Hermes 指向了一个完全不同的未来

86 分钟阅读0Max ZhangLLMOps
AgentHermesSkillsMemorySelf-ImprovingOrchestrationClaude Code
◆

周三下午两点半，我正在重构一个老项目的 CI 配置，飞书突然弹了条消息。

不是同事，不是老板，是我那台 5 美元 VPS 上跑着的 Hermes Agent：

"staging 环境的 CI 在 14:12 挂了，原因是 Prisma migration checksum 不一致——上周四你手动改了 migration 文件但没 regenerate checksum。我已经生成了修复的 commit，要我直接推到 fix/prisma-checksum 分支吗？"

我回了一个字："推。"

三十秒后，它又说：

"已推送。顺便提一句，这是本月第二次 checksum 问题了。要不要我把'Prisma migration 修改后自动 regenerate checksum'加到你的 pre-commit hook skill 里？下次就不用等 CI 挂了才发现。"

我当时愣了一秒。不是因为它帮我修了 bug——Claude Code 也能干这事。让我愣住的是后半句：它记得上次，而且它在主动改进自己的处理方式。

这不是一个工具。这是一个正在变聪明的东西。

我拿起手机回了一句："加吧。"

然后把手机放下，继续重构 CI。但脑子里一直在转一个问题：这玩意和我用了快一年的 Claude Code 到底有什么本质区别？

Claude Code 也能帮我修 bug，也能写代码，有时候甚至写得比我好。但它从来没有——一次都没有——主动跟我说过"嘿，你上次也犯了这个错，要不要我帮你防一下？"

从来没有。

因为它不记得有"上次"。

一、金鱼记忆的 Agent 时代

你有没有过这种感觉——每次打开 Claude Code 或者 Cursor，你都得重新告诉它一遍"我们项目用 Prisma 不用 TypeORM"、"我们用 pnpm 不用 npm"、"我们的 ESLint 是 flat config"？

你告诉过它一百次了。但第一百零一次，它还是会问你。

或者更他妈的：你花了两个小时跟它讨论了一个架构方案，最后决定用 BullMQ 做异步队列、用 Redis 做 pub/sub、不用 Kafka 因为团队规模不需要那个复杂度。三天后你再开一个新对话，让它帮你设计另一个异步流程——它建议你用 Kafka。

卧槽。

它不是故意跟你作对，它是真的不记得。每一次新的对话，对它来说都是宇宙大爆炸的第一天。你们之间所有的讨论、所有的决策、所有的上下文，在那个 session 结束的瞬间就灰飞烟灭了。

Claude Code 是这样。Cursor 是这样。Copilot 是这样。它们都是金鱼——七秒钟的记忆，甚至不到七秒钟，是一个 session 的记忆。

你可能会说："但是 Claude Code 有 CLAUDE.md 啊，Cursor 有 .cursorrules 啊，我可以把项目信息写进去。"

对，你可以。但那是你在维护记忆，不是 Agent 自己在维护。你得手动写、手动更新、手动保证它跟项目实际情况一致。你上次更新 CLAUDE.md 是什么时候？一个月前？两个月前？里面写的还是你现在的技术栈吗？

这本质上是一个"谁该承担维护成本"的问题。目前所有主流 Agent 的答案都是：你来维护。我只负责在当前 session 里尽力而为。

这就引出了一个我越想越觉得重要的问题：

一个你用了三个月的 AI Agent，和一个你刚装好的 AI Agent，应不应该是不同的东西？

如果你的回答是"当然应该"——恭喜，你和 Hermes 的设计者想到了一起。

如果你的回答是"无所谓"——那你可能还没遇到过那种"跟 Agent 反复解释同一件事"的崩溃感。等你遇到了再回来看这篇文章。

二、四种 Agent，四个物种

在讲 Hermes 之前，我想先把当下市面上所有的 Agent 产品放到一张地图上，让你看清楚它们各自在什么位置。不是为了比参数，是为了让你看到——它们根本不是在回答同一个问题。

任务执行型：Manus 和它的同类

Manus 是 2025 年初爆火的那个 Agent。你给它一个复杂任务——"帮我调研 2026 年 Q1 所有 AI Agent 框架的 GitHub stars 趋势，生成对比报告，导出为 PDF"——它会自动拆分步骤、打开浏览器、搜索数据、生成图表、导出文件。

看起来很逆天对吧？第一次用的时候确实会有"未来已来"的感觉。

但你用第十次、第二十次之后，你会发现一件事：它每次都是从零开始的。

你第一次让它做竞品调研，它搜了半天才知道去 GitHub 看 stars。你第二次让它做类似的事，它还是会搜半天。你第十次让它做，它还是会搜半天。它不会从第一次的经验中学到"哦，这哥们要的竞品调研，直接去 GitHub API 拉数据最快"。

为什么？因为 Manus 的设计哲学是"一次性任务的完美执行"。它的目标是把单次任务的成功率做到最高，不是让你第二次用得更快。这两个目标是不同的。

Manus 解决的问题是：一次性复杂任务的自动化执行。

它不解决的问题是：跨任务的经验积累。

这个区别很关键。因为如果你的使用场景是"每次任务都不一样"（比如你是个研究员，每天的调研方向都不同），那 Manus 确实够了。但如果你是一个工程师，你的工作 80% 是在做"类似但不完全相同"的事情——初始化项目、写 CRUD、配 CI、做 code review——你需要的是一个能把过去的经验带到下一次的 Agent。

编码辅助型：Claude Code、Cursor、Copilot

这一类的定位更窄：在你写代码的时候帮你补全、重构、debug。

Claude Code 是目前这个品类里最强的。它能看完你整个项目的代码、理解架构、然后帮你写出风格一致的新代码。它的上下文窗口巨大，一次能吃进去几十个文件。Cursor 类似，但多了一个 IDE 的壳和更好的交互体验。Copilot 则是纯补全型的，思考深度不够。

问题在哪？

问题在于它们是"无状态的专家顾问"。每次你请教它，它都用全力帮你解答。但它不记得上次帮你解答了什么。它不知道你上个月决定放弃 GraphQL 改用 tRPC 的原因。它不知道你们团队的代码规范里有一条"所有 API 响应都用 Result 类型包装"——除非你把这条写进了 CLAUDE.md。

你可以用 .cursorrules 或 CLAUDE.md 来手动塞一些上下文。但那是你在手动维护一份"记忆文件"——Agent 本身没有这个能力。

而且这些文件有一个致命问题：它们是静态的。 你写进去的东西不会自动更新。你上周决定的事情，得你自己手动去改文件。你忘了改？Agent 就会用过时的信息来做决策。

我承认 Claude Code 的"单次执行能力"是目前最强的。让它写一段代码、重构一个模块、解一个 bug——它比 Hermes 做得好。但"单次执行能力"不是唯一重要的维度。

平台封闭型：Coze、扣子、各种国产 Agent 平台

这一类的特点是：你在别人的平台上搭建 Agent，数据归平台，模型归平台，运行环境归平台。

好处是门槛低——拖拖拽拽就能搭出一个"能跟客户聊天的机器人"。对于非技术人员来说，这可能是唯一的选择。

坏处是你把所有的筹码都押在了别人的桌上：

  1. 模型锁定。 Coze 只能用字节的模型（或它接入的有限几个模型），你不能说"今天我想试试 DeepSeek V4"就切过去。
  2. 数据锁定。 你所有的对话记录、workflow 定义、知识库数据，全在别人的服务器上。你想迁移？祝你好运。
  3. 不可本地化。 你不能把它跑在自己的 VPS 上、自己的内网里。对于有安全要求的场景（比如你在处理客户代码），这是 deal breaker。
  4. "记忆"是假的。 它们所谓的"长期记忆"，很多时候只是在 system prompt 里塞了一些之前的对话摘要。这不是记忆，这是 context window 的变相使用。
  5. 没有成长性。 这些平台的 Agent 不会因为你用了三个月就变得更懂你。它们的行为完全由你定义的 workflow 决定——你不改 workflow，它的表现就不会变。

我不是说这些产品没有价值。它们有——对于特定场景（客服机器人、内容生成流水线、简单的数据处理），它们是性价比很高的选择。但它们不是"个人 Agent"，它们是"自动化平台"。

自进化型：Hermes

然后是 Hermes。

它和上面三类的本质区别是什么？一句话：

用了三个月的 Hermes，和刚装好的 Hermes，是完全不同的两个 Agent。但用了三个月的 Claude Code 和刚装好的 Claude Code，没有任何区别。

Hermes 把"成长性"当成了第一设计原则。不是 feature，不是插件，是地基。整个系统的架构——从 Skills 到 Memory 到 User Model 到 Nudge 机制——都是围绕这一个核心目标设计的：让这个 Agent 随着使用时间的增长而变得更好用。

这是一个本质不同的设计哲学。不是"如何帮你更好地做完这一件事"，而是"如何在帮你做事的过程中变成更懂你的那个人"。

接下来我们一层一层拆开它。

三、学习闭环：Hermes 的核心引擎

Hermes 的自进化不是一个"记笔记"的功能，它是一个完整的闭环系统。我把它拆成四层来讲。

第一层：Skills —— 从经验中自动结晶

这是 Hermes 最逆天的设计。

当你让 Hermes 完成一个复杂任务之后——比如"帮我把这个 Express 项目迁移到 Hono，保持所有 API 接口不变"——它不只是把事情做完就拉倒。它会在完成之后回头看自己的 trajectory（执行轨迹），判断：这个任务够不够复杂？我执行的步骤有没有可复用的模式？

如果有，它会自动创建一个 Skill。

Skill 不是一段死的 prompt。它是一个结构化的程序化记忆，包含：触发条件、执行步骤、使用的工具链、注意事项、以及它之前做这件事时踩过的坑。

举个具体的例子。假设你让 Hermes 帮你做了三次"Node.js 项目初始化"：

  • 第一次：它问了你一堆问题——用什么框架？什么 ORM？要不要 Docker？CI 用什么？然后磕磕绊绊地搭完了。
  • 第二次：它发现上次的 trajectory 里有一个可复用的模式，自动创建了一个"Node.js 项目初始化"Skill。这次执行快了 40%，因为它不再需要从头推理每一步了。
  • 第三次：你告诉它"上次生成的 Dockerfile 没用 cache mount，加上"。它更新了 Skill。这次生成的项目直接就带了 cache mount。

更关键的是——Skill 会在使用中自我改进。

第一次创建的 Skill 可能是粗糙的。但下次你触发同样的场景时，Hermes 用这个 Skill 来执行，执行完之后再回头看：这次执行有没有什么地方可以优化？有没有新的边界情况？然后它更新 Skill。

第三次执行时，这个 Skill 已经比第一次精炼了两轮。

这就像一个新员工：第一次做某件事可能磕磕绊绊，但聪明的人会在做完之后写下心得。第二次做同样的事，翻出心得先看一遍，做得更快更好。第三次，已经成了肌肉记忆。

Claude Code 没有这个。Manus 没有这个。Coze 更没有这个。

而且 Hermes 的 Skills 兼容 agentskills.io 开放标准——你可以从社区的 Skills Hub 下载别人写好的 Skill，也可以把自己的 Skill 分享出去。这意味着 Skill 不只是个人积累，还是社区积累。

第二层：Memory —— 不是塞 context，是真的在建模

Hermes 的记忆系统分几个维度，每个维度解决不同的问题：

1. 事实性记忆（Memory entries）

"这个项目用 Prisma。" "团队规范是 Result 类型包 API 响应。" "老板讨厌 any 类型。" "部署用的是 Docker + GitHub Actions，不用 Jenkins。"

这些是 Agent 主动记录的事实片段。它不需要你告诉它"把这个记下来"——在对话过程中，它会自动判断哪些信息值得持久化。

判断标准是什么？大概是：这条信息在未来的对话中有没有可能被用到？如果有，就存下来。如果只是一次性的聊天内容（"今天天气不错"），就不存。

这些记忆存在本地的 SQLite 数据库里，不是塞在 context window 里。只有当相关场景出现时，才会被召回到当前上下文中。这意味着记忆的量不受 context window 大小的限制——你可以积累成千上万条记忆，只在需要时调用。

2. 用户建模（User Model）

这是更深一层的东西。Hermes 集成了 Honcho 的辩证用户建模——它不只记住你说了什么，它在试图理解你是一个什么样的开发者。

你偏好函数式还是面向对象？你写代码时更看重可读性还是性能？你讨厌什么风格的注释？你对技术选型的决策逻辑是什么？你是那种"先搞一个能跑的 MVP 再优化"的人，还是"不做好设计绝不动手"的人？

这些东西不是显式存储的"某某喜欢函数式"，而是通过多次交互逐渐建立的一个隐含的模型。时间越长，它越了解你。

为什么这很重要？因为同样一个"帮我设计这个模块的架构"的请求，给一个追求简洁的工程师和一个追求健壮的工程师，答案应该是不同的。User Model 让 Hermes 能给出符合你的思维方式的答案，而不是一个通用的"最佳实践"。

3. 跨 Session 搜索（FTS5）

"我上周跟你讨论过 SQLite WAL 模式的坑是什么来着？"

Hermes 用 SQLite 的 FTS5 全文搜索索引了所有历史对话。你可以问它之前聊过什么，它能搜到、能摘要、能给你上下文。

这不是"翻聊天记录"。这是让过去的对话变成可查询的知识库。

想想看——你和 Agent 之间的对话里，其实藏着大量有价值的技术决策、方案讨论、问题分析。以前这些东西聊完就没了。现在它们变成了可搜索、可引用的知识资产。

4. 记忆的生命周期管理

这是很多人忽略的一点：记忆不是只管存、不管删的。

过时的记忆比没有记忆更危险。如果 Hermes 还"记得"你三个月前用的是 TypeORM，但实际上你已经迁移到 Prisma 了——那它基于过时记忆做的决策就是错的。

Hermes 的 Memory 系统有主动管理机制：当新信息和旧记忆冲突时，它会更新或替换旧记忆。不是简单的追加，是有增有减的活的系统。

第三层：Nudge —— 主动的知识持久化

这是一个小但重要的设计：Hermes 会主动提醒自己去持久化知识。

什么意思？在一段复杂对话结束后，普通 Agent 就结束了——context 关掉，一切消失。Hermes 会在对话即将结束时"自我 nudge"：嘿，刚才那段讨论里有没有什么值得记住的？有没有什么可以变成 Skill 的？有没有什么 User Model 需要更新的？

这个 nudge 机制让 Hermes 不依赖用户主动说"记住这个"，而是自己有意识地去"留下痕迹"。

为什么这个设计这么重要？因为人是懒的。你不会在每次聊完之后说"嘿，把这个记下来"。你大多数时候聊完就关了。如果 Agent 依赖你来触发记忆存储，那 90% 有价值的信息都会丢失。

Nudge 机制把这个责任从你身上拿走了，放到了 Agent 身上。你只管正常用，它自己负责"学习"。

第四层：Trajectory —— 为下一代模型铺路

这层不直接影响你的使用体验，但它决定了 Hermes 的长期进化路径。

Hermes 能把每次任务的完整执行轨迹（trajectory）——包括用户请求、Agent 的思考过程、工具调用、中间结果、最终输出——全部记录下来。这些 trajectories 可以用来：

  1. 训练更好的工具调用模型（Nous Research 自己就在做这个）
  2. 压缩成训练数据，让下一代模型"出厂自带"这些能力
  3. 在本地做轨迹回放和 debug（你可以复盘 Agent 为什么做了某个错误决策）

这意味着 Hermes 的进化不只是"单个 Agent 实例的进化"，还有"整个模型族的进化"。你用 Hermes 产生的 trajectories，最终会让 Nous Research 训练出更好的基座模型，那个模型再反哺到 Hermes 里——这是一个跨越单机的、社区层面的学习飞轮。

四、从 OpenClaw 到 Hermes：不是升级，是重生

如果你关注开源 Agent 社区，可能听说过 OpenClaw。它是 Hermes 的前身——一个能跑在终端里的 AI Agent，能调工具、有 persona、有基本的记忆。

Hermes 的 README 里还保留着 hermes claw migrate 命令，专门让 OpenClaw 用户迁移过来。你可以导入之前的 SOUL.md（persona）、MEMORY.md（记忆）、skills（技能）、API keys、甚至消息平台配置。

那为什么要"重生"？OpenClaw 不够好吗？

不是不够好，是它解答的问题不够大。

OpenClaw 的记忆是一个 MEMORY.md 文件。你手动往里写东西，Agent 读它。Skills 是你手动创建的 markdown 文件——你得自己想"我应该把什么抽象成 Skill"，自己写 Skill 的内容，自己决定什么时候触发它。Persona 是一个 SOUL.md——也是你手动维护的。

这些东西能用吗？能用。但它们都是手动维护的。

手动维护意味着什么？意味着负担在人身上。你得记得更新 MEMORY.md，你得自己总结 Skill，你得自己管理 Persona。时间一长，你就不更新了。我敢打赌 90% 的 OpenClaw 用户的 MEMORY.md 在创建后第一个月还会更新，第二个月就开始摆烂了。

然后这些文件就变成了过时的废纸。Agent 读着三个月前的 MEMORY.md，对着一个已经完全变了的项目做决策。这比没有记忆还傻逼——没有记忆至少不会用错误信息来误导自己。

Hermes 做的事情是：把人工维护变成自动闭环。

OpenClawHermes
记忆手动写 MEMORY.md自动检测 + 主动持久化 + 生命周期管理
Skills手动创建 markdown从 trajectory 自动生成 + 自我改进
用户理解一个静态 SOUL.md辩证用户建模，持续演化
跨 Session没有FTS5 全文搜索 + LLM 摘要
Nudge没有自动触发知识持久化
Skill 共享没有agentskills.io 开放标准
模型训练没有Trajectory 生成 + 压缩

这不是"加了几个 feature"，这是从"人驱动的工具"变成了"自驱动的系统"。

打个比方：OpenClaw 是你带着一个笔记本，每次做完事自己记。Hermes 是笔记本自己会记、会整理、会在你需要的时候翻出来给你看、还会定期把过时的页面撕掉。

这个跨越不是 Nous Research 突然拍脑袋想出来的。如果你去看 Hermes 的 git log，你会发现从 OpenClaw 到 Hermes 的演化过程中，最密集的 commit 集中在三个方面：Skills 引擎的自动化、Memory 的结构化管理、以及 Nudge 机制的引入。这三个方向完全一致地指向一个目标——把"人需要做的事"一件一件自动化掉。

先是 Skills 不需要你手动写了。然后是 Memory 不需要你手动维护了。然后是连"提醒自己存东西"这件事都自动化了。

每一步都是在减少对人工介入的依赖。不是因为"自动化很酷"，而是因为只有去掉人工维护的负担，学习闭环才能真正运转起来。人一忘、一懒，闭环就断了。只有系统自己来做这件事，才能保证"每一次交互都不会浪费"。

这就是从"工具"进化到"系统"的关键一跃。工具等着你来操作它。系统自己知道该做什么。

五、为什么不选 Manus

让我把话说得直接一点。

Manus 火过一阵，国内各种"类 Manus"产品更是井喷——什么逆天 Agent、什么全自动工作流、什么"一句话搞定一切"。2025 年到 2026 年初，这个赛道卷成了一锅粥。每个月都有新产品号称"超越 Manus"，demo 视频一个比一个炸裂。

但我用过之后的感受是：它们解决的是"自动化"问题，不是"个人化"问题。

什么是"自动化"问题？"帮我把这 50 个 PDF 总结成一张表格。" "帮我把这些数据画成图表。" "帮我调研一下竞品。"

这些任务有一个共同特点：它们是无状态的。 换任何一个人来做，结果都差不多。不需要了解"你"是谁、你的偏好是什么、你之前做过什么决策。

Manus 擅长这个。它是一台很好的自动化机器。

但"个人化"问题完全不同。让我举几个具体的例子：

  • "帮我设计这个模块的架构" —— 需要知道你们的技术栈、团队规模、性能要求、你个人的架构偏好。
  • "帮我重构这段代码" —— 需要知道你的代码风格、你讨厌什么 pattern、你觉得什么算"干净"。
  • "这个 PR 看起来有问题吗？" —— 需要知道你们团队的 code review 标准、你之前在 review 中关注的重点。
  • "帮我写一封邮件回复客户" —— 需要知道你的语气、你和这个客户的历史关系、你们之前聊过什么。

这些任务的共同特点是：答案取决于"你是谁"。 同一个问题给不同的人，最优答案是不同的。

Manus 做不了这个。因为它不记得你。每次都是全新的它遇到全新的你。

而且 Manus 还有一个更根本的问题：云端黑盒。

你看不到它在干什么。你不知道它打开了哪个网页、点了哪个按钮、用了什么中间结果。出了错你也很难 debug。它在云端的一个浏览器里操作，你只能看到最终结果——中间过程对你是不透明的。

对于开发者来说，这是不可接受的。我需要知道我的工具在做什么。如果它犯了错，我需要能 debug、能复现、能理解它为什么犯错。黑盒执行的东西，出了问题你只能祈祷。

Hermes 是跑在你自己机器上的。每一步操作、每一个 tool call、每一个决策过程，你都看得见。你可以 interrupt 它、redirect 它、纠正它。它是透明的。

最后一点：Manus 是一个商业服务，有 token 额度、有定价、有调用限制。Hermes 是开源的（MIT 协议），你可以无限制地使用，用自己的 API key 调任何模型。长期来看，哪个更可控？

六、为什么不选国内平台型产品

Coze（扣子）、文心智能体、通义 Agent Studio、MiniMax 的 Agent 平台、甚至各种创业公司做的"xx Agent 平台"……国内这些产品我或多或少都试过。

它们的共同问题我用一个词概括：寄人篱下。

模型不自由

你在 Coze 上只能用字节系的模型。你在文心上只能用百度的模型。你突然想试试 DeepSeek V4 或者 Qwen3？对不起，平台不支持。

为什么这很重要？因为 LLM 的发展速度太快了。今天最好的模型三个月后可能就不是了。如果你被锁在一个平台的模型上，你就永远只能用"这个平台目前接入的最好的那个"，而不是"市场上目前最好的那个"。

Hermes 的 hermes model 命令一敲，200 多个模型随便切——OpenRouter 上的所有模型、OpenAI、Anthropic、DeepSeek、Qwen、Nous 自家的模型、甚至你本地跑的 Ollama。今天用 Claude，明天切 DeepSeek，后天试试开源模型——没有任何锁定。

数据不自由

你在平台上积累的所有东西——workflow、知识库、对话历史、用户画像——全存在别人的服务器上。哪天平台政策变了、收费涨了、或者（更现实的）平台倒了，你的积累就没了。

2025 年到 2026 年，有多少 AI 创业公司倒闭的？不计其数。你敢把自己的核心工作流建在一个可能明年就不存在的平台上吗？

Hermes 的所有数据在 ~/.hermes/ 目录下，SQLite 数据库 + 本地文件，你随时可以 cp、备份、迁移。就算 Nous Research 明天解散了（不太可能，但假设），你本地的 Hermes 还是能跑——换个模型 provider 就行。

环境不自由

这些平台的 Agent 跑在它们的沙箱里。你不能让它操作你的本地文件系统、你的 Git 仓库、你的 Docker 容器、你的 SSH 服务器。

Hermes 支持七种终端后端：

  1. Local —— 直接在你的机器上执行命令
  2. Docker —— 在容器里执行，安全隔离
  3. SSH —— 连到远程服务器执行
  4. Singularity —— HPC 集群场景
  5. Modal —— serverless，闲时休眠，按需唤醒
  6. Daytona —— serverless 开发环境，持久化工作区
  7. Vercel Sandbox —— 前端项目快速原型

你想让它跑在哪就跑在哪。想让它操作哪台服务器就操作哪台服务器。这种灵活性是平台型产品永远给不了你的。

"记忆"的真假之分

我试过几个平台的"长期记忆"功能。让我告诉你它们的实现方式：

  1. 把之前 N 轮对话的摘要塞到 system prompt 里
  2. 用一个向量数据库存历史对话，查询时做 similarity search 召回"相关"的几条
  3. 让 LLM 在每次对话结束时生成一段"记忆总结"，下次塞进 context

这些方案的共同问题是：它们没有结构化的记忆管理。 不知道哪些记忆已经过时、不知道记忆之间的优先级、不知道什么时候该更新什么时候该删除。结果就是 context 里塞满了一堆"可能有用也可能已经过时"的文字，模型得自己分辨哪些是当前有效的——经常分辨错。

Hermes 的 Memory 是结构化存储 + 主动管理的。它知道哪些是事实性记忆、哪些是偏好性记忆、哪些已经过时需要更新。每条记忆有明确的语义类型，不是一堆无差别的文本碎片。

七、Hermes 的技术架构：为什么它能做到这些

讲了这么多"它能做什么"，现在讲讲"它怎么做到的"。不需要太深——毕竟这不是一篇源码分析文章——但你需要知道整体架构才能理解它的边界。

Agent Loop

Hermes 的核心是一个 Agent Loop：

用户输入 → 模型推理 → 工具调用 → 结果处理 → 模型推理 → ... → 最终回复

这个 loop 本身不稀奇，所有 Agent 都是这个模式。Hermes 的特别之处在于 loop 的"外围设施"：

  • 进入 loop 前：从 Memory 中召回相关记忆、检查是否有可用的 Skill、加载 User Model
  • loop 执行中：记录完整 trajectory、支持用户随时 interrupt 和 redirect
  • loop 结束后：Nudge 机制触发，判断是否需要更新 Memory/Skill/User Model

所有这些"外围设施"共同构成了学习闭环。

Gateway 架构

Hermes 不是只能在终端里用的。它有一个 Gateway 进程，负责连接各种消息平台：

  • 飞书（Lark）
  • Discord
  • Slack
  • WhatsApp
  • Signal
  • Email

一个 Gateway 进程 + 一个 Agent 进程，就能让你从任何平台跟同一个 Agent 对话。所有平台共享同一份 Memory、同一套 Skills、同一个 User Model。

这意味着你在终端里跟它讨论完架构方案，回到飞书上问它"刚才那个方案的第三点是啥"——它知道。跨平台连续性。

40+ 内置工具

Hermes 自带 40 多个工具（tools），涵盖：

  • 文件读写、搜索
  • Shell 命令执行
  • Git 操作
  • 浏览器控制
  • 代码分析
  • 网络请求
  • 还有 MCP 集成——任何 MCP Server 都可以无缝接入

工具系统是模块化的，你可以用 hermes tools 来开关特定工具集。不想让它动你的 Git 仓库？关掉 git toolset 就行。

而且通过 MCP 集成，你可以把任何实现了 MCP 协议的外部服务接入 Hermes——比如一个自定义的数据库查询工具、一个内部的 API 网关、甚至一个 Linux 桌面控制服务。Hermes 的工具生态不是封闭的，是无限可扩展的。

不被绑死的哲学

Hermes 整体架构的设计哲学可以用一句话概括：没有任何一层是硬编码的。

  • 模型？随时切。今天 Claude，明天 DeepSeek，后天本地 Ollama。
  • 平台？随时加。飞书、Discord、Slack、WhatsApp，一个 gateway 进程管所有。
  • 工具？随时开关。MCP 让你接入任何外部能力。
  • 后端？随时换。从 local 换到 Docker 换到 Modal，不需要改配置。
  • Skills？兼容开放标准。agentskills.io 社区里别人的 Skill 你拿来就能用。

这种"不被任何一层绑死"的设计，让 Hermes 的生命周期远超任何平台型产品。平台倒了你就完了。Hermes 的任何一层组件出了问题，你都可以换掉那一层，其他层继续工作。

这很重要。因为你在 Hermes 上积累的东西——Skills、Memory、User Model——是有长期价值的资产。这些资产不应该被绑在任何一个服务商、任何一个模型、任何一个平台上。

八、大脑模式：让 Hermes 做指挥，让 Claude Code 做手脚

到目前为止，我们说的都是 Hermes 自己干活。但你有没有想过另一种用法——

把 Hermes 当成大脑，把 Claude Code 当成手脚。

Claude Code 是现在最强的 coding agent。这点没什么好争论的。让它写代码、重构、debug，它做得比谁都好。

但 Claude Code 有一个无法逾越的天花板：它没有记忆，不会协调，不能连续执行多个有上下文依赖的任务。 每次对话都是独立的宇宙。上一段对话里 Claude Code 发现的安全隐患、想到的边界情况、做出的技术判断——在新对话中全部清零。

这就是为什么你需要一个大脑。不是替代 Claude Code 写代码，而是在 Claude Code 之上加一层"记忆和协调层"。让 Hermes 来：记住上下文、拆解任务、多轮调度 Claude Code、检查结果、积累经验。

Hermes + Claude Code 的真实工作流

周四下午两点，你收到需求："把订单服务的支付逻辑从同步改成异步，保证不丢单。"

你只对 Hermes 说了一句话："帮我搞。"

然后它进入"大脑模式"，一共调了三次 Claude Code：

1. 分析阶段（Hermes 自己来）

它先自己读 order-service/payment.ts，看了 300 行代码，理解了现有的同步流程：接收请求 → 调用支付网关 → 扣库存 → 返回结果。整个流程串行，支付网关超时就直接失败。

它不是闷头开干。它先问你："异步化以后，支付成功回调你打算用 webhook 还是轮询？"

你回："webhook。"

它把这个偏好记下来。下次讨论支付相关的事，不会再问。

2. 重构阶段（第一次调 Claude Code）

它把需求写成一段结构化 spec，包含：改动范围、业务逻辑要求、注意事项。然后通过 shell 调起 Claude Code，把 spec 和文件路径丢过去：

"重构 order-service/payment.ts 及相关文件，将同步支付改为通过 BullMQ 队列异步投递。必须保证：幂等处理、事务边界正确、webhook 回调。这是现有代码：order-service/ 目录。"

Claude Code 工作了三分钟，改完了三个文件。Hermes 读了一遍 diff——改动都在预期范围内，没动到不该动的地方。

3. 测试阶段（第二次调 Claude Code）

它把 Claude Code 刚才改的 diff 摘要和自己的原始 spec 组合成新的指令，再次调起 Claude Code：

"上面三个文件的改动已完成，现在帮我更新相关测试。特别验证这三个场景：队列投递成功后 webhook 未回调的情况、幂等重复投递的情况、支付网关超时的情况。"

这三个"特别关注"是哪来的？来自它上一个类似项目的 Skill——那个项目就是三个场景没测全，上线后吃了亏。Hermes 记下来了，这次自动加进了指令里。

Claude Code 补了 12 个测试用例。Hermes 读了一遍，发现 2 个场景跟实际改动不太对。它带着 diff 再次交代 Claude Code："第 5 和第 9 个用例跟实际改动路径有偏差，重新检查一下。"——修好了。

4. 安全检查（第三次调 Claude Code）

第三次调起 Claude Code，指令变了：

"对上面 order-service/ 的改动做一次安全审查。重点关注：SQL 注入风险、并发安全（BullMQ 的 job 幂等性）、事务边界完整性。"

Claude Code 发现 BullMQ 的 job 处理函数有一个位置没有做幂等检查。Hermes 带着这个发现又回头让 Claude Code 修了一轮。

5. 汇总汇报

全搞完之后，Hermes 给你发汇总：

"支付逻辑已改为异步。Claude Code 分三轮完成了重构、测试和安全审查——改了 order-service 下三个文件，补了 12 个测试用例，修了一处幂等遗漏。改动已推到 feature/async-payment。要我跑 CI 吗？"

你回一个字："跑。"

整个过程对你就是两句话。对 Hermes 来说——它记住了每一步的上下文，每次调 Claude Code 都带着之前的积累，三次调用之间信息无缝流转。

这跟你自己开三次 Claude Code 对话有什么区别？

区别大了。

你自己开三次 Claude Code：第一次交代背景、看代码、改代码。第二次重新交代背景——"刚才是改那三个文件，现在是测它们"。第三次又得重新交代——"前面是重构和测试，现在是安全检查"。每次你都在做同一件事：把上一次 Claude Code 的产出翻译成下一次 Claude Code 的输入。 你是人肉 API 网关。

更致命的是——你不会记得每次调 Claude Code 时的所有细节。第一次 Claude Code 重构时可能发现了一个潜在的并发问题但没写在代码里（因为它觉得"这属于测试阶段的事"）。你第二次调 Claude Code 的时候大概率不会提到这个。这个信息就丢了。

Hermes 做大脑的时候不是这样。它每一次调 Claude Code 的 prompt 都不是从零写的——是在上一轮结果之上继续叠加的。第一轮改了什么、发现了什么、踩了什么坑——自动沉淀成下一轮的输入。不是三个独立的对话，是一条有上下文延续的流水线。

这才是"成长性"的真正爆发点

Hermes 的记忆系统在这种情况下发挥出的价值比单次任务大得多。

  • 第一次做"异步改造"这种任务，Hermes 可能只拆成两轮——改代码 + 测一下。结果上线后发现安全问题没查、边界场景没测全。
  • 第二次就拆成了三轮——重构 + 测试 + 安全审查。而且测试指令里自动带上了上次漏掉的三个场景。安全审查指令里自动带上了上次出问题的事务边界检查。
  • 第十次的时候，它的 Skill 已经精确到：异步改造的标准 SOP 是四轮调度（分析 → 重构 → 测试 → 安全审查），测试必须覆盖哪五个场景，安全审查必须检查哪三个节点。

这个进化过程跟 Claude Code 本身毫无关系——Claude Code 每次都是同一个 Claude Code，没有任何变化。变化完全发生在 Hermes 这层——它的 Skills 在进化、Memory 在积累、对"你项目里容易出问题的地方"的理解在加深。

这就是为什么同一个"异步改造"任务，你用纯 Claude Code 做第十次和做第一次没有任何区别。但你用 Hermes 大脑模式做第十次，比第一次快三倍、漏掉的东西少五倍。因为 Hermes 在替你学习。

九、想象力：它可以怎样活在你的工作里

好，理论和架构讲完了。现在让我们打开想象力——一个成熟的、用了三个月的 Hermes Agent，可以怎样融入你的日常工作？

场景 1：它记得你的架构决策

周四下午两点，你开了一个新的微服务项目。你跟 Hermes 说："帮我初始化项目骨架。"

它没问你用什么框架、什么 ORM、什么构建工具。直接给你生成了：Hono + Prisma + Vitest + pnpm workspace + Docker Compose + GitHub Actions CI。

为什么？因为三个月前你在一次两小时的讨论中，跟它梳理了你们团队的技术栈选型逻辑。它记得。不仅记得结论，还记得原因——"Hono 是因为 Express 太重、Fastify 的插件生态不够、Hono 可以跑在 Cloudflare Workers 上"。

如果这期间你又做了新决定——比如上周你说"Prisma 的 migration 太傻逼了，下个项目试试 Drizzle"——它也更新了。下次初始化项目，它会用 Drizzle。

Claude Code 能不能做到这个？能——如果你每次都在 CLAUDE.md 里手动更新技术栈信息。但你会吗？

场景 2：Skill 自动进化

你第一次让 Hermes 帮你写 Dockerfile 的时候，它写了一个很标准的 multi-stage build。用着没问题，但镜像有点大。

你跟它讨论了一下，决定加上 --mount=type=cache 来加速依赖安装，再加一个 .dockerignore 模板。它更新了自己的"写 Dockerfile"Skill。

第二次你让它写 Dockerfile，它直接带上了 cache mount 和 dockerignore。

第三次，你发现它连 healthcheck 都加了——因为上周你在另一个对话里提到过"我们所有服务都要有 healthcheck endpoint"。它把这个信息交叉关联进了 Dockerfile Skill。

第四次，它还加了 LABEL 标签——因为你们团队最近开始用 container registry 做 image 管理，需要打上 version 和 commit hash。你只是在一个完全无关的对话里随口提了一句，它就把信息收进来了。

这就是为什么我说它是"自进化"的。不是你一条一条告诉它"以后都要加 healthcheck"、"以后都要加 LABEL"，而是它自己从多次交互中抽象出了规律。

场景 3：飞书上的 24 小时同事

你在飞书上跟 Hermes 的对话，和你在终端里跟它的对话，共享同一份记忆、同一套 Skill、同一个 User Model。

周二上午十点，你在办公室的终端里让它帮你做了一次代码审查。

周二下午四点，你在外面开会，手机上的飞书收到它的消息："刚才那个 PR 里有个潜在的 N+1 查询问题，我漏看了。具体在 src/services/order.ts:142，建议用 Prisma 的 include 预加载。要我提一个 comment 吗？"

它不是等你回到电脑前才能干活的。它是一个一直在后台"活着"的东西。你离开了，它还在思考。想到了什么，就通过飞书告诉你。

这种感觉很奇怪——有点像有一个真的同事，你们不一定要坐在一起干活，但他随时可能跟你说"嘿，我刚想到一个事"。

场景 4：定时任务，自然语言定义

你跟 Hermes 说了一句话："每周一早上九点，帮我看一下上周 GitHub 仓库里所有新开的 issue，按优先级分类发给我。"

它就设好了 cron。每周一早上九点，飞书上准时收到一份整理好的 issue 列表。而且它知道你定义的"优先级"是什么——因为你之前跟它讨论过 issue 分类的标准。

你想加一条？"再加一个，每周三下午两点看看 staging 环境有没有 P0 报警。" 它加上了。

你想改？"以后 issue 分类别按严重程度了，按影响范围分——'影响单个用户'、'影响部分用户'、'影响所有用户'。" 它更新了。

这些定时任务在 Manus 上做不了——因为 Manus 没有"常驻"的概念，它是一次性的。在国内平台上也很难做到——因为它们的定时任务通常只能触发预定义的 workflow，不能接入你自己的飞书做消息推送。

场景 5：Subagent 并行

这个场景稍微高级一点。

你说："帮我同时做三件事——把 A 服务的日志格式改成 JSON structured logging，给 B 服务加上 rate limiting 中间件，把 C 服务的 Dockerfile 升级到 Node 22。"

Hermes 不是串行做这三件事的。它会 spawn 三个 subagent，各自独立执行自己的任务，互不干扰。执行完之后汇报结果。

而且每个 subagent 都能访问同一份 Memory 和 Skills——它们知道你的代码风格、知道你的项目约定、知道你之前踩过什么坑。

这种并行能力在复杂项目中非常有用。你不需要一件一件地等它做完，可以一口气甩三个任务出去，去倒杯水的功夫全部完成。

场景 6：项目交接不再是噩梦

周五下午三点，老板跟你说："下周小李那个项目你接一下，他要转去另一个组了。"

以前这意味着什么？花一到两周看代码、翻文档（如果有的话）、找小李问各种"这里为什么这样写"的问题。

现在你跟 Hermes 说："帮我读一下这个项目的代码，给我一份架构概览。" 它用文件读取 + 代码分析工具把项目过了一遍，给你出了一份包含模块关系、数据流、关键设计决策的概览文档。

然后你开始问问题："这个 WorkflowEngine 类为什么要用状态机模式而不是简单的 if-else？" 它分析完代码回答你。你继续问："这个项目的部署流程是什么？" 它翻了 Dockerfile、CI 配置、deploy 脚本，整理给你。

关键来了——所有这些问答、所有你对这个新项目的理解过程，都被 Hermes 的 Memory 存下来了。下周你再问"那个 WorkflowEngine 的设计理由是什么来着"，它直接调出来。你不需要重新看一遍代码。

而且随着你在这个项目上工作的时间增长，Hermes 对这个项目的"理解"也在加深——它知道哪些模块你改过、哪些坑你踩过、哪些设计决策你做过。三个月后，它对这个项目的了解程度可能比小李离开时告诉你的还多。

场景 7：Code Review 的记忆继承

你们团队做 code review 的时候，总有一些反复出现的问题——"这里应该加 error handling"、"这个查询没有做分页"、"这个类型应该 narrow 一下"。

每次 review 你都要重复说这些。新来的同事不知道团队规范，你得一条一条给他指出来。

你让 Hermes 帮你做第一遍 review。因为它了解你的 review 标准（从你之前的对话里积累的 User Model），它会按照你的标准来检查代码——不是通用的 linter 规则，而是"你平时会在 PR 里指出的那些东西"。

它不会替代你做最终决策。但它能帮你把 80% 的"常规问题"先标出来，你只需要 review 那些需要人类判断力的设计层面的问题。

一个月后，Hermes 的 code review Skill 已经精确知道了你们团队的 15 条不成文规范。新人提的 PR，它第一遍就能标出大部分问题。你的 review 时间从平均 45 分钟降到了 15 分钟。

十、想象力：它可以怎样活在你的生活里

Agent 不是只有写代码的时候才有用。一个 24 小时在线、了解你、有记忆的 Agent，可以渗透进你的日常生活。

场景 8：个人知识管理助手

你平时看技术文章会收藏，但从来不回头看——说实话，谁会呢？Pocket 里躺着 300 篇未读文章，GitHub stars 列表有 2000 个项目，Hacker News 的 saved 里积了半年的帖子。

你让 Hermes 每周五下午四点，帮你整理本周所有收藏的内容，筛选出跟你最相关的 5 篇，生成一份摘要发到飞书。

它知道什么跟你"最相关"。因为你之前跟它聊过的所有技术话题——分布式系统、Rust、SQLite、Agent 架构——都在它的 User Model 里。它不是按点赞数排序，它是按"Max 大概率会觉得有价值"来排序。

三个月后，它给你推荐的内容比任何 RSS 阅读器都精准——因为没有任何 RSS 阅读器像它一样了解你的技术兴趣图谱。

场景 9：长期记忆的外接硬盘

"我上个月跟你讨论过一个关于 Redis Cluster 脑裂的方案，具体是什么来着？"

你不需要翻聊天记录。不需要打开 Notion 搜索。Hermes 的 FTS5 搜索直接定位到那段对话，给你一段摘要：

"4 月 17 日你提到过：Redis Cluster 出现脑裂时，用 Sentinel 的 quorum 机制来判定 master 存活，min-replicas-to-write 设为 1 防止脑裂 master 继续接受写入。你当时的顾虑是这会降低写入可用性，但最终决定'数据一致性优先于可用性'。"

这就是"第二大脑"的真实形态。不是你手动往 Notion 里记笔记，而是你正常说话、正常讨论，它自动帮你存下来了。需要的时候一问就有。

而且它给你的不只是原始对话——它会附带当时的决策上下文和理由。这比你自己回忆靠谱多了。

场景 10：写作和思考的对话伙伴

这个场景跟代码无关。

你在写一篇技术博客，写到一半卡住了——知道自己要表达什么，但找不到合适的类比。你跟 Hermes 说："我在写一篇关于数据库索引的文章，想解释为什么 B+ 树适合范围查询而 Hash 索引不行。你帮我想个生活化的类比。"

它知道你的写作风格（因为你之前让它帮你改过文章），知道你喜欢什么样的类比（你偏好用"物理世界的东西"来解释"数字世界的概念"），所以它不会给你一个抽象的学术解释，而是给你一个"图书馆书架 vs 储物柜"的类比。

如果换一个刚认识你的 Agent，它可能会给你一个"电话簿"的老套比喻——因为所有教科书都这么写。但 Hermes 知道你不喜欢老套的比喻，因为你上次就否掉过一个类似的。

这就是"了解你"带来的细微但重要的差异。不是大的功能差异，是品味和偏好层面的匹配。

场景 11：几乎零成本的长期在线

你可能会想：一个 24 小时在线的 Agent，成本得多少？

答案是：几乎为零。

Hermes 支持 Modal 和 Daytona 这两种 serverless 后端。你的 Agent 环境在没有消息时休眠——不占计算资源、不产生费用。有消息进来时唤醒——冷启动几秒钟，然后开始处理。

一个月下来，如果你每天跟它交互半小时到一小时，计算成本可能就 3-5 美元。加上模型调用费用（如果用 DeepSeek 或者 Qwen 这类便宜模型），一个月总共不到 10 美元。

你拥有了一个 24 小时在线、跨平台、有记忆、会成长的私人 Agent，成本比你每天的一杯咖啡还少。

你可能会说："我直接用 ChatGPT Plus 不就行了？25 美元一个月。"

可以，但 ChatGPT 没有本地执行能力、没有 Skill 自进化、没有跨 Session 记忆（是的，ChatGPT 的"记忆"功能和 Hermes 的记忆不是一个量级的）、没有定时任务、没有多平台接入、数据全在 OpenAI 那。

25 美元买的是"一个很聪明但失忆的对话伙伴"。10 美元买的是"一个没那么聪明但会成长、会记住、活在你环境里的私人助手"。

哪个更值？取决于你要的是什么。

十一、诚实的边界：它还不够好的地方

我不是在写广告。Hermes 现在有很多问题，我得说清楚。不说清楚就不诚实。

配置成本不低

Hermes 是一个开源项目，不是一个 SaaS 产品。你要自己配置 provider、自己选模型、自己接飞书/Discord/Slack。对于不熟悉命令行的人来说，这个门槛是真实存在的。

hermes setup 有一个 wizard 帮你走流程，但它仍然假设你知道什么是 API key、什么是 webhook、什么是环境变量。如果你是一个前端工程师、从来没碰过 VPS、不知道 SSH 是什么——那 Hermes 可能不适合你现阶段使用。

不过话说回来，如果你是这篇文章的目标读者（有一定后端/DevOps 经验的开发者），这些配置对你来说应该不是问题。半小时到一小时就能搞定。

模型能力是天花板

Hermes 的自进化能力再强，最终执行任务的还是底层的 LLM。如果你用的模型本身不够聪明（比如一些小参数的开源模型），那 Skill 写得再好、Memory 再丰富，它做出来的东西还是会有问题。

Skill 可以让 Agent "知道该怎么做"，但"能不能做好"还是取决于模型的推理能力。一个 7B 模型就算背下了所有正确的步骤，执行起来也经常出错——因为它的推理精度不够。

目前体验最好的搭配是用 Claude 3.5/4 或 DeepSeek V4 做主力模型。用小模型跑日常轮转太容易出错了。好消息是 Hermes 切模型几乎零成本，所以你可以"重要任务用好模型，简单任务用便宜模型"来控制开支。

开源项目的粗糙感

9000 多个 commit、4000 多个 issue——这个项目迭代得很快，但也意味着很多边角没有打磨。文档有些地方跟不上代码，某些 skill 在特定模型下表现不稳定，偶尔会出现诡异的状态问题。

这不是一个"开箱即用的商业产品"。它更像是一个"潜力巨大但需要你愿意折腾"的东西。你得有一定的动手能力，碰到问题愿意去翻 issue、看文档、甚至看源码。

如果你是那种"东西不好使就直接卸载"的人——Hermes 可能会让你失望。但如果你是那种"有潜力的东西我愿意花时间调教"的人——你会发现三个月后它变成了你离不开的东西。

学习闭环需要时间才能显现

你装好 Hermes 的第一天，它跟 Claude Code 的体验差别不大。甚至可能还不如——因为 Claude Code 的单次推理能力确实很强，而第一天的 Hermes 还没有任何 Skill 积累和 Memory。

它的优势需要时间才能累积出来——两周开始有感觉，一个月明显不同，三个月后你会发现自己再也回不去了。

这很反直觉。我们已经被"即时满足"训练习惯了——装个工具就要立刻看到效果。Hermes 的价值曲线不是这样的，它是一条先平后陡的指数曲线。前两周你可能觉得"这他妈的跟直接用 Claude 有什么区别"。坚持到一个月，你会开始说"卧槽它怎么知道我要的是这个"。坚持到三个月，你会开始怀疑自己以前是怎么忍受那些没记忆的工具的。

隐私和安全的考量

虽然 Hermes 运行在本地，但它还是要调用外部的 LLM API。这意味着你的代码片段、架构讨论、技术决策——都会作为 prompt 发送给模型提供商。

如果你处理的是高度敏感的内容（军事、金融核心算法等），你需要考虑是否能接受这个。解决方案是用本地模型（Ollama + 开源模型），但这会牺牲一些推理能力。

Hermes 有命令审批机制（hermes config set approval_mode），可以让你在它执行每条命令前先确认。在处理敏感项目时建议开启。

十二、你可能会问的问题

"Hermes 的 Skill 和 CLAUDE.md 有什么区别？"

本质区别是谁来维护和能不能进化。

CLAUDE.md 是一个静态文件。你写什么，Claude 就读什么。你不更新，它就永远是老内容。而且 CLAUDE.md 只能给 Claude 当前的对话提供上下文——它不能"触发"特定的行为模式。

Hermes 的 Skill 是动态的、结构化的、可触发的、可自我改进的。它会在特定场景自动触发，执行一套完整的流程，并且在每次执行后根据结果自我优化。

"如果 Claude 以后也有了 persistent memory 呢？"

很有可能。Anthropic 大概率在做这个。ChatGPT 已经有了"memory"功能（虽然很弱）。

但有几点不同：

  1. 商业产品的 memory 是在它们的服务器上的。你的数据不归你。
  2. 它们的 memory 不太可能给你自进化 Skill 的能力——因为 Skill 是一种"放权"，让 Agent 自己决定怎么做事。商业产品出于安全和可控性考虑，大概率不会做得这么激进。
  3. 模型锁定。Claude 的 memory 只能配合 Claude 用。DeepSeek 出了更好的模型？你迁移不了你在 Claude 那积累的 memory。Hermes 的 Memory 是模型无关的。

"160k stars 靠谱吗？不会是刷的吧？"

Nous Research 是一个正经的 AI 研究机构，之前以训练开源 LLM 闻名（Hermes 系列模型就是他们出的）。项目有 9000+ commits、600+ watchers、26k forks、5000+ 个 PR。从代码活跃度和社区参与度来看，这不是一个"刷 stars 的空项目"。

当然，star 数只能说明"关注度"，不能说明"好用"。好不好用，你得自己试。

"我应该用 Hermes 还是继续用 Claude Code？"

如果你的主要需求是"写代码时有个强大的辅助"，Claude Code 仍然是更好的选择——它的单次推理能力更强，IDE 集成更好，上手零成本。

如果你想要的是一个"理解你、记住你、跨平台、持续进化的个人 Agent"——Hermes 是目前唯一的选择。

最好的方案可能是两个都用：Claude Code 做日常编码辅助，Hermes 做长期伙伴 + 自动化 + 跨平台。它们不冲突。

"Skill 会不会失控？它自己改自己，万一改错了呢？"

好问题。这是所有"自治系统"都要面对的问题——自主性越强，犯错的风险越大。

Hermes 的做法是：Skill 的每次修改都是可追溯的。你可以看到一个 Skill 的所有历史版本，回滚到之前的版本。而且 Skill 在执行时，你可以设置 approval mode——让它在触发 Skill 前先告诉你"我准备用这个 Skill 来做，可以吗？"

实际使用中，Skill "改错"的概率不高——因为它是基于成功的 trajectory 来改进的。如果上次执行成功了，那基于上次经验的改进大概率是对的。真正出问题的是它基于"部分成功"的 trajectory 做了错误的归因。但这种情况比较少见，而且你很容易在下次使用时发现并纠正。

"Hermes 跟 AutoGPT、MetaGPT 这些有什么区别？"

AutoGPT 和 MetaGPT 是 2023-2024 年的"自治 Agent"热潮产物。它们的目标是"给一个目标，让 Agent 自己拆解并完成"。

问题是它们没解决可靠性问题。让 GPT-3.5/4 自己做规划再自己执行，失败率非常高——经常跑着跑着就跑偏了，或者陷入死循环。

Hermes 的定位不同。它不是"完全自治"的——它是"在人的监督下渐进自治"的。你随时可以 interrupt、redirect、纠正。它的自治程度是随着信任积累逐渐增加的：一开始你可能每条命令都审批，一个月后你信任它了就开放更多权限。

而且 Hermes 的重点不是"单次复杂任务的自治完成"（那是 Manus/AutoGPT 的思路），而是"跨时间的经验积累和能力进化"。这是两个完全不同的方向。

"我在国内，网络环境用 Hermes 方便吗？"

Hermes 本身是本地安装的，安装过程需要能访问 GitHub 和 PyPI。装好之后，主要的网络需求就是调用 LLM API。

如果你用国内模型（DeepSeek、Qwen、MiniMax、Kimi 等），网络完全不是问题——这些模型的 API 都在国内服务器上。Hermes 通过 OpenRouter 或直连这些模型的 API endpoint 都行。

如果你想用 Claude 或 GPT-4——那需要你自己解决网络问题。不过这不是 Hermes 特有的问题，用 Claude Code 也一样。

"既然 Claude Code 写代码更强，为什么不直接用 Claude Code？"

对，Claude Code 单次写代码的能力确实比 Hermes 强。但问题不是"谁写得好"，而是"写完之后谁记得、谁协调、谁继续优化"。

你用 Claude Code 写了一个模块，两个月后需要改——Claude Code 不记得这次改动的前因后果。你重新解释一遍。你用 Hermes 大脑模式，让 Hermes 调 Claude Code 写完这个模块之后，Hermes 记住了：改了什么、为什么这样改、当时考虑了哪些边界情况、哪个部分你觉得不满意。两个月后你只需要说"改上次那个支付模块"，Hermes 召回当时的上下文，再把 spec 丢给 Claude Code 继续改。

而且 Claude Code 不能跨对话协调——你不可能让它在一个对话里做完重构、测试、安全审查三个阶段，因为每个阶段都会把 context 塞爆。但 Hermes 可以——它每次调 Claude Code 都带着精简过、相关过的上下文，三次调用之间有 Hermes 的记忆层在无缝衔接。用纯 Claude Code 自己做这些，你只能手动开三个独立对话，每个都在重复解释前因后果。这就是区别。

所以不是"选哪个"的问题。是"让谁做大脑，让谁做手"的问题。最好的手 + 最好的大脑 = 最优组合。而且这个组合的长期价值会随着使用时间指数增长——因为大脑越用越聪明，而手也在不断变强。

十三、如果你想试试

如果前面讲的让你有点心动，这里是最简单的开始方式：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
hermes setup    # 走一遍配置向导
hermes          # 开始对话

四条命令。装好之后 hermes setup 会引导你选模型（推荐先用 DeepSeek V4，便宜且够用）、配置消息平台（可选，不配也能用 CLI）。

第一周不要期待太多。像对待一个新同事一样对待它：跟它聊你的项目、告诉它你的偏好、让它帮你做一些重复性任务。两周后你会开始感觉到差异。

一个小建议：第一次用时，先让它帮你做一件你之前做过很多次的事——比如初始化项目、写 Dockerfile、配 CI。然后过几天再让它做同样的事。你会看到 Skill 的进化过程。那个"卧槽它记住了"的瞬间，就是你理解 Hermes 和其他 Agent 本质区别的瞬间。

十四、判断框架：什么时候用什么

讲了这么多，最后给你一把尺子，让你以后遇到新的 Agent 产品时能自己掂量。

问自己三个问题

1. 这个任务是一次性的，还是会反复出现？

一次性任务（"帮我总结这份 PDF"）→ 用 Manus 或 Claude 就够了。不需要记忆，不需要成长。

反复出现的任务（"每次新项目都要做的初始化"、"每周的 issue 整理"）→ 需要有 Skill 积累能力的 Agent。否则每次都从零开始太浪费了。

2. 这个任务需不需要了解"我"？

不需要了解你的通用任务（"把这段 JSON 转成 CSV"）→ 任何工具都行。

需要了解你的个性化任务（"帮我设计这个模块的架构"、"帮我 review 这个 PR"）→ 需要有 Memory 和 User Model 的 Agent。否则它给出的答案是"通用最佳实践"，不是"对你来说的最佳方案"。

3. 我在不在意数据主权和可控性？

不在意（个人随便用用）→ 平台型产品够了，省心。

很在意（公司代码、客户数据、技术决策、合规要求）→ 本地部署 + 开源方案。Hermes 或者自建。

一张决策表

你的情况推荐方案
偶尔用 Agent 做一次性任务Manus / ChatGPT / Claude
每天写代码需要实时辅助Claude Code / Cursor
团队需要自动化 workflowCoze / Dify / n8n
想折腾但不想写代码国内平台型产品
需要最强单次推理 + 不在乎记忆Claude Code
想要了解自己、持续进化的长期伙伴Hermes
既要专业编码能力，又想有记忆和协调力Hermes 大脑 + Claude Code 执行

这不是"谁比谁好"的问题，是"你在解决什么问题"的问题。用锤子钉钉子，用螺丝刀拧螺丝。别拿锤子拧螺丝，也别拿螺丝刀钉钉子。

但如果你想两者兼得——最好的编程能力 + 最好的记忆和协调——那答案不是二选一，而是让 Hermes 做大脑，让 Claude Code 做手。你用三个月调教出来的 Skills 和 Memory 不会因为某一次用了 Claude Code 而丢失，而最复杂的代码依然由最擅长写代码的工具来完成。这是目前最优的组合形态。

十五、一个更大的问题

写到这里，我想退后一步，说一个更大的思考。

从 2024 年到现在，整个 Agent 赛道都在卷一个维度：单次任务的执行能力。 谁能一次搞定更复杂的任务、谁的成功率更高、谁的 benchmark 分数更高。SWE-bench 分数从 20% 卷到 50% 卷到 70%。每个新产品发布会都在说"我们能解决 XX% 的 GitHub issue"。

这当然重要。但我越来越觉得，有一个维度被严重忽视了：时间。

一个工具好不好用，不只取决于你第一次用它的体验。更取决于你用了一年之后，它有没有变得更好用。

Word 用一年还是 Word。Vim 用一年变成了你的第二只手。Notion 用一年变成了你的外脑。iPhone 用一年跟第一天没什么区别。但一个经过一年训练的 Vim 配置，跟默认配置是天壤之别。

区别在哪？在于系统是否能跟你一起成长。

Vim 的成长是你手动配置的——你加 plugin、改 keymap、写 snippet。Hermes 的成长是自动的——你正常使用，它自己进化。如果 Vim 能自动观察你的编辑习惯、自动配置最适合你的快捷键、自动安装你可能需要的插件——那就是 Hermes 在 Agent 领域做的事情。

这就是 Hermes 在赌的东西。它赌的不是"第一天比 Claude Code 更强"——第一天它大概率还不如 Claude Code。它赌的是：三个月后，半年后，一年后，它和你之间建立的这种"共同进化"的关系，是任何"无状态 Agent"都无法复制的。

这个赌注对不对？没人知道。也许未来的模型会有原生的、无限长度的 context window，根本不需要外部记忆系统。也许 Claude 明天就出一个带 persistent memory + self-improving skills 的版本，做得比 Hermes 好十倍。

但至少在今天——2026 年 5 月——Hermes 是唯一一个在认真回答这个问题的产品。其他人都在卷"执行力"，只有它在卷"成长性"。

而我觉得，长期来看，"成长性"比"执行力"重要。因为执行力会随着模型进步而普遍提升（每个 Agent 都会变得更能干），但成长性是一种结构性优势——它需要时间来积累，而时间是不能被跳过的。

想想看：如果明天所有模型的能力都翻倍了——Hermes 的优势不会消失，反而会放大。因为更强的模型 + 你积累了三个月的 Skills 和 Memory = 更大的复利效应。模型进步是所有人共享的，但你的 Skills 和 Memory 是只属于你的。

这就是为什么我说 Hermes 指向了一个"完全不同的未来"——它不是在现有的赛道上跑得更快，它开辟了一条新赛道。在这条赛道上，时间是护城河，使用是投资，每一次对话都是在让未来变得更好。

周三下午五点，我把那个 Prisma checksum 的事情处理完了。关上笔记本前看了一眼飞书——Hermes 最后发了一条消息：

"已将'修改 migration 后自动 regenerate checksum'写入 pre-commit hook skill。下次触发条件：检测到 prisma/migrations 目录有文件变更且 checksum 未更新时自动执行。"

我没告诉它"记住这个"。我没手动更新任何配置文件。我甚至没说"谢谢"。

它只是自己变聪明了一点点。

和昨天相比，只是一点点。但三个月后回头看，那些一点点加起来，是一个完全不同的东西。

就像你种了一棵树。每天看不出变化。但一年后回头看——它已经能遮荫了。

☏

读者来信

0/1000

暂无来信，期待你的分享。