Hermes Agent：三层记忆与多代理工作流

这篇文章只根据两份本地资料整理与翻译，不把社媒长文当成官方文档替代品，也不把评论区观点写成既成事实。

• 本地 HTML 1：temp/X 上的 Akshay 🚀："Hermes Agent Masterclass" _ X (2026_5_16 14：39：52).html
• 本地 HTML 2：temp/X 上的 Akshay 🚀："the three-tier memory of Hermes agent._AI agents forgets everything when your session ends. Hermes doesn't._it has three memory layers, each at a different speed….html
• 原始 X 来源（社媒长文）：https://x.com/akshay_pachaar/status/2054564519280804028
• 原始 X 来源（社媒线程）：https://x.com/akshay_pachaar/status/2054861039804772827

为了便于回查，我把原始 HTML、清理摘录和图片都放进了 docs/ai/references/hermes-agent-masterclass-zh/ 与 docs/ai/assets/hermes-agent-masterclass-zh/。正文分成长文、线程和合并整理三部分。

一、Hermes Agent Masterclass 讲了什么

来源类型：社媒长文 / X Article
对应入口：https://x.com/akshay_pachaar/status/2054564519280804028

这篇长文的主线很明确：Hermes 不只想做一个"会聊天的 agent"，它想把三件通常分开的能力放到同一套运行时里：

1. 持续记忆；
2. 自己写、自己维护的技能；
3. 离线优化技能质量的 GEPA 管线。

原文开头把问题说得很直接：很多 agent 一到新会话就要重新开始，之前纠正过的项目约定、工具坑、修复经验，都得再讲一遍。单靠拉长上下文，Hermes 觉得不够用，所以它把"身份、记忆、技能、离线优化"拆成了几层。

1. 架构重点：统一的 agent core

长文把 Hermes 描述成一个平台无关的 agent core。CLI、消息网关、批处理、IDE 集成，都只是进入同一个 AIAgent 核心类的不同入口。

下图是长文里给出的结构图：

按原文整理，这个核心循环有几个关键点：

• 采用类似 ReAct 的同步循环；
• 每轮构造系统提示，判断要不要压缩；
• 然后发起可中断的模型调用；
• 有工具调用就执行，再继续下一轮。

原文还特别点出三件工程细节：

• 执行位置可以切换，本地终端、Docker、SSH、Modal、Daytona、Singularity 都是同一套逻辑；
• 模型提供方可以替换，Claude、GPT、Gemini、本地 Ollama 等可以通过兼容层接进去；
• 单个任务有 90 轮上限，子代理共享这笔预算，避免递归委派把额度悄悄烧穿。

这些工程细节后面都会用到：长期运行、多代理配置和技能沉淀都建立在这里。

2. 记忆之前还有 SOUL.md

长文专门把 SOUL.md 放在记忆系统前面讲。原文的意思是：记忆解决"知道什么"，技能解决"怎么做"，但两者都不决定"这个 agent 以什么风格出现"。

Hermes 把这层身份定义放进一个单独文件里：

• 默认位置：~/.hermes/SOUL.md
• 加载顺序：系统提示最前面
• 作用：人格、语气、沟通方式、行为约束

这层定义放在最前面，作用就是先把角色和行为口径定住，后面的记忆与技能都在这个前提下展开。

3. 三层记忆只是其中一部分

长文里的记忆章节和后面的独立线程讲的是同一套东西，但长文给出的语境更完整：三层记忆是为了让 agent 在会话内和跨会话之间都能保持状态，不需要把所有内容都常驻在 prompt 里。

下图是长文配图里的三层记忆示意：

这里先记住长文给出的总原则：

• 始终在上下文里的内容要极小；
• 容量大的内容应该可检索，不适合常驻；
• 更深层的语义建模可以外接 provider，但不能直接替代前两层。

4. 自进化技能：把做过的流程沉淀下来

长文把 skills 解释为程序性记忆。重点不在"模型知道什么"，而在"模型以后遇到同类问题时按什么步骤做"。

原文给出的技能结构是 Markdown + YAML frontmatter，大意包括：

• skill 名称与触发描述；
• 适用平台；
• 具体步骤；
• 常见坑；
• 验收标准。

长文强调了一个很重要的设计：progressive disclosure。也就是：

• 第 0 层只让 agent 看见技能名和描述；
• 真要用某个技能时，再加载完整内容；
• 如果技能里还有参考文件，继续按需深入。

这样可以把 token 用量压住。技能库越大，这种按需展开就越重要。

5. Curator：技能会增殖，所以要有人负责清理

原文没有把"自进化技能"讲成无条件利好，反而花了不少篇幅说明技能库会越来越乱：重复、过窄、长期不用的 playbook 会不断堆积。

Hermes 在长文里的解法叫 Curator。按原文整理，它有几个限制条件：

• 只处理 agent 自己创建的 skills；
• 不自动删官方 bundled skill，也不动 hub 安装的 skill；
• 不做不可恢复删除，最坏情况是归档到 .archive/；
• 每次整理前会先做整目录备份。

Curator 负责后台归档和修剪，不负责让 agent 自由改写一切。

6. GEPA：运行时会积累经验，但离线优化另算一层

长文里关于 GEPA 的段落也很清楚：它不在 Hermes runtime 里面，而是单独跑在配套仓库中。

• 配套仓库：https://github.com/NousResearch/hermes-agent-self-evolution
• 论文入口：https://arxiv.org/abs/2507.19457

这里的关键判断是：如果直接让 agent 自己评估"我刚才做得怎么样"，它往往会高估自己。GEPA 会读取执行轨迹，分析失败点，再通过演化搜索提出候选改法，然后用评测规则筛选，最后以 PR 形式输出，不直接写进运行时。

这三块各管一段：

• runtime loop 负责一边工作一边积累经验；
• Curator 负责整理已有技能；
• GEPA 负责离线打磨那些真正值得保留的技能版本。

7. 从安装到可用

长文后半段不再复述概念，直接从安装写到多代理实践。它给出的最短命令是：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
hermes setup
hermes

接下来它把 Telegram 接入也放进同一条链路里：

• Bot token 通过 https://t.me/BotFather 获取；
• Telegram user id 通过 https://t.me/userinfobot 获取；
• 然后把 Hermes 指到对应 bot。

原文的重点不在"终端能跑起来"，而在"从手机上也能把 agent 当成常驻入口来用"。

8. profiles、多代理与分工

长文里一个很值得保留的点，是多代理用隔离 profile 来落地，不是给一个大 agent 配一堆标签。

按原文整理，profile 的隔离范围包括：

• 独立 config；
• 独立 memory；
• 独立 skills；
• 独立 sessions；
• 独立 SOUL.md。

长文给出的三种示例 agent 是：

• designer
• programmer
• researcher

并且强调它们默认互不共享状态。这个设计和很多"所有人共用一份记忆池"的系统正好相反。

下图是长文里的 Telegram 多代理示意图：

9. 三种代理的工作方式也不同

原文没有只停留在"建三个角色"。它给出的用法是分工不同、执行链路也不同。

programmer

长文里最详细的是 programmer profile。原文建议让 Hermes 负责编排，把真正的读写代码、跑命令、管理 git 的执行交给 Claude Code CLI。也就是说：

• Hermes 决定接下来做什么；
• Claude Code 负责实际代码执行；
• Hermes 再根据结果继续判断。

这是 orchestration 与 execution 分离的一种做法。

designer

designer profile 的思路是：喂参考图，让 agent 自己写出"生成同风格图片"的 skill。也就是把风格学习本身也做成 skill 生成任务。

researcher

researcher profile 则被拿来做 Telegram 日报。原文提到 Hermes 自带 scheduler，agent 可以用自然语言定义任务，再交给 cron 组件定时运行，输出会写到相应目录并投递到聊天入口。

这三种用法合在一起，才是长文所谓"从 1 个 agent 变成 10 个 agent"的具体做法：每个 profile 都有自己的身份、技能、记忆和消息入口。

二、three-tier memory 线程整理

来源类型：社媒线程 / X post
对应入口：https://x.com/akshay_pachaar/status/2054861039804772827

这条线程比长文短很多，但内容更集中，基本只讲三层记忆本身，以及三层在单轮对话里怎样组合。

1. Tier 1：两份很小的 Markdown 文件

线程把第一层概括成两个小文件：

• MEMORY.md：约 2200 字符上限
• USER.md：约 1375 字符上限

按线程原意：

• MEMORY.md 存项目约定、工具脾气、经验教训；
• USER.md 存用户画像，例如名字、沟通风格、技能水平、需要避免的事项。

它们会在会话开始时作为冻结快照注入系统提示。这个"冻结快照"很关键，因为线程同时说明了一点：即使本轮会话中 agent 又写入了新记忆，这条更新虽然已经落盘，但当前会话里的 prompt 不会立刻变；它要到下一个 session 才会自然出现。

线程还解释了为什么这一层必须足够小：文件到达大约 80% 容量时，会触发 consolidation。也就是：

• 合并相关条目；
• 删除冗余；
• 保留信息密度更高的版本。

线程把这种机制叫作"对记忆施加自然选择压力"。重点不是保存尽可能多，而是让真正会重复出现、以后真的还会用到的事实留下来。

2. Tier 2：会话全文检索，按需搜索

线程给第二层的定义是：

• 所有会话写入 SQLite；
• 通过 FTS5 建全文索引；
• agent 需要时调用 session_search 去找。

线程里还有一个很具体的执行细节：当 session_search 触发时，FTS5 会先在成千上万份文档里做快速排序，然后再让 LLM 汇总高相关结果，最后只把一段紧凑结果送回当前上下文。

这里的分工很清楚：

• tier 1 一直都在，但非常小；
• tier 2 几乎不限容量，但要主动搜索；
• 因此"关键事实进 memory，其他内容保持可搜索"才是它想要的工作方式。

3. Tier 3：外部 memory providers，与前两层并行

线程里把第三层定义为 8 个可插拔 provider 的集合，并强调：它们是 alongside，不是 replacement。

线程点名提到的三个例子是：

• Honcho
• Holographic
• Supermemory

对应入口在官方文档里可以继续看：https://hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers

这一段重点不在 provider 名单，而在接入方式：

• 每轮开始前做 prefetch；
• agent 回复后做 sync；
• 会话结束时做 extraction。

也就是说，第三层承担的是更慢、更深的语义记忆建模，但它依然围绕前两层运转，不会把常驻小记忆和全文检索替掉。

4. 三层在单轮对话里怎样组合

线程里最有价值的一段，是把三层记忆压成了一个五步循环：

1. 新一轮开始时，tier 1 已经在 prompt 里，tier 3 先把预取结果补进来；
2. agent 在这三层共同提供的上下文上作答；
3. 周期性 nudge 触发，agent 会判断这一轮有没有值得沉淀的内容；
4. 如果有，就写进 MEMORY.md，但当前会话里因为 prefix cache 仍然是旧快照，所以不会立即可见；
5. 会话结束时，tier 2 记录转录，tier 3 做语义抽取，下个 session 再带着新状态开始。

这一段把 Hermes 记忆系统最重要的工程事实讲清楚了：会话内的持续可用状态、跨会话的状态保持，以及更深层的语义提取，不是同一速度。

三、把两篇重复内容并成一套理解框架

前面的长文和线程有不少重复点，合在一起看，会更容易把 Hermes 的记忆和工作流分清。

1. 长会话靠分层，不靠无限上下文

两篇资料都在强调，长会话要靠内容分流：

• 小而稳定、必须一直带着的内容，放 tier 1；
• 大而杂、但偶尔需要追溯的内容，放 tier 2；
• 更慢、更深的用户建模或外部语义记忆，放 tier 3。

如果把所有历史都塞进 prompt，走的是另一条路。Hermes 选择的是：保住核心热记忆，给冷数据准备检索面，再把更深的长期建模放到 provider。

2. 记忆和工具调用是连在一起的

两篇资料都没有把 memory 写成纯数据库能力。它本身就是工具链的一部分：

• tier 2 要靠搜索工具拿结果；
• tier 3 要靠 provider 的同步与抽取机制接起来；
• skills 则把"下一次怎么操作工具"沉淀成程序性记忆。

所以 Hermes 的运行状态，依赖的是一套外部系统组合：

1. 小记忆给当前轮次定基调；
2. 需要细节时再查历史会话；
3. 需要更深用户建模时走外部 provider；
4. 反复成功的工具用法，再进一步提炼成 skill。

3. 记忆负责保留状态，skill 负责保留做法

这是两篇资料最该分开的地方。

• MEMORY.md / USER.md 保存的是事实、偏好、约束；
• session search 保存的是可追溯历史；
• provider 保存的是更慢的语义层；
• skills 保存的是可复用工作流。

因此，Hermes 组织起来的不止多层记忆，还包括身份层、事实层、历史层、外部记忆层、程序性技能层。

四、延伸说明

下面不再逐段翻译，直接把前面的材料收成几条便于理解的说明。

1. 什么叫快慢记忆

如果只按工程速度区分，Hermes 的三层记忆可以这样理解：

• 快记忆：tier 1。小、热、始终在 prompt 里。
• 中速记忆：tier 2。默认不进 prompt，需要时快速搜索。
• 慢记忆：tier 3。依赖 provider 做更深的预取、同步和抽取。

这也是为什么线程一再强调"不同速度"。不是每种信息都该以同样方式保存、同样时机读取。

2. 会话结束后怎样保持状态

两份资料合起来，Hermes 的跨会话保持机制大致是：

• 会话开始：读取 tier 1 快照，必要时加上 tier 3 预取结果；
• 会话进行中：如果出现值得记住的内容，可以写入磁盘，但当前 prompt 不会立刻重构；
• 会话结束：tier 2 记完整历史，tier 3 提取更深层语义；
• 下次再开：新快照和新提取结果成为新的起点。

因此，会话结束后留下来的，不是"模型脑子里的状态"，而是已经被外部系统整理过的状态；下次再开会话时，它会按合适速度被带回来。

3. Agent 工作流怎么用

长文给出的三种 profile，正好可以拿来说明这套工作流怎么落地。

programmer：编排和执行拆开

programmer profile 的思路是 Hermes 做总控，Claude Code CLI 做实际代码执行。这里的重点不在换模型，而在让编排、代码修改、命令执行、git 操作各有稳定入口。

designer：把风格学习也做成 skill 生成任务

designer profile 的做法，是给范例，让 agent 根据范例总结工作法。参考图不是一次性喂完就结束，而会被转成后续可复用的 skill。

researcher：把定时任务交给 scheduler

researcher profile 用来跑 Telegram digest，说明 Hermes 并不把 agent 限定为"等你问一句答一句"。它也可以承担按计划执行、自动投递的工作。

如果把这三种模式放在一起看，Hermes 的工作流大致是：

• 用 SOUL.md 固定身份；
• 用三层记忆保存状态；
• 用 skills 固定做法；
• 用 scheduler 让某些任务脱离人工触发。

五、引用与转载说明

这篇文章的资料性质需要单独说明：

• Hermes Agent Masterclass 是社媒长文 / X Article；
• three-tier memory 是社媒线程 / X post；
• 文中关于仓库、文档、论文、Telegram 入口的链接，都是从原文保留下来的非 t.co 目标或与原文对应的直接入口；
• 正文以整理、翻译、说明为主，没有整段转抄长文；
• 如果要核对实现细节，应继续看官方文档与仓库：https://hermes-agent.nousresearch.com/docs/、https://github.com/NousResearch/hermes-agent。

六、延伸阅读

如果你想把 Hermes 放回更大的 Agent 记忆与 RAG 语境里，可以继续看这几篇：

• 第 11 篇：TencentDB Agent Memory
• 第 30 篇：AI Agent 如何记住东西
• 第 39 篇：PageIndex：树状索引版 Vectorless RAG