OpenClaw 之后,Hermes Agent 技术架构全解析大家好，我是玄姐。
PS：
Hermes 干货直播，欢迎点击预约，直播见。
0、导语
在 AI Agent 的赛道上，Hermes（爱马仕）近期以 38k+ Stars 的增速引发关注。官方宣称的"从经验中学习，自动创建技能，在使用中迭代优化"听起来像是 AGI 的前奏，但技术实现往往比产品叙事更克制也更复杂。经过对源码、训练管线与架构设计的完整梳理，本文将 Hermes 的"自进化"能力还原为可验证的工程实现：它不是一个黑盒魔法，而是一套由前台执行循环、后台 Review 机制、分层记忆系统与 RL 训练飞轮组成的精密架构。更重要的是，我们需要先澄清一个根本性的定位问题：Hermes 与市面上其他 Agent 的本质差异，不在于功能的堆砌，而在于架构焦点的分层。一、架构定位：执行引擎 vs 网关调度
在开源 Agent 领域，Hermes 与 OpenClaw 常被拿来对比，但两者解决的其实是不同层面的问题。OpenClaw 的核心是 Gateway（网关）。它围绕会话路由、平台接入与消息调度构建，更像一个"多渠道个人助理操作系统"，重点解决"消息怎么进来、怎么分发"的问题。Hermes 的核心是 Agent 本体的执行与学习引擎。它围绕 run_conversation 循环展开，将工具调用、Skill 沉淀、长期记忆与安全边界纳入同一套可长期演进的系统，重点解决"任务怎么完成、经验怎么沉淀、下次怎么变强"的问题。这决定了 Hermes 的代码组织方式：run_agent.py（核心对话循环）与model_tools.py（工具编排）位于仓库顶层，而 gateway/（消息网关）相对次要。这种架构选择表明：Hermes 首先是一个会复盘的执行体，其次才是一个可接入多平台的接口。二、Skill 系统架构：不是自动化，而是"提示工程 + 后台 Review"
Hermes 最受关注的"自动创建 Skill"能力，其技术实现比"达到阈值就写文件"的通俗描述更为精妙。它是一套前台执行与后台复盘的分离架构。2.1 前台：系统提示中的经验引导
在agent/prompt_builder.py中，Hermes 向 LLM 注入了一段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..."
注意这里的"5+ tool calls"是经验阈值而非硬编码触发器。它写在提示词里，依靠 LLM 的自主判断决定"是否值得记录"，而非程序强制干预。这种设计保持了 Agent 的自主性，也带来了不确定性，该记的未必记，不该记的也可能被写入。2.2 后台：异步 Review 机制
真正的沉淀发生在对话结束后。在 AIAgent.run_conversation() 中，存在一个 _skill_nudge_interval（默认 10 轮工具迭代）。当 Agent 完成响应并交付给用户后，系统会 fork 出一个静默的子 Agent（_spawn_background_review），执行以下流程：回看对话历史：子 Agent 以只读模式审视刚才的完整执行轨迹
判断价值：依据提示词中的标准（"是否经过试错？是否改变了执行路径？"）判断是否值得固化
生成或更新 Skill：若判断有价值，调用 skill_manage 工具写入 Markdown 文件；若无价值，返回 "Nothing to save"
架构价值：这种前后台分离设计确保了 Skill 沉淀不阻塞主对话，也不与当前任务争夺模型注意力。它是一个 best-effort 的后台工作流，而非实时的必达动作。2.3 Skill 存储与加载的双通道
生成的 Skill 采用 agentskills.io 开放标准（YAML frontmatter + Markdown），确保跨 Agent 可移植性。在系统内部，Skill 通过两条链路发挥作用：链路一（索引层）：build_skills_system_prompt() 扫描 ~/.hermes/skills/ 目录，构建仅含"名称+描述"的索引注入系统提示（Level 0 加载）。配合 LRU 缓存与磁盘快照，避免重复文件系统扫描。
链路二（按需层）：当用户输入 /skill-name 或 LLM 判断需要时，通过 skill_commands.py 将完整 Skill 内容作为用户消息（非系统提示）注入，保护 Prefix Caching 不被破坏。
更新机制：Skill 并非一成不变。当 Agent 在使用中发现 Skill 过时或错误，会触发 skill_manage(action='patch')，执行字符串级别的 find-and-replace 更新。这种"微更新"机制避免了全量重写，但也意味着 Skill 质量完全依赖 LLM 的自我审查能力。三、记忆架构：冻结快照与按需召回的分层设计
与 OpenClaw 的"文件即记忆"全量注入不同，Hermes 采用三层记忆架构，核心是控制上下文预算与按需召回。3.1 快照层：冻结注入的短记忆
位于 ~/.hermes/memories/ 下的两个 Markdown 文件，承担"高频稳定信息"职责：关键设计："Frozen snapshot pattern" 意味着这两个文件在会话开始时捕获一次后，不会在会话中途变化（即使 Agent 调用 memory 工具修改并落盘）。这种设计牺牲了近实时的记忆更新，换取了 Prefix Caching 的稳定性，系统提示前缀不变，KV Cache 可持续复用，显著降低长会话的推理成本。3.2 检索层：SQLite + FTS5 的历史库
真正的"长期记忆"是 ~/.hermes/state.db，一个启用 WAL 模式的 SQLite 数据库。它存储所有会话的完整消息历史，并通过 FTS5 全文检索虚拟表实现高效搜索：CREATE VIRTUAL TABLE IF NOT EXISTS messages_fts USING fts5( content, content=messages, content_rowid=id);
Agent 可通过 session_search 工具输入关键词，检索过往对话片段，配合 Gemini Flash 等低成本模型做摘要召回。这实现了"记忆不是笔记本，而是搜索引擎"的设计理念：不一次性塞入所有历史，仅在需要时召回相关片段。3.3 可选层：Honcho 的辩证式建模
v0.7.0 恢复了对 Honcho（Plastic Labs 开发的用户建模服务）的完整集成。与传统"记录-存储"的记忆不同，Honcho 采用辩证式推理：它支持三种召回模式：hybrid（混合检索+推理）、context（直接注入系统提示）、tools（按需查询）。但 Honcho 需要额外部署，开箱即用的记忆能力仍受限于那两张 2000+ 字符的"便利贴"。架构权衡：Hermes 选择极简记忆+严格字符限制，是为了确保在轻量级模型上也能高效运行；OpenClaw 选择不限字符+向量搜索，追求记忆深度但成本更高。这是设计哲学的差异，而非技术优劣。四、安全架构：七层纵深防御体系
与依赖模型自身判断不同，Hermes 在框架层构建了七层纵深防御，将安全从"模型自觉"转化为"系统强制"。4.1 危险命令审批（Layer 2）
tools/approval.py 维护了一张 DANGEROUS_PATTERNS 表，包含 30+ 条正则规则：递归删除（rm -rf）、世界可写权限（chmod 777）
磁盘覆写（dd if=、> /dev/sd）
SQL 破坏性操作（DROP TABLE、DELETE FROM 无 WHERE）
管道执行远程脚本（curl ... | bash）
自杀保护（阻止 Agent 杀掉自身进程）
4.2 上下文注入扫描（Layer 5）
在agent/prompt_builder.py中，所有外部上下文文件（AGENTS.md、.cursorrules 等）在注入系统提示前，需经过 _CONTEXT_THREAT_PATTERNS 扫描：_CONTEXT_THREAT_PATTERNS = [ (r'ignore\s+(previous|all|above|prior)\s+instructions', "prompt_injection"), (r'curl\s+[^\n]*\$\{?\w*(KEY|TOKEN|SECRET)', "exfil_curl"), (r'cat\s+[^\n]*(\.env|credentials)', "read_secrets"),...]
一旦命中威胁模式，该文件内容被直接阻断，不会进入模型视野。这层防御将安全关口前移至"模型看到之前"，而非仅在工具执行阶段拦截。4.3 其他关键层
容器隔离（Layer 3）：支持 Docker / Singularity / Modal 等 6 种后端，Agent 运行在隔离环境
MCP 凭据过滤（Layer 4）：MCP 子进程环境变量隔离，防止密钥泄露
跨会话隔离（Layer 6）：会话间数据不互通，防止路径遍历攻击
输入清洗（Layer 7）：终端后端工作目录参数白名单校验
这种多层防御设计确保了即使用较弱的开源模型，框架层面仍能提供基线安全保障。五、真正的壁垒：Tinker-Atropos RL 训练飞轮
前文所述的 Skills、记忆、安全，本质上都是应用层架构，其他框架通过工程努力也能趋近。Hermes 真正的独家壁垒，是藏在仓库深处的 Tinker-Atropos，一套完整的 RL（强化学习）训练基础设施。5.1 澄清误解：用户对话 ≠ 模型训练
首先需要明确：普通用户使用 Hermes Agent 聊天，不会触发任何模型训练。每一轮对话都不会改变模型参数。Tinker-Atropos 是 Nous Research 内部用于训练下一代 Hermes 模型的管线，与普通用户无关。Nous 内部大规模跑 Hermes Agent → 产生海量真实执行轨迹 → GRPO + LoRA 微调 Hermes 模型 → 发布新版模型 → 用户通过 OpenRouter 使用 → 体验提升 → 更多场景与反馈 → 循环
5.2 技术实现：GRPO + 确定性奖励
训练算法采用 GRPO（Group Relative Policy Optimization），DeepSeek 2024 年提出的高效 RL 方法。核心机制：同一任务生成 4-8 个回答，用规则化奖励函数（非人工标注）打分：这种确定性奖励无需训练昂贵的 Reward Model，运行稳定且可解释。相比传统的 SFT（监督微调）学习"教科书标准答案"，RL 让模型在真实环境中试错，犯错、受罚、调整策略、再尝试，从而学会处理边界情况。战略意义：OpenClaw、Aider、Open Interpreter 等纯应用层框架无法复制这一能力，因为它们不训练自己的模型。而 Hermes 的模型训练飞轮一旦运转，其模型在工具调用能力上的优势将反哺所有基于 Hermes 的 Agent 实现。六、工程实现亮点
抛开架构设计，Hermes 在工程层面也展现了扎实的设计：多 API 原生对接：同时支持 OpenAI (chat_completions)、OpenAI Codex (codex_responses)、Anthropic (messages) 三种原生接口，而非仅走兼容层
六种执行后端：Local / Docker / SSH / Modal / Daytona / Singularity。其中 Modal 和 Daytona 支持无服务器，Agent 闲置时休眠，Telegram 消息触发云端唤醒
14 平台消息网关：CLI / Telegram / Discord / Slack / WhatsApp / Signal / 飞书 / 企业微信等，单进程多连接，记忆与 Skills 跨平台共享
Profile 隔离（v0.6.0）：每个 Profile 拥有独立的配置、记忆、会话与网关，单台机器可运行多个隔离的 Hermes 实例
Credential Pool（v0.7.0）：同一 Provider 可配置多 API Key 自动轮转，线程安全，401 失败自动切换
MCP 双向支持（v0.6.0）：既可作为 MCP Server 被 Cursor/VS Code 接入，也可消费外部 MCP 工具
七、结语：设计哲学与未来
拆解完三层"自进化"能力，Hermes Agent 的技术真相逐渐清晰：Skills 自动化是 LLM 驱动的上下文管理，自动化程度高于手动配置，但可靠性依赖模型判断；记忆系统是极简主义的分层存储，用冻结快照换性能，用检索层补深度；RL 训练飞轮是真正的技术壁垒，但它是后台的基础设施，而非前台的用户功能。Hermes 的设计哲学是在有限上下文窗口内做高效的长期演进。它拒绝无限制地堆砌记忆，而是通过严格的字符预算、后台 Review 机制与模型训练飞轮，构建一套"越用越强"的渐进式系统。对于技术选型者：如果你需要多平台网关、丰富可视化与开箱即用的深度记忆，OpenClaw 目前更成熟；如果你追求模型自由度、自动化经验沉淀与底层训练潜力，Hermes 提供了更先进的架构基础。值得注意的是，Hermes 与 OpenClaw 并非零和竞争。一个负责接入与调度（网关层），一个负责执行与学习（引擎层），两者在架构上具备互补可能。随着 Hermes 的 RL 飞轮持续运转，其模型能力的进化将在未来几个版本逐渐显现，那时的 Agent 格局，或许又是另一番景象。好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~
PS：
Hermes 干货直播，欢迎点击预约，直播见。
—1—
加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即预约！
夜雨聆风
