当前位置：首页 > news >正文

Hermes Agent 技术深潜（三）：记忆系统与学习循环的完整源码解析

news 2026/4/15 9:25:08

本文是 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 tokens

MEMORY.md存储的是"环境事实"类信息，举几个典型例子：

项目位于 ~/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，带二级目录 § 偏好工具：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工具主动发起查询：

# 伪代码：session_search 工具的执行逻辑defsession_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. 将摘要注入当前上下文，而非原始内容returnsummary

这个两步走的设计很关键：先用 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.log

Hermes 出厂内置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 完整格式：

---name:daily-news-summarydescription:每日抓取指定来源的新闻，生成中文摘要并推送version:1.2.0platforms:[linux,macos]metadata:hermes:tags:[news,automation,telegram]category:productivityrequired_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 技能创建触发器

# 技能创建触发条件（满足任一即可）SKILL_CREATION_TRIGGERS=["工具调用次数 >= 5",# 复杂任务完成"从错误中恢复并找到有效路径",# 错误修复路径有价值"用户显式纠正了 Agent 行为",# 用户反馈是高质量信号"发现了非显而易见的工作流",# 新知识值得沉淀]# 创建后的技能文件立即可用# 注册为 slash command，下次会话自动出现在 Tier 0 索引

4.3 技能更新策略：Patch 优先于重写

当 Agent 在后续执行中发现更好的方法，更新技能时优先用 patch 而非全量重写：

# 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	实验性功能	研究用途

# 配置外部记忆提供商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 处理简单的单次任务，这个开销不值得。

八、调试与监控技巧

查看当前记忆状态

cat~/.hermes/memories/MEMORY.mdcat~/.hermes/memories/USER.md

查看技能库

hermes skills browse# 浏览所有技能hermes skills search"docker"# 搜索特定技能ls~/.hermes/skills/# 直接查看文件系统

查询历史会话

# 在 Hermes 对话中：hermes ❯ 搜索我上周关于 PostgreSQL 迁移的对话# Agent 会调用 session_search 工具，FTS5 检索后摘要返回

手动写入记忆（强制触发）

hermes ❯ 记住：我的主力项目在 ~/code/saas-dashboard， 使用 React + FastAPI，部署在 Railway（staging） 和 Hetzner VPS（production）

诊断工具

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