新一类 AI 工具正在悄然成形：这些 Agent 不再局限于你打开又关闭的聊天窗口，而是持续运行在云端，通过即时通讯工具与你对话，就像一个永不掉线的同事。
Hermes 是这一理念下最有趣的实现之一，它与 OpenClaw 等同类 Agent 的核心区别在于内置了自我改进循环——一个能观察你的对话、从中提取有用模式，并将这些模式转化为自身记忆和技能集永久升级的系统。
本文将介绍 Hermes 的架构、配置方法，以及这个自我改进循环在底层实际运作的原理。
Hermes 是什么，它与 OpenClaw 有何不同
Hermes 是一个云端 AI Agent，结构上与 OpenClaw 类似：它 24/7 运行，你通过即时通讯应用（而非终端或浏览器标签页）与之交互。
其显著差异体现在三个方面。
首先，Hermes 开箱即用，自带更庞大的内置技能库，因此你花在配置集成上的时间更少。
其次，设置流程更加精简——一个引导式的 TUI（终端用户界面）几乎能处理所有事务。
第三，也是最重要的一点，Hermes 围绕持续自我改进设计：它不仅仅执行任务，还会积累关于如何更好执行任务的程序性知识，并随时间推移不断优化。
安装与初始设置
运行 Hermes 只需一条命令。
在 Windows 上，在 PowerShell 中运行：
iex (irm
在 Linux、macOS 或 WSL 上，等效命令为：
curl -fsSL
安装完成后，重新启动终端并运行 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 中完成，例如：
1# Primary model for chat and complex reasoning2model:3 provider: "anthropic"4 default: "claude-4-8-sonnet"5 auxiliary:6 vision:7 provider: "gemini"8 model: "gemini-2.5-flash"9 compression:10 provider: "custom"11 base_url: "http://localhost:11434/v1"12 api_key: "none"13 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 更快，并能自动处理环境设置和依赖安装。
对于大多数个人使用场景，本地后端完全足够——其他选项主要在你运行不可信代码或团队规模运营时才显得重要。
消息网关与工具配置
终端后端设置完成后，下一步是选择与你实际对话的渠道——Telegram 是最成熟的选项。选择它后会生成一个直接链接，即可启动一个预配置的机器人；无需手动设置机器人令牌。
设置的剩余部分会引导你启用各个工具及其相应的提供商——浏览器自动化、图像生成、文本转语音和网络搜索。对于网络搜索，自托管的 Firecrawl 或 Exa 是面向 Agent 的抓取和检索的优秀选择。
X 搜索需要 Grok 订阅才能启用，这一点在你在菜单中寻找之前值得了解。
值得了解的斜杠命令
Hermes 附带一长串斜杠命令，大部分根据名称即可理解其用途，但有几个需要特别指出。
/background <prompt>在后台运行任务，不中断主会话。/goal设置一个 Agent 持续努力追求的长期目标，并包含暂停、恢复、清除或检查状态的子命令；/subgoal管理嵌套在活跃目标下的较小目标。/kanban通过多个独立 Agent 编排异步、长期运行的工作——类似于一个实际看板，任务池在 Worker 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 任务与 Webhooks
两个自动化原语值得特别关注。
- Cron 任务允许你按定时计划运行脚本；如果在创建时传递
-no-agent参数，Hermes 将执行纯 Python 或 Bash 脚本，并仅将其输出转发到你的消息应用，完全不消耗任何 LLM 令牌。 - Webhooks 是更强大的部分：它们让 Agent 响应外部事件（而非定时器）。你可以配置一个 webhook，例如，当 GitHub 上新建一个拉取请求时，自动触发一个带有特定提示和技能集的 Agent——实际上就是为每个 PR 部署一个随叫随到的审查 Agent，无需任何手动干预。
上下文引擎
上下文引擎决定了 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 和策展人（Curator）。
- 触发系统
Hermes 不会实时分析每条消息，因为那会浪费令牌而毫无益处。相反，它依赖两个计数器，当它们超过阈值时触发一轮反思。
记忆触发器每十个用户提示触发一次，检查对话中是否出现了值得保存的新事实。
技能触发器每轮对话中每十次工具调用迭代触发一次，其理论是：如果 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。
- 只有当技能表现一致且确定时，才将其交接给始终在线的 Agent。如果该流程依赖于某个外部服务，在从头构建之前，值得检查现有的 MCP 服务器或 CLI 是否已覆盖该服务。
更广泛的观点是，你可以交给像这样 Agent 的任务范围主要受限于你描述工作的能力，而非 Agent 的原始能力。
三个原则似乎在各种使用场景中普遍适用：不要将编码工作外包给无监督的 24/7 云端 Agent，保持人工参与审查 Agent 实际产出的内容，并将技能优化视为持续工作，而非一次性完成就置之不理的事情。
如果这篇文章对你有帮助——请收藏它。你以后会需要回来查阅的。
想要获取更多类似的深度解析，请关注 @ScottyBeamIO
没有废话，只有真正有效的内容。
