现在的 Agent 已经很会“做事”了：调用终端、修改文件、浏览网页、连接外部服务，甚至把任务分给多个子 Agent 并行完成。
但这也暴露出一个更根本的问题：如果一次任务中形成的经验不能进入下一次任务，那么 Agent 无论完成过多少工作，下次仍然可能从头摸索。
Hermes 真正想解决的，正是这件事。
Hermes 首先是一个长期运行的 Agent
Hermes 的 README 把自己定义为 self-improving AI agent。不过，自我改进并不是它唯一的组成部分。README 首屏列出的重点能力还包括：
- 跨入口持续对话：支持 CLI、Telegram、Discord、WhatsApp、微信等入口
- 无人值守运行：使用内置 Cron 执行定时任务
- 并行处理任务：创建隔离的子 Agent，拆分多个工作流
- 跨环境执行：可在 Local、Docker、SSH、Singularity、Modal、Daytona 和 Vercel Sandbox 等环境中执行命令
- 模型供应商无关：可在 Nous Portal、OpenRouter、OpenAI 和自建模型接口之间切换
这些能力共同构成了 Hermes 的底座：它不是一个只在当前窗口中回答问题的聊天应用，而是一个可以长期驻留、跨入口工作并持续保存状态的 Agent runtime。
可真正让这个运行时形成长期价值的，则是下一层——学习闭环。
所谓“学习”，不是训练模型权重
Hermes 不会因为完成一次任务，就自动微调底层大模型。 它的学习发生在模型之外，主要沉淀为两类可持久化信息：
- Memory：用户是谁、喜欢什么、当前处于什么状态
- Skill：以后遇到这一类任务，应该按照什么方法完成
例如，用户说“分析源码时必须讲证据”，可以被拆成两种知识：
- 记忆：这个用户重视有出处的结论
- 技能：分析项目时，应引用具体文件和实现位置，并区分 README 宣传、代码注释和真实运行路径
两者看起来接近，作用却不同。Memory 描述的是人与状态，Skill 保存的是可复用的做事方式。
对话之后，另一个 Agent 开始复盘
Hermes 的核心流程可以简化为：
正常对话与工具调用
↓
回答先交付给用户
↓
复制当前会话快照
↓
后台启动受限的 Agent fork
↓
判断哪些内容值得长期保存
├─ 用户、偏好、状态 → Memory
├─ 方法、纠正、工作流 → Skill
└─ 没有长期价值 → Nothing to save
↓
写入记忆或技能库，供后续会话复用源码中的 agent/background_review.py 对这个机制给出了直接说明：一轮对话完成后，系统可以启动 daemon thread，重放会话快照，并询问一个派生出来的 Agent：“是否应该保存或更新某项记忆与技能？”
这意味着学习过程具有几个特点：
- 回答后运行：它发生在主回答交付之后，不阻塞用户当前任务
- 上下文隔离：它阅读的是会话快照，不直接修改正在进行的聊天上下文
- 模型语义判断：它不是依靠关键词或固定正则抽取
- 受控工具写入：它通过
memory和skill_manage完成持久化 - 允许不写入：如果没有值得长期保存的内容，可以选择
Nothing to save
于是问题自然变成：它会不会每聊一句就启动一次昂贵的后台模型？
学习不是每轮无条件执行
Hermes 为记忆和技能设置了不同的触发节奏。
Memory 按用户对话轮数累计
内置记忆默认每 10 个用户回合触发一次复盘。 计数会随着会话历史恢复，因此恢复旧 Session 后不会完全重新计算。
适合进入 Memory 的内容包括：
- 用户身份与长期目标
- 稳定的表达和格式偏好
- 用户期望 Agent 遵循的协作方式
- 值得跨会话保留的项目或运行状态
此外，Hermes 还支持插件式外部 Memory provider。外部后端可以在每个完成的回合后同步信息，这与周期性的内置 Memory 复盘是两条不同路径。
Skill 按工具循环次数累计
技能复盘默认也以 10 为阈值，但计数单位不是用户说了多少句话，而是 Agent 经历了多少次工具调用循环。
这个设计让触发概率与任务复杂度更接近：
- 普通闲聊很少形成新技能
- 一次复杂排障可能在一个用户回合内调用十几次工具
- 只要达到阈值，本轮结束后就能立即进入技能复盘
因此，Hermes 并不是定时把全部聊天机械地改写成 Skill，而是优先在真正经历了复杂执行过程之后复盘。
一个 Skill 是怎样形成的
后台 Agent 会寻找几类明确的学习信号：
- 用户纠正了回答风格、格式或详略程度
- 用户纠正了工作流程、判断方式或步骤顺序
- 任务中出现了可复用的调试方法、修复技巧或工具组合
- 本次加载的已有 Skill 被证明缺少步骤或已经过时
- 用户明确要求记住一种以后仍应遵循的做法
但发现信号不代表立即创建一个新文件。Hermes 规定了优先顺序：
- 优先更新本次实际使用过的相关 Skill
- 其次补充已有的同类“伞状技能”
- 再次沉淀具体案例到现有 Skill 的
references/、templates/或scripts/ - 最后才新建类别级 Skill，而且仅限现有技能都无法覆盖时
这项规则决定了技能库能否长期使用。 否则每次任务都创建一个技能，最终得到的只会是一堆诸如“修复今天这个错误”“分析某个 PR”的一次性文件，而不是能在未来复用的方法库。
自动改进不等于可以随意改写
后台复盘 Agent 的权限受到严格限制。 它默认只能读取技能、搜索相关文件，以及使用 Memory 和 Skill 管理工具，不能借学习之名随意执行终端命令或修改项目源码。
技能本身也有所有权边界。后台机制默认不能修改：
- Hermes 随项目提供的内置技能
- 从 Skills Hub 安装的技能
- 外部目录中的技能
- 用户手工编写、尚未交给 Curator 管理的技能
- 用户明确固定的 pinned 技能
修改已有 Skill 前，后台 Agent 还必须在当前复盘中重新读取它。这条 read-before-write 规则可以避免模型凭借会话中的旧版本直接覆盖文件。
用户还可以开启技能写入审批。开启后，自动修改只会生成待审变更，用户查看 diff 后再批准或拒绝。技能变更默认还会记录修改前后的哈希，并保存可供回滚的内容。
这就引出了另一个容易被忽略的问题：如果模型把一次偶发失败当成永久规律，学习本身是否会变成污染？
Hermes 刻意不学习什么
后台复盘提示明确排除了一些内容：
- 当前机器缺少依赖或尚未配置凭证
- “某工具不能使用”之类可能很快过时的负面判断
- 重试后已经消失的临时故障
- 只适用于当天任务的一次性叙述
- 最终没有找到有效方法的失败尝试
尤其是最后一点：如果任务并未解决，就不能把一串失败步骤包装成“可靠工作流”。 真正应该保存的是经过验证的方法，而不是听起来像经验的猜测。
为什么要派生 Agent，而不是直接改主对话
后台复盘使用独立 Agent fork，还有两个重要原因。
- 隔离上下文：复盘提示和模型输出不会写进用户的真实 Session，避免下一轮把“请检查并更新技能”误认为用户的持续要求
- 复用缓存：使用相同模型时，fork 会尽量保持 system prompt、工具定义和推理配置一致，从而复用主会话已经建立的 prompt cache
如果用户为后台复盘指定了另一个更便宜的模型，Hermes 则会生成会话摘要交给它，而不是把完整冷上下文全部重新发送。
因此，这个学习闭环并不是简单地“再请求一次模型”。它同时处理了：
- 触发时机
- 对话隔离
- 工具权限
- 写入所有权
- Prompt Cache 成本
- 变更审批与回滚
- 后续技能维护
这是不是 Hermes 最核心的特性
如果把“核心”理解为最有辨识度的产品能力，答案是肯定的。README 也把 self-improving 和 closed learning loop 放在最前面。
但如果把“核心”理解为完整系统，就不能只看后台学习。Hermes 的整体结构更接近：
- Agent runtime 负责模型循环、工具调用与上下文管理
- Gateway 让同一个 Agent 出现在不同聊天入口
- Session 与 Memory 负责跨会话连续性
- Cron 负责无人值守运行
- 子 Agent 负责隔离与并行执行
- Skill 负责沉淀可复用的方法
- Background Review 把一次任务的经验送入下一次任务
学习闭环之所以重要，正是因为其他部分让它有地方发挥作用。 没有长期会话和持续运行环境，沉淀的经验很难形成复利；没有技能加载和权限边界，所谓学习又很容易变成上下文污染。
最后：Hermes 学到的究竟是什么
Hermes 的底层模型没有因此改变。发生变化的是模型下一次工作时能够读取的外部状态。
它所建立的不是新的神经网络参数，而是一个逐渐丰富的个人知识与方法层：
- Memory 让 Agent 更了解用户
- Session Search 让 Agent 找回过去发生过什么
- Skill 让 Agent 记住以后应该怎样做
- Curator 继续整理、归并和淘汰自动生成的技能
所以，对 Hermes 最准确的概括并不是“一个会自动写 Skill 的聊天机器人”，而是：
一个长期运行的 Agent，在完成现实任务的同时，通过受控的后台复盘，把对用户的理解沉淀为记忆，把解决问题的方法沉淀为技能，并在后续会话中继续复用。
这也是它区别于一次性 Agent 的地方：任务结束了，但经验没有跟着会话一起消失。