Hermes 的"成人礼"：11 万星、RCE 修复与生态接入，下一代 Agent 为什么开始像基础设施
一个开源 Agent 项目，凭什么能在同一段时间里，让小米、阿里云、AMD 这些名字同时出现在它的讨论链里？
只靠热度不够。
只靠会调工具也不够。
真正让 Hermes 值得重估的，是它开始同时通过三种完全不同的考试：开源社区的增长考试、工程体系的落地考试、安全事件的压力考试。
截至 4 月 23 日，Hermes Agent 的 GitHub 星标已经来到 11.1 万 。从 3 月 12 日的 v0.2.0 到 4 月 16 日的 v0.10.0 ，官方在 35 天里连续发了 9 个版本 。GitHub contributors 列表也已经超过 500 位。
这不是一个"做着玩"的节奏。
这更像一个项目从明星 demo，开始往基础设施位置拱。
真正值得去看的点，也不只是数据漂亮。
而是 Hermes 正在回答一个更大的问题：AI Agent 到底怎样才算会成长。
一、Hermes 为什么突然"像样了"？因为它先把成长机制做成了系统能力
很多 Agent 项目也会接工具、接模型、接浏览器。
但 Hermes 真正拉开差距的，不是工具数量，而是它把"越用越强"拆成了几块可执行的工程结构。
1）它的记忆不是堆历史，而是主动管理
Hermes 的长期记忆不是无限追加。
它直接把内置记忆分成两份：MEMORY.md 和 USER.md，而且是有上限的。
官方配置里，前者大约 2200 字符 ，后者大约 1375 字符 。
这件事看上去像保守，实际上很聪明。
因为很多 Agent 的记忆系统，最后都死在一个问题上：越记越多，越记越乱，最后谁也不敢再往 prompt 里塞。
Hermes 的做法正好反过来。
它先承认上下文预算是稀缺资源，再倒逼自己做压缩、清理和取舍。
再配合 session_search 的 SQLite FTS5 全文检索，长期记忆和历史对话召回是分开的：
- 该常驻的，进 MEMORY / USER
- 该按需翻的，走 session_search
这不是"会记住"。
这是知道什么该常驻，什么该检索。
2）它把 Skill 做成了真正的程序性经验
Hermes 最有意思的一点，是它不把 Skill 当提示词收藏夹。
在它的官方文档和 README 里，Skill 的定位非常明确：
复杂任务跑通之后，要把条件、步骤、命令、坑点、验收标准沉成可复用方法。
而且这个技能不是一次写死，后续还能继续 patch、继续修。
这就把 Agent 的"经验"从聊天记录里拿出来，变成了独立资产。
很多系统也说自己能学习。
但大量所谓学习，最后只是"把历史再塞回来"。
Hermes 不一样。
它把学习拆成了两类：
- 偏好、约束、身份，进 memory
- 跑通过的方法，进 skill
前者回答"你是谁"。
后者回答"这事以后怎么做"。
这两件事一分开，系统就开始像人了。
3）它的多 Agent，不是热闹，而是隔离
Hermes 的 subagent 设计也值得高看一眼。
它不是把一堆 Agent 拉进群聊互相喊话，而是明确给子 Agent 独立上下文、独立终端、独立任务边界，甚至禁止递归委托、禁止直接写共享 memory。
这背后的判断很成熟：
协作的前提不是会分工，而是不会串味。
很多多 Agent 框架最容易翻车的地方，就是看起来很聪明，实际上权限、状态、上下文全混了。
Hermes 至少在架构上先把这个坑堵住了。
4）它已经给出了一套生产级 best practice
如果把 Hermes 近几版 release 和文档连起来看，你会发现它不只是"功能多"，而是在持续固化一套生产级方法：
- 长期记忆和历史搜索分离
- skills 作为程序性记忆而不是提示词碎片
- profile 隔离，避免多身份串配置
- cron 定时任务原生内置
- 危险操作审批
- 多平台消息入口统一
- 本地、Docker、SSH、Daytona、Modal 等多后端运行
所以 Hermes 火，不只是因为会做事。
而是因为它开始像一套有方法论的 Agent 操作系统。
二、为什么 AMD、小米、阿里云会同时出现在 Hermes 语境里？
因为 Hermes 已经不是"只在一台开发机上玩玩"的项目了。
它的底层设计，本来就在往生态接入走。
先看小米：这是最明确的一次信号
在 4 月 8 日的 v0.8.0 release 里，官方直接写了：
Nous Portal 已支持 free-tier 的 Xiaomi MiMo v2 Pro，并且能用于压缩、视觉、总结等辅助任务。
这件事的价值，不只是"多了一个模型可用"。
而是 Hermes 对国产模型的接入，已经不是社区 Hack，而是正式能力面的一部分了。
再看阿里云：它已经是一等 provider 了
Hermes 官方 provider 文档里，Alibaba Cloud / DashScope 已经被列成一等接入项。
命令级示例都给到了：
bash
hermes chat --provider alibaba --model qwen3.5-plus这意味着什么？
意味着 Hermes 的生态边界已经不再是"欧美主流闭源模型"。
它在设计上已经把国内模型、国内 API 体系、国内团队的接入路径考虑进去了。
再看 AMD：重点不是一句背书，而是本地运行条件已经成熟
关于 AMD AI PC 场景，社区最近讨论很多。
我更关心的不是哪条新闻标题，而是 Hermes 为什么接得住本地端叙事。
答案其实在官方文档里：
Hermes 已经明确支持本地 / 自托管推理路径，比如 llama.cpp、Ollama、vLLM ，并且把本地模型的最低上下文要求直接卡在 64K。
这说明它从设计上就不是云端专属产品。
它天然适合被装进本地端、边缘端、AI PC、私有化环境。
换句话说，AMD、AI PC、国产模型这些关键词之所以会和 Hermes 连在一起，不是因为营销词碰巧撞上了，而是因为 Hermes 的架构本来就允许它进入这些场景。
它不是一个只能在 demo 环境里表演的 Agent。
它是真的在往可部署、可替换、可嫁接 走。
三、从一次 SMS RCE 修复，看清 Hermes 真正稀缺的地方
Hermes 在 4 月 13 日发布的 v0.9.0 里，release note 直接写得很重：
Twilio webhook signature validation（SMS RCE fix）。
官方还在短信接入文档里明确要求：
SMS_WEBHOOK_URL必须配置- Hermes 会校验
X-Twilio-Signature SMS_INSECURE_NO_SIGNATURE=true只能用于本地开发，不能上生产
这说明问题已经非常明确：
这不是普通 bug 修补，而是一次真实的安全边界补齐。
技术上，它本质上是入站 webhook 来源校验缺失 。
如果服务端收到一个长得像 Twilio 的 POST 请求，就直接把其中的短信正文当成真实用户输入，那么攻击者就不需要真的发短信，只要伪造 webhook 请求，就能把恶意文本直接塞进 Agent。
一旦这个 SMS 通道后面还连着工具执行，问题就会从"伪造消息"继续滑向"远程指令执行"。
但这件事最值得行业看的，不只是"补了一个洞"。
而是 Hermes 这套架构，本来就有把一次事故转化为长期免疫资产的潜力。
为什么这么说？
因为它有三层天然适合安全沉淀的结构：
- memory：可以记录攻击模式、风险偏好、禁区规则
- skill：可以把一次修复流程沉成安全审查手册
- prompt / context 扫描：对注入、越权、敏感指令有前置过滤意识
所以社区把这类故事讲成"自我免疫"，我觉得核心方向并没有讲错。
哪怕你把戏剧性细节先放一边，Hermes 的确比很多 Agent 更接近一种"可学习的防御体"：
它不是只靠开发者手工打补丁，还是在努力把每次踩坑变成系统的长期约束。
这在 Agent 时代非常关键。
因为传统软件修一个漏洞，通常意味着版本升级。
但 Agent 修一个漏洞，理想状态不只是代码变了，行为规则、审批边界、记忆口径、技能资产也应该一起变。
Hermes 至少已经把这条路铺出来了。
四、Hermes vs OpenClaw：不是谁替代谁，而是路线已经分岔
很多人喜欢把 Hermes 和 OpenClaw 直接放在一起 PK。
可以比。
但我更愿意说，它们越来越像两条不同路线。
从官方迁移文档和 Honcho 集成对比文档看，差异已经很明显了。
| 维度 | Hermes | OpenClaw |
|---|---|---|
| 记忆策略 | 有界记忆，主动压缩；长期记忆与 session_search 分开 | 更偏 workspace / 插件式长期协作 |
| 上下文注入 | 倾向一次注入、缓存命中、异步预取 | 插件钩子更强，但更容易每轮同步取上下文 |
| Skill 角色 | 程序性经验资产，可生成、可 patch、可自修 | 更偏人为维护的工作区规则与配置 |
| 多 Agent 观 | 强隔离、强边界 | 更适合工作区/插件生态型协作 |
一句话总结：Hermes 在做"会成长的运行时"，OpenClaw 更像"可拼装的工作台"。
所以如果你问我怎么选：
- 偏 AI 编程、开发者效率、长期个人助手、可进化工作流：选 Hermes
- 偏已有工作区沉淀、强插件/强手工配置、桌面协作型场景：选 OpenClaw
真正的重点不是谁把谁打死。
而是 Hermes 已经很明确地走向了另一条路：
它要做的不是一个可配置的 Agent 壳，而是一个会沉淀、会复用、会收束风险的 Agent 运行时。
五、国内团队现在最该抄 Hermes 的，不是热度，是这 3 个动作
如果你是做 AI 产品、企业智能体、开发者工具链的，我觉得今天最值得抄的不是它的 UI，也不是它的模型名单。
而是下面这 3 件事：
今天就能做的 3 条
- 把"长期记忆"和"历史检索"拆开，别再把所有历史都硬塞 RAG
- 把一次成功任务沉成 Skill，别让经验永远停留在聊天记录里
- 把工具执行前的审批、签名校验、隔离边界补齐，别等上线后再补安全
本周该推进的 3 条
- 给 Agent 建一份有上限、可清理的长期记忆结构
- 给高频任务建一套可 patch 的技能库
- 给外部入口补签名校验、allowlist、审计日志和沙箱边界
这才是 Hermes 真正让行业兴奋的地方。
不是"它又会了一个新功能"。
而是它把 Agent 最难的三件事------成长、复用、止血------开始接成了一条线。
结语
Hermes 这波爆火，当然有流量因素。
但如果只把它理解成"一个很红的开源项目"，其实是低估了它。
它更重要的意义在于：
它正在把 AI Agent 从"会调用工具"推进到"会积累经验、会收束风险、会形成体系"。
11 万星不是终点。
一次 RCE 修复也不是重点。
真正值得行业盯住的是：它已经开始回答那个最难的问题------
AI 到底怎样才算真正成长。
如果这个问题被它持续答对，Hermes 接下来争的就不是下一个爆款项目的位置了。
它争的是 Agent 基础设施的入场券。
你更看好下一代 Agent 先跑成哪一种形态：
像 Hermes 这样先做"会成长的运行时"，还是像 OpenClaw 那样先做"可拼装的工作台"？或者从hermes的体系架构中，对你企业甚至个人搭建智能体有什么启发？