Hermes Agent 架构分析与思考

#AI技术#架构设计#Agent

Hermes Agent 架构分析与思考

作者视角：本文基于对 Hermes Agent 开源代码库的深度分析，面向对 AI Agent 系统架构感兴趣的技术读者。

一、Hermes 是什么

Hermes 是由 Nous Research 开源的 AI Agent 框架，自称”the only agent with a built-in learning loop”——唯一内置学习闭环的 Agent。它不只是一个聊天 Bot，而是一个可自我进化、跨平台部署、模型无关的持久化智能体系统。

当前最新版本为 v0.9.0（2026 年 4 月），该版本已支持 16 个消息平台、200+ 模型、6 种执行环境，拥有约 3000 个测试用例，社区提交达 487 个 commit / 269 个 PR。

这个体量已经越过了”概念验证”阶段，进入了有真实用户和持续社区维护的”早期生产”阶段，值得认真对待。

二、顶层架构全景

┌─────────────────────────────────────────────────────────────┐
│                      用户交互层                              │
│                                                             │
│  ┌─────────────┐          ┌──────────────────────────────┐  │
│  │  终端 CLI   │          │        消息网关 Gateway       │  │
│  │  (TUI)      │          │  Telegram / Discord / Slack  │  │
│  │             │          │  WhatsApp / Signal / Matrix  │  │
│  │  prompt_    │          │  iMessage / WeChat / SMS     │  │
│  │  toolkit    │          │  DingTalk / Feishu / Email   │  │
│  └──────┬──────┘          │  WeCom / Webhook / HomeAsst  │  │
│         │                 └──────────────┬───────────────┘  │
└─────────┼─────────────────────────────────┼─────────────────┘
          │                                 │
          ▼                                 ▼
┌─────────────────────────────────────────────────────────────┐
│                     Agent 核心层                             │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │                   AIAgent                            │   │
│  │                                                      │   │
│  │  ┌────────────┐  ┌─────────────┐  ┌──────────────┐  │   │
│  │  │ Prompt     │  │ Agent Loop  │  │ Context      │  │   │
│  │  │ Builder    │  │ (同步主循环) │  │ Compressor   │  │   │
│  │  └────────────┘  └──────┬──────┘  └──────────────┘  │   │
│  │                         │                            │   │
│  │  ┌────────────┐  ┌──────▼──────┐  ┌──────────────┐  │   │
│  │  │ Prompt     │  │ Model Call  │  │ Trajectory   │  │   │
│  │  │ Cache      │  │ (OpenAI格式)│  │ Recorder     │  │   │
│  │  └────────────┘  └─────────────┘  └──────────────┘  │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────────────────────────┐
│                      工具层                                  │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │               Tool Registry (中央注册表)              │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐   │
│  │ Terminal │ │ File     │ │  Web &   │ │  Delegate    │   │
│  │  Tool    │ │  Tools   │ │ Browser  │ │  (子 Agent)  │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────────┘   │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐   │
│  │  Memory  │ │  Skills  │ │  MCP     │ │  Cron /      │   │
│  │  Tool    │ │  Tool    │ │  Client  │ │  Send Msg    │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────────┘   │
└─────────────────────────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────────────────────────┐
│                    执行环境层                                 │
│                                                             │
│   Local │ Docker │ SSH │ Modal(Serverless) │ Daytona │ Singularity
└─────────────────────────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────────────────────────┐
│                   持久化 & 学习层                             │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────────────┐  │
│  │  Session DB  │  │  Memory /    │  │  Skills System    │  │
│  │  (SQLite     │  │  SOUL.md     │  │  (程序记忆库)      │  │
│  │   FTS5)      │  │  USER.md     │  │  agentskills.io   │  │
│  └──────────────┘  └──────────────┘  └───────────────────┘  │
│  ┌──────────────┐  ┌──────────────┐                         │
│  │  Cron        │  │  Trajectory  │                         │
│  │  Scheduler   │  │  (RL训练数据)│                         │
│  └──────────────┘  └──────────────┘                         │
└─────────────────────────────────────────────────────────────┘

三、六大核心设计理念

1. 模型无关（Model Agnostic）

Hermes 使用统一的 OpenAI 消息格式作为内部协议，通过 model_tools.py 这一适配层对接所有外部 LLM。用户可以在 200+ 模型之间一键切换，无需修改任何代码。

支持的提供商涵盖：Anthropic、OpenAI、OpenRouter、Nous Portal、xAI（Grok）、Xiaomi MiMo、Kimi/Moonshot、MiniMax、Z.AI/GLM、Hugging Face，以及本地自托管端点。

设计本质：将 LLM 视为可替换的”推理引擎”，而非系统的核心依赖。这意味着随着模型能力迭代，Hermes 的能力上限会自然跟随模型能力的天花板上移，而不需要改变框架本身。

这个设计的代价是：所有工具调用必须符合 OpenAI Function Calling 格式，部分模型厂商的特有能力（如 Anthropic 的扩展上下文、Google 的长文档模式）难以充分利用。

2. 平台无关（Platform Agnostic）

Gateway 层通过 BasePlatformAdapter 抽象接口统一了 16 个消息平台的差异。每个平台适配器只需实现约 5 个方法（connect / send / send_typing / send_image / get_chat_info），其余全部复用网关核心逻辑。

同一条斜杠命令（如 /model、/compress、/skills）在终端 CLI、Telegram、Discord、Slack 里表现完全一致，背后是统一的 COMMAND_REGISTRY——命令注册一次，所有平台自动生效。

设计本质：用户的交互方式不应被”在哪里”所限制，Agent 的能力应该跟着用户走。这在个人 AI 助手场景中意义重大——当你从电脑切换到手机时，你仍然在和”同一个 Agent”对话，共享同一份记忆和技能库。

3. 封闭学习闭环（Closed Learning Loop）

这是 Hermes 最独特也最有野心的设计。传统 AI Agent 用完即止，Hermes 则内建了四个互相强化的记忆机制：

┌──────────────────────────────────────────────────────┐
│                  封闭学习闭环                         │
│                                                      │
│   用户对话                                           │
│       │                                              │
│       ▼                                              │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐   │
│  │ 片段记忆  │    │ 用户画像  │    │  技能自创建  │   │
│  │ MEMORY.md│    │ USER.md  │    │  Skills      │   │
│  │ 周期性   │    │ Honcho   │    │  从复杂任务  │   │
│  │ 提示固化  │    │ 辩证建模  │    │  自动提炼   │   │
│  └──────────┘    └──────────┘    └──────────────┘   │
│                                                      │
│  ┌───────────────────────────────────────────────┐   │
│  │  会话搜索 (FTS5 全文检索 + LLM 摘要)            │   │
│  │  跨会话召回历史上下文                           │   │
│  └───────────────────────────────────────────────┘   │
│                                                      │
│       └──────────── 下一次对话更聪明 ───────────────┘ │
└──────────────────────────────────────────────────────┘
  • 片段记忆：Agent 被周期性”nudge”，主动将重要信息写入 MEMORY.md，这不是被动响应，而是主动的记忆固化行为
  • 用户画像：通过 Honcho 构建并迭代用户模型，采用”辩证建模”——不只记录用户说了什么，还会不断质疑和修正对用户的理解
  • 技能自创建：完成复杂任务后，Agent 自动将解决过程提炼为可复用的 Skill（程序记忆）
  • 跨会话搜索：SQLite FTS5 全文索引历史对话，配合 LLM 摘要实现语义召回

设计本质：Agent 不应该每次都”从零开始”，而应该像人一样积累经验、加深对用户的理解。

这个闭环的关键在于”主动性”——记忆的写入不是事后归档，而是 Agent 在运行过程中主动判断、主动记录的。这带来了灵活性，也带来了不确定性，我们会在”不足”部分深入讨论。

类比而言：向量数据库记忆相当于人类的”陈述性记忆”（我知道这个事情），而 Skills 系统相当于”程序性记忆”（我知道怎么做这件事）。认知科学已经证明这是两种本质不同的记忆系统，Hermes 是少数在工程层面同时实现两者的框架。

4. 技能生态（Skills as Procedural Memory）

Skills 系统是 Hermes 对”程序记忆”的实现。每个 Skill 是一份结构化的 Markdown 文档（SKILL.md），描述某类任务的操作流程、关键知识和注意事项。

技能的生命周期：
  自动生成  ──►  本地存储  ──►  使用中优化  ──►  发布到 agentskills.io  ──►  社区共享
  (复杂任务后)   (~/.hermes/    (Skills会       (开放标准)              (他人安装)
                  skills/)       自我改进)

Skills Hub（agentskills.io）是 Hermes 对标 npm / PyPI 所构建的技能包管理生态，实现了”一次创建，多处复用”的知识共享模式。

这是一个有前瞻性的设计——当前大多数 Agent 框架把工具（Tool）作为能力的载体，工具是确定性的函数；而 Hermes 的技能是过程性的知识文档，是不确定性的指南。技能的本质更接近人类的”操作手册”而非”API 接口”。

设计本质：将 Agent 的”怎么做”这类过程性知识外化、标准化、可分发。

5. 工具注册中心（Centralized Tool Registry）

所有工具通过 tools/registry.py 这一中央注册表管理，遵循”约定优于配置”原则：

tools/*.py 文件中调用 registry.register() 时自动注册
       ↓
model_tools.py 触发自动发现，无需手动维护导入列表
       ↓
AIAgent 按 Toolset 分组按需加载，不同平台配置不同工具集

工具集（Toolset）的分层组合设计：

hermes-gateway (网关工具集)
    ├── hermes-telegram
    ├── hermes-discord
    └── hermes-slack
            └── (均包含) hermes-core-tools
                    ├── terminal, file, web...
                    └── (按需) mcp, browser, voice...

设计本质：工具是 Agent 能力的载体，中央注册 + 按需组合，使能力边界清晰且可扩展。新增工具只需一个文件，删除工具不影响其他模块。

6. 随处运行（Run Anywhere）

Hermes 不绑定任何特定的计算环境。六种执行后端（Local / Docker / SSH / Modal / Daytona / Singularity）通过统一接口抽象，支持多种有价值的运行模式：

  • 无服务器弹性：Modal、Daytona 后端在空闲时休眠，按需唤醒，几乎零闲置成本
  • 手机上运行：Termux/Android 适配，移动端也能跑完整 Agent，让”随身携带的 AI 助手”真正成为现实
  • 多实例隔离：Profiles 机制让一台机器运行多个完全隔离的 Hermes 实例（各自的配置、记忆、技能、网关）

四、Agent 主循环设计

用户消息
    │
    ▼
┌─────────────────────────────────────────────────────┐
│  System Prompt 构建                                  │
│  (persona + memory + skills + platform hints +      │
│   context files + tool descriptions)                │
└──────────────────────────┬──────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────┐
│  迭代推理循环 (max 90 轮)                            │
│                                                     │
│  ┌─────────────────────────────────────────────┐    │
│  │   LLM API Call (streaming)                  │    │
│  │   → 返回 text 或 tool_calls                  │    │
│  └──────────────┬──────────────────────────────┘    │
│                 │                                   │
│         ┌───────┴────────┐                          │
│         ▼                ▼                          │
│   [有 tool_calls]   [纯文本回复]                     │
│         │                │                          │
│         ▼                ▼                          │
│   执行工具            返回给用户                     │
│   追加结果            结束循环                       │
│   继续下一轮                                        │
│                                                     │
│  ──────────── 内置保护机制 ────────────────────────  │
│  · Prompt Caching（会话内不重建 System Prompt）      │
│  · Context Compression（上下文压缩，保留任务焦点）   │
│  · Iteration Budget（防止无限循环，上限 90 轮）      │
│  · Interrupt Signal（用户随时打断，干净退出）        │
└─────────────────────────────────────────────────────┘

这四个保护机制缺一不可：Prompt Caching 解决成本问题，Context Compression 解决窗口溢出问题，Iteration Budget 解决死循环问题，Interrupt Signal 解决用户控制权问题。它们共同构成了一个”安全可控”的推理循环。

五、模块依赖拓扑

tools/registry.py          ← 无依赖，基础层
      ↑
tools/*.py                 ← 各工具实现，各自独立
      ↑
model_tools.py             ← 工具发现与调度中心
      ↑
run_agent.py               ← AIAgent 核心，消费 model_tools
      ↑
┌─────────────┬─────────────┬──────────────┐
│   cli.py    │ gateway/    │ batch_runner │
│ (交互终端)  │ run.py      │ (批量任务)   │
│             │ (消息网关)  │              │
└─────────────┴─────────────┴──────────────┘

这种拓扑的优势是依赖方向清晰、各层职责分明；潜在的风险是 run_agent.py 成为单点——一旦 Agent 核心接口发生变化，三个入口点都需要同步更新。

六、先进性、亮点与不足

先进性：它在做别人没做的事

自进化的程序记忆

当前绝大多数 AI Agent 框架（LangChain、AutoGPT、CrewAI 等）都把”记忆”停留在向量数据库检索这一层。Hermes 走得更远——它会主动从每次复杂任务中提炼技能，并持续优化这些技能。这是在模拟人类”从实践中学习并形成肌肉记忆”的过程，在已知开源 Agent 框架中极为罕见。

统一学习闭环作为系统一等公民

不是作为插件附加，而是从系统设计之初就内建——记忆写入的 nudge 机制、Honcho 用户建模、FTS5 跨会话搜索、技能自创建，这四个机制相互配合构成了一个真正的学习回路。

16 个平台的统一 Agent 体验

这在工程上代价极高，但意义重大：用户无论在 Telegram 还是 Discord、CLI 还是 iMessage，都在和”同一个” Agent 交流，共享同一份记忆和技能库。大多数竞争产品只做到了”多平台接入”，Hermes 做到了”跨平台的同一个智能体”。

RL 训练管道内置

轨迹录制（Trajectory）、批量运行（batch_runner）、Atropos RL 环境——Hermes 直接内置了从 Agent 使用到模型训练的完整数据管道，将”使用”和”训练下一代模型”闭合为一个循环。

亮点

  • Slash Command 一次注册全平台生效：COMMAND_REGISTRY 的设计优雅，新增命令不需要在 CLI、Gateway、Telegram、Slack 各处分别处理，降低了维护成本。

  • Prompt Caching 作为硬约束：将缓存不失效作为开发规范写入 AGENTS.md，并禁止在会话中途重建 System Prompt，对成本控制有实质效果（尤其是 Anthropic 的 prompt cache 折扣）。

  • Profiles 多实例隔离：一台机器可以运行多个完全隔离的 Hermes（开发环境 / 生产环境 / 个人 / 团队），这在 Agent 运维场景下很有价值。

  • 工具自动发现：tools/*.py 文件中调用 registry.register() 就完成注册，无需维护手动导入列表。新增工具只需新建一个文件。

  • 开放标准 agentskills.io：不是封闭生态，技能可以跨实例分发，类似于 Agent 版的包管理器。如果形成网络效应，这会是 Hermes 最重要的护城河之一。

不足与值得商榷之处

同步主循环的性能瓶颈

Agent 的核心循环 run_conversation() 是完全同步的。这意味着当 Agent 在等待一个耗时工具返回（比如执行长命令）时，整个线程都在阻塞。对于单用户个人 Agent 尚可接受，但若要扩展到多用户并发场景，这一设计会成为天花板。Gateway 通过异步任务（asyncio）缓解了这个问题，但 Agent 核心层的同步性质没有改变。

从架构演进的角度看，将同步核心迁移到异步是一个高风险的重构——不只是换关键字，而是整个状态管理和错误处理模型都需要重新设计。这是 Hermes 在”个人助手”和”企业服务端”之间最大的鸿沟。

技能系统的质量控制

技能自动从对话中提炼，这在”创造”端很高效，但在”质量”端存在隐患：低质量的技能一旦被写入，后续对话都会被它影响。目前 Hermes 依赖 Agent 自己判断技能质量，缺乏结构化的技能评审或自动测试机制。

更深层的问题是：技能的”正确性”是相对于特定上下文的。一个在 A 环境下有效的技能，在 B 环境下可能完全无效甚至有害。当前的技能系统缺乏上下文适用性的标注和验证机制。

跨会话记忆的一致性

Memory 写入是由 Agent “自觉”触发的（通过 nudge 机制），而非强制性事务写入。这意味着记忆的完整性依赖于模型的”善意”，在高频使用场景下，可能出现记忆遗漏或信息不一致。

配置系统的分裂

AGENTS.md 中明确记录了三套并存的配置加载器，这是历史演进的痕迹，对新接手代码的开发者来说理解成本较高，也存在配置不一致的潜在风险。

工具数量膨胀

tools/ 目录下已有约 40 个工具文件，部分工具的边界相互交叉（如 file_tools.py 与 file_operations.py）。随着工具数量继续增长，工具选择的认知负担会转移到 LLM 侧，可能影响工具调用准确率。Claude Code 通过”工具三档加载”（高频常驻、中频按需、低频休眠）缓解了这个问题，Hermes 目前缺乏类似机制。

七、横向对比：Hermes 在 Agent 框架中的位置

                高度自主 / 自进化
                        │
                        │
            Hermes ●    │
                        │
  ────────────────────────────────────  工具生态丰富度
  个人 / 单用户         │         平台 / 企业级
                        │
  AutoGPT (过时) ●      │
                        │    ● LangGraph
                        │    ● CrewAI
                        │
                低度自主 / 工具框架
  • vs LangChain/LangGraph：Hermes 是一个完整的 Agent 产品，LangGraph 是编排框架。前者开箱即用，后者需要大量组装。如果你的目标是”我想要一个 AI 助手”，Hermes 比 LangGraph 更直接；如果你的目标是”我要在现有系统上嵌入一个 Agent 引擎”，LangGraph 更合适。
  • vs AutoGPT：同为”自主 Agent”定位，但 Hermes 更务实，有可用的界面、稳定的记忆、真实的社区生态。AutoGPT 在技术上证明了”自主 Agent 可以做什么”，Hermes 在工程上证明了”自主 Agent 可以怎么用”。
  • vs CrewAI：CrewAI 聚焦多 Agent 协作编排，Hermes 是单 Agent 深度进化（通过 delegate_tool 也可实现子 Agent 并行）。CrewAI 认为复杂任务应该分工，Hermes 认为单个 Agent 应该变得更强。
  • vs Claude Code（Anthropic）：定位最接近。Claude Code 是 Anthropic 闭源产品，Hermes 是开源替代，且更侧重学习闭环而非纯粹的代码辅助。Claude Code 的工程成熟度更高（经过日活百万级验证），Hermes 的场景覆盖更广（不局限于代码）。

八、一个值得关注的深层问题

Hermes 的学习闭环设计引出了一个 Agent 架构的深层哲学问题：Agent 的”自我”应该如何定义？

当 Hermes 将一次对话提炼为技能，这个技能会影响未来所有对话；当它建立用户画像，这个画像会影响它对用户意图的解读。这意味着 Hermes 是一个会随时间演变的系统——今天的 Hermes 和三个月后的 Hermes，在行为上可能存在实质性差异。

这带来了一个有趣的工程挑战：如何保证一个持续自我演变的系统仍然是可预测的、可信任的、可调试的？当出现错误时，你如何判断问题出在当次对话、某个历史技能，还是某个用户画像假设？

这些问题在学术上已有探讨，但在工程上，Hermes 是少数几个真正把这些问题变成需要解决的实际挑战而非理论讨论的框架。

九、总结

Hermes 的核心价值不在于它支持多少平台、集成了多少工具，而在于它提出并实践了一个重要命题：AI Agent 应该像人一样从经验中学习，而不是每次都从零开始。

封闭学习闭环（技能自创建、记忆固化、用户建模、跨会话搜索）是它最值得关注的创新，也是它与同类框架最本质的差异。

当然，这个野心也带来了复杂性——同步循环的性能上限、记忆质量的不确定性、配置系统的历史包袱，都是它在走向更大规模应用时需要正视的挑战。

但就当前开源 Agent 生态而言，Hermes 是少数几个真正在系统层面而非功能拼凑层面思考”Agent 应该如何成长”的框架之一。

分析时间：2026 年 4 月 | 代码版本：v0.9.0 (v2026.4.13)