快速摘要
Hermes Agent 是由 Nous Research 团队开源的自我进化 AI Agent，目前在 GitHub 上已获得超过 49000 Star，并在 2026 年 4 月冲上了 GitHub Trending 榜首。它的核心亮点在于「自我学习闭环」——Agent 在完成任务后会自动将过程写成可复用的 Skill（技能文档），下次遇到类似任务时直接调用，无需重新推理。同时它拥有持久化记忆系统，能跨会话记住你的偏好和项目上下文，用得越久就越懂你。 它支持私有部署，数据完全自主，兼容 OpenRouter、OpenAI 等多种模型端点，还可以通过 Telegram、Discord、飞书、企业微信等 15 个以上的消息平台与你交互。往下看有关于安装部署、技能系统、记忆架构、与 OpenClaw 的对比等更详细的技术拆解。
本文由 莫潇羽@源码七号站 原创撰写，转载请注明出处：www.fuyuan7.com
一、这个项目凭什么这么火？
2026 年初开源 Agent 赛道上最热门的两个项目，一个是 OpenClaw，另一个就是 Hermes Agent。从 2026 年 2 月底开源到今天，Hermes Agent 以平均不到一周一个大版本的惊人速度迭代，截至 2026 年 4 月 10 日已更新到 v0.8.0 版本，Star 数也一路飙升到 49000 以上，登上了 GitHub Trending 日榜第一。
这种热度不是凭空来的。在开发者社区中，不少从 OpenClaw 迁移过来的用户反馈，Hermes 在响应速度和实际使用体验上有着非常明显的提升。社区的关注焦点也逐渐从"功能是否齐全"转向了"Agent 能不能自己变强"这个更本质的问题，而 Hermes Agent 恰好在回答这个问题。
那么一个刚开源不到两个月的项目，是凭什么做到近五万 Star 的呢？莫潇羽认为主要有三个原因。第一是团队背景过硬，Nous Research 在开源模型领域已经深耕多年，Hermes 系列模型的下载量超过五千万次，在社区中有极高的信任度和影响力。第二是项目切中了当前 Agent 赛道最痛的痛点——大多数 Agent 用起来像"一次性筷子"，每次都要重新教，效率低且体验差。第三是项目的完成度和工程质量确实很高，不是一个概念验证级别的 demo，而是一个经过精心设计的、可以日常使用的生产级工具。
在深入技术细节之前，莫潇羽先帮大家做一个全景扫描：Hermes Agent 不是一个绑定在 IDE 上的代码助手，也不是一个套壳聊天机器人。它是一个可以部署在你自己服务器上的自治 Agent，拥有持久记忆、自动技能生成、定时任务调度、多平台消息网关等能力。而且它是完全开源的，基于 MIT 协议发布，没有使用限制，没有供应商锁定。你可以把它理解为一个驻留在你服务器上的全天候 AI 助手——它不会在你关掉电脑后失忆，也不会因为你隔了一周没用就忘记你是谁。
二、Hermes Agent 的核心原理：自我学习闭环
2.1 什么是"自我学习闭环"？
在解释这个概念之前，我们先回顾一下当前大多数 AI Agent 的工作模式：你给它一个任务，它根据系统提示词和当前上下文进行推理，调用各种工具来完成任务，任务结束后关闭窗口，一切归零。下一次你再给它同样的任务，哪怕是完全相同的操作步骤，它依然要从头开始推理、试错、找路径。对于那些偶尔执行一次的简单任务来说，这还可以接受；但如果你每周都要做一次相同的部署操作，或者你的项目有一套独特的测试流程需要频繁执行，这种"每次都当新手"的模式就显得非常浪费了——不仅浪费你等待的时间，也浪费了大量的 Token 推理费用。
更深层的问题在于，传统 Agent 的"能力"完全取决于底层模型的通用知识和系统提示词的质量。它不会因为你使用了一百次而变得更擅长处理你的任务，它在第一次使用和第一百次使用时的表现本质上是一样的。这就像你雇了一个能力很强但患有失忆症的助手——每天早上他都不记得昨天做了什么，你需要把所有事情重新交代一遍。
Hermes Agent 的核心设计理念就是要打破这个困局，建立一条从「使用」到「学习」再到「优化」的完整闭环链路。它的目标不是做一个更聪明的一次性工具，而是做一个能够持续积累和进化的长期伙伴。具体来说，这个闭环包含四个关键环节：
- 任务执行：Agent 接收任务后，利用内置的 47 个工具（终端命令、文件管理、网页搜索、代码执行等）来完成工作。
- 技能提取：当 Agent 成功完成一个复杂任务（通常涉及 5 次以上的工具调用）后，它会自动将整个执行过程提炼成一份 Skill 文档，记录做了什么、踩了哪些坑、下次该注意什么。
- 技能复用：下次遇到类似的任务时，Agent 会检索已有的 Skill 库，直接加载相关技能文档作为执行指南，跳过重复推理的过程。
- 技能自优化：在使用 Skill 的过程中，如果发现了更好的做法或者原始方案存在不足，Agent 会自动修补和更新这份 Skill 文档。
这就是 Nous Research 团队所说的"closed learning loop"（封闭学习闭环）。它不需要人类手动维护技能库，Agent 自己写、自己用、自己改，用的时间越长，积累越厚实。
2.2 技能系统的技术实现细节
莫潇羽在查阅了 Hermes Agent 的官方文档和源码后，整理出技能系统的关键技术细节。
Hermes 的技能文件存储在 ~/.hermes/skills/ 目录下，每个技能就是一个 Markdown 文件，遵循 agentskills.io 开放标准格式。一个典型的 Skill 文档结构如下：
---
name: deploy-k8s
description: 使用 kubectl 部署应用到 Kubernetes 集群
version: 1.0.0
platforms: [macos, linux]
metadata:
hermes:
tags: [devops, kubernetes]
category: devops
---# K8s 部署技能
## 何时使用
当用户要求将应用部署到 Kubernetes 集群时触发。
## 执行步骤
1. 检查 kubectl 配置和集群连接
2. 验证部署清单文件
3. 执行滚动更新
4. 验证 Pod 状态
## 已知坑点
- 镜像拉取策略需要设置为 Always
- 节点资源不足时要检查 limits 配置
## 验证方式
kubectl get pods 确认所有 Pod 处于 Running 状态技能的加载采用了渐进式披露（Progressive Disclosure）策略来控制 Token 消耗。这个策略分为三个级别，理解这三个级别对于优化 Agent 的性能至关重要：
- Level 0（默认级别）：系统提示词中只加载技能的名称和简短描述。对于 40 个以上的技能，大约只消耗 3K Token。这是最节省的方式，适合日常使用。
- Level 1（按需加载）：当 Agent 判断当前任务需要某个特定技能时，才会加载该技能的完整 SKILL.md 内容。这个判断过程是 Agent 自主完成的，它会根据任务的关键词、上下文信息和历史经验来决定加载哪些技能。
- Level 2（主动请求）：用户通过斜杠命令（如
/deploy-k8s）直接触发某个技能时，Agent 会立即加载该技能的完整内容。
这个三级加载策略的精妙之处在于，它让 Agent 在"知道自己拥有什么能力"和"不浪费不必要的 Token"之间找到了平衡点。社区用户的实际测试表明，在拥有 40 个以上自定义技能的场景下，使用渐进式加载相比全量加载可以节省大约 60% 到 70% 的系统提示词 Token 消耗。
Agent 通过内置的 skill_manage 工具来管理技能，支持创建、更新（patch 模式，只传输变更部分，更省 Token）、删除等操作。每个安装的技能还会自动注册为一个斜杠命令，用户可以在 CLI 或消息平台中通过 /技能名 直接触发。
2.3 这条链路为什么重要？
从更深层的视角来看，Hermes Agent 日常产生的每一条工具调用记录（trajectory），都可以直接用来训练下一代模型。Nous Research 为此专门构建了 Atropos RL 环境和轨迹压缩工具，形成了一条从 Agent 使用数据到模型训练的完整管线。
这意味着 Hermes Agent 不仅仅是一个 Agent 产品，它同时也是一个数据飞轮——越多人使用，产生的高质量工具调用数据越多，训练出的模型就越强，反过来又让 Agent 变得更聪明。这条从使用到训练的自我成长链路，是 Nous Research 在 Agent 赛道上的核心竞争壁垒。
三、四层记忆架构：为什么它能越用越懂你？
Hermes Agent 的记忆系统不是一个简单的聊天历史记录。它被精心设计为四个独立的层次，每一层负责不同类型的信息，存储在不同的位置，在不同的时机被读取。莫潇羽@源码七号站 在这里给大家做一个完整的拆解。
3.1 第一层：提示词记忆（MEMORY.md 和 USER.md）
这是 Agent 的"工作知识层"，是整个记忆架构中最核心、最频繁被使用的一层。它存储在 ~/.hermes/memories/ 目录下的两个文件中：
MEMORY.md存储关于你的环境和项目的事实性信息。比如你正在开发的项目使用了什么技术栈，代码仓库的目录结构是什么样的，团队遵循什么编码规范，之前在部署时踩过哪些坑等等。这些都是"关于你的工作环境"的硬知识。USER.md存储关于你个人的软信息。比如你喜欢简洁还是详细的回复风格，你在讨论技术方案时偏好什么样的分析角度，你习惯使用什么工具链，你曾经纠正过 Agent 的哪些行为等等。这个文件让 Agent 不仅了解你的项目，还了解"你这个人"。
两个文件分开存储是有意设计的。项目信息和个人偏好本质上是不同类型的知识，分开管理可以让 Agent 在更换项目时保留对你个人习惯的了解，也可以在多人协作场景中共享项目记忆而不泄露个人偏好。
这两个文件会在每个会话开始时注入到系统提示词中，作为一个冻结快照。这里有一个精妙的设计细节需要特别说明：会话中 Agent 通过 memory 工具做的修改会立即写入磁盘，但不会在当前会话的系统提示词中生效，要等到下一个会话才能看到变化。这种"冻结快照"模式是故意设计的，目的是保护 LLM 的前缀缓存（prefix cache）。
为什么前缀缓存这么重要呢？简单来说，LLM 在处理你的对话时，系统提示词的部分通常是固定不变的。如果这个固定部分在会话中途被修改，LLM 就需要重新计算整个提示词的表示，无法复用之前缓存的计算结果。对于使用 Claude 等按 Token 计费的模型来说，这会导致每轮对话的推理成本显著增加。通过将记忆快照冻结在会话开始时，Hermes 确保了系统提示词的稳定性，从而让 LLM 能够最大程度地利用前缀缓存来降低费用。
记忆空间有字符上限（默认 2200 个字符）。你可能会觉得 2200 个字符有点少，但这恰恰是设计的精髓。有限的空间迫使 Agent 必须做出取舍和压缩，只保留真正重要的信息。当记忆接近满载时，Agent 会主动合并和压缩条目，把三条分散的"项目使用了 X"合并成一条完整的项目描述。这样既保证了关键信息不会丢失，又不会让系统提示词无限膨胀。
Agent 管理记忆的具体操作方式如下：
# 添加新条目
memory(action="add", content="用户的项目使用 Go 1.22，sqlc 做数据库查询，chi 路由器")
# 替换已有条目
memory(action="replace",
old_text="Docker 不要用 sudo",
new_text="Docker 不要用 sudo —— 用户已在 docker 组中")
# 删除过时条目
memory(action="remove", content="数据库已从 MySQL 迁移完成")注意这里没有 read 操作——记忆是自动注入的，Agent 不需要主动读取。
来看一个实际的记忆内容示例：
══════════════════════════════════════════════
MEMORY（你的个人笔记）[67% — 1,474/2,200 字符]
══════════════════════════════════════════════
用户的项目是位于 ~/code/myapi 的 Rust Web 服务，使用 Axum + SQLx
§ 这台机器运行 Ubuntu 22.04，安装了 Docker 和 Podman
§ 用户喜欢简洁回复，不喜欢冗长解释3.2 第二层：会话归档（Session Archive）
所有的 CLI 和消息平台会话都存储在 SQLite 数据库（~/.hermes/state.db）中，并且建立了 FTS5 全文搜索索引。FTS5 是 SQLite 的全文搜索扩展，提供了类似搜索引擎的查询能力，支持前缀匹配、短语搜索等高级功能。
当 Agent 需要回忆过去的对话时，它可以通过内置的 session_search 工具来检索历史会话。搜索的流程分为两步：首先在 FTS5 索引中检索匹配的会话片段，然后由一个辅助 LLM（默认使用你配置的模型，通常是 Gemini Flash 等轻量模型来节省费用）对检索结果进行智能摘要，最后将摘要注入到当前上下文中。
来看一个实际的使用场景。假设两周前你和 Agent 一起排查过一个数据库连接超时的问题，最终发现是连接池配置不当。两周后类似的问题再次出现，你对 Agent 说"我们之前是不是遇到过数据库超时的问题？当时是怎么解决的？"Agent 会搜索历史会话，找到那次排查的完整过程，提炼出关键信息（修改了哪个配置项、改成了什么值），然后回复你。这个过程不需要你记住那次对话发生在哪天，也不需要手动翻阅聊天记录。
这一层处理的是情景记忆（episodic memory），即"发生了什么、在什么时候"，它和技能层处理的程序记忆（procedural memory，即"怎么做事"）是刻意分开的。从认知科学的角度来说，人类大脑中的海马体负责情景记忆，基底神经节负责程序记忆，两者有不同的存储和检索机制。Hermes 的记忆架构在一定程度上模拟了这种分离。
这种分离设计的实际好处是避免了信息检索的混乱。想象一下，如果所有类型的记忆混在一个存储中，当 Agent 搜索"Docker 部署"时，它可能同时找到"上周三我们讨论了 Docker 部署方案"（情景记忆）和"Docker 部署应该先检查镜像版本再执行 pull"（程序记忆），这两种信息的用途完全不同，混在一起会降低检索质量。分开存储后，Agent 可以根据当前需求选择从哪一层检索信息。
社区用户的实际使用反馈显示，运行数月的 Hermes 实例在存储了数千个会话的情况下，搜索性能并没有明显下降，SQLite 的 FTS5 索引在这个规模下表现稳定。
3.3 第三层：技能库（Skills）
前面已经详细介绍了技能系统，这里从记忆架构的角度补充一个关键点：技能是 Agent 的程序记忆，回答的是"这件事该怎么做"的问题。当 Agent 完成一个复杂任务时，它会判断这个过程是否值得保存为技能。如果值得，它就会提取关键步骤和注意事项，生成一份 Skill 文档。这些文档不仅 Agent 自己可以用，还兼容 agentskills.io 开放标准，可以在社区中分享和导入。
3.4 第四层：用户建模（Honcho 引擎）
Hermes Agent 集成了 Honcho 辩证式用户建模引擎，它会在交互过程中逐步构建一个关于你的综合画像——不只是你的偏好设置，还包括你的领域知识水平、工作风格、沟通模式、甚至你在不同话题上的立场和习惯用语。这个模型随着使用时间的增长会越来越精准，最终让 Agent 的回复风格和内容组织方式自然而然地匹配你的预期。
"辩证式"（Dialectic）这个词在这里有特定的含义：Honcho 不是简单地记录"用户喜欢 X"这样的静态标签，而是通过持续的对话交互来不断修正和深化对你的理解。比如它可能最初判断你是一个偏好详细解释的用户，但在几次互动后发现你只在学习新技术时需要详细解释，在处理熟悉领域的任务时反而喜欢简洁直接的指令式回复。这种"在使用中持续修正用户画像"的能力，是 Honcho 区别于传统用户偏好系统的核心特点。
Honcho 现在已经作为统一记忆提供者系统的七个 Provider 之一集成在 Hermes 中。如果你之前单独配置过 Honcho，升级后会自动迁移配置，不需要手动操作，也不会丢失已有的用户建模数据。
3.5 "周期性自省"机制
四层记忆不是被动存储的，Hermes Agent 有一个被称为周期性自省（Periodic Nudge）的机制来主动管理记忆。在会话进行的过程中，系统会定期向 Agent 发送一个内部提示，要求它回顾最近发生的事情，判断是否有值得持久化到记忆中的内容。这个过程不需要用户介入，完全在后台运行。
Agent 会根据信息的性质来判断它应该放在哪一层：如果一条信息在未来每次对话中都很重要，它就写入 MEMORY.md 或 USER.md；如果它只在特定话题再次出现时才有用，就留在会话归档中按需检索。这种分层判断机制，是 Hermes Agent 记忆系统保持精准和高效的关键。
四、Hermes Agent 与 OpenClaw 的深度对比
了解了 Hermes Agent 的核心机制之后，我们不可避免要和 Agent 赛道上的另一个热门项目 OpenClaw 做一个对比。莫潇羽认为，这两个项目解决的是 Agent 发展路径上的两个不同阶段的问题。
4.1 定位差异
OpenClaw 解决的核心问题是连接。它让 Agent 能够接入各种渠道、使用各种工具，打造了丰富的插件生态系统。OpenClaw 的竞争优势在于它的生态广度——支持的工具多、平台多、社区贡献的插件丰富。
Hermes Agent 解决的核心问题是积累。它让 Agent 用得越久越懂你，时间本身就是它的竞争壁垒。当连接基础设施建好之后，自然而然的下一个问题就是：Agent 能不能自己变强？Hermes 正在回答这个问题，而 OpenClaw 目前在自我进化能力上还比较薄弱。
4.2 技能管理方式的本质区别
这是两者最核心的差异点，莫潇羽@源码七号站认为理解这个区别是判断 Agent 赛道未来走向的关键。
OpenClaw 的技能管理模式可以类比为"应用商店"模式。社区开发者编写技能，提交到公共仓库，其他用户从仓库中挑选安装。技能的质量取决于社区贡献者的水平，更新频率取决于维护者的活跃度。这种模式的优点是标准化程度高、可以快速获取大量通用技能；缺点是技能与你的具体工作场景之间总是存在一个"适配缝隙"——通用技能无法覆盖你独特的项目需求和个人习惯。
Hermes Agent 的技能管理模式可以类比为"学徒成长"模式。Agent 在陪你工作的过程中，自己总结出"这类事情应该怎么做"的经验，并且随着使用不断修正和完善。这些技能天然就是针对你的工作场景定制的，不存在适配问题。更重要的是，技能的积累速度完全取决于你和 Agent 的互动频率——你用得越多，Agent 积累的技能就越丰富，也越精准。
举一个具体的例子来说明这种差异。假设你有一个项目，每次部署都需要先跑一遍特定的测试套件，然后检查特定环境变量是否配置正确，再按照特定的顺序执行三个部署脚本，最后验证几个关键 API 端点是否正常响应。在 OpenClaw 中，你需要自己编写一个包含所有这些步骤的技能文件，或者在社区找一个类似的技能然后手动修改。而在 Hermes 中，你只需要手动完成一次这个部署流程（或者口述让 Agent 执行一次），Agent 就会自动把整个过程提炼成一个 Skill，包括所有的细节、注意事项和验证步骤。下次你只需要说"部署一下"，Agent 就知道该怎么做了。如果某次部署过程中发现测试套件需要额外加一个新的检查项，Agent 还会自动更新这个 Skill。
4.3 互通而非对立
值得注意的是，这两个项目并不是互斥的关系。事实上它们已经可以互通——一个 Hermes Agent 和一个 OpenClaw Agent 可以互相委派任务。在开源社区里，不少开发者的做法是搭配使用：利用 OpenClaw 的丰富工具生态做连接层，利用 Hermes 的自我学习能力做积累层，各取所长。
如果你本地电脑上已经安装了 OpenClaw，在安装 Hermes Agent 的过程中还会自动提供迁移选项，可以一键导入原有的设置、记忆和技能，迁移成本非常低。
五、从零开始部署 Hermes Agent（详细教程）
说了这么多原理，接下来莫潇羽@源码七号站 带大家一步步把 Hermes Agent 跑起来。整个过程比你想象的简单得多。
5.1 系统要求
Hermes Agent 目前支持以下平台：
- Linux（主要开发和测试平台）
- macOS（完整支持）
- WSL2（Windows 用户通过 Windows Subsystem for Linux 2 使用）
- Android（通过 Termux 终端模拟器）
- Docker（容器化部署）
需要注意的是，原生 Windows 环境暂不支持，Windows 用户需要先安装 WSL2。
运行环境需要 Python 3.11 或以上版本。安装脚本会自动处理大部分平台相关的依赖，但如果你的系统没有预装 Python 3.11，可能需要先手动安装。
5.2 一键安装
Hermes 提供了一键安装脚本，在终端中执行以下命令即可：
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash这个脚本会自动完成以下工作：
- 检测你的操作系统和 CPU 架构
- 安装必要的系统依赖（如 Python、git、curl 等）
- 下载 Hermes Agent 源码到本地
- 创建 Python 虚拟环境并安装所有依赖包
- 配置 hermes 命令到系统 PATH 中
安装过程大约需要几分钟，取决于你的网络速度和机器性能。安装脚本在各个平台上的行为有所不同：在 Linux 上它会使用系统包管理器安装依赖，在 macOS 上会检查 Homebrew 是否可用，在 Android Termux 上会安装一个精简版的依赖集（因为完整的语音依赖在 Android 上不兼容）。
如果你更习惯从源码手动安装，也可以按照以下步骤操作：
# 克隆仓库
git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
# 安装 uv 包管理器
curl -LsSf https://astral.sh/uv/install.sh | sh
# 创建虚拟环境
uv venv venv --python 3.11
source venv/bin/activate
# 安装所有依赖
uv pip install -e ".[all,dev]"手动安装的好处是你可以完全掌控安装过程，适合那些对自己的开发环境有特殊配置需求的用户。
5.3 初始配置
安装完成后，需要刷新一下环境变量并运行配置向导：
source ~/.bashrc
hermes setuphermes setup 会启动一个交互式配置向导，引导你完成以下设置：
选择模型提供商：Hermes 支持非常灵活的模型配置，你可以选择：
- Nous Portal（Nous Research 自己的模型端点）
- OpenRouter（聚合了 200 多个模型，选择最丰富）
- OpenAI 兼容端点（包括 Kimi/Moonshot、MiniMax、智谱 GLM 等国内模型）
- 本地模型（通过 Ollama、LM Studio 等本地推理框架）
- 任意自定义端点
填写 API Key：根据你选择的提供商，输入对应的 API Key。如果使用 OpenRouter，只需要一个 OpenRouter 的 Key 就可以访问 200 多个模型。
配置消息平台（可选）：如果你想通过 Telegram、Discord 等平台和 Agent 交互，这一步会引导你完成对应的 Bot Token 配置。
整个配置过程通常不超过 5 分钟。配置完成后，直接在终端输入 hermes 就可以开始对话了。
5.4 从 OpenClaw 迁移
如果你之前使用 OpenClaw，Hermes 提供了完善的迁移工具。在运行 hermes setup 时，配置向导会自动检测 ~/.openclaw 目录，如果发现了 OpenClaw 的安装，会主动询问是否要迁移。
你也可以手动执行迁移命令：
# 交互式迁移（完整模式）
hermes claw migrate
# 预览将要迁移的内容（不实际执行）
hermes claw migrate --dry-run
# 只迁移用户数据，不迁移 API Key 等敏感信息
hermes claw migrate --preset user-data
# 覆盖已存在的冲突项
hermes claw migrate --overwrite迁移工具会自动导入你在 OpenClaw 中的设置、记忆、技能和 API Key，让你在 Hermes 上无缝继续之前的工作。
5.5 基础使用
启动 Hermes 后，你会看到一个全功能的终端 UI（TUI），支持多行编辑、斜杠命令自动补全、对话历史浏览、中断重定向等操作。以下是一些常用命令：
# 启动 Hermes CLI
hermes
# 切换模型
hermes model
# 查看已安装的工具
hermes tools
# 查看技能列表
hermes skills
# 查看日志
hermes logs
# 管理配置
hermes config show在对话中，你可以使用斜杠命令来快速操作：
/memory 查看当前记忆内容
/skills 列出所有可用技能
/model 切换对话使用的模型
/bg 将当前任务放到后台运行5.6 配置消息网关
Hermes Agent 的一大特色是它不绑定在终端上。通过消息网关（Gateway），你可以从多个平台和它交互，这在实际使用中带来了极大的便利。想象一个场景：你正在出门的路上，突然想到一个需要 Agent 处理的任务，你可以直接打开手机上的 Telegram 给 Agent 发一条消息，Agent 会在你的服务器上开始执行任务，你到达目的地后打开电脑的终端就能看到执行结果。
目前 Hermes 支持的消息平台已经覆盖了全球主流的即时通讯工具：
- Telegram（最成熟的集成，支持语音消息、文件传输、按钮审批）
- Discord（支持语音频道交互）
- Slack（支持多工作空间 OAuth，v0.8.0 新增按钮审批和线程上下文保持）
- WhatsApp、Signal（端到端加密消息平台）
- Matrix、Mattermost（开源即时通讯）
- 电子邮件、短信
- 飞书 / Lark（完整的飞书适配，支持事件订阅、消息卡片、群聊、图片和文件附件）
- 企业微信 / WeCom（支持文字、图片、语音消息和群聊）
- DingTalk（钉钉集成）
- Home Assistant（智能家居平台集成）
- BlueBubbles（苹果 iMessage 桥接）
所有平台共享同一个 Agent 实例，记忆和上下文完全互通。你可以在 Telegram 上开始一个任务，在电脑的终端上检查进度，再在 Discord 上继续讨论，Agent 始终保持完整的上下文。对于国内用户来说，飞书和企业微信的原生支持是一个非常大的亮点，这意味着你可以在日常办公工具中直接和 Agent 交互，不需要额外安装其他应用。
配置消息网关的方式很简单，在 ~/.hermes/config.yaml 中添加对应平台的配置即可。以 Telegram 为例：
messaging:
telegram:
bot_token: "你的Bot Token"
allowed_users:
- "你的Telegram用户ID"对于飞书的配置，你需要在飞书开放平台创建一个机器人应用，获取 App ID 和 App Secret，然后配置事件订阅的回调地址。Hermes 的文档中有详细的飞书集成指南，涵盖了从创建应用到消息卡片配置的完整流程。
然后启动网关服务：
hermes gateway start网关服务会作为一个后台进程运行，同时监听所有已配置平台的消息。你可以通过 hermes gateway status 查看当前连接状态，确认各个平台是否正常在线。
六、六种终端后端：灵活的部署选项
Hermes Agent 提供了六种终端后端，适应不同的部署场景。莫潇羽在这里逐一说明它们的适用场景和配置方式。
6.1 Local（本地模式）
最简单的模式，Agent 直接在你的机器上执行命令。适合个人开发者在自己的工作站上使用。不需要额外配置，默认就是这个模式。
6.2 Docker（容器模式）
Agent 在 Docker 容器中执行命令，提供一定程度的隔离。适合需要安全隔离但又不想配置远程服务器的场景。Hermes 提供了官方 Dockerfile，支持 CLI 和 Gateway 两种运行模式。
# 使用 Docker 运行 Hermes
docker run -d \
-v ~/.hermes:/root/.hermes \
nousresearch/hermes-agent:latest6.3 SSH（远程服务器模式）
Agent 通过 SSH 连接到远程服务器执行命令。适合你有一台专门的开发服务器，想让 Agent 在那台机器上工作的场景。
6.4 Daytona（无服务器持久化）
Daytona 提供了无服务器的持久化环境。Agent 的工作环境在闲置时自动休眠，有请求时自动唤醒，闲置期间几乎不产生费用。适合需要 Agent 随时待命但使用频率不高的场景。
6.5 Singularity（HPC 环境）
为高性能计算集群设计的后端，适合需要大规模算力支持的 Agent 任务。
6.6 Modal（云端无服务器）
与 Daytona 类似，提供无服务器的持久化计算环境。环境在闲置时休眠，有任务时自动启动，适合将 Agent 部署在云端的场景。
七、高级功能详解
7.1 定时任务（Cron 调度）
Hermes Agent 内置了 Cron 调度器，这是它区别于大多数 Agent 的一个杀手级功能。你可以让 Agent 在无人值守的情况下定时执行任务，真正实现了 Agent 的自治运行。
和传统的 Linux cron 不同，Hermes 的定时任务支持用自然语言设置。你不需要记住 cron 表达式的语法，只需要告诉 Agent "每天早上 9 点给我生成一份项目进展报告"或者"每个小时检查一次服务器的磁盘使用率"，Agent 会自动将自然语言描述转换为对应的 cron 表达式。
典型的使用场景包括：
- 每天早上自动生成项目进展报告并发送到 Telegram 或飞书
- 每小时检查一次服务器状态，发现异常时主动告警
- 每周一自动整理上周的代码提交记录，生成周报草稿
- 定期备份重要文件到指定位置
- 定期检查项目依赖的安全漏洞并生成报告
定时任务的执行结果会自动发送到你配置的消息平台上。这里有一个 v0.8.0 版本的重要改进：超时机制现在基于实际的工具活动而不是挂钟时间来判断。这意味着如果一个定时任务正在积极地执行（比如在做一个耗时的代码分析），它不会因为"运行时间太长"而被强制终止。只有真正处于空闲状态的任务才会被超时回收。这个改动解决了之前版本中长时间运行的报告任务被意外终止的问题。
7.2 子代理（Subagent）
Hermes 支持派生隔离的子代理来并行处理工作流。每个子代理拥有独立的对话上下文、终端环境和 Python RPC 脚本，可以实现零上下文成本的并行管线。
这意味着你可以让主 Agent 同时处理多个独立任务，而不会相互干扰。比如一个子代理在处理代码审查，另一个在部署应用，第三个在编写文档，它们互不影响。子代理完成任务后，结果会汇报给主 Agent，由主 Agent 做最终的整合。
在实际工程场景中，子代理的一个典型应用是"程序化工具调用"（Programmatic Tool Calling）。传统的方式是 Agent 一步步调用工具，每一步都需要一次 LLM 推理来决定下一步做什么。而通过 execute_code 工具，Agent 可以编写一段 Python 脚本来批量执行多步操作，将原本需要十几轮 LLM 推理的管线压缩成一次推理加一次代码执行。这不仅大幅提升了执行速度，还显
