Hermes Agent 为什么火：持久记忆与自学习 Agent 的想象力

为什么我们总在重复解释同一件事

我用 AI 助手写了大半年代码，发现一个规律：每次新开一个会话，它都会忘掉上次的偏好。我说过「项目用 pnpm」「回复用中文」「测试不要 mock 网络请求」，这些话重复说了几十遍。更麻烦的不是单个偏好，而是一整套工作习惯——代码风格、提交规范、目录边界、review 关注点。这些东西不是 Prompt 里写几句就能覆盖的，它们需要在几十次、上百次协作中逐步沉淀。

Hermes Agent 在 2026 年初发布后快速获得关注，核心原因就在这里。它不是一次会话里的问答助手，而是一个试图「记住用户是怎么工作的」系统。Nous Research 在 MIT 协议下开源了这个项目，截至 6 月已经累积了超过 20 万颗 Star 和 18 个正式版本，最新的是 v0.17.0。它的核心卖点是「closed learning loop」——完成任务后自动提取经验，生成可复用的 Skill，并在后续使用中持续改进。

这个方向不是 Hermes 独创的。LangChain 在 2026 年 4 月发表的博客中，把 Agent 持续学习拆成了三个层次：模型层（权重更新）、工具框架层（Harness 代码迭代）和上下文层（记忆与 Skill）。Hermes 主要发力在上下文层，用记忆文件和 Skill 文件来承载学习成果。这条路线的好处是不需要微调模型，所有学习产物都是人类可读、可编辑的文本文件。

LangChain 的三层学习框架

理解 Hermes 的设计选择，需要先看清 Agent 学习这件事的完整图景。Harrison Chase 在 LangChain 的博客里提出了一个实用的分层模型，把 Agent 能从经验中学到的东西分成三层：

大多数团队能立刻用的是第三层。模型层需要训练资源，工具框架层需要对编排代码有深入理解，而上下文层的学习产物就是几个 Markdown 文件。Hermes 的 MEMORY.md 和 USER.md 存事实记忆，Skills 目录存操作手册，全部是纯文本。可以用 Git 追踪每次变更，也可以随时手动编辑或删除某条记忆。

这种设计还支持多粒度的作用域。LangChain 的文章特别提到，上下文层的学习可以同时在 Agent 级（全局配置）、用户级（个人偏好）和组织级（团队规范）展开。Hermes 用项目目录下的上下文文件实现了类似效果——同一个 Agent 在不同项目中加载不同的记忆和 Skill，不需要在模型层面做任何区分。

更新时机也分两种：离线批量（在后台分析历史 Trace，提取经验后合并进记忆）和实时写入（任务过程中发现新偏好立刻保存）。Hermes 采用的是「Agent 主动 + 定期提醒」的混合策略，它在完成任务后会主动判断是否有值得保存的内容，同时内置了周期性整理机制。

Hermes 的自学习闭环

Hermes 的学习循环可以拆成五个阶段。这不是一步到位的自动训练，而是一个有人工校验节点的渐进积累过程：

这套循环的关键设计点在于「候选」和「确认」之间的缓冲带。Agent 从经验中提取的 Skill 不是立刻变成永久规则，而是先进入一个可审查状态。Google Research 在 2026 年 4 月发表的 ReasoningBank 工作中也得出了类似结论：Agent 从成功和失败中提取的推理策略，需要经过「泛化验证」才能成为可靠的长期知识。

Hermes 用文件系统而不是数据库来存储这些学习产物，降低了解释成本。可以像 review 代码一样 review Agent 的记忆变更——哪条记忆是什么时候因为什么任务写入的，改了哪些内容，一目了然。

案例一：记忆分层防止信息污染

记忆系统最容易翻车的地方，是把临时信息当成长期事实。我在早期使用类似系统时遇到过：一次调试中 Agent 帮我排查了一个数据库连接池问题，之后每次提到数据库操作，它都会建议「检查连接池配置」。事实上那个项目的连接池配置没有任何问题，真正的原因是上游服务的限流策略。

这个问题的根源在于 Agent 没有区分记忆类型。Trajectory-Informed Memory Generation 那篇论文（2026 年 3 月发表于 arXiv）对此做了更系统的分析：如果 Agent 把失败恢复过程中的临时策略当作通用规则保存，后续遇到相似但不同的任务时，这些「伪经验」反而会成为干扰。

解决方案是把记忆按生命周期和稳定性分层：

# ❌ 坏做法：所有记忆平铺在一个文件里
memory:
  - 用户偏好中文回复
  - 当前项目使用 pnpm
  - 2026-06-15 排查了数据库连接池超时
  - 用户今天要先修搜索 bug
  - Node.js 版本是 22
 
# ✅ 好做法：按稳定性分层存储
# memory/stable.yaml — 长期不变更
stable:
  - 用户默认使用简体中文交付
  - 项目使用 pnpm + Turborepo
  - Node.js 版本 22+
 
# memory/session.yaml — 会话级，任务结束清理
session:
  - 今天优先修搜索 bug
  - 数据库超时是上游限流导致，非连接池问题
 
# memory/project.yaml — 项目级，跟随仓库
project:
  - 测试文件放 apps/tests/
  - 环境变量读取走 apps/src/config/env/

分层之后，Agent 在开始新任务时只加载稳定偏好和项目事实，会话临时记忆不参与后续推理。这样就不会因为上一次排查数据库超时，就在下一次数据库相关任务中反复提及连接池。

案例二：Skill 设计中的粒度陷阱

Hermes 的 Skill 系统和记忆是互补的。记忆描述「用户或项目是什么样」，Skill 描述「遇到某类任务怎么做」。这个区分看起来简单，实际落地时经常混淆。

我见过的一种典型问题是 Skill 写得太宽泛。比如有人让 Agent 在修复了一个 React 组件的 memo 问题后，自动生成了一个 Skill：「React 组件性能优化」。这个 Skill 覆盖了 memo、useMemo、useCallback、虚拟列表、代码分割等几乎所有优化手段，结果后续每次提到 React 组件，Agent 都会把这整套方案列出来，反而增加了阅读成本。

arXiv 上那篇 Trajectory-Informed Memory Generation 论文对此给出了「提取粒度」的概念——子任务级（subtask-level）的提取比任务级（task-level）的提取更有跨任务复用价值。论文实验数据也证实了这一点：子任务级提取在任务目标完成率上比任务级高出 1.8 个百分点，在场景目标完成率上则高出 6.7 个百分点。

# ❌ 坏做法：Skill 粒度过宽
skill:
  name: React 组件性能优化
  description: 优化 React 组件性能
  content: |
    1. 检查是否需要 React.memo
    2. 检查是否需要 useMemo
    3. 检查是否需要 useCallback
    4. 考虑虚拟列表
    5. 考虑代码分割
    6. 考虑 SSR/SSG
    # 问题：每次都全量列出，没有聚焦
 
# ✅ 好做法：Skill 聚焦于可复现的具体场景
skill:
  name: React 列表组件重渲染排查
  description: 当列表组件因父级状态变化导致不必要的重渲染时
  trigger: 列表组件 + 父组件频繁 setState + 列表项未变化
  content: |
    1. 确认重渲染来源：React DevTools Profiler 看哪些 props 变了
    2. 对列表项组件加 React.memo，比较 memo 前后渲染次数
    3. 如果列表项内部有回调函数传给父级，用 useCallback 稳定引用
    4. 如果列表项接收对象/数组 props，用 useMemo 或拆分为原始类型
    # 精确到场景，不做无关展开

好的 Skill 应该像一本手册里的某个章节：有明确的适用条件、有具体的操作步骤、有清晰的退出标准。如果一条 Skill 在任何任务中都能被「部分命中」，那它大概率太宽泛了。

案例三：反馈循环中的人工校验节点

自学习系统最危险的操作，是跳过人工校验直接把经验写入长期记忆。ReasoningBank 框架在这方面的设计值得参考：它要求 Agent 从执行轨迹中提取三类学习产物——策略型（Strategy，从成功执行中提取有效模式）、恢复型（Recovery，从失败后恢复中提取修正路径）和优化型（Optimization，从「完成但不够好」的执行中提取效率改进）。这三种产物都需要经过验证才能成为正式知识。

我在实际使用中碰到的问题是：Agent 帮我重构了一个工具函数，过程中它把三个小 helper 合并成了一个通用函数。结果不错，它就把「合并小 helper 为通用函数」记成了偏好。之后每次我写新的工具函数，它都建议我先写小 helper 再合并——而我大多数时候根本不需要这个步骤。

# ❌ 坏做法：跳过校验直接固化经验
def on_task_complete(task, result):
    # Agent 认为「合并 helper」是好模式，直接写入长期记忆
    if result.quality_score > 0.8:
        memory.save(
            type="preference",
            content="优先合并小 helper 为通用函数",
            # 问题：一次成功不代表这是通用偏好
        )
 
# ✅ 好做法：写入候选区，需要多次确认或人工审批
def on_task_complete(task, result):
    if result.quality_score > 0.8:
        # 先写入候选记忆，附带来源任务 ID
        candidate_memory.save(
            type="preference_candidate",
            content="在该场景下合并 helper 有效",
            source_task_id=task.id,
            confirmation_count=1,  # 只出现过一次
        )
    # 同一模式出现 3 次以上才自动提升为正式记忆
    candidates = candidate_memory.find_similar(content, min_count=3)
    if candidates:
        memory.promote(candidates)
        candidate_memory.archive(candidates)

LangChain 的文章把这种设计称为「显式与隐式」的权衡：隐式更新（Agent 自己决定写什么）效率高但可控性差，显式更新（需要人工触发或确认）更安全但会打断工作流。Hermes 选择了偏隐式的路线，同时保留了用户随时查看和编辑记忆文件的能力，算是一种务实折中。

自学习闭环中的反思机制

上面三个案例都涉及一个共同的主题：Agent 需要能反思自己的执行过程。Reflexion 框架（Shinn et al., 2023）最早系统化了这个思路——它让 Agent 在每次执行后用自然语言写下自我评估，指出哪些步骤有效、哪些步骤多余、哪些步骤缺失。这些反思文本会被注入到下一次执行的 Prompt 中，作为额外的上下文。

Hermes 的自评估环节在理念上与此类似，但实现路径不同。它不依赖单独的「反思模型」来生成评估文本，而是通过 Skill 自改进机制来实现——当一个 Skill 在后续任务中表现不好时，Agent 会修改这个 Skill 的内容。这本质上是用「修改操作手册」代替了「生成反思文本」，好处是学习产物直接变成了可执行指令，坏处是缺少了对失败原因的显式分析。

从 LangChain 三层框架的角度看，这两种方式分属不同层次。Reflexion 的反思文本属于上下文层的实时注入，每次任务都需要从历史中检索相关反思；Hermes 的 Skill 自改进属于工具框架层的 Harness 迭代，修改一次就对所有后续任务生效。两者并不矛盾，但在设计时需要明确选择。

从研究到落地：适用场景与风险边界

自学习 Agent 的价值来自长期使用后的积累。它在以下场景中回报最明显：

但在以下场景中，早期阶段不建议直接使用：

• 生产环境自动化操作：Agent 的记忆如果包含过时的部署配置或错误的回滚步骤，自动执行可能造成实际损害。
• 多人共享的 Agent 实例：A 用户的偏好可能和 B 用户的偏好冲突，记忆隔离不到位会互相污染。
• 涉及敏感数据的任务：记忆文件中可能包含客户数据片段或内部 API 地址，需要有分级存储和访问控制。
• 需要审计追踪的合规场景：Agent 的记忆变更需要完整的审计链，文件系统级别的记忆目前缺少原生的版本化审计能力。

Hermes 在这方面提供了一些基础设施：命令审批系统（command approval）防止 Agent 执行未授权操作，DM 配对机制限制谁能和 Agent 交互，容器隔离确保 Agent 操作不会影响宿主系统。但这些是安全层面的防护，不能完全替代记忆治理。

落地检查清单

如果打算在自己的项目中引入自学习 Agent，以下清单按实施阶段分组。每一条都是可执行的动作，不是原则性建议。

第一阶段：初始化配置

• 创建独立的记忆目录（如 agent-memory/），用 Git 追踪变更历史
• 按稳定性分三类文件：stable.yaml（长期偏好）、project.yaml（项目事实）、session.yaml（会话临时）
• 在 Agent 的基线指令中明确「session 级记忆不参与后续任务推理」
• 关闭或限制 Agent 的自动记忆写入，先用候选缓冲模式运行一周

第二阶段：Skill 建设

• 为前 5 个高频任务手动编写初始 Skill（不要等 Agent 自动生成）
• 每个 Skill 必须包含 trigger 字段，明确什么条件下激活
• Skill 粒度控制在「一个具体场景对应一套操作步骤」，避免宽泛的知识列表
• 建立 Skill 审查节奏：每两周 review 一次 Agent 新增或修改的 Skill

第三阶段：反馈循环

• 设定反馈收集节点：任务完成后由 Agent 输出简要自评估
• 前两周每天花 5 分钟 review Agent 的记忆变更（Git diff 即可）
• 建立「记忆晋升」规则：同一模式出现 3 次以上才从候选提升为正式
• 定期清理：每月检查一次稳定记忆中是否有过时内容

第四阶段：扩展与治理

• 多人使用时配置记忆隔离：每个用户或项目独立的记忆空间
• 敏感信息过滤：在记忆写入前检查是否包含 API Key、密码、客户数据
• 记忆回滚能力：确保可以通过 Git revert 撤销任何一次记忆变更
• 定期对照检查 Agent 的记忆是否和项目实际情况一致（特别是技术栈版本、目录结构等易变信息）

自学习 Agent 的边界在哪

Hermes Agent 在 2026 年引发的关注，本质上映射了开发者对 AI 助手的一个核心期待：不要每次都从零开始。无论是 Hermes 的 Skill 自改进、ReasoningBank 的经验蒸馏，还是 LangChain 提出的三层学习框架，都在尝试回答同一个问题——Agent 怎么把一次性的任务执行变成长期的能力积累。

但自学习不等于自动变好。记忆污染、Skill 退化、反馈偏差，这些问题不会因为加了一个学习循环就消失。我观察到的一个规律是：自学习系统的效果和使用者的审查投入成正比。花时间在记忆治理和 Skill 维护上的团队，Agent 越用越顺手；完全交给 Agent 自主管理的，半年后记忆文件里堆满了过时信息和矛盾结论。

Hermes 的设计选择——纯文本记忆、文件系统存储、Git 友好——至少保证了学习产物是可解释和可审计的。这在自学习 Agent 领域不是理所当然的。很多框架把学习成果存在向量数据库里，检索效率高但人类几乎无法直接审查。当 Agent 做出一个出乎意料的决策时，能不能追溯到底层是哪条记忆或哪个 Skill 在起作用？如果答案是「不能」，那这个系统的可控性就打了折扣。

Hermes 的想象空间在于它试图让 Agent 成为一个「会成长的工作伙伴」，而不只是工具。这个方向是对的，但成长需要养分——准确的反馈、清晰的边界、持续的审查。技术上的闭环只是起点，治理上的闭环才能决定它能走多远。

参考资料

1. Nous Research. Hermes Agent: The Agent That Grows with You. GitHub Repository, 2026. https://github.com/nousresearch/hermes-agent

2. Harrison Chase. Continual Learning for AI Agents. LangChain Blog, April 2026. https://www.langchain.com/blog/continual-learning-for-ai-agents

3. Google Research. ReasoningBank: Enabling Agents to Learn from Experience. April 2026. https://research.google/blog/reasoningbank-enabling-agents-to-learn-from-experience/

4. arXiv. Trajectory-Informed Memory Generation for Self-Improving Agent Systems. March 2026. https://arxiv.org/html/2603.10600v1

5. Noah Shinn et al. Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. https://www.langchain.com/blog/reflection-agents

6. ICLR 2026 Workshop. AI with Recursive Self-Improvement. April 2026. https://iclr.cc/virtual/2026/workshop/10000796

7. Steve Kinney. Memory Systems for AI Agents: What the Research Says. March 2026. https://stevekinney.com/writing/agent-memory-systems