03 | Hermes Agent 核心机制深度解析 —— 记忆系统、技能系统与自进化引擎

Hermes Agent 核心机制深度解析 —— 记忆系统、技能系统与自进化引擎声明：📝 作者：甜城瑞庄的核桃（ZMJ）原创学习笔记，欢迎分享，但请保留作者信息及原文链接哦～适合人群：已安装 Hermes Agent，想深度理解内部机制的开发者 / AI 工程师前置知识：完成安装与首次配置（第 2 篇）学习目标：透彻理解四层记忆系统的设计原理与各层职责掌握技能系统的完整生命周期（创建 → 复用 → 进化）了解闭环学习循环（Learning Loop）的四个驱动齿轮理解自进化引擎（DSPy + GEPA）的技术栈学会通过 AGENTS.md / SOUL.md 精准控制 Agent 行为📌版本说明：本文基于 Hermes Agentv0.10.0（2026.4.16），技术细节随版本迭代可能变化，如有出入请以 官方文档 为准。一、先理解问题：传统 Agent 的"失忆困境"在深入机制之前，先明确 Hermes Agent 要解决的根本问题。当前市面上绝大多数 AI Agent（包括 ChatGPT、Claude Code、GitHub Copilot，乃至早期版本的 OpenClaw）都是Stateless（无状态）的：痛点具体表现能力固化技能预先写死，遇到新问题每次从零推理体验割裂会话结束记忆归零，下次需要重新交代背景知识不积累相同的错误反复踩，没有经验沉淀机制模型绑定只能选用特定模型，迁移成本高Hermes Agent 的核心破局点是一个被称为“闭环学习循环（Closed Learning Loop）”的架构设计。它让 Agent 从“每次重来”变成“持续积累”：传统 Agent： 任务 → 执行 → 完成 → 遗忘 Hermes Agent：任务 → 执行 → 完成 → 总结 → 沉淀 → 复用 → 优化 → 再次任务 ...理解了这个根本区别，后面所有机制的设计动机就清晰了。二、四层记忆系统：从"金鱼"到"老友"Hermes Agent 的记忆架构借鉴认知科学中人类记忆的分层模型，将记忆划分为四层，每层职责不同、触发时机不同、存储位置不同：┌──────────────────────────────────────────────────────────────┐ │ Hermes Agent 四层记忆架构 │ ├──────────────────────────────────────────────────────────────┤ │ Layer 4: 冻结系统提示记忆 (Frozen Prompt Memory) │ │ ├── MEMORY.md（约2200字符）- 环境事实、项目信息 │ │ └── USER.md（约1375字符） - 用户画像、偏好设置 │ │ 特点：始终在线，每次会话自动注入，Agent 只读不写 │ ├──────────────────────────────────────────────────────────────┤ │ Layer 3: 工作记忆 (Working Memory) │ │ └── 当前对话的完整上下文窗口 │ │ 特点：实时读写，超长时自动压缩，会话结束后归档 │ ├──────────────────────────────────────────────────────────────┤ │ Layer 2: 情景记忆 (Episodic Memory) │ │ └── SQLite + FTS5 全文检索的历史会话索引 │ │ 特点：按需检索，回答"什么时候发生了什么" │ ├──────────────────────────────────────────────────────────────┤ │ Layer 1: 程序记忆 (Procedural Memory) │ │ └── ~/.hermes/skills/ 目录下的技能文件 │ │ 特点：方法论沉淀，回答"怎么做这件事" │ └──────────────────────────────────────────────────────────────┘2.1 Layer 4 —— 冻结系统提示记忆（始终在线）这是信息密度最高的一层，总字符上限3,575 字符（MEMORY.md ≈ 2,200 字符 + USER.md ≈ 1,375 字符），每次会话启动时自动注入系统提示，Agent 每次对话都带着这些信息开场。📄 MEMORY.md —— 环境事实记忆存储 Agent 自动提炼的项目和环境事实，适合放置"跨会话永远成立"的稳定信息：# 项目信息 - 项目位于 ~/code/myapi，使用 Rust + Axum + SQLx - 此机器运行 Ubuntu 22.04，已安装 Docker - 代码风格：Tab 缩进，120 字符行宽 - 已于 2026-01-15 将数据库从 MySQL 迁移到 PostgreSQL - 测试命令：cargo test --workspace📄 USER.md —— 用户画像记忆存储 Agent 从交互中自动学习到的用户偏好，适合放置"个人化偏好和沟通风格"：# 用户画像 - 回复语言：中文为主，技术术语保留英文 - 报告格式：Markdown，带二级目录 - 偏好工具：pip 用 uv 替代，npm 用 pnpm 替代 - 沟通风格：直接给结论，不要铺垫 - 常用技术栈：Python FastAPI + React + PostgreSQL⚠️关键设计约束：两个文件有严格字符上限，这是故意的。容量小，强迫 Agent 做策展而不是堆积。Agent 通过memory工具执行三种操作：add、replace、remove——当新信息比旧信息更重要时，主动替换而非追加。⚠️重要限制：会话中途对 MEMORY.md 或 USER.md 的修改，要到下一次会话才生效，不会影响当前对话。这避免了运行时记忆一致性问题，但也意味着长会话中 Agent 可能基于过时记忆工作。2.2 Layer 3 —— 工作记忆（实时上下文）工作记忆就是当前对话的完整上下文窗口。当对话过长接近模型 context 上限时，Hermes 会触发上下文压缩机制（agent/context_compressor.py）：压缩策略： 1. 保留头部（系统提示 + 第一轮对话） 2. 保留尾部（最近 20K tokens） 3. 用辅助 LLM 对中间部分进行有损摘要 4. 将摘要注入新的上下文窗口替代原内容这一机制使 Hermes 可以在理论上无限延长的会话中保持可用性，但需要注意：摘要是有损的，极细节的中间过程可能会丢失。2