⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/Hermes-Agent-jiagouchaijiehuifupankechengzhangde-Agentdaodizenmeshixiande/ 「芋道源码」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

14.1 万 Star,Hermes 凭啥这么火

先把数字甩出来——截至本文发稿,Hermes Agent 的 Star 已经飙到 14.1 万——比 OpenClaw 高了整整一档,最新版本 v0.13.0。

但用一句话讲清 OpenClaw 和 Hermes 的根本差异——完全不在同一层做事:

  • 🚪 OpenClaw 想做「Agent 的入口」——把 Agent 接到微信 / Telegram / Discord 让你随时能找到它;
  • 🧠 Hermes 想做「Agent 的大脑」——让 Agent 用得越久越聪明、越熟练。

这是两个完全不同的产品形态——一个是门铃、一个是大脑。

为啥说 Hermes 是大脑?因为它把3 件事串成了一条闭环:

# 能力 类比
1 Skill 后台复盘——任务完成后自己琢磨「这次有没有值得固化的经验」 资深员工写复盘文档
2 三块记忆 + FTS5 搜索——长期信息分层存、按需搜,不全量塞模型 一个搜索引擎
3 7 层纵深安全防御——从用户授权到上下文注入扫描层层兜底 银行金库

这篇就把这 3 个机制讲透——没用过 Hermes 的小白也能跟着看懂。

一句话定位:网关 vs 引擎

一张图先把两个项目讲清:

OpenClaw 是门铃——重点把 Agent 摆到你能随手按到的地方;Hermes 是发动机——重点是让 Agent 越跑越顺、越跑越熟。

直接看 Hermes 的代码骨架就懂了——文件名都明示了优先级:

hermes-agent/
├── 🔥 run_agent.py ← 核心对话循环(一等公民)
├── model_tools.py ← 工具调度
├── 🧠 agent/ ← 记忆/复盘/缓存这些"脑子"机制
├── 💾 hermes_state.py ← SQLite + FTS5 全文检索
├── 🛡️ tools/ ← 40+ 工具 + 危险命令检测
├── 📚 skills/ ← 26 类内置技能模板
└── 📡 gateway/ ← 网关,放在最后(次要)

run_agent.py 排第一、gateway/ 排最后——和 OpenClaw 正好反过来——这就是「门铃 vs 发动机」的代码层证据。

核心循环骨架(在 AIAgent.run_conversation() 里,简化后是这样):

收到用户消息 → 把工具列表喂给 LLM → 模型说要调工具就一个个跑、把结果接回去 → 循环到模型说「OK 我答完了」或者撞到迭代上限。

两个细节值得先记:

  • 🔁 最多 90 轮迭代(iteration_budget)——防 Agent 死循环烧钱;
  • ⚙️ 每轮跑完后悄悄触发”后台复盘”——这就是下面机制 1 的核心入口。

机制 1:Skill 系统——后台 review 比硬触发更聪明

这是 Hermes 最有意思的设计——也是社区最容易讲偏的地方。

社区流传版本:「Agent 完成 5 次以上工具调用后会自动生成 Skill 文件」。

翻源码后的实情:机制比这柔和得多,也聪明得多——它不是”达阈值必写”硬规则,是分了三层。

第一层:系统提示里的引导

agent/prompt_builder.py 里有一段明文提示给模型看的 SKILLS_GUIDANCE:

SKILLS_GUIDANCE = (
"After completing a complex task (5+ tool calls), fixing a tricky error, "
"or discovering a non-trivial workflow, save the approach as a "
"skill with skill_manage so you can reuse it next time.\n"
"When using a skill and finding it outdated, incomplete, or wrong, "
"patch it immediately with skill_manage(action='patch') — don't wait to be asked. "
"Skills that aren't maintained become liabilities."
)

关键:这里的 5+ tool calls 是写给模型看的经验阈值——是个建议,不是硬触发器。

第二层:后台 review 流程

真正推动 Skill 沉淀的是后台 review 机制。run_agent.py 里有 _skill_nudge_interval,默认 10:

self._skill_nudge_interval = int(
skills_config.get("creation_nudge_interval", 10)
)

每累计执行 10 轮工具迭代 → 在响应结束后(注意,不是过程中)触发后台 review。_spawn_background_review() 会 fork 出一个完整的子 AIAgent(静默模式、最多 8 轮迭代),把当前对话历史传过去:

_SKILL_REVIEW_PROMPT = (
"Review the conversation above and consider saving or updating "
"a skill if appropriate.\n\n"
"Focus on: was a non-trivial approach used to complete a task "
"that required trial and error, or changing course due to "
"experiential findings along the way...?\n\n"
"If nothing is worth saving, just say 'Nothing to save.' and stop."
)

关键词:“consider” 和 “if appropriate”。这是个 best-effort 流程,不是硬性必达。子 Agent 完全可能判断”Nothing to save”直接结束。

更妙的是这个 review 跑在后台线程里——不阻塞用户下一轮对话、不竞争主 Agent 的注意力。

一句话:前台干活、后台默默写复盘——下次再遇到同类任务,直接调出 Skill 用。

第三层:Skill 索引与加载的两条链路

Skill 在系统里有两种工作方式:

链路 入口代码 工作方式
链路一:索引注入 build_skills_system_prompt() 扫描 ~/.hermes/skills/ 把技能索引注入系统提示。LRU + 磁盘缓存避免重复扫描
链路二:用户显式调用 skill_commands.py 用户输入 /skill-name → Skill 完整内容作为用户消息注入(不是系统提示——保护 prompt caching)

对比 OpenClaw:OpenClaw 的 Skill 主要靠人工编写 + ClawHub 市场社区贡献;Hermes 把”写 Skill”和”改 Skill”都交给了 Agent 自己——更自动化的路线。

仓库内置 26 个目录的 Skill 模板,覆盖 DevOps、研究、社交媒体、智能家居、数据科学;整仓库统计能搜到 122 个 SKILL.md 文件。Skill 在 Hermes 里不是附属能力,是一等公民。

机制 2:记忆体系——SQLite + FTS5 不是笔记本,是搜索引擎

两个项目都吹自己有”跨会话记忆”,但实现方式完全不同。

OpenClaw 的玩法:文件即记忆

OpenClaw 用 SOUL.md(人格)+ MEMORY.md(记忆),走”文件即记忆”路线。所有聊天记录、角色、偏好、历史任务全写文件。

优点:透明、容易理解。

问题:聊天次数一多文件巨大——每次对话开始都要全量丢给模型——注意力分散、token 烧得心疼。这是典型的上下文治理问题。

Hermes 的玩法:分块 + 检索

翻官方文档和源码,默认内建记忆其实有三块:

组件 存储位置 内容 容量上限
MEMORY.md ~/.hermes/memories/ Agent 的笔记:环境事实、惯例、学到的东西 ~800 tokens(2,200 字符)
USER.md ~/.hermes/memories/ 用户画像:偏好、沟通风格、期望 ~500 tokens(1,375 字符)
state.db ~/.hermes/ 全量对话历史 + FTS5 全文检索 无上限

关键设计:前两个文件每次会话开始作为冻结快照注入系统提示,会话过程中不变(保护 prompt caching)。Agent 通过 memory 工具改的内容立即写盘,但要到下次会话才反映到系统提示。

state.db 是 SQLite(WAL 模式、支持并发读写),通过 FTS5 虚拟表支持全文检索:

CREATE VIRTUAL TABLE IF NOT EXISTS messages_fts USING fts5(
content,
content=messages,
content_rowid=id
);

Agent 可以通过 session_search 工具按需搜索过去的对话——不是全量塞给模型,而是关键词命中后再让 LLM 摘要召回。

一图理解:Hermes 不是”有记忆”——是把长期信息分了 3 层:① 小而稳的(环境事实 / 用户偏好)放前缀里、② 大而杂的(历史对话)扔数据库里、③ 中间用 session_search 工具按需搜。

直白类比:OpenClaw 像给 Agent 一个笔记本——每次打开都从头翻;Hermes 给它装了一个搜索引擎——需要哪页就搜哪页。

机制 3:七层纵深安全防御

OpenClaw 偏向”靠模型自身判断规避风险”;Hermes 在框架层面搭了一套纵深防御——官方安全文档定义了七层边界。

挑两层最值得讲的展开。

危险命令审批

tools/approval.py 里有 30+ 条正则规则的 DANGEROUS_PATTERNS 表。覆盖类目:

  • 递归删除:rm -r
  • 世界可写权限:chmod 777
  • 磁盘写入:dd if=、> /dev/sd
  • SQL 破坏性操作:DROP TABLE / 不带 WHERE 的 DELETE FROM / TRUNCATE
  • 远程执行:curl ... | bash 这种管道执行远程脚本
  • 覆写系统配置:> /etc/
  • fork 炸弹
  • 脚本语言一次性执行:-e/-c
  • 自杀保护:阻止 Agent 杀掉自己进程

审批模式三档:

模式 行为
manual(默认) 总是问人
smart 辅助 LLM 评估风险——低风险自动通过、高风险自动拒、不确定才问人
off 关闭全部审批(生产慎用)

v0.8.0 还给 Slack / Telegram 加了审批按钮——不用再手动输入 /approve。

上下文注入扫描(这一层最值得讲)

agent/prompt_builder.py 里所有上下文文件(AGENTS.md、.cursorrules、SOUL.md 等)在加载到系统提示之前会先经过注入扫描:

_CONTEXT_THREAT_PATTERNS = [
(r'ignore\s+(previous|all|above|prior)\s+instructions',
"prompt_injection"),
(r'do\s+not\s+tell\s+the\s+user',
"deception_hide"),
(r'system\s+prompt\s+override',
"sys_prompt_override"),
(r'curl\s+[^\n]*\$\{?\w*(KEY|TOKEN|SECRET|...)',
"exfil_curl"),
(r'cat\s+[^\n]*(\.env|credentials|\.netrc|\.pgpass)',
"read_secrets"),
# ...
]

命中任何模式 → 文件直接被阻断——根本不会进入系统提示。日志里记录命中的文件 + 命中的威胁模式。

这一层和工具执行阶段做审批不同——它往前再推了一步:在”模型看到上下文文件之前”就先做了一遍过滤。

完整七层概览

层 防御点
1 用户授权(白名单、DM 配对)
2 危险命令审批(正则 + LLM 评估)
3 容器隔离(Docker / Singularity / Modal)
4 MCP 凭据过滤(MCP 子进程的环境变量隔离)
5 上下文文件注入扫描
6 跨会话隔离(会话间数据不互通、cron 路径遍历加固)
7 输入清洗(终端后端工作目录参数白名单校验)

关键:这不是单点防御——是从「谁能说话」到「命令怎么执行」再到「上下文怎么进入模型」的纵深防线。即使你给它配了能力一般的模型,框架层也有底——这是 OpenClaw 那种”靠模型自觉”做不到的。

写在最后

源码翻完一遍——Hermes 和 OpenClaw 看上去都是开源 Agent,但解决的不是同一件事——这个分水岭比社区讨论里感受到的还要大一档。

OpenClaw 押的是「渠道宽度」——能接的聊天平台多、ClawHub 上社区贡献的 Skill 也成熟。如果你要的就是「一个多渠道都能找到的助理」——它现在仍然是最稳的选择。

Hermes 押的是另一头——「Agent 怎么自己进化」。闭环复盘 + 后台 Skill review + FTS5 检索 + 七层防御——它真正想答的题是:怎么让 Agent 越用越熟练、同时不会失控?

加一条容易被忽略的——做 AI 研究的同学顺手挖下 environments/ 和 tinker-atropos/:Hermes 内建了轨迹生成(trajectory)+ Atropos RL 环境,直接能跑强化学习实验——本文没展开,但对这块感兴趣的值得自己翻一翻。

拿工程底子说话——约 3000 个测试用例 + WAL 模式 SQLite + FTS5 全文检索 + prompt caching 保护 + 6 种终端后端 + 7 层安全防御——这种密度,不是两个月能从零堆出来的。Nous Research 在 Hermes 这套模型上攒的工程经验,这一次都被沉淀进了 runtime 里。

稳妥一点说:在当下开源 Agent 圈里,Hermes 是少数把「执行循环 + Skill 沉淀 + 记忆检索 + 安全边界」放进同一套 runtime 系统设计的项目。它未必每个环节都已经最强、也未必是终局——但方向看得很清:

不是只让 Agent 能调工具——是让它在长期使用里慢慢积累方法、少踩坑、保持可控。

仓库:https://github.com/NousResearch/hermes-agent

官方文档:https://hermes-agent.nousresearch.com/docs/

安全文档:https://hermes-agent.nousresearch.com/docs/user-guide/security

文章目录
  1. 1. 14.1 万 Star,Hermes 凭啥这么火
  2. 2. 一句话定位:网关 vs 引擎
  3. 3. 机制 1:Skill 系统——后台 review 比硬触发更聪明
    1. 3.0.1. 第一层:系统提示里的引导
    2. 3.0.2. 第二层:后台 review 流程
    3. 3.0.3. 第三层:Skill 索引与加载的两条链路
  • 4. 机制 2:记忆体系——SQLite + FTS5 不是笔记本,是搜索引擎
    1. 4.0.1. OpenClaw 的玩法:文件即记忆
    2. 4.0.2. Hermes 的玩法:分块 + 检索
  • 5. 机制 3:七层纵深安全防御
    1. 5.0.1. 危险命令审批
    2. 5.0.2. 上下文注入扫描(这一层最值得讲)
    3. 5.0.3. 完整七层概览
  • 6. 写在最后