本文是 Hermes Agent 系列第三篇，面向想真正搞懂其"自我进化"底层机制的读者。我们将逐层拆解记忆系统架构、技能系统的四级加载策略、periodic nudge 的触发机制，以及学习循环的完整数据流。
阅读前置：建议先读完系列一（基础介绍）和系列二（实战部署），本篇直接进入架构细节。
一、为什么要认真研究它的记忆设计
大多数 AI Agent 的"记忆"其实是个伪命题：要么把所有上下文塞进 context window（烧钱且有上限），要么会话结束一清二白（等于没有）。
Hermes 的设计者显然认真研究过这个问题，最终给出的答案是：不同时效性的信息，用不同结构存储，用不同策略检索。
理解这套设计，你就理解了 Hermes 为什么能"越用越强"。
二、三层记忆系统全解剖
第一层：冻结系统提示记忆（Frozen Prompt Memory）
这是最核心的一层，包含两个文件：
~/.hermes/memories/
├── MEMORY.md # Agent 的工作笔记，上限 2200 字符 ≈ 800 tokens
└── USER.md # 用户画像与偏好，上限 1375 字符 ≈ 500 tokensMEMORY.md 存储的是"环境事实"类信息，举几个典型例子：
markdown
项目位于 ~/code/myapi，使用 Rust + Axum + SQLx §
此机器运行 Ubuntu 22.04，已安装 Docker（用户在 docker 组，无需 sudo）§
代码风格：Tab 缩进，120 字符行宽，Google docstrings §
已于 2026-01-15 将数据库从 MySQL 迁移到 PostgreSQL §
图片生成首选 fal.ai Nano Banana + Python/PIL 添加水印 §USER.md 存储的是"用户偏好"类信息：
markdown
回复语言：中文为主，技术术语保留英文 §
报告格式：Markdown，带二级目录 §
偏好工具：pip 用 uv 替代，npm 用 pnpm 替代 §
沟通风格：直接给结论，不要铺垫 §关键设计决策：为什么上限这么小？
2200 + 1375 = 3575 字符，合计约 1300 tokens。这个数字是故意收窄的，原因有两个：
-
前缀缓存稳定性：这两个文件在每次会话开始时以冻结快照（frozen snapshot）形式注入 system prompt。如果内容频繁变化，LLM 的 KV cache 就会失效，每次都需要重新计算，成本急剧上升。固定内容 + 固定格式 = 缓存命中率极高，省钱。
-
强制信息筛选：容量限制迫使 Agent 和用户都必须认真筛选哪些信息"值得占用这个空间"，而不是无脑堆砌。内存压力下，Agent 会自动执行压缩------由 LLM 判断哪些条目值得保留，哪些可以丢弃。
注意 ：会话中写入的新记忆立即持久化到磁盘，但不会出现在当前会话的 system prompt 里（因为是冻结快照），下次会话启动时才生效。这是个容易踩的坑。
安全防护：写入记忆前，系统会扫描内容是否包含注入/泄露模式（prompt injection、credential exfiltration、SSH 后门），以及隐形 Unicode 字符（常用于提示注入攻击）。匹配威胁模式的内容会被直接拒绝。重复条目也会被自动去重。
第二层：会话归档（Session Archive）
~/.hermes/state.db # SQLite 数据库，WAL 模式，FTS5 全文索引所有 CLI 会话和消息平台会话均存入这个数据库。没有容量上限，有用户反映连续运行数月、数千条会话后检索性能依然正常（FTS5 的全文检索在 10000+ 文档量级下约 10ms）。
检索机制：
Agent 不会自动把所有历史上下文都加载进来（那会把 context window 撑爆）。当它判断需要历史信息时，通过 session_search 工具主动发起查询：
python
# 伪代码：session_search 工具的执行逻辑
def session_search(query: str, limit: int = 5) -> str:
# 1. FTS5 全文检索，毫秒级响应
results = db.execute(
"SELECT content FROM sessions WHERE sessions MATCH ? LIMIT ?",
(query, limit)
)
# 2. 用 LLM 对检索结果做摘要，只保留与当前任务相关的部分
summary = llm.summarize(results, context=current_task)
# 3. 将摘要注入当前上下文，而非原始内容
return summary这个两步走的设计很关键：先用 FTS5 快速筛选相关会话，再用 LLM 压缩摘要，只有真正相关的信息才进入当前 context，既保证召回质量，又控制 token 消耗。
第三层：技能库（Skill Documents）
技能是 Hermes 记忆系统里最特殊的一层------它存的不是"发生了什么"，而是"怎么做某件事"。
~/.hermes/skills/
├── mlops/
│ ├── axolotl/
│ │ ├── SKILL.md # 主文档（必须）
│ │ ├── references/ # 参考资料
│ │ ├── templates/ # 输出模板
│ │ ├── scripts/ # 可调用脚本
│ │ └── assets/ # 补充文件
│ └── vllm/
│ └── SKILL.md
├── devops/
│ └── deploy-k8s/ # Agent 自动创建的技能
│ ├── SKILL.md
│ └── references/
└── .hub/ # Skills Hub 状态管理
├── lock.json
├── quarantine/
└── audit.logHermes 出厂内置 118 个技能（96 个核心 + 22 个可选），覆盖 22 个类别。社区 Skills Hub 还有大量第三方技能可安装。
三、四级渐进式加载策略（Progressive Disclosure）
这是 Hermes 技能系统最值得深究的工程设计。
核心问题：如果你有 40 个技能，每个技能文档平均 2000 tokens，全部加载 = 80000 tokens，一次对话的成本就废了。
解决方案：四级按需加载。
Tier 0（默认加载）：技能名称 + 简介索引
└── 约 3000 tokens，告诉 Agent"有哪些技能"
Tier 1（按需加载）：单个技能的完整 SKILL.md 内容
└── 仅当任务匹配时才加载，成本可控
Tier 2（深度加载）：references/ templates/ 等附属文件
└── 仅当技能执行需要详细参考资料时加载
Tier 3（脚本执行）：scripts/ 目录下的可执行脚本
└── 直接调用，不占用 context token过滤机制 ：技能加载前还会检查环境变量是否满足 required_environment_variables，缺失的密钥会提示用户交互式输入。没有平台或工具集限制的技能始终可见；有限制的技能（如仅限桌面端的浏览器自动化）在消息平台会话中自动隐藏。
SKILL.md 完整格式：
yaml
---
name: daily-news-summary
description: 每日抓取指定来源的新闻，生成中文摘要并推送
version: 1.2.0
platforms: [linux, macos]
metadata:
hermes:
tags: [news, automation, telegram]
category: productivity
required_environment_variables:
- TELEGRAM_BOT_TOKEN
- NEWS_API_KEY
---
# 每日资讯摘要
## 触发条件
当用户要求定期推送新闻摘要，或提到"每日简报"时。
## 执行步骤
1. 调用 News API 获取指定关键词的最新文章
2. 用 LLM 将英文内容翻译并压缩为 150 字中文摘要
3. 格式化为 Telegram Markdown 格式
4. 通过 gateway 推送至用户
## 已知坑点
- News API 免费版有 100 次/天限制，注意错误处理
- Telegram 消息长度上限 4096 字符，超长需分段发送
## 验证方法
检查 Telegram 是否收到格式正确的推送，包含标题、摘要和来源链接。四、学习循环的完整数据流
这是 Hermes 最核心的自进化机制，把上面所有组件串联起来。
4.1 Periodic Nudge（周期性反思触发器）
这是 Hermes 记忆系统的"自动驾驶"模块。
正常对话进行中
↓（每隔 nudge_interval 轮次）
系统级内部提示触发：
"回顾一下刚才发生了什么，有什么值得永久记住的吗？"
↓
Agent 扫描近期活动，做出判断：
┌─────────────────────────────────────────────────────┐
│ 值得写入 MEMORY.md？ │
│ → 环境配置、用户纠正、完成的重要事项、工作约定 │
│ │
│ 值得写入 USER.md？ │
│ → 用户偏好变化、沟通风格调整、工具倾向 │
│ │
│ 不值得记录？ │
│ → 临时路径、单次调试、已知常识、可随时搜到的信息 │
└─────────────────────────────────────────────────────┘
↓
写入磁盘，下次会话生效在 gateway 模式（消息平台接入）下，Nudge 还会在空闲超时前主动 flush，确保长时间运行的会话不丢失记忆。
v0.8.0 中，内存/技能的回顾从阻塞式 改为后台异步执行------每轮对话结束后在后台静默运行，只有发现重要内容时才打断用户。这避免了早期版本"对话被反思打断"的体验问题。
4.2 技能创建触发器
python
# 技能创建触发条件（满足任一即可）
SKILL_CREATION_TRIGGERS = [
"工具调用次数 >= 5", # 复杂任务完成
"从错误中恢复并找到有效路径", # 错误修复路径有价值
"用户显式纠正了 Agent 行为", # 用户反馈是高质量信号
"发现了非显而易见的工作流", # 新知识值得沉淀
]
# 创建后的技能文件立即可用
# 注册为 slash command，下次会话自动出现在 Tier 0 索引4.3 技能更新策略：Patch 优先于重写
当 Agent 在后续执行中发现更好的方法，更新技能时优先用 patch 而非全量重写：
python
# patch 模式：只传入旧字符串和替换内容
skill_manage(
action="patch",
skill_name="deploy-k8s",
old_str="kubectl apply -f deployment.yaml",
new_str="kubectl apply -f deployment.yaml --server-side"
)
# 而非：
skill_manage(
action="edit",
skill_name="deploy-k8s",
content="...整个文件内容..." # 容易破坏其他有效部分
)这不是随意的工程选择，背后有两个考虑：
- 安全性：全量重写容易把原来有效的部分一起覆盖掉
- Token 效率：patch 只传改动部分，消耗的 token 远少于整体重写
4.4 完整学习循环状态机
┌─────────────────┐
│ 用户发起任务 │
└────────┬────────┘
│
┌────────▼────────┐
│ 加载系统上下文 │
│ MEMORY.md │
│ USER.md │
│ 技能索引(Tier0)│
└────────┬────────┘
│
┌────────▼────────┐
┌────│ 执行任务循环 │────┐
│ └────────┬────────┘ │
│ │ │
需要技能时 │ ┌────────▼────────┐ │ 需要历史时
│ │ 工具调用 + 推理 │ │
│ └────────┬────────┘ │
│ │ │
┌─────────▼──┐ │ ┌────────▼──────┐
│ Tier1/2加载 │ │ │ session_search │
│ 完整SKILL │ │ │ FTS5 + LLM摘要 │
└─────────┬──┘ │ └────────┬──────┘
│ │ │
└─────────────▼─────────────┘
│
┌────────▼────────┐
│ 任务完成检查 │
│ ≥5次工具调用? │
│ 发现新路径? │
│ 用户纠正? │
└────────┬────────┘
是 / │ 否
┌────────▼────────┐
│ 自动创建/更新 │
│ SKILL.md (patch)│
└────────┬────────┘
│
┌────────▼────────┐
│ Periodic Nudge │
│ MEMORY.md更新 │
│ USER.md更新 │
└────────┬────────┘
│
┌────────▼────────┐
│ 下次会话更强 │
└─────────────────┘五、外部记忆提供商扩展层
内置记忆层是 Hermes 的基础，对于需要更强召回能力的用户，Hermes 提供了 8 个外部记忆提供商插件：
| 提供商 | 核心能力 | 适合场景 |
|---|---|---|
| Hindsight | 知识图谱 + 跨记忆反思合成，LongMemEval 评分 91.4% | 长期复杂知识积累 |
| Honcho | 辩证式用户建模（dialectic user modeling） | 深度个性化 |
| Mem0 | 语义搜索 + 自动事实提取 | 快速部署 |
| Supermemory | 跨设备同步 | 多机器使用 |
| RetainDB | 结构化知识存储 | 企业场景 |
| ByteRover | 向量检索 | 大规模文档库 |
| OpenViking / Holographic | 实验性功能 | 研究用途 |
bash
# 配置外部记忆提供商
hermes memory setup # 交互式选择并配置
hermes memory status # 查看当前激活状态外部提供商与内置记忆并行运行，不替换内置层。
Hindsight 为什么被推荐？
它是唯一具备 reflect 操作的提供商------跨所有存储记忆做横向合成，推导出更高层次的洞察，并更新知识图谱。其他提供商存储的是文本块，检索是近似匹配；Hindsight 存储的是结构化事实（实体 + 关系），检索是精确匹配。LongMemEval 基准测试中以 91.4% 排名第一。
六、agentskills.io 开放标准的意义
Hermes 的技能格式遵循 agentskills.io 开放标准，这不是一个无关紧要的技术选择。
agentskills.io 兼容的工具：
- Hermes Agent ✓
- Claude Code（Anthropic）✓
- OpenAI Codex ✓
- Cursor ✓
- 其他兼容代理 ✓这意味着：
- 技能可移植：在 Hermes 里积累的技能库，可以直接迁移到其他 Agent 工具
- 社区生态复用：从 skills.sh、GitHub、Skills Hub 安装的社区技能无需转换格式
- 长期价值积累：你的技能库不被任何单一工具厂商锁定
社区里已经有人在构建 PLUR 插件------让多个 Hermes 实例共享 engram（经验记忆），一个 Agent 做了修正，知识自动传播到共享同一项目的其他 Agent 实例。这是从个人工具向团队基础设施进化的关键一步。
七、记忆系统的已知局限与工程权衡
诚实地说，Hermes 的记忆设计不是完美的，有几处权衡值得理解：
1. 自动记忆不透明
内置记忆是 Agent 自主管理的，你无法完全知道它在什么时候记了什么、为什么记。如果你更偏好"完全可控"的方式，OpenClaw 的手动文件维护反而更透明。
解决方案 ：定期用 cat ~/.hermes/memories/MEMORY.md 检查内容，或安装 HERMES TUI Companion（社区工具，实时展示记忆状态）。
2. nudge_interval 的配置影响
如果会话很短或 nudge_interval 设置过长，某次会话里发生的重要事情可能不会被记录。不要假设"Agent 一定记住了某件事"。
解决方案：对重要事项显式告诉 Agent："记住这个------[内容]"，触发即时记忆写入。
3. 技能自动生成质量不稳定
Agent 有时会把某次特殊情况误归纳为通用技能，或者创建出逻辑有漏洞的流程。
解决方案 ：定期 hermes skills browse 审查技能列表，删除低质量技能。对重要场景，手写技能比自动生成更可靠。
4. 学习循环有约 15-25% 的 token 开销
Periodic nudge 和技能反思会消耗额外 token。如果你只是用 Hermes 处理简单的单次任务，这个开销不值得。
八、调试与监控技巧
查看当前记忆状态
bash
cat ~/.hermes/memories/MEMORY.md
cat ~/.hermes/memories/USER.md查看技能库
bash
hermes skills browse # 浏览所有技能
hermes skills search "docker" # 搜索特定技能
ls ~/.hermes/skills/ # 直接查看文件系统查询历史会话
bash
# 在 Hermes 对话中：
hermes ❯ 搜索我上周关于 PostgreSQL 迁移的对话
# Agent 会调用 session_search 工具，FTS5 检索后摘要返回手动写入记忆（强制触发）
bash
hermes ❯ 记住：我的主力项目在 ~/code/saas-dashboard，
使用 React + FastAPI，部署在 Railway（staging）
和 Hetzner VPS（production）诊断工具
bash
hermes doctor # 检查配置、依赖、记忆文件完整性
hermes memory status # 检查外部记忆提供商状态九、总结：Hermes 记忆架构的核心设计哲学
通读完整套系统，Hermes 记忆设计背后有几条一致的工程哲学：
1. 分层而非堆叠：不同时效、不同用途的信息用不同结构存储，而不是全往一个地方塞。热数据（常驻 prompt）、温数据（技能库按需加载）、冷数据（SQLite 全文检索）各司其职。
2. Agent 自主管理，而非用户手动维护：记忆的增删改由 Agent 自己判断，人工只在需要时介入修正。这是"自进化"的核心------人类不应该成为 Agent 进化的瓶颈。
3. 以 token 效率为约束设计一切：3575 字符的记忆上限、四级渐进加载、patch 优于重写------每一个设计决策背后都有明确的 token 成本考量。AI 能力的边界往往不是模型智商，而是 context 预算。
4. 开放标准，拒绝锁定：agentskills.io 兼容性、MIT 协议、模型无关------Hermes 在架构层面拒绝成为"围墙花园"。
这套架构放到 2026 年的 AI Agent 生态里，依然是目前最完整的"自进化"工程实现。
系列导航
- 第一篇：[Hermes Agent 深度解析：会自我进化的开源 AI 智能体]（基础介绍 + 核心特性）
- 第二篇：[Hermes Agent 进阶实战（下）]（部署配置 + 真实场景 + 竞品对比）
- 第三篇（本文）：技术架构深潜 --- 记忆系统与学习循环完整解析
参考资料
- Hermes Agent 官方文档 Memory 章节：https://hermes-agent.nousresearch.com/docs/user-guide/features/memory/
- 官方文档 Skills 章节：https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
- GitHub 仓库：https://github.com/NousResearch/hermes-agent
- agentskills.io 开放标准：https://agentskills.io
- Skills Hub（社区技能仓库）：https://hermeshub.xyz
如果你在实际使用中遇到了记忆系统的有趣行为，欢迎在评论区分享你的观察！技术理解往往需要实践来校验。👇