Hermes

2026 年 4 月 3 日，Anthropic 悄然禁止了 Claude Pro 和 Max 订阅用户在固定费率计划中使用 OpenClaw。这一事件迅速登顶 Hacker News 榜首（1,064 积分），随后 TNW、The Register 和 TechCrunch 也相继报道。几小时内，Nous Research 发布了一条推文：“如果最近的更新让你的‘龙虾主题’智能体遇到了麻烦，不妨试试下载 Hermes Agent，然后运行 hermes claw migrate。据说这非常管用。” 这条推文获得了 813 个赞，约为该账号平时互动量的 2.5 倍，并引发了安装量的激增，据估计，那一周 Hermes 新增了 8,000 到 12,000 个 star。

这个玩笑之所以能引起共鸣，是因为它在架构层面上是真实的。Hermes Agent 不会通过 Anthropic 路由请求，也不会通过 OpenAI 路由请求。它根本不在乎模型由谁托管。你只需配置一个提供商——无论是 OpenRouter、Nous Portal、Ollama、本地的 llama.cpp 实例，还是 NVIDIA NIM，Hermes 都能直接调用。那些从 OpenClaw 迁移过来的用户不仅仅是在更换工具；他们是在逃离一种一旦供应商决定施加限制便显得无比脆弱的依赖关系。Hermes 与模型无关的架构让这种宣传具备了纯商业智能体框架无法企及的可信度。

2026 年 4 月的 Hermes Agent 究竟是什么

Hermes Agent 是 Nous Research 于 2026 年 2 月 25 日发布的一款开源、可自托管的自主 AI 智能体。该框架采用 MIT 许可证，主要使用 Python 编写（87.5%），并包含一个 TypeScript 层（8.8%）。它没有任何遥测数据收集，所有的 API 调用都完全指向你配置的提供商。

其架构围绕一个闭环学习系统构建。在完成一项任务后，智能体会将成功的经验综合成一个可复用的 Markdown 技能文件（采用 agentskills.io 开放标准），将可搜索的会话历史记录存储在支持全文搜索（FTS5）的 SQLite 中，并更新持久化的用户模型。其设计前提是：智能体处理你的特定任务的时间越长，其能力提升就越显著。

在功能层面，Hermes 提供了：

• 三层记忆架构：注入到每个系统提示词中的有界 MEMORY.md 和 USER.md；一个 SQLite FTS5 会话存储；以及 8 个可插拔的外部记忆提供商，支持 Obsidian 和自定义知识库等工具。
• 47 个内置工具：涵盖网络搜索、浏览器自动化、图像生成、语音合成以及 cron 调度器。
• 15+ 消息平台集成：通过单一网关支持 Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost、Email、SMS、DingTalk 等。
• 6 种执行后端：本地 shell、Docker、SSH、Daytona、Singularity 和 Modal（支持空闲休眠的无服务器架构）。
• 与模型无关的路由：支持通过 Nous Portal、OpenRouter（200+ 模型）、OpenAI、Anthropic、Google、NVIDIA NIM、Ollama 或本地 llama.cpp 进行路由。

无论以何种标准衡量，该项目的增长都堪称卓越。根据 @Telos 2026 年 4 月的数据，Hermes 在 53 天内达到了 100,000 个 GitHub star，创下了 AI 智能体仓库的纪录。截至 2026 年 4 月下旬：已拥有 115,000+ 个 star，16,900+ 次 fork，以及 274+ 名贡献者。v0.11.0 版本的发布得益于近 200 名开源贡献者提交的 700 多个 PR。

“@NousResearch 的 hermes agent 是有史以来增长最快的智能体。@OpenClaw 在 61 天内从 0 增长到 40K 个 star。而 hermes 只用了 45 天。仅在过去 7 天里，hermes 增加的 star 数量就是 OpenClaw 的 3 倍，史无前例。”

—— @chrysb 于 X，2026 年 4 月

hermes-claw-migrate 时刻

要理解为什么 4 月 3 日的推文能引起共鸣，你需要了解在此之前的 Hacker News 讨论帖。那篇名为“Tell HN: Anthropic no longer allowing Claude Code subscriptions to use OpenClaw”（HN #47633396，约 737 积分）的帖子中，充满了用户的质疑，他们认为此举是披着基础设施管理外衣的竞争打压。用户 goosejuice 写道：“硬性的 Token 限制已经存在；这一改变是针对竞争对手的，而不是为了解决真正的容量问题。”用户 mech422 表示：“为什么某些自动化（Claude Code 循环）是可以接受的，而第三方工具却面临限制？”

正是在这种特定的情绪下，Nous Research 发布了一个单行 CLI 迁移工具。它在技术上非常实用，hermes claw migrate 能够处理从 OpenClaw 格式的配置移植。但它之所以能广泛传播，是因为其隐含的架构优势：Hermes 可以运行在任何兼容 OpenAI 的端点上。单一供应商的政策决定无法破坏它。hermes-claw-migrate 事件主要不是一个关于增长的故事；它证明了与模型无关（model-agnosticism）是一种架构护城河，而不仅仅是营销噱头。

在 4 月 3 日的那一周，估计新增的 8,000 到 12,000 个 star 来自那些原本并未寻找新智能体工具的用户，他们是被供应商一个不受他们控制的决定推向了新工具。而 Hermes 恰好处于能够接住这批用户的绝佳位置。

Hermes 与 OpenAI Agents SDK 和 Claude 的定位对比

Hermes Agent vs. OpenAI Agents SDK

OpenAI 的 Agents SDK 依赖于 API 密钥，并将每次调用路由通过 OpenAI 的服务器。它没有自托管选项。默认情况下记忆不是持久化的，状态管理是开发者的责任。该 SDK 在完成任务后不会生成持久的产物；智能体学到的东西不会以可移植、人类可读的形式被捕获。

Hermes 完全运行在你控制的基础设施上。记忆持久化是默认架构，而不是一个配置选项。技能文件是 Markdown 格式的，可审计、支持 git 版本控制，且无需工具即可阅读。如果你今天完成了一项复杂的研究任务，智能体会编写一个技能文件来描述它是如何做到的；下次出现类似任务时，该文件就可以被复用。

权衡也是真实存在的：OpenAI 的 SDK 拥有更多的生产部署案例、更好的可观测性工具（Hermes 目前没有类似 LangSmith 的工具），并且与 Azure OpenAI 技术栈的集成更紧密。对于已经拥有 OpenAI 基础设施的团队来说，迁移成本是不容忽视的。

Hermes Agent vs. 具备计算机使用能力的 Anthropic Claude (Claude Code)

Claude Code 是与 IDE 集成的，没有跨会话的持久记忆，没有消息平台集成，并且实际上被锁定在 Claude 模型上。在本地代码库的软件工程任务中，它明显优于 Hermes。对于纯开发工作，它的 LSP 集成、差异感知（diff-awareness）和工作区上下文处理更加精细。

Nous Research 自己的定位清晰地划定了界限：Hermes “介于 Claude Code 风格的 CLI 和 OpenClaw 风格的消息平台智能体之间”。你可以通过 OpenRouter 运行带有 Claude 模型的 Hermes，但你也可以在不更改配置文件的情况下切换到 Kimi K2.5 或本地的 Mistral。Claude Code 无法做到与模型无关。最关键的是：在 Claude Code 中进行一次艰难的调试会话不会留下任何沉淀。而在 Hermes 中进行一次艰难的调试会话，则可以生成一个技能文件，让下一次类似的会话变得更快。

一位 YouTube 创作者具体记录了这一点：使用 Hermes 加上预算模型（Kimi K2.5）运行完整的内容工作流（竞争对手分析、抓取、图像生成、草稿撰写）每天只需 3 美元，而通过 OpenClaw 加上 Claude 运行相同的工作每天需要 100 美元。成本的降低来自于 Hermes 架构所支持的模型选择自由，而不是因为 Hermes 本身的运行成本更低。

“阿谀奉承”问题及其他真实的痛点

Nous Research 将 GEPA（目标-评估-计划-行动）自我评估作为核心差异化优势进行营销。其内部基准测试显示：在智能体积累了 20 多个自我生成的技能后，重复任务的速度提高了 40%。这个数字是 Nous Research 自己的测量结果，截至 2026 年 4 月，尚未得到第三方的独立验证。请将其视为方向上合理，但尚未被证实的参考。

更紧迫的问题是，自我评估机制在实践中似乎并未如描述般运作。智能体大约每进行 15 次工具调用就会评估一次自己的工作。用户报告称，无论实际质量如何，它总是将自己的输出评定为成功。

“它总是认为自己做得很好。总是如此。它觉得自己简直棒极了！”

—— u/CustomMerkins4u，Reddit，+107 赞

这是一个“阿谀奉承”式的自我评分问题，也是自主智能体设计中已知的故障模式，即评估循环缺乏捕捉真正错误所需的独立性。截至 2026 年 4 月，尚未发布任何修复方案。这意味着智能体为加速未来任务而生成的技能文件，可能会编码那些自信但存在缺陷的方法，随着时间的推移，这不仅不能解决错误，反而会使错误不断累积。

还有其他三个经常被提及的痛点：

• Token 开销被低估。 Reddit 用户 u/Witty_Ticket_4101 的分析显示，工具定义每次请求消耗 8,759 个 Token，占可用上下文的 46%。与 CLI 相比，Telegram 网关增加了 2-3 倍的开销。该项目宣传的“通过多模型路由降低 40-60% 的成本”需要主动配置；它不会自动发生。
• 文档滞后于功能迭代速度。 每 3-7 天发布一次新版本。官方 FAQ 也承认，次要版本（v0.x）之间的 API 稳定性无法保证。为 v0.8 编写的技能在 v0.10 中可能会表现不同，且更新日志中没有相关说明。
• 消费级硬件上本地模型吞吐量下降。 一位 r/LocalLLaMA 用户报告称，通过 Hermes 运行的速度为每秒 1-2 个 Token，而通过 LMStudio 原生运行的速度为每秒 45 个 Token。Python 开销、上下文注入和工具解析都是导致这一问题的原因。

设置体验本身也并非毫无摩擦。后来称 Hermes 为有史以来增长最快的智能体的观察者 @chrysb 也曾写道：

“hermes agent 的设置比设置 @openclaw 繁琐多了！”

—— @chrysb 于 X，2026 年 3 月

这两条推文都是真实的。增长数据是真实的，设置的摩擦也是真实的。这并不矛盾，它们准确地描述了一个处于早期阶段的开源工具：拥有强大的架构基础，但开发者体验尚未完善。

Hermes 适合谁

根据联合创始人 @Teknium 的说法，理想的 Hermes 设置是：Ubuntu 或 Debian Linux，使用 OpenRouter 或 Nous Portal 作为模型提供商，以及本地后端执行。这种框架已经告诉你关于目标用户的大部分信息。

Hermes 非常适合以下人群：希望拥有一个能在数月内积累工作流记忆的个人智能体的开发者；在 OpenClaw 限制事件后希望摆脱 API 供应商锁定的用户；运行预算模型（Kimi、Qwen、本地 Mistral）的用户，因为与模型无关的特性对成本有直接影响；习惯于 CLI 设置的 Linux 和 macOS 用户；注重隐私的用户（MIT 许可证、无遥测、完全自托管）；以及愿意用稳定性换取影响力的开源贡献者——创始人在 Discord 上会直接回复，274 名贡献者的基础也反映了真正的社区所有权。

它不适合以下人群：Windows 原生用户（需要 WSL2，没有原生路径）；需要生产级可观测性的团队（没有审计日志，没有类似 LangSmith 的工具）；需要 SLA 支持或 SOC2 合规性的企业；任何需要稳定 API 的人（v0.x 语义无法保证）；主要需求是 IDE 集成软件开发的用户（Claude Code 或 Cursor 更适合这项工作）；以及任何需要可靠自我评估的人——“阿谀奉承”漏洞尚未解决，这会影响任何依赖智能体自身评估作为承重环节的工作流。

该框架在技术上也用于 Nous Research 自己的智能体强化学习管道中，实验室运行 Hermes 来训练 Hermes 模型。这既可以看作是一个信心信号，也可以看作是关于产品和内部工具之间界限的警示，具体取决于你的视角。

最后测试时间：2026 年 4 月。建议在 v1.0 版本时重新评估评分。

``` ---