自进化 Agent 诞生：Hermes 闭环学习架构总览
Hermes Agent 是目前唯一内置完整学习闭环的 AI 代理——从经验中创建技能，在使用中改进技能，主动持久化知识，搜索过往对话，跨会话构建对用户的深度理解。本文是这个深度解析系列的总览，分析其闭环学习架构的三根支柱和它们如何协同工作。
本文是「Hermes 自我进化机制深度解析」系列第一篇。
大多数 AI Agent 的问题不是不够聪明——而是每次对话都从零开始。
你花了半小时教 Agent 你的代码风格偏好，下一次对话它忘得一干二净。你纠正了它三次不要用 emoji，第四次它又开始加表情。这不是模型的错，是架构的缺陷：没有持久化的学习闭环。
Hermes Agent 由 Nous Research 构建，是目前少数真正实现了自进化闭环的开源 Agent。它的 README 开宗明义：
唯一内置学习闭环的智能代理——从经验中创建技能，在使用中改进技能，主动持久化知识，搜索过往对话，在跨会话中逐步构建对你的深度理解。
这不是营销话术。读完它的源码后，我认为 Hermes 的自我进化机制是当前开源 Agent 中设计最精巧的。这个系列就用五篇文章把它的进化机制拆干净。
什么是「自进化 Agent」？
先明确一下定义。一个自进化 Agent 需要满足三个条件：
- 经验持久化 — 跨会话保留知识，不会每次从零开始
- 主动学习 — 不需要用户显式说"记住这个"，能自己判断什么值得保留
- 渐进改进 — 技能和知识随使用越来越精准，而不是只增不减
大多数 Agent 框架止步于第一点（比如给 LLM 加一个向量数据库做 RAG）。Hermes 三点都做到了，而且做得非常克制——它清楚地定义了什么该学、什么不该学、什么时候该自动归档。
闭环学习架构：三根支柱
Hermes 的自我进化由三个子系统协同完成：
┌─────────────────────────────────────────────────┐
│ 用户对话 │
│ (每轮交互) │
└──────────┬──────────────────────┬────────────────┘
│ │
▼ ▼
┌──────────────┐ ┌─────────────────┐
│ 主对话循环 │ │ 后台审查代理 │
│ conversation │ │ background_ │
│ _loop.py │ │ review.py │
└──────┬───────┘ └────────┬────────┘
│ │
│ ┌────────┴────────┐
│ ▼ ▼
│ ┌─────────────┐ ┌──────────────┐
│ │ 记忆系统 │ │ 技能系统 │
│ │ memory_tool │ │ skill_manage │
│ │ │ │ skill_usage │
│ └──────┬──────┘ └──────┬───────┘
│ │ │
│ ▼ ▼
│ ┌──────────────────────────┐
│ │ 持久化存储 │
│ │ ~/.hermes/ │
│ │ ├── memories/ │
│ │ │ ├── MEMORY.md │
│ │ │ └── USER.md │
│ │ ├── skills/ │
│ │ │ ├── .usage.json │
│ │ │ └── <skill>/ │
│ │ │ └── SKILL.md │
│ │ └── sessions.db │
│ └──────────────────────────┘
│ ▲
│ │ 定期维护
│ ┌────────┴────────┐
│ │ Curator 策展人 │
│ │ curator.py │
│ └─────────────────┘
│
▼
下一轮对话时，
系统提示词自动加载
最新的记忆和技能
支柱一：记忆系统
记忆系统回答的问题是「你是谁、世界是什么样的」。
Hermes 维护两个持久化文件：
- MEMORY.md — Agent 对环境的观察（工具配置、项目约定、已知的坑）
- USER.md — Agent 对你的理解（沟通偏好、工作习惯、个人需求）
这两个文件在每次会话开始时作为系统提示词的一部分注入，会话中途可以修改但不会实时刷新（为了保护提示前缀缓存）。下一篇文章会深入拆解。
支柱二：技能系统
技能系统回答的问题是「这类事该怎么做」。
技能是 Markdown 文件（SKILL.md），存储在 ~/.hermes/skills/ 下。每个技能描述一类任务的完整做法——不只是步骤，还包括已知的陷阱、用户偏好和参考文档。
技能有自己的生命周期：active → stale → archived。代理使用技能时自动追踪使用频率，长期不用的技能会被 Curator 自动归档。
第三篇和第四篇文章会分别深入后台审查和技能进化。
支柱三：后台审查
后台审查是连接「经验」和「记忆/技能」的桥梁。
每一轮对话结束后，Hermes 会 fork 一个轻量级的审查代理（background review agent），让它回放对话并回答两个问题：
- 记忆方面：用户是否透露了值得记住的信息？（偏好、身份、工作方式）
- 技能方面：这次对话中有没有值得提炼的操作模式？（新技术、修正的工作流、被纠正的做法）
审查代理使用与主对话完全相同的模型和凭据，但工具权限被限制为只能操作记忆和技能。这样它既能利用已有的前缀缓存降低成本，又不会干扰主对话。
审查代理的设计哲学很有意思——它被明确告知"什么都不做是错失学习机会，而不是中性结果"（A pass that does nothing is a missed learning opportunity, not a neutral outcome）。但同时它也被严格限制不能捕获某些类型的"教训"（比如环境依赖的一次性错误），因为这些会变成持久的自我约束。
Curator：自动策展人
光有创建没有清理，技能库会变成垃圾堆。Curator 是 Hermes 的自动策展系统：
- 触发条件：代理空闲超过 2 小时，且距离上次策展超过 7 天
- 工作内容：合并重叠技能、归档过期技能、更新生命周期状态
- 安全边界：只操作代理创建的技能，绝不触碰内置技能、Hub 安装的技能或用户手动置顶的技能
没有这个机制，技能库会无限膨胀。
工作流：一次完整的学习闭环
让我用一个具体例子展示闭环是怎么转起来的：
第一轮对话
你第一次使用 Hermes，让它帮你调试一个 Python 项目。
你：帮我把这个项目的测试跑通
Hermes：（执行测试、修复代码、跑通）
对话结束后，后台审查代理启动：
- 记忆：用户在做 Python 项目，使用 pytest
- 技能：（暂无——太通用了不值得提炼）
第三轮对话
你：别用 print 调试，用 pdb
Hermes：好的，改用 pdb
后台审查捕获到：
- 记忆：用户偏好 pdb 而非 print 调试
- 技能：更新「Python 调试」技能，加入用户偏好
第十轮对话
你：帮我写一个 Flask API
Hermes：（加载 Python 调试技能，已经知道用 pdb）
一个月后
Curator 在空闲时运行，发现「Python 调试」技能 30 天没被用过——但用户偏好还在，所以它不会被归档（有用户偏好嵌入的技能不会被轻易归档）。
这就是闭环：使用 → 反思 → 提炼 → 持久化 → 下次使用时自动加载。
关键设计决策
读完源码后，我觉得 Hermes 做了几个非常值得注意的设计决策：
1. 冻结快照模式（Frozen Snapshot）
记忆在会话开始时注入系统提示词，会话中途修改记忆只写磁盘不更新提示词。这看似是个限制，实际上是为了保护提示前缀缓存——如果每次写入都重建系统提示词，Anthropic/OpenRouter 的缓存会全部失效，成本直接翻倍。
2. 反模式清单
审查代理被明确禁止保存以下类型的"教训"：
- 环境依赖的失败（缺少二进制、未安装包）
- 对工具的负面断言（"浏览器工具不好用"）
- 一次性错误（重试就好的那种）
- 一次性任务叙述（"帮我总结今天的市场"）
原因很深刻——这些"教训"会变成持久的自我约束。Agent 会引用自己几个月前写的"这个工具不好用"来拒绝使用已经修好的功能。
3. 前缀缓存共享
审查代理继承父代理的缓存系统提示词，字节级一致，这样它的 API 调用直接命中前缀缓存。根据 PR #17276 的分析，这带来了约 26% 的端到端成本降低。
Hermes Agent 是 Nous Research 的开源项目，代码在 github.com/NousResearch/hermes-agent。