Hermes Agent 架构、设置与自我改进循环详解

有一类新型 AI 工具正在悄然成形：那些并非栖息于你打开又关掉的聊天窗口中，而是在云端持续运行、通过即时通讯工具与你对话的 Agent——就像一位永远不会下线的同事。

Hermes 是这个想法中较为有趣的实现之一，它与 OpenClaw 等同类 Agent 的区别在于内置了一个自我改进循环——一个能观察你的对话、从中提取有用模式，并将这些模式转化为自身记忆和技能集永久升级的系统。

本文将介绍 Hermes 是如何构建的、如何配置它，以及那个自我改进循环在底层究竟如何运作。

Hermes 是什么，它与 OpenClaw 有何不同

Hermes 是一个驻留云端的 AI Agent，结构上与 OpenClaw 类似：它全天候运行，你通过即时通讯应用而非终端或浏览器标签与之交互。

其主要区别体现在三个方面。

首先，Hermes 开箱即用配备了更大的内置技能库，因此你花在手动配置集成上的时间更少。

其次，设置流程相当简化——一个引导式的 TUI 几乎处理了所有事情。

第三，也是最重要的一点，Hermes 围绕持续自我改进设计：它不仅执行任务，还会积累关于如何随着时间的推移更好地执行这些任务的程序性知识。

安装与初始设置

只需一条命令即可运行 Hermes。

在 Windows 上，在 PowerShell 中运行：

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

在 Linux、macOS 或 WSL 上，相应的命令为：

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

安装完成后，重启终端并运行 hermes setup 即可启动一个引导式配置流程，依次带你完成模型选择、终端后端、消息网关和工具设置。

选择与路由模型

设置中第一个真正的决策是选择哪个 LLM 提供商作为 Agent 的“大脑”。认证通过 OAuth 而非原始 API 密钥进行，这甚至可以让你通过已有的 Claude Code 或 Codex CLI 会话登录，而无需生成单独的 API 密钥。

这里设计得真正巧妙的地方在于，Hermes 将用于主对话的模型与用于后台和辅助任务的模型区分开来。默认情况下，同一个模型处理所有任务，但每个辅助任务都可以独立指向不同的提供商。

支持这种覆盖的任务包括：

• vision – 图像分析与描述
• web_extract – 总结长网页
• compression – 压缩溢出的对话上下文
• title_generation – 生成会话标题
• curator – 负责自我改进循环的后台 Agent
• kanban_decomposer – 在看板模式下将大任务分解为子任务
• goal_judge – 检查 /goal 是否已实现的 Agent

这直接在 config.yaml 中配置，例如：

## 用于聊天和复杂推理的主要模型
model:
  provider: "anthropic"
  default: "claude-4-8-sonnet"
  auxiliary:
    vision:
      provider: "gemini"
      model: "gemini-2.5-flash"
    compression:
      provider: "custom"
      base_url: "http://localhost:11434/v1"
      api_key: "none"
      model: "qwen2.5:32b"

这种显式路由解决了将 OpenRouter 作为默认选择时的一个实际问题：同一个名义模型通常由许多不同提供商部署，且常常采用不同量化级别，而 OpenRouter 会静默地将每个新请求随机分配给大约二十个实例中的某一个。

实际效果是，在单个会话中，你并非在与一个一致的模型对话——你是在与一连串配置各异的模型实例轮番对话，其中一些处理工具调用和提示模板的可靠性比其他实例更高。在 Hermes 内部手动路由完全避免了这一问题。

同样值得注意的是，如果你想在对话模型上节省成本而不牺牲编码质量，Hermes 支持 /claude_code 和 /codex 命令，这些命令直接将编码任务委托给那些 CLI 工具，而不是用配置的聊天模型来处理。

终端后端

架构的一个核心部分是终端后端环境，它决定了 shell 命令和 Python 脚本在何处及如何执行，以及 Agent 如何访问你的文件系统。Hermes 支持五种。

Local 是默认选项。命令直接在你的机器上以你用户账户的相同权限运行——无隔离。对于本地开发和受信任的个人使用来说，这是正确的选择，因为你希望 Agent 编辑你的实际项目文件。

这里的安全性完全依赖于一个内置的审批系统，该系统会拦截破坏性命令（如 rm -rf /、DROP TABLE），并在运行它们之前请求明确许可。

Docker 将 Agent 运行在隔离的沙箱中，使其无法触及你的宿主系统。SSH 让 Agent 通过远程连接在远程服务器上执行命令和处理文件。Modal 将所有内容运行在无服务器云沙箱中——你实际上按秒租用计算资源，只为代码实际运行的秒数付费。

Daytona 是一个专为 AI 编码 Agent 构建的容器管理层；它比直接运行 Docker 更快，并能自动处理环境设置和依赖安装。

对于大多数个人使用场景，Local 确实足够——其他选项主要在你运行不受信任的代码或团队规模操作时才显得重要。

消息网关与工具配置

终端后端之后，设置进入选择你实际与 Agent 对话的位置——Telegram 是最完善的选项。选择它后会提供一个直接链接，启动一个预先配置好的机器人；无需手动设置机器人 Token。

剩余的设置过程会引导你启用各个工具及其对应的提供商——浏览器自动化、图像生成、文本转语音和网络搜索。对于网络搜索，自托管的 Firecrawl 或 Exa 是面向 Agent 的抓取和检索的突出选择。

X 搜索需要订阅 Grok 才能启用，这一点在你去菜单中寻找之前值得了解。

值得了解的斜杠命令

Hermes 自带一长串斜杠命令，大多数按名称即可自明，但有少数值得特别指出。

• /background <提示> 在后台运行一个任务，不中断你的主会话。
• /goal 设置一个持久性长期目标，Agent 会持续为之努力，包含暂停、恢复、清除或检查状态的子命令；
• /subgoal 管理嵌套在当前活动目标下的较小目标。
• /kanban 协调多个独立 Agent 之间的异步、长时间运行的工作——它就像一块真正的看板，任务池被分配给工作 Agent，并在它们之间移交时经历待办、进行中和已完成的状态。

在开发方面：

• /github_pr_workflow 处理从分支到合并的完整流程，包括 CI，
• /github_code_review 审查拉取请求，
• /codebase_inspection 分析仓库的语言分布和代码行数。
• /dogfood 是一个专门的 QA 模式，用于在 Web 应用中搜索错误并生成基于证据的报告。
• /spike 运行一个快速、一次性的实验，在投入完整开发之前验证某个想法。
• /systematic_debugging 分四个阶段处理错误，在尝试修复之前先理解根本原因。

还有一组集成特定的命令——/notion、/obsidian、/airtable、/google_workspace、/arxiv、/blogwatcher、/polymarket、/ocr_and_documents、/youtube_content——每个命令封装一个特定的外部服务或工作流，再加上 /bundles，它通过小型 YAML 配置文件将多个现有技能组合到一个斜杠命令下。

Cron 任务与 Webhook

两个自动化原语值得特别关注。

Cron 任务允许你按定时器调度脚本运行；如果你在创建时传递了 -no-agent 参数，Hermes 将执行一个纯 Python 或 bash 脚本，并仅将其输出转发给你的即时通讯工具，完全不消耗 LLM Token。

Webhook 是更强大的部分：它们让 Agent 对外部事件（而非定时器）作出反应。你可以配置一个 Webhook，例如，一个新的 GitHub 拉取请求会自动触发一个具有特定提示和技能集的 Agent——这相当于为每个 PR 无需人工干预就设立了一个待命审查 Agent。

上下文引擎

上下文引擎决定了当对话历史接近模型 Token 限制时，Hermes 如何压缩和管理它，有两个选项。

默认选项称为 Compressor，对长对话的中间部分应用有损摘要。

替代选项 LCM（无损上下文管理）采用结构上不同的方法：它不是生成文本摘要，而是构建对话关键点的有向无环图，让 Agent 从高度压缩的概览视图向下导航到支持该视图的特定原始消息。

记忆引擎

外部记忆提供程序与 Hermes 的内置本地记忆文件 MEMORY.md 和 USER.md 一起运行，添加了语义搜索和知识图谱等功能。

其中几个可以直接通过设置 TUI 进行配置。

• Honcho 围绕建模详细用户档案构建，使用后台 LLM 调用来综合两个层次的观察：基础层包含会话摘要和档案，辩证层分析用户的当前需求。
• OpenViking 是一个上下文数据库，构建类文件系统的知识层次结构，支持分层上下文检索，并在每个会话结束时自动将提取的事实分类到六个类别——事件、模式、偏好等。
• Mem0 是一个完全托管的云记忆服务；事实提取通过 LLM 在服务器端进行，包括语义搜索、结果重排序和自动去重，不过由于是云端托管，它是这里唯一有持续成本的选择。
• Hindsight 是一个更先进的长期记忆系统，基于知识图谱，采用 GraphRAG 风格。它从会话中提取实体，构建它们之间的关系，并保留包括工具调用在内的完整对话轮次，记忆分为四类：关于世界的事实、Agent 自身的经验、意见和观察。
• Holographic 是一个本地的、基于 SQLite 的事实存储，无外部依赖，包含存储事实的信任评分系统，并使用全息约简表示来支持代数组合查询，能够自动检测其知识库中的矛盾。
• RetainDB 是一个用于团队记忆的云 API，提供向量、BM25 和重排序方法的混合搜索，记忆分为七个不同的类型，并使用增量压缩保持存储效率。
• ByteRover 是一个便携式本地记忆系统，通过 CLI 访问，构建分层知识树并在有损压缩有机会将它们从上下文中丢弃之前提取重要事实。
• Supermemory 提供带有图 API 的语义长期记忆：它在对话结束后吸收完整的会话日志来构建知识图谱，定期清理召回的事实以避免当前轮次造成污染，并可以将记忆隔离到每个 Agent 配置文件的独立容器中。

对于日常使用，默认的本地记忆对大多数人来说确实足够——更重的系统用真实的资源成本（尤其是本地托管选项的 RAM）来换取大多数工作流尚不需要的能力。

自我改进循环

这是 Hermes 与常规 Agent 最显著的区别：一组异步后台进程持续分析你的对话，从中提取有用模式，并将这些模式写入长期记忆和程序性记忆（技能）——然后维护这些积累的知识，使其不会随时间退化。整个系统与你的主聊天并行运行，由三个组件构成：触发系统、后台审查 Agent 和策展人。

触发系统

Hermes 不会实时分析每一条消息，因为那会无益地消耗 Token。相反，它依赖于两个计数器，一旦它们超过阈值就会触发一次反思过程。

一个记忆触发器每十次用户提示触发一次，检查对话中是否出现了值得保存的新事实。

一个技能触发器每十次工具调用迭代（在单个轮次内）触发一次，其理论是：如果 Agent 刚刚花费那么多步骤通过试错解决了问题，那么这段经验就值得分析并可能转化为可复用的技能。

一旦任一计数器达到其限制，一个内部函数就会触发，将当前对话的快照交给后台审查进程。

后台审查 Agent

这个快照会交给一个完全独立的 Agent 进程，该进程并行运行，不中断你的主会话。它双向工作。

在声明性方面，如果它注意到新的用户偏好或环境细节——对 Supabase 的偏好、项目固定使用 Python 3.12——它会更新 MEMORY.md 或 USER.md，具体取决于该事实属于哪个文件。

在程序性方面，如果它检测到 Agent 刚刚解决了一个非平凡问题或完成了一个复杂过程，它可以创建一个新技能、编辑现有技能、应用有针对性的补丁，或直接删除一个技能。它创建的任何技能都会被明确标记为 Agent 生成，因此其来源始终可追溯。

为了让策展人最终判断哪些自我生成的技能真正值得保留，Hermes 维护了一个隐藏的使用日志，追踪每个技能的：被加载到提示中的次数、被 Agent 打开读取的次数、被编辑的次数，以及创建、最后使用和最后编辑的时间戳。

策展人

如果不加检查，这个过程最终可能会产生成百上千个技能，其中一些是冗余的，一些是过时的。

策展人的存在就是为了防止知识库退化。它仅在两个条件同时满足时才开始运行：距离上次运行已经过去足够的时间（默认七天），并且主 Agent 已经空闲足够长时间（默认两小时），这样一场繁重的维护工作就不会干扰活跃工作。

在进行任何更改之前，它会自动备份整个技能目录，因此任何不满意的结果都可以通过一条终端命令回滚。

策展人的工作分两个阶段：

第一阶段纯粹是机械性的，完全不涉及 LLM 调用：它检查使用指标，将任何超过 30 天未使用的 Agent 生成技能标记为已弃用，并将超过 90 天未使用的技能移入归档文件夹。重要的技能可以显式固定以保护它们免受此过程影响。

第二阶段是真正的 LLM 审查，通过一个单独的隔离 Agent 实例运行，该实例使用为策展人辅助任务配置的任何模型——默认与主对话使用的模型相同，尽管它可以指向更便宜的模型。在这里过分追求低成本需要谨慎，因为这些决策的质量对技能库有实质性的下游影响。

对于每个技能，策展人决定：

• 如果仍然准确且有用，则原样保留，
• 如果包含错误或过时的方法，则修复它，
• 如果与另一个技能覆盖基本相同的领域，则合并（正确迁移任何关联的脚本、评估或参考文件，并在过程中重写相对路径），
• 或直接归档。

在周期结束时，它会生成一份详细报告，包括一个重命名映射，准确显示旧技能名称在合并后如何映射到新名称，因此每个决策背后的推理都是完全可审计的。

用好 Hermes

像这样的云端 Agent 对于任何你希望 24/7 运行的流程都真正有价值——编码工作是一个显著的例外——前提是你已经认真地将该流程数字化，并围绕它构建了一个扎实的技能，包括评估。

那种往往能产生良好结果的工作流程大致如下：

• 首先，详细地记录你自己从绝对开始到结束的整个流程，理想情况下使用听写工具以便准确捕捉——并且这一步只有在你真的理解该流程或已对其进行过恰当研究时才有效。
• 将那段录音或笔记输入一个编码 Agent，使用技能创建工具生成初稿；它还不值得直接移交，尤其是对于任何复杂的事情。
• 构建评估——代表正确结果的参考解决方案——因为它们能让你实际衡量技能是否表现良好，而不是靠猜测。
• 在测试环境中运行该技能，并根据观察结果改进评估和技能内容，大部分编辑工作应手动完成而非委派。
• 只有当技能表现一致且确定时，才将其移交给始终在线的 Agent。如果该流程依赖于某个外部服务，在从头构建之前，值得检查是否已有现有的 MCP 服务器或 CLI 可以覆盖它。

更广泛的观点是，你能交给这类 Agent 的任务范围主要受限于你能否很好地定义工作，而非 Agent 的原始能力。

三个原则似乎在各种用例中都成立：不要将编码工作外包给不受监督的 24/7 云端 Agent，始终有人类在环中审查 Agent 实际产出的内容，并将技能优化视为持续的工作，而非一次性完成就撒手不管的事情。

• 原文链接： x.com/scottybeamio/statu...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～