快速蹿红的Hermes Agent，会成为下一个OpenClaw吗？

文 | AI 价值官，作者丨星   野，编 辑丨美 圻

最近一段时间，Hermes Agent 的名字开始频繁出现在开发者社区里，而且不再只是零散的"新项目推荐"，而是下一个 OpenClaw 的热门候选者。

在英文技术社区、Reddit、X 以及 The New Stack 等媒体的讨论中，它被反复拿来和 OpenClaw 对比；在中文互联网，从知乎、小红书到技术社群，也开始出现越来越多真实的使用反馈。

伴随讨论度升温的，是一组很难忽视的数据变化：Hermes 的 GitHub Star 数在短时间内持续攀升，目前已超过 35k。OpenRouter 上的 token 使用量从 3 月下旬开始明显加速，单日使用量连续刷新新高，全球日排名一度进入前列。在 Productivity、Personal Agents、Coding Agents 等多个榜单中同时靠前，这对于一个上线不到两个月的 Agent 框架而言，并不常见。

更重要的是叙事的变化。讨论 Hermes 的人，不再只是"它能不能用""值不值得试"，而是开始出现一种判断：它能否成为下一个 OpenClaw。

这个说法并不意味着体量对等（毕竟，Hermes 的星标数和 OpenClaw 差了一个数量级），而是一种角色上的类比——在 OpenClaw 之后，是否终于出现了一个足够完整、足够严肃、值得长期投入的 Agent 框架选择。

OpenClaw 瓶颈渐显

Agent 生态或告别"一家独大"

过去三个月，OpenClaw 代表的是一种近乎共识的答案：多渠道接入、全天候运行、庞大的技能生态，让 Agent 从"会话工具"变成"常驻服务"。

然而，随着使用规模扩大、使用周期拉长，一些更底层的问题开始被反复提起：架构复杂度是否会不断外溢？长期运行的上下文和记忆如何管控？系统成本会不会随着生态扩张线性上升？这些问题并非突然出现，而是在狂热期之后自然浮出水面。

在此背景下，小米大模型负责人罗福莉 4 月初发表的文章进一步推波助澜。当 Anthropic 宣布切断 OpenClaw 等通过 Claude 订阅接入的通道，她从工程成本角度拆解了第三方 Agent 框架的效率问题。

她观察到，OpenClaw 的上下文管理存在明显浪费：一次用户查询往往被拆分为多轮低价值工具调用，每次 API 请求都携带超过 10 万 token 的上下文窗口。按 API 定价折算，单次任务的真实推理成本可能达到订阅价格的数十倍——"这不是一个小差距，是一个巨坑"。

她同时指出，这种压力短期内会倒逼框架开发者改进上下文管理，而更根本的出路在于"更高 token 效率的 Agent 框架"与"更强大高效的模型"的协同进化，而不是单纯压低 token 价格。

罗福莉的文章之所以在开发者圈子里引发共鸣，是因为它把许多用户长期使用中感受到的问题，以及行业不断攀升的 token 成本压力，摆在了面上。

从 OpenRouter 的使用数据来看，OpenClaw 依然是体量最大的 Agent 框架，但已经开始从 3 月底的峰值回落。结合 Anthropic 收紧第三方调用路径带来的冲击，部分开发者已开始重估单一框架路径依赖的风险，Agent 生态正进入一轮新的开放竞争阶段。

正是在此背景下，Hermes 的热度开始上升。它受到关注，不是因为提供了更多平台接入或更庞大的技能市场，而是因为在架构层面给出了另一种回答：当 Agent 被设计为长期运行的系统，是否可以把复杂度更多地收敛进模型和学习循环本身，而不是不断堆叠外部编排层？

也正是在这一刻，" Hermes 会不会成为下一个 OpenClaw "这个问题才真正成立——它比的不是规模，而是哪一种架构路径，更有可能支撑 Agent 走得更远。

Hermes 的设计哲学有何不同？

如果只对照功能列表，Hermes 和 OpenClaw 的重合度并不低：同样支持多消息平台接入，同样具备持久化记忆、技能系统和多模型切换能力，也都采用 MIT 协议、自托管部署。真正拉开两者差距的，是它们设计哲学上的显著差异。

OpenClaw 的核心是一套 Gateway 架构。它的设计重心在于连接和协调：统一管理会话、路由和渠道，把 Telegram、Slack、WhatsApp 等入口汇聚到一个调度中心，再将请求分发给模型和工具。这种架构非常适合快速扩展生态，也解释了为什么 OpenClaw 能在短时间内积累起庞大的技能市场和第三方集成网络。

自我进化

Hermes 走的是另一条路线，围绕" Agent 如何在长期使用中变得更强"来构建。整个系统的核心不是网关，而是 Agent 自身的执行循环，官方称之为 closed learning loop（闭环学习循环）。这意味着，Hermes 并不试图通过不断叠加外部编排层来解决问题，而是实现 agent 的自我进化，真正实现" grows with you "的愿景。

这种差异首先体现在技能系统上。Hermes 的技能不是预先编写的功能模块，而是在任务完成后，由 Agent 自行生成和维护的操作文档。当一次任务涉及多次工具调用并形成相对稳定的解决路径时，Agent 会把整个过程沉淀为一份结构化的 Markdown 技能文件。下次遇到类似问题，它不会重新从零推理，而是直接加载技能，并在执行过程中持续修订它。

有用户统计，连续使用一个月后，同类任务的工具调用次数从 20 多次压缩到八到十次，模型本身没有变化，变化的是 Agent 已经积累了一套可复用、可改进的"操作手册"。

相比之下，OpenClaw 也拥有庞大的技能生态，但技能更多是由他人编写、为通用场景服务，本身并不会随着某一个用户的使用而自动进化。一个更像公共教材，一个更像私人工作笔记。

有限记忆

Hermes 在设计哲学上与 Openclaw 的另一重分歧，在于对于"记忆"这件事的不同理解。

OpenClaw 的策略是"什么都存"，所有对话，所有上下文，全部持久化到数据库里。需要的时候全量检索。好处是信息不会丢，坏处是 token 消耗大，而且噪音会随时间指数级递增。

图片来源：Inside Hermes Agent: How a Self-Improving AI Agent Actually Works，Daily AI Insights

Hermes Agent 选了一条反直觉的路：有限记忆。它并没有采取"什么都存"的策略，而是有意为长期记忆设置上限。MEMORY.md 和 USER.md 的字符数被严格限制。设计者的判断是：对大模型来说，少量精准的记忆比大量模糊的记忆更有用。

记忆文件在每个 session 开始时注入系统提示词，占的 token 是固定的，不会随着使用时间越来越膨胀。而且因为空间有限，agent 被迫学会做信息的筛选和压缩，只保留真正重要的东西。记忆满了怎么办？agent 会自己合并旧条目、删掉过时信息、把多条相关记录压缩成一条。更像一个人在整理笔记，而不是一个数据库在堆叠数据。

在这一限制之上，Hermes 通过分层结构来解决记忆难题：所有历史对话被完整存储在 SQLite 中，通过 FTS5 全文检索按需召回；技能文件承担程序性记忆的角色；向量索引用于长期语义搜索；可选的 Honcho 用户建模模块，则用于捕捉用户偏好和认知变化的趋势，而不是简单堆叠事实。

这种设计的结果是，上下文不会随着使用时间失控膨胀，但 Agent 依然能够"记得住事"。对用户而言，最直观的体验是不再反复解释背景，不同会话、不同入口之间的理解保持一致。

模型解耦

此外，Hermes 在模型切换这件事上也走得更彻底。OpenClaw 官方虽然也支持多模型，但在实际使用中仍然更推荐搭配自家模型，而 Hermes 从一开始就把"模型可替换"当作前提条件来设计。

目前 Hermes 开箱即用地支持 18 个以上的 LLM 提供商，切换模型只需要一条命令，所有记忆、技能和历史数据都保存在本地，几乎不存在迁移成本。

这意味着用户可以根据价格、稳定性或具体任务特性自由切换模型。对于不希望被长期绑定在某一个模型或某一家厂商生态里的开发者来说，这种自由度本身就是一种安全感。

综合来看，Hermes 的这些设计并不是为了在某一次任务中显得更聪明，而是围绕一个更长期的问题展开：当 Agent 被持续使用数周甚至数月之后，它是否还能保持稳定、可控，并且越来越贴合用户自身的工作方式。正是在这个时间维度上，Hermes 与 OpenClaw 拉开了差异。

当然，这条路线的代价同样清晰。Hermes 在任务状态管理、长流程稳定性和子 Agent 协作上仍然不成熟，对模型规模的要求更高，学习曲线也明显陡于 OpenClaw。

更关键的是，Hermes 目前的生态成熟度与 OpenClaw 仍存在显著差距，第三方平台集成、社区教程、问题排查支持远不完善，普通用户的上手门槛远高于常规开源工具。它并不适合只想 "装好就用" 的用户。但对于愿意长期运行一个 agent、并期望它随着时间减少重复劳动的人来说，Hermes 提供的是一种完全不同的价值曲线。

Agent 框架趋同进化

分层架构正在形成

Hermes 的持续升温，并非对 OpenClaw 的单向替代，而是整个 Agent 框架生态同步进化的一个关键信号。

事实上，OpenClaw 早已意识到早期架构所面临的瓶颈，并主动推进底层能力迭代。在模型解耦与记忆机制这两个核心方向上，它正呈现出与 Hermes 异曲同工的进化趋势。

早在被 Anthropic 政策收紧影响之前，OpenClaw 就已经开始为 "去单一模型依赖" 做全面准备。在 3 月的更新中，OpenClaw 通过统一兼容层，抹平了不同模型在接口、认证方式和返回结构上的差异，用户切换模型只需修改一个配置项，无需重新适配工具。这与 Hermes 从设计之初就坚持的"模型可替换"思路高度一致。

在记忆机制上，针对早期"全量存储"带来的 token 浪费、上下文臃肿问题，OpenClaw 在 4 月 5 日发布的 v2026.4.5 版本中，正式上线了 "梦境" 记忆系统。这套系统模拟人类睡眠中的记忆巩固过程，在用户不活跃的时段自动完成记忆的筛选、压缩与提纯，仅将高价值信息沉淀为长期记忆。

这套机制与 Hermes 的有限记忆设计，在目标层面高度一致——让 Agent 越用越懂用户，同时对长期运行的成本与噪音进行严格控制。

不过，底层架构的差异，依然决定了两者的进化路径与适用人群的分野。

OpenClaw 的进化，是建立在原有 Gateway 架构之上的优化升级：它依然保留全量数据作为兜底，梦境系统更多是一种上层的离线提纯能力；模型解耦的重点，也放在兼容更丰富的生态与场景，而非从根本上重构执行逻辑。

Hermes 则从一开始就以"闭环学习循环"为核心，将复杂度直接内化进 Agent 的执行过程之中。这种底层设计基因的不同，使两者天然服务于不同类型的用户。

当用户对 Agent 的需求从 "尝鲜可用" 走向 "长期深度使用"，需求端已经出现了清晰的分层，与之对应，Agent 框架的三层结构正在逐渐成型。

OpenClaw 是面向普通用户的多渠道 Agent 平台，核心价值在于生态深度与低上手门槛，更像" AI Agent 的 Android "，目标是让用户无需理解底层细节，也能直接使用成熟的 Agent 能力。

Hermes 定位于面向专业开发者的 Agent 基础设施，强调可编程性、记忆深度与长期进化能力，适合希望深度定制、追求长期效率的用户；Claude Cowork 则代表面向安全敏感场景的封闭生态，模型能力强、沙箱成熟，更符合对数据安全有严格要求的企业环境。

这三种定位并不互斥，边界也在被主动打通。Hermes 已支持从 ClawHub 安装社区技能，也可以通过 MCP 协议接入 Claude Desktop 与 Cursor。

不少用户已经形成组合使用的模式：OpenClaw 负责多渠道消息路由与任务执行，Hermes 作为核心推理与记忆引擎。

这种分工协作的现实路径，显然比"谁取代谁"的线性叙事更贴近真实市场。

因此，与其追问"谁会成为下一个 OpenClaw "，不如承认一个更清晰的现实：Agent 框架正在从单点爆款时代，进入长期结构分化的阶段。

真正决定未来走向的，是在模型快速更迭的时代，谁能让 Agent 在时间维度上持续积累价值，并把这种积累牢牢掌握在用户手中。