Hermes Agent 自进化架构深度解析（一）：从“静态工具“到“自治系统“＞

i晟z

648人浏览 · 2026-07-05 23:20:56

i晟z · 2026-07-05 23:20:56 发布

本文是 Hermes Agent 自进化设计哲学系列的第一篇。我们将从一个核心问题出发：为什么大多数 AI 助手无法自我进化，而 Hermes 能做到？答案不在 AI 模型本身——在于它设计了一套由五个模块组成的自治架构。

一、什么是"自进化"

当我们说一个 AI 助手"自进化"时，不是在说模型的权重在自动更新。我们说的是：

它能自动判断什么该记住——不需要用户说"记住这个"
它能自动修复自己的知识——发现技能过时了，立刻更新
它能自动清理冗余——后台审查，合并重复，归档过时内容
它能检索历史经验——下次遇到相似问题，自动回溯之前的处理方式
它在做这一切时不会失控——每层自进化机制上方都有一层硬性约束

大多数 AI 助手——包括 Claude Code——停留在"被动配置"阶段。你有 CLAUDE.md，你可以往里写指令，AI 会读取。但你得自己写、自己维护、自己清理。AI 不会主动做任何事。

Hermes 选择了另一条路。

二、五模块架构

Hermes 的自进化由五个模块协同完成。它们不是孤立的——通过一套共同的信号系统（provenance、lifecycle state、ContextVar）互相感知、互相触发。

┌─────────────────────────────────────────────────┐
│                   Hermes Agent                    │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────────┐   │
│  │ Memory   │  │ Skills   │  │ Session      │   │
│  │ System   │  │ System   │  │ Search       │   │
│  │          │  │          │  │              │   │
│  │ 自动判断 │  │ Provenance│  │ FTS5 双索引  │   │
│  │ 冻结快照 │  │ 生命周期  │  │ cron 降权    │   │
│  │ 漂移检测 │  │ Auto-Patch│  │ 经验回溯     │   │
│  └────┬─────┘  └────┬─────┘  └──────┬───────┘   │
│       │             │               │            │
│       └─────────────┼───────────────┘            │
│                     │                            │
│              ┌──────┴──────┐                     │
│              │   Curator   │                     │
│              │             │                     │
│              │ 定期审查    │                     │
│              │ 合并重复    │                     │
│              │ 归档陈旧    │                     │
│              └──────┬──────┘                     │
│                     │                            │
│              ┌──────┴──────┐                     │
│              │Background   │                     │
│              │Review Fork  │                     │
│              │             │                     │
│              │独立 Agent   │                     │
│              │ContextVar   │                     │
│              │权限隔离     │                     │
│              └─────────────┘                     │
│                                                   │
│  ┌──────────────────────────────────────────┐    │
│  │           Safety Layer (全模块)            │    │
│  │  注入扫描 │ 漂移检测 │ 文件锁 │ 防死循环  │    │
│  └──────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

每个模块在后续文章中会详细展开。这里先给出一个整体对比：

能力	Hermes	Claude Code
持久记忆	MEMORY.md + USER.md，`§` 分隔纯文本 + 双态模型	CLAUDE.md，Markdown 格式
记忆自动判断	容量上限触发整理、三次失败自我降级	无——用户手动管理
技能创建	Agent 自动建议 + provenance 标记来源	用户手动编写
技能自动修复	使用时发现过时 → 立刻 auto-patch	用户手动修改
技能生命周期	active → stale → archived + pinned	存在 / 不存在
后台审查	Curator 独立进程定期运行	无
审查执行	Background Review Fork + 独立 ContextVar	无
会话检索	SQLite FTS5 双索引，支持全文搜索	无持久索引
安全防护	注入扫描 + 漂移检测 + 文件锁 + 三层防死循环	无系统级安全机制

三、Claude Code 缺了什么

Claude Code 是一个优秀的代码助手。它的 CLAUDE.md 机制让用户可以定义项目级偏好和自定义指令。但它的设计哲学是"被动响应"——所有行为都是对用户指令的回应。

它缺少的不是"能力"——是机制：

1. Provenance（来源追溯）

Claude Code 没有"这个配置是谁写的"的概念。它分不清哪些是你手动写的、哪些是它生成的。所以它不敢自动修改任何东西。

Hermes 用 created_by 字段 + ContextVar 运行时判断解决了这个问题。用户在对话中让 Agent 创建的技能 → created_by = null → curator 永不触碰。Background Review fork 自动创建的技能 → created_by = "agent" → curator 可以管理。

2. Curator（后台审查者）

Claude Code 按需启动，执行完退出。没有后台进程，没有定期审查。

Hermes 的 curator 是一个独立进程——有自己的状态文件（.curator_state）、调度周期、操作权限。它在用户不看的时候运行，扫描 agent-created 的技能，合并重复，归档陈旧。

3. Lifecycle（生命周期管理）

Claude Code 的技能只有两个状态：你用，或者你删。

Hermes 的技能有完整的状态机：active → stale → archived，加上正交的 pinned 锁定标志。curator 按时间阈值自动过渡状态。

4. Background Review Fork（独立执行环境）

Claude Code 没有独立的 fork 来执行 curator 的决策。所有操作都在前台对话上下文中。

Hermes 的 _spawn_background_review() 创建独立的 Agent 实例——有自己的 ContextVar、自己的工具调用上下文。这个 fork 的每一步操作都有运行时权限检查。

四、安全不是功能，是地基

一个自治系统天然比被动系统更"危险"——因为它会在你不看的时候自己做决定。所以 Hermes 的安全机制不是"可选的配置项"——它们是硬编码在读写路径上的。

注入扫描：写入时和加载时双层检测。即使磁盘文件被供应链攻击污染，恶意内容也进不了系统提示词。

外部漂移检测：如果其他进程直接修改了记忆文件，下一次 replace/remove 操作会检测到 round-trip 不匹配 → 拒绝写入 + 创建 .bak 备份。

文件锁：操作系统级排他锁，防止并发写入竞态。

防死循环：记忆整理失败 3 次 → 停止重试。Agent 最多 90 轮工具调用 → 强制停止。内置关键技能（如 plan）被硬编码保护 → curator 任何路径都无法触及。

这些安全机制默认开启，不可关闭。Hermes 的设计哲学是：安全不应该是用户的责任。

五、本系列文章结构

篇目	主题	核心源码
第二篇	记忆系统：容量上限如何触发自我整理	`memory_tool.py`
第三篇	技能系统：Provenance 追溯与生命周期管理	`skill_usage.py`、`skill_manager_tool.py`
第四篇	Curator 与 Background Review：后台自治的核心	`skill_provenance.py`、`.curator_state`
第五篇	安全架构：注入扫描、漂移检测与防死循环	`memory_tool.py`、`threat_patterns.py`
第六篇	Session Search：经验检索与 FTS5 双索引	`session_search_tool.py`、`hermes_state.py`
第七篇	开放透明设计：从配置到 API 请求的全链路	`config.yaml`、`transports/`、`plugins/`