Hermes Agent架构深度解析：循环机制、记忆系统与网关设计

Hermes Agent 架构深度解析

Hermes Agent 作为一款持续学习型 AI 智能体，凭借灵活的网关系统和多层记忆架构，迅速成为开发者社区中备受关注的项目。本文将基于对 Hermes 源码和架构的深度分析，系统拆解其核心运作机制，帮助你理解如何使用它，以及如何构建类似的智能体系统。

鸟瞰全局：Hermes 的整体架构

Hermes 的架构设计出奇地简洁。其核心由以下几个组件构成：

• AI Agent Core（智能体核心）：即核心的 Agentic Loop，是整个系统的大脑
• 多种接入方式：CLI 命令行、Gateway 网关（Telegram/Email/Slack 等）、API 接口
• 内置服务：预装工具（Tools）、技能（Skills）、以及多层记忆系统

Hermes 的设计哲学体现了当前 AI Agent 工程化的主流趋势：将 LLM 作为推理引擎，通过工具调用扩展能力边界，通过记忆系统突破上下文限制。这与 LangChain、AutoGPT、CrewAI 等框架的核心思路一脉相承，但 Hermes 更注重「个人助手」场景的深度定制化——它不试图成为一个通用的 Agent 框架，而是专注于打造一个真正「认识你」的私人智能体。

安装 Hermes 后，你会获得一套开箱即用的工具集和技能集。而真正让 Hermes 区别于普通聊天机器人的，是它的记忆系统——分为内部记忆（会话记录、soul.md、user.md 等文件）和外部记忆（mem0、Super Memory 等第三方服务）。这种双层记忆设计让智能体能够在持续交互中不断学习和进化。

Agent Loop：智能体循环的运作机制

Hermes 的核心循环与 PiAgent、OpenCode 等极简智能体类似，但在细节上做了更多考量。每当用户发送一条消息，循环就会启动。

Agentic Loop（智能体循环）是当前 AI Agent 架构中最核心的设计模式。与传统的「请求-响应」模式不同，Agentic Loop 允许 LLM 在一次用户输入后进行多轮自主决策——它可以反复调用工具、观察结果、再决定下一步行动，直到认为任务完成。这种模式源自 ReAct（Reasoning + Acting）范式，由 Shunyu Yao 等人在 2022 年论文《ReAct: Synergizing Reasoning and Acting in Language Models》中正式提出，核心贡献是证明了让 LLM 交替输出「思考轨迹」和「行动指令」能显著提升复杂任务的完成质量。

ReAct 范式的运作逻辑可以用一个简单的伪代码描述：Thought → Action → Observation → Thought → ...，即模型先输出对当前状态的思考，再输出一个具体行动（如调用搜索工具），观察行动结果后继续思考，如此循环直到得出最终答案。这种「思考-行动-观察」的三元组结构，使得模型的推理过程变得可解释、可调试，也为人类监督提供了介入点。相比之前的 Chain-of-Thought（CoT）提示技术只有思考没有行动，ReAct 的关键突破在于将语言模型与外部环境（工具、数据库、API）真正打通。这一范式直接影响了 OpenAI Function Calling 和 Anthropic Tool Use 的 API 设计规范——这两套 API 本质上都是为了让开发者能够优雅地实现 ReAct 循环而设计的标准化接口，将「模型决定调用哪个工具、传入什么参数」这一步骤结构化为 JSON Schema，从而避免了早期实现中需要用正则表达式解析模型输出的脆弱做法。

第一步：构建上下文（Build Context）

系统从内部记忆和预设提示词中组装完整的上下文，包括系统提示词、soul.md（智能体人格）、user.md（用户画像）、消息历史等。

第二步：发送至 LLM

将完整上下文和消息历史发送给大语言模型进行推理。

第三步：工具调用循环

LLM 可以决定调用工具（如网页搜索、文件读写等），工具执行结果会返回给 LLM，这个过程会持续进行，直到 LLM 认为不再需要调用工具为止。

第四步：生成最终响应

完成所有工具调用后，LLM 输出最终回复。

第五步：记忆更新（Memory Update）

这是 Hermes 的精髓所在——在每次回复之后，系统会分析本轮对话，判断是否有值得记住的信息，并将其写入记忆系统。这就是 Hermes 能够「越用越聪明」的根本原因。

上下文构建与压缩策略

Hermes 的上下文由几个关键的 Markdown 文件组成：

• soul.md：定义智能体的人格、语气、目标和行为方式。初始安装时为空，会使用默认系统提示词，但强烈建议用户自定义
• user.md：用户画像文件，Hermes 会在对话中自动学习并更新你的信息（如职业、工作内容等）
• memory.md：任意记忆文件，存储工具使用方法、工作流程、对话中学到的有趣事实等

除了这些文件，上下文还包括过往会话摘要（需配置外部记忆）、技能和工具描述，以及最近的消息历史。

上下文压缩机制

当对话变长时，上下文压缩就变得至关重要。Hermes 默认在上下文使用量达到 50% 时触发压缩，将历史消息总结为摘要。

压缩检查发生在两个时机：每次消息发送前和LLM 返回上下文窗口错误时。

在首次消息时，由于尚未获得 LLM 的 token 使用数据，Hermes 采用了一个巧妙的近似方法：总字符数 ÷ 4 ≈ token 数。后续消息则直接使用 LLM 返回的 usage 参数获取精确的 token 计数。

关于 token 估算的技术背景值得深入理解：大语言模型普遍采用 BPE（Byte Pair Encoding） 或 SentencePiece 算法构建词表。BPE 最初是一种数据压缩算法，由 Philip Gage 于 1994 年提出，后被 OpenAI 在 GPT-2 中引入 NLP 领域。其核心思想是从单个字符出发，反复合并出现频率最高的相邻字符对，最终形成一个覆盖常见词汇和子词的词表。Token 是模型词表中的最小语义单元，其粒度介于字符和单词之间——常见英文单词通常是一个 token，而罕见词或专有名词则会被拆分为多个子词 token。对于英文文本，1 个 token 大约对应 4 个字符或 0.75 个单词；对于中文文本，由于汉字本身信息密度高，1 个汉字通常对应 1-2 个 token，这意味着「字符数÷4」的公式在中文场景下会严重低估实际 token 数。不同模型的上下文窗口差异巨大：GPT-4o 支持 128K token，Claude 3.5 支持 200K token。生产级系统通常会集成 tiktoken（OpenAI 开源的 tokenizer 库）进行精确计数，但其调用开销在高频场景下不可忽视——这正是 Hermes 选择近似方法的工程权衡所在。

压缩提示词本身非常丰富，要求 LLM 生成包含多个维度的摘要：整体目标、约束条件、已完成操作、活跃状态、历史进展、当前阻塞项、关键决策、已解决问题、相关文件等。相比 Pi 的极简压缩提示词，Hermes 的版本明显更加详尽，能为智能体保留更多上下文信息。

Gateway：连接万物的网关系统

Gateway 可以说是让 Hermes 真正「出圈」的功能——它让你的 AI 智能体可以通过 Telegram、Slack、Email、WhatsApp、Discord 等平台与你对话。

网关的工作原理

网关启动后会运行一个 AsyncIO 事件循环，持续监听各个消息平台的新消息。

AsyncIO 是 Python 的异步编程框架，自 3.4 版本引入、3.7 版本后趋于成熟，基于协程（coroutine）和事件循环（event loop）实现非阻塞 I/O 操作。理解 AsyncIO 的优势，需要先理解 Python 的 GIL（全局解释器锁） 限制：GIL 是 CPython 解释器中的一把互斥锁，确保同一时刻只有一个线程执行 Python 字节码，这使得 Python 的多线程在 CPU 密集型任务中几乎无法利用多核优势。然而在 I/O 密集型场景（如等待网络响应），线程大部分时间处于阻塞等待状态，GIL 会在 I/O 等待期间释放，允许其他线程运行——但线程切换本身的开销（上下文保存、调度器介入）仍然存在。AsyncIO 通过单线程事件循环配合 await 关键字，完全绕开了线程切换开销：当一个协程遇到 await 时，它主动让出控制权给事件循环，事件循环再调度其他就绪的协程执行，整个过程在单线程内完成，没有锁竞争，没有上下文切换开销。在网关场景中，智能体需要同时监听多个消息平台的输入，AsyncIO 可以在一个线程内高效管理数百个并发连接——这对于需要同时处理 Telegram 轮询、WebSocket 长连接和 Webhook 回调的网关系统来说，是最合适的技术选型。

不同平台的接入方式各异：

• 部分使用 Webhook 推送
• 部分使用轮询机制（如 Telegram 支持每秒轮询 API）
• 部分使用 WebSocket 长连接

这三种消息接入方式代表了分布式系统中三种经典的通信模式，其差异本质上是「谁主动发起通信」的问题。Webhook 是「推送」模式，平台在有新消息时主动向你的服务器发送 HTTP POST 请求，实时性最好但需要公网可达的服务器地址，且需要处理平台的重试逻辑和签名验证。轮询（Polling） 是「拉取」模式，客户端定期向平台 API 发送请求检查新消息，实现简单但有延迟且浪费带宽；Telegram 的长轮询（Long Polling）是一种优化变体，通过设置 timeout=30 让服务器在有消息时才返回响应，兼顾了实现简单和实时性，且无需公网 IP，非常适合本地开发环境。WebSocket 是全双工长连接，基于 HTTP Upgrade 机制建立，连接建立后双方可随时发送数据，兼具实时性和效率，但需要维护连接状态、处理断线重连逻辑，实现复杂度最高。Telegram 同时支持 Webhook 和长轮询两种模式，正是为了适配不同的部署场景——本地开发时用长轮询，生产环境用 Webhook。

每个平台的集成都需要独立配置（通过 hermes setup gateway 命令），包括 Bot ID、允许通信的用户 ID 等。

上下文重建与会话管理

网关接收到的是单条消息，而非完整对话。因此它需要从 SQLite 数据库中重建完整的消息历史。会话 ID 的构成方式为：平台名称 + 平台返回的 Session ID + 其他标识符。

网关还内置了一个会话管理器（Session Manager），负责处理消息并发场景：当智能体正在处理上一条消息时，新消息可以被排队（默认）、中断（/interrupt）或引导（/steer）。

三层记忆系统深度解析

Hermes 的记忆系统是其最具特色的设计之一，分为三个层次：

第一层：Markdown 文件记忆

即前文提到的 soul.md、user.md 和 memory.md，始终附加在系统提示词之后，是最直接的记忆形式。这种设计的优雅之处在于：Markdown 文件对人类可读、可编辑，用户可以直接修改这些文件来「教导」智能体，同时也便于版本控制（如 Git 追踪）。

第二层：SQLite 数据库存储

Hermes 将每一次交互的完整记录存储在本地 SQLite 数据库中。数据库中包含多个表和数据模型，本质上都是所有会话的完整文字记录。说个细节，数据库中还维护了一个纯文本表，专门用于对历史对话进行相似性搜索，这是一个非常实用的设计。

SQLite 的选择本身也值得关注：作为嵌入式数据库，SQLite 无需独立服务进程，数据存储在单个文件中，非常适合个人助手这类单用户场景。其全文搜索扩展（FTS5）支持基于 BM25（Best Match 25） 算法的关键词检索——BM25 是信息检索领域的经典排序算法，由 Stephen Robertson 等人在 1990 年代提出，是 TF-IDF 的改进版本，通过引入文档长度归一化和词频饱和机制，在关键词匹配精度上显著优于简单的词频统计。BM25 的优势在于对精确关键词的高召回率，而其局限在于无法理解语义相似性——「汽车」和「轿车」在 BM25 看来是完全不同的词。这正是第三层外部记忆（向量检索）的用武之地：两者形成互补，BM25 负责精确匹配，向量检索负责语义理解，在本地环境中零依赖、零延迟的 SQLite FTS5 成为外部向量服务的有力补充。

第三层：外部记忆服务

外部记忆需要手动配置，支持 mem0、Super Memory、Honcho 等多个提供商。每个提供商的工作方式不同——有的使用语义相似性搜索，有的使用 LLM 提取关键记忆。

语义相似性搜索是基于向量嵌入（embedding）的检索技术，也是当前 RAG（检索增强生成）架构的核心基础设施。其原理是：将文本通过嵌入模型（如 OpenAI 的 text-embedding-3-small，输出 1536 维向量）转换为高维向量，语义相近的文本在向量空间中距离更近。这一特性来源于嵌入模型的训练方式——通过对比学习（Contrastive Learning），模型被训练成让语义相似的文本对在向量空间中相互靠近，语义不相关的文本对相互远离。查询时，将用户输入同样转换为向量，然后通过余弦相似度或欧氏距离找到最相关的历史记忆。主流向量数据库（如 Pinecone、Weaviate、Chroma、Qdrant）提供了高效的**近似最近邻（ANN，Approximate Nearest Neighbor）**搜索能力——精确最近邻搜索在高维空间中的时间复杂度是 O(n)，而 ANN 算法（如 HNSW、IVF）通过构建索引结构，能在毫秒级时间内从数百万条记忆中检索最相关的内容，代价是牺牲极小的召回精度。mem0 等服务在此基础上还加入了 LLM 提取层，先用模型从对话中提取结构化记忆点（如「用户偏好使用 Python 而非 JavaScript」），再进行向量化存储，从而提高召回的精准度和可解释性——这种「先提取、再存储」的两阶段设计，避免了将冗长对话原文直接向量化导致的语义稀释问题。

一个重要的细节：外部记忆的查询发生在第一条消息之后。也就是说，当你开始一个新话题时，智能体先回复你的第一条消息，然后才会去查询外部记忆，尝试预判你接下来可能会问什么——这很像人类在回答问题后回忆相关经历的过程。因此，如果第一条消息没有触发记忆召回，可以在第二条消息中追问，此时外部记忆已经被查询过了。

Cron Jobs：定时任务调度

Hermes 的定时任务系统让智能体能够自动执行周期性工作，比如每天早上发送 AI 新闻摘要、每周五给老板发送工作汇报等。

实现机制

Hermes 的 Cron 并非依赖系统级的 cron 进程，而是自己维护了一个每分钟执行一次的循环，每次执行一个名为 tick 的函数。

传统 Unix/Linux 系统中的 cron 是一个守护进程，通过读取 crontab 配置文件来调度定时任务，使用「分 时 日 月 周」五段式表达式定义执行时间（如 0 9 * * 1-5 表示工作日早上 9 点执行）。这一语法自 1970 年代沿用至今，已成为定时任务的事实标准，被 Kubernetes CronJob、GitHub Actions schedule 等现代系统广泛沿用。然而系统级 cron 存在几个固有局限：首先是跨平台兼容性问题，Windows 没有原生 cron（Task Scheduler 语法完全不同），macOS 的 launchd 虽然功能更强但配置繁琐；其次是任务管理能力的限制，系统 cron 难以优雅实现动态添加/删除任务、任务执行状态追踪、失败重试策略、执行结果持久化等功能；第三是权限隔离问题，系统 cron 任务以特定用户权限运行，与应用进程的权限上下文不一致，可能引发环境变量、工作目录等配置问题。Hermes 选择自行实现进程内调度循环，与 Python 的 APScheduler、Node.js 的 node-cron 等应用层调度库思路一致，将调度逻辑内嵌到应用进程中，获得了完整的编程控制能力。

说个细节，尽管官方文档声称 Cron Jobs 存储在 SQLite 中，但实际源码分析表明，任务配置存储在 .hermes/cron/jobs.json 这个 JSON 文件中。每次 tick 时，系统读取该文件判断是否有任务需要执行。执行结果则存储在 .hermes/cron/output/{jobID}/ 目录下的 Markdown 文件中。JSON 文件的选择使得用户可以直接用文本编辑器查看和修改任务配置，也便于纳入版本控制系统管理。

消息投递机制

Cron 任务的结果不是通过智能体调用「发送消息」工具来投递的，而是自动发送到你设置为 Home 的消息平台。在配置 Gateway 时，系统会询问是否将某个平台设为 Home，Cron 任务的通知就会投递到该平台。

总结与启示

Hermes Agent 的架构虽然组件不多，但每个部分都经过精心设计：简洁的 Agent Loop 保证了可靠性，多层记忆系统实现了持续学习，Gateway 网关打通了日常通信渠道，Cron 系统则赋予了自主行动能力。

对于想要构建自己智能体的开发者来说，Hermes 的架构提供了几个值得借鉴的设计思路：用 Markdown 文件管理人格和记忆、用 SQLite 存储会话历史并支持全文搜索、用字符数近似估算 token 数来降低计算成本、以及在首次回复后异步查询外部记忆的策略。这些都是在工程实践中非常实用的技巧。

从更宏观的视角来看，Hermes 代表了 AI Agent 发展的一个重要方向：从无状态的对话工具演进为有记忆、有人格、能自主行动的持续学习系统。随着上下文窗口不断扩大（GPT-4o 的 128K、Claude 3.5 的 200K 仅仅是当前的起点）、向量检索与 LLM 提取相结合的记忆技术持续进步，这类智能体将越来越接近真正的「数字助手」——不仅能回答问题，还能理解你、记住你、并主动为你工作。

核心要点