Hermes 智能体完整指南：架构、搭建与自我进化循环

Hermes Agent 完整指南：架构、设置，以及自我改进循环 2026 年 6 月 16 日 · 15 分钟阅读 · 查看原文 ↗ AI Claude 自动化 YouTube 有一类新的 AI 工具正在悄然成形：那些不活在你打开又关掉的聊天窗口里、而是持续运行在云端、通过一个即时通讯工具跟你说话的智能体——像一个永远不会下线的同事。 Hermes 是这个想法中比较有意思的实现之一，而它区别于 OpenClaw 等同类智能体的，是一个内置的自我改进循环——一个观察你的对话、从中提取有用模式、并把那些模式变成对它自己记忆和技能集的永久升级的系统。 这篇文章走一遍 Hermes 是如何拼装起来的、如何配置它，以及那个自我改进循环在引擎盖下到底是如何工作的。 Hermes 是什么，以及它与 OpenClaw 有何不同 Hermes 是一个云端常驻的 AI 智能体，结构上与 OpenClaw 相似：它 7×24 运行，你通过一个即时通讯应用与它交互，而不是终端或浏览器标签页。 有意义的区别有三点。 第一，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 供应商为智能体的"大脑"供能。认证通过 OAuth 而不是原始 API 密钥完成，这延伸到一个好处：能通过一个已有的 Claude Code 或 Codex CLI 会话登录，而不必单独生成一个 API 密钥。 这里真正设计精妙的地方，是 Hermes 如何把"用于你主对话的模型"和"用于后台与辅助任务的模型"分开。默认情况下，同一个模型两者兼做，但每一个辅助任务都可以独立地指向不同的供应商。 支持这种覆盖的任务有： vision —— 图像分析与描述 web_extract —— 总结长网页 compression —— 压缩一个溢出的对话上下文 title_generation —— 生成会话标题 curator —— 负责自我改进循环的后台智能体 kanban_decomposer —— 在 Kanban 模式下把大任务拆成子任务 goal_judge —— 检查一个 /goal 是否真的达成了的智能体 这直接在 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 工具，而不是用配置的聊天模型处理。 终端后端 架构的核心部件是终端后端环境（Terminal Backend Environment），它决定 shell 命令和 Python 脚本实际在哪里、如何执行，以及智能体如何触碰你的文件系统。Hermes 支持五种。 Local（本地）是默认选项。命令直接在你的机器上运行，权限与你的用户账户相同——没有隔离。对于本地开发和可信的个人使用来说，这是正确的选择，因为你想让智能体编辑你实际的项目文件。 这里的安全性完全依赖一个内置的审批系统，它拦截破坏性命令（一个 rm -rf /、一个 DROP TABLE），并在运行前请求明确许可。 Docker 在一个隔离沙箱里运行智能体，这样它碰不到你的宿主系统。SSH 让智能体通过远程连接，在一台远程服务器上执行命令、处理文件。Modal 在无服务器云沙箱里运行一切——本质上你是按秒租计算，只为你的代码真正运行的那几秒付费。 Daytona 是一个为 AI 编码智能体量身定制的容器管理层；它比直接跑 Docker 更快，并自动处理环境设置和依赖安装。 对大多数个人用例来说，Local 真的就足够了——其他选项主要在你跑不可信代码、或是在团队规模上运作时才有意义。 消息网关与工具配置 在终端后端之后，设置进入"你究竟在哪里跟智能体说话"的选择——Telegram 是最打磨好的选项。选中它会给你一个直接链接，起一个预配置好的机器人；没有手动的 bot-token 设置。 设置的其余部分走过启用各个工具及其各自的供应商——浏览器自动化、图像生成、文本转语音，以及网络搜索。就网络搜索而言，自托管的 Firecrawl 或 Exa，是面向智能体的抓取和检索的强有力选择。 X 搜索需要 Grok 订阅才能启用，这一点值得在你去菜单里找它之前知道。 值得知道的斜杠命令 Hermes 自带一长串斜杠命令，大多看名字就自明，但有少数几个值得单独点出来。 /background <prompt> 在后台运行一个任务，不打断你的主会话。 /goal 设定一个智能体持久推进的长期目标，带子命令用于暂停、恢复、清除或查看状态； /subgoal 管理一个活跃目标下嵌套的较小目标。 /kanban 编排跨多个独立智能体的异步、长期工作——像一个真正的 Kanban 看板一样运作，一池任务在工人智能体之间分配，随着在它们之间交接，依次走"待办、进行中、已完成"。 在开发这一侧，/github_pr_workflow 处理从分支到合并的完整周期，包括 CI，/github_code_review 审查拉取请求，/codebase_inspection 分析一个仓库的语言构成和行数。/dogfood 是一个专门的 QA 模式，在一个 Web 应用里找 bug，并产出一份有证据支撑的报告。/spike 跑一个快速的、用完即弃的实验，在投入完整开发前验证一个想法，而 /systematic_debugging 分四个阶段处理 bug，在尝试修复之前先理解根因。 还有一簇集成专属命令——/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 是更强大的一件：它们让智能体对外部事件而不是定时器做出反应。你可以配置一个 webhook，使得比如一个新的 GitHub 拉取请求自动触发一个带特定提示词和技能集的智能体——实际上就是架起一个无需每个 PR 手动干预的随叫随到审查智能体。 上下文引擎 上下文引擎管理 Hermes 在对话历史接近模型 token 上限时，如何压缩和管理它，而这里有两个选项。 默认的那个叫 Compressor（压缩器），对一段长对话的中间部分应用有损摘要。 替代选项 LCM（无损上下文管理，Lossless Context Management）采用结构性不同的方法：它不产生文本摘要，而是构建一张对话关键点的有向无环图，让智能体能从一个高层的、高度压缩的视图，向下导航到支撑它的那些具体原始消息。 记忆引擎 外部记忆供应商与 Hermes 内置的本地记忆文件 MEMORY.md 和 USER.md 并肩运行，增加语义搜索和知识图谱等能力。 有几个可以直接通过设置 TUI 配置。 Honcho 围绕建模一个详细的用户画像构建，使用后台 LLM 调用在两层上综合观察：一层基础的会话摘要与画像，以及一个分析用户当前需求的辩证层。 OpenViking 是一个上下文数据库，构建一个文件系统式的知识层级，支持分层上下文检索，并在每个会话结束时把提取出的事实自动归入六类——事件、模式、偏好，等等。 Mem0 是一个全托管的云端记忆服务；事实提取在服务端通过 LLM 发生，它包含语义搜索、结果重排和自动去重，不过作为云端托管，它也是这里唯一一个有周期性成本的选项。 Hindsight 是一个更高级的长期记忆系统，建立在知识图谱之上，属于 GraphRAG 风格。它从会话中提取实体，在它们之间构建关系，并保留完整的对话轮次，包括工具调用，记忆被分为四类：关于世界的事实、智能体自身的经验、观点，以及观察。 Holographic 是一个本地的、基于 SQLite 的事实存储，没有外部依赖，包括一个针对已存事实的信任评分系统，以及使用全息降维表征（Holographic Reduced Representations）来支持代数的、组合式的查询，并能在其知识库内自动检测矛盾。 RetainDB 是一个用于团队记忆的云端 API，提供跨向量、BM25 和重排方法的混合搜索，记忆被拆成七种不同的类型，并用增量压缩保持存储高效。 ByteRover 是一个通过 CLI 访问的便携式本地记忆系统，构建一个层级知识树，并在有损压缩有机会把它们从上下文里丢掉之前，提取重要事实。 Supermemory 提供一个带图 API 的语义长期记忆：它在一次对话结束后摄入完整的会话日志来构建知识图谱，定期清理被召回的事实以避免被当前轮次污染，并能把记忆隔离进每个智能体画像各自的独立容器。 对于日常使用，默认的本地记忆对大多数人来说真的够用——那些更重的系统，是在用真实的资源成本（对本地托管选项来说尤其是 RAM）去换取大多数工作流目前还不需要的能力。 自我改进循环 这是最让 Hermes 区别于传统智能体的特性：一组异步后台进程，持续分析你的对话，从中提取有用的模式，并把那些模式写进长期记忆和程序性记忆（技能）——然后维护那份积累下来的知识，好让它不会随时间衰退。整个系统与你的主聊天并行运行，由三个组件构成：一个触发器系统、一个后台审查智能体，以及一个策展人（curator）。 触发器系统 Hermes 不会实时分析每一条消息，因为那会白白烧 token。相反，它依赖两个计数器，一旦越过阈值就触发一次反思。 一个记忆触发器每十个用户提示词触发一次，检查对话里是否出现了值得保存的新事实。 一个技能触发器在单轮之内每十次工具调用迭代触发一次，其理论是：如果智能体刚刚花了那么多步靠试错硬啃一个问题，那份经验就值得分析，也可能值得变成一个可复用的技能。 一旦任一计数器撞到上限，一个内部函数就触发，把当前对话的快照交给一个后台审查进程。 后台审查智能体 这份快照进入一个完全独立的、隔离的智能体进程，它并行运行，不打断你的主会话。它朝两个方向工作。 在声明式一侧，如果它注意到新的用户偏好或环境细节——对 Supabase 的偏好、一个锁定在 Python 3.12 的项目——它就更新 MEMORY.md 或 USER.md，取决于那条事实属于哪个文件。 在程序式一侧，如果它检测到智能体刚刚解决了一个非平凡的问题、或者摸索出了一个复杂流程，它就能创建一个新技能、编辑一个已有的、打一个针对性补丁，或者直接删掉一个。它创建的任何技能都会被显式标记为"agent-generated"（智能体生成的），所以它的来源总是可追溯的。 为了让策展人最终能判断这些自生成技能里哪些真正值得保留，Hermes 维护一份隐藏的使用日志，为每一个技能追踪：它被加载进提示词的次数、智能体打开它去读它的次数、它被编辑的次数，以及创建、最近使用、最近编辑的时间戳。 策展人 不加约束的话，这个过程最终可能产生数百个技能，有些冗余，有些过时。 策展人的存在，就是为了让那个知识库不退化。它只在两个条件同时成立时才启动：距它上次运行已经过了足够久（默认七天），而且主智能体已经闲置了足够久（默认两小时），好让一次沉重的维护不会干扰活跃工作。 在做任何更改之前，它会自动备份整个技能目录，这样任何不满意的结果都能通过一条终端命令回滚。 策展人的工作分两个阶段： 第一阶段纯粹是机械的，完全不涉及 LLM 调用：它检查使用指标，把任何超过 30 天未使用的智能体生成技能标记为弃用，把任何超过 90 天未使用的东西移进归档文件夹。重要技能可以被显式置顶（pin）来保护它免受这个过程影响。 第二阶段是一次真正的 LLM 审查，通过一个单独的隔离智能体实例运行，使用为策展人辅助任务配置的任意模型——默认与主对话相同，不过也可以指向更便宜的东西。这里值得谨慎不要用太便宜的，因为这些决定的质量对技能库有真实的下游影响。 对每一个技能，策展人决定：如果它仍然准确、有用，就原样保留；如果它包含错误或过时的方法，就修复它；如果它与另一个覆盖基本相同领域的技能重叠，就合并它（在这个过程中正确地迁移任何相关脚本、评估或参考文件，并重写相对路径）；或者干脆归档它。 在这个周期结束时，它产出一份详细的报告，包括一张重命名映射表，精确展示任何合并之后旧技能名是如何映射到新技能名的，好让每一个决定背后的推理都可审计。 把 Hermes 用好 对于任何你能 7×24 运行的过程，这类云端智能体真的很有价值——编码工作是个显著例外——前提是你已经仔细地把那个过程数字化，并为它构建了一个扎实的技能，包括评估（evals）。 能产出好结果的工作流，大致长这样： 先把你自己从头到尾详细走一遍那个过程录下来，最好用听写工具，好准确捕捉——而这一步只有在你是真正理解那个过程、或者把它调研透了的情况下才管用。 把那段录音或那些笔记，用技能创建工具喂给一个编码智能体，产出第一稿；它还没好到能交付，尤其是对任何复杂的东西。 构建进 evals——代表一个正确结果的参考解——因为它们才是让你真正衡量技能表现好不好的东西，而不是瞎猜。 在一个测试环境里跑那个技能，根据你观察到的东西精修 evals 和技能内容，大部分编辑用手动完成，而不是委托出去。 只有在这个技能表现得一致、确定之后，才把它交给那个常开智能体。如果那个过程依赖某个外部服务，值得先查查是否已经有一个 MCP 服务器或 CLI 覆盖了它，再从头造一个。 更宏观的一点是：你能交给这样一个智能体的事情的范围，主要受限于你能把工作说明得多清楚，而不是智能体的原始能力。 有三条原则似乎在不同用例中都成立：不要把编码工作外包给一个无人监督的 7×24 云端智能体，让一个人保持在环中审查智能体实际产出的东西，以及把技能精修当作一项持续的工作、而不是做完一次就走开的事。 如果这对你有用——收藏它。你会想回来再看的。 想看更多这样的拆解，关注 @ScottyBeamIO 没有废话，只有真正管用的东西。 标签：# X # AI # Claude # Automation # Youtube # Guide # Hermes # Grok # Sonnet 相关文章 How I Built a Faceless YouTube Channel to $41k/Month Using Claude AI Most creators fail at faceless YouTube because they use generic ChatGPT prompts that spit out robotic scripts nobody wants to watch. Youtube Claude AI Automation