Hermes Agent 的自学习机制：Learning Loop、分层记忆与多模型编排

Hermes Agent 是 Nous Research 推出的开源 AI Agent 框架。它的定位不是再做一个只能聊天的大语言模型客户端，而是把 AI Agent 接到终端、消息平台、文件、网页和各种工具上，让它能真正执行任务。

AI Agent 指的是能够理解目标、调用工具、拆解步骤并执行任务的智能体。大多数 Agent 工具已经能做到“帮我跑命令”“帮我整理文件”“帮我调用浏览器”“帮我发消息”，但还有一个更麻烦的问题：一次任务结束以后，执行过程中学到的东西通常不会自动沉淀下来。

Hermes Agent 的重点正是这个问题。它想让 Agent 不只是完成一次任务，而是在使用过程中记住哪些路径有效、哪些错误修复过、哪些流程可以复用。官方给它的描述是 “the agent that grows with you”，也就是一个会和用户一起成长的 Agent。

Hermes Agent 解决的核心问题

OpenClaw 这类工具的优势是把 AI 从聊天框里拉出来，让它接入真实工作环境。比如连接 Telegram、飞书、Slack、Discord，执行终端命令，控制浏览器，处理文件，完成邮件和日程相关操作。

这类 Agent 的常见工作方式是：

flowchart LR
    A[用户提出任务] --> B[Agent 读取配置和提示词]
    B --> C[调用模型推理]
    C --> D[调用工具执行]
    D --> E[返回结果]
    E --> F[会话结束]

问题出在最后一步。会话结束以后，Agent 很可能不会自动把“这次任务为什么成功”“中间踩了什么坑”“下次该走哪条路径”保存成可复用经验。

很多工具可以通过配置文件、提示词、Skill 或手动总结来增强能力，但这些信息通常需要用户主动维护。Hermes Agent 的设计目标是让这件事进入 Agent 的底层循环：任务结束后自动判断是否值得学习，值得就沉淀为 Skill 或记忆，下次遇到类似任务再调出来。

可以把 Hermes Agent 理解成一套长期运行的个人 Agent 基础设施，而不只是一次性任务执行器。

flowchart TD
    U[用户 / 消息平台 / 命令行] --> G[网关层]
    G --> E[同步执行引擎]

    E --> M[记忆构建]
    M --> P[系统提示与上下文]
    P --> R[模型路由]
    R --> L[主 LLM 推理]
    L --> T[工具调用]

    T --> E
    E --> O[返回结果]

    E --> C[任务复盘]
    C --> S[Skill 生成或更新]
    C --> A[会话归档 / 用户画像]

    S --> M
    A --> M

    R --> X[辅助模型]
    X --> M
    X --> S

这张结构图里有几个关键模块：

Learning Loop：把一次成功经验变成可复用 Skill

Hermes Agent 最有辨识度的设计是 Learning Loop，也就是学习循环。

它不会把所有对话都保存成流程，而是在每次任务完成后做一次判断：这次执行过程是否值得沉淀？如果满足条件，就在本地生成或更新一个 Skill 文件。

触发条件很具体：

学习循环大致是这样的：

flowchart TD
    A[任务完成] --> B{是否满足学习条件}
    B -- 否 --> C[只保存普通会话记录]
    B -- 是 --> D[提取目标、步骤、工具调用和修复经验]
    D --> E{已有相关 Skill?}
    E -- 否 --> F[创建新的 Skill 文件]
    E -- 是 --> G[用 patch 更新旧 Skill]
    F --> H[保存到 ~/.hermes/skills]
    G --> H
    H --> I[后续任务按需加载]

Skill 文件保存在：

~/.hermes/skills

一个 Skill 至少要表达几类信息：

---
name: fix-node-build-error
description: 修复 Node.js 项目中常见的构建失败问题
tools:
  - shell
  - file_edit
---

# 适用场景

当 Node.js 项目执行构建命令失败，并且错误与依赖版本、锁文件或构建缓存有关时使用。

# 操作步骤

1. 读取 package.json，确认脚本命令和依赖版本。
2. 查看 npm、pnpm 或 yarn 的锁文件。
3. 清理构建缓存。
4. 重新安装依赖。
5. 再次执行构建命令。
6. 如果仍失败，提取错误日志中的第一个根因，而不是盲目重复安装。

# 注意事项

- 不要在没有确认的情况下删除用户源码文件。
- 删除 lock 文件前需要征得用户确认。

这个例子只是用来说明 Skill 的信息结构：名称、描述、适用场景、步骤、工具和注意事项。Hermes Agent 生成的 Skill 遵循 agentskills.io 开放标准，理论上可以被其他兼容 Agent 使用，比如 OpenClaw、Claude Code、Cursor 等。

更关键的是，Hermes Agent 不把 Skill 当成一次性生成的静态文件。后续任务中如果发现旧流程有问题，或者有更短、更安全的路径，它会修改已有 Skill。

修改时优先使用 patch，而不是整体重写。

这个选择很符合 Agent 的实际使用场景。自动生成内容最怕“为了修一个小问题，把原来正常的部分改坏”。patch 的粒度更小，错误面也更小。

四层记忆系统：不同信息放在不同位置

Agent 的记忆不能简单理解成“把所有内容都存起来”。如果什么都塞进上下文，模型很快就会被无关信息干扰；如果什么都不存，Agent 又无法长期学习用户习惯。

Hermes Agent 把记忆分成四层，每层负责一种信息。

常驻提示记忆：只放每次都需要的信息

第一层由两个文件组成：

MEMORY.md
USER.md

它们会在每次会话开始时加载。Hermes Agent 给这一层设置了 3575 个字符的上限，这个限制很重要：常驻记忆必须克制，只保存每次都需要的内容。

适合放在这一层的信息包括：

常驻记忆越短，Agent 每次启动时受到的干扰越少。真正只在特定任务中有用的信息，应该放到后面的检索层。

会话归档：用 SQLite 和全文索引保存历史

第二层是会话归档。Hermes Agent 会把每次对话写入 SQLite 数据库，并通过全文索引支持检索。

当 Agent 需要历史上下文时，它不会把整个数据库都塞进提示词，而是：

sequenceDiagram
    participant E as 执行引擎
    participant DB as SQLite 会话归档
    participant L as LLM 摘要
    participant P as 当前提示词

    E->>DB: 根据当前任务检索历史记录
    DB-->>E: 返回相关片段
    E->>L: 请求压缩和摘要
    L-->>E: 返回与当前任务相关的上下文
    E->>P: 注入精简后的历史信息

这套流程的重点是“检索后再摘要”。历史会话通常很长，直接注入会浪费上下文窗口，还会把无关内容带进来。先检索，再让 LLM（大语言模型）压缩，可以降低噪声。

Skill 文件：只加载描述，全文按需调入

第三层就是 Learning Loop 生成的 Skill 文件。

Hermes Agent 默认不会把所有 Skill 全文塞进系统提示里，而是只加载 Skill 的名称和简短描述。只有当前任务匹配到某个 Skill 时，才把完整内容调入上下文。

这个设计解决了一个很现实的问题：Skill 数量会增长。

如果有 40 个 Skill，每个全文都塞进上下文，成本还勉强能接受；如果增长到 200 个，全部加载就会拖慢速度、增加费用，还会干扰模型判断。只加载元信息，相当于先建立目录，真正用到时再翻开对应章节。

Honcho：长期用户画像

第四层叫 Honcho，是可选的用户建模层。它会在跨会话之间被动积累用户偏好、沟通风格和领域知识。

这一层适合长期个人助理场景，比如：

如果只是偶尔让 Agent 跑一次命令，Honcho 的价值不明显；如果把 Hermes Agent 当作长期助手，这一层会逐渐变得重要。

一条消息进入 Hermes Agent 后会发生什么

Hermes Agent 支持多种入口：命令行、Telegram、Discord、Slack、飞书等。无论消息来自哪里，最终都会进入同一套执行引擎。

完整链路可以拆成几步：

sequenceDiagram
    participant U as 用户
    participant G as 网关 / CLI
    participant E as 执行引擎
    participant M as 记忆层
    participant R as 模型路由
    participant L as 主模型
    participant T as 工具系统
    participant S as Skill / 归档

    U->>G: 发送任务
    G->>E: 转成统一消息格式
    E->>E: 生成任务 ID
    E->>M: 构建系统提示和上下文
    M-->>E: 返回常驻记忆、检索摘要、Skill 元信息
    E->>E: 复用缓存提示，检查上下文长度
    E->>R: 选择主模型和辅助模型
    R->>L: 发起推理
    L->>T: 调用工具
    T-->>L: 返回执行结果
    L-->>E: 生成回复
    E->>S: 写入会话归档，必要时更新 Skill
    E-->>G: 返回结果
    G-->>U: 展示回复

这里有两个细节很重要。

一个是系统提示缓存。构建上下文并不便宜，尤其当常驻记忆、Skill 元信息、历史摘要都要参与时，重复构建会浪费时间。Hermes Agent 会优先复用缓存版本。

另一个是上下文长度检查。发送给模型前，执行引擎会判断上下文是否接近上限，避免任务执行到一半才因为上下文过长失败。

Periodic Nudge：没有用户输入时也会复盘

Hermes Agent 不只在任务结束时学习。它还有一个 Periodic Nudge 机制，可以理解成周期性内部提醒。

在没有用户输入的情况下，系统会定期给 Agent 发一条内部提示，让它回顾最近操作，判断哪些内容值得写入记忆。

flowchart LR
    A[一段时间没有用户输入] --> B[系统触发内部提示]
    B --> C[Agent 回顾近期任务]
    C --> D{是否有可沉淀信息}
    D -- 否 --> E[不写入]
    D -- 是 --> F[更新记忆或 Skill]

这让 Hermes Agent 更像一个持续运行的系统，而不是只在用户提问时才工作的聊天窗口。它会在后台整理经验，但这也带来新的管理问题：自动记忆必须可审计，否则敏感信息可能被错误保存。

Auxiliary Models：主模型负责主任务，轻量模型处理侧任务

Hermes Agent 还有一个 Auxiliary Models 模块，用来处理“高频、重要、但不一定值得调用主模型”的侧任务。

这些任务包括：

默认情况下，辅助任务会自动检测并优先使用 Gemini Flash。用户也可以根据自己的模型供应商做配置。

这种设计的价值在于成本控制。主模型通常更贵、更慢，适合处理复杂推理和最终决策；辅助模型更便宜，适合处理大量边角任务。

flowchart TD
    A[用户任务] --> B{任务类型判断}
    B -- 复杂规划 / 最终决策 --> C[主模型]
    B -- 网页提取 --> D[辅助模型]
    B -- 图像分析 --> E[辅助模型]
    B -- Skill 匹配 --> F[辅助模型]
    B -- 记忆摘要 --> G[辅助模型]

    D --> H[结构化结果]
    E --> H
    F --> H
    G --> H
    H --> C
    C --> I[工具调用与回复]

Hermes Agent 支持的推理服务商范围比较广：

模型选择会影响 Agent 的稳定性、成本和速度。如果任务涉及企业数据或本地代码，是否允许把上下文发给第三方模型服务商，需要提前定好边界。

Hermes Agent 和 OpenClaw 的差异

Hermes Agent 经常被拿来和 OpenClaw 对比，因为两者都在做“把 AI 接入真实工具和消息平台”的事情。但它们的侧重点并不一样。

如果目标只是“在手机上给 AI 发消息，让它帮我跑几个命令”，OpenClaw 这类方案更轻。配置一个 SOUL.md，接上 Telegram 或其他网关，就可以完成很多任务。

如果目标是“让 Agent 在三个月后比第一天更懂我的工作流”，Hermes Agent 的学习循环和分层记忆更合适。它不是单纯减少配置，而是把长期积累能力做进系统结构里。

上手 Hermes Agent 需要准备什么

Hermes Agent 支持 Linux、macOS、WSL2 和 Android Termux。

Windows 需要通过 WSL2 运行。WSL2 是 Windows Subsystem for Linux，也就是 Windows 上的 Linux 兼容环境。Hermes Agent 不支持原生 Windows 环境，直接在 Windows 终端里安装通常不是推荐路径。

安装过程会处理多种依赖，包括：

正式安装命令应以官网为准：

# 官网
https://hermes-agent.nousresearch.com

安装前可以先检查基础环境：

python3 --version
node --version
rg --version
ffmpeg -version

安装完成后，需要完成几件事：

flowchart TD
    A[安装 Hermes Agent] --> B[选择模型服务商]
    B --> C[配置主模型]
    C --> D[配置辅助模型或使用默认策略]
    D --> E[选择入口：CLI / Telegram / Discord / Slack / 飞书]
    E --> F[执行真实任务]
    F --> G[检查 ~/.hermes/skills]
    G --> H[审查自动生成的 Skill 和记忆]

比较稳妥的使用方式是从低风险任务开始，例如整理文件、总结公开网页、生成脚本草稿、检索项目文档。等确认工具权限、记忆写入和模型路由都符合预期，再接入更关键的生产环境流程。

什么场景适合 Hermes Agent

Hermes Agent 更适合“重复、复杂、会变化”的任务，而不是一次性的问答。

使用 Hermes Agent 时要注意的坑

自动记忆需要审计

Hermes Agent 会自动沉淀记忆和 Skill，这带来便利，也带来风险。API key、客户数据、内部地址、访问令牌、未公开代码路径都不应该被随意写入长期记忆。

建议定期检查：

ls ~/.hermes/skills

同时关注常驻记忆文件和会话归档，避免敏感信息长期留存。

Skill 不是生成出来就永远正确

自动生成的 Skill 可能只适合当时的项目结构、依赖版本或工具环境。环境变化后，旧 Skill 可能会误导 Agent。

对高风险流程，最好把自动生成的 Skill 当成草稿，人工检查后再让它长期使用。

工具权限要分级

Agent 一旦能操作终端、浏览器、文件系统和消息平台，就不能只按“聊天机器人”的安全标准看待它。

更安全的做法是：

多模型编排会带来一致性问题

主模型和辅助模型分工可以降低成本，但不同模型对同一内容的理解可能不完全一致。对于强一致性要求高的任务，比如法律、财务、合规审查，不应完全依赖自动路由，需要固定模型和审计链路。

Windows 用户需要接受 WSL2 成本

Hermes Agent 不支持原生 Windows。使用 Windows 的开发者需要先配置 WSL2，再在 Linux 环境里安装和运行。这比普通桌面软件复杂，排错时也要同时考虑 Windows、WSL2 和 Linux 依赖。

Hermes Agent 的价值边界

Hermes Agent 的真正价值，不在于“又多了一个能聊天的 AI 工具”，而在于它把任务执行、经验沉淀、记忆检索和技能更新连成了闭环。

它适合长期运行，也适合那些会不断重复但又不断变化的工作流。每一次纠错、每一次绕路成功、每一次复杂工具调用，都可能成为下次任务的起点。

代价也很清楚：系统更复杂，安装和维护成本更高，自动记忆需要审计，工具权限需要安全边界，多模型路由也要考虑成本和一致性。

如果只需要一个轻量 AI 助手，简单 Agent 工具已经够用；如果需要一个能从日常任务中积累经验的开源 Agent 基础设施，Hermes Agent 的 Learning Loop、四层记忆和辅助模型编排，提供了一条很有代表性的路线。