Hermes Agent 经常被概括为“一个会记忆和自我学习的 CLI Agent”。这个描述没有错，但没有解释它为什么能持续工作。源码真正的中心是一个 Python Agent Loop，外围围绕它接入 provider、工具、执行环境、Gateway、memory、skills、plugins 和研究训练接口。

本文以 NousResearch/hermes-agent v2026.9.21 和主线为参照，进化部分结合 hermes-agent-self-evolution。最新仓库已经出现 Plugin Catalog、可选内置插件、context engine、多个 memory provider 和更清晰的 CLI subcommands，因此本文把 Hermes 作为一项 harness 工程来分析，而不是只讲一个循环函数。

01 一张图看懂：中心是 Loop，外围是可替换能力

Hermes Agent 整体架构

CLI / TUI / Gateway / Cron / Batch / RL Environment
                    |
                AIAgent
                    |
  provider -> context -> model -> tool registry -> environment
                    |
        session / memory / skills / evaluation

Hermes 和以 Gateway 为中心的系统不同：Gateway 只是入口，复杂度集中在 Agent Core。这样的选择适合个人工作站和研究型任务，因为核心 loop 直接暴露大量控制点；代价是 run_agent.py 一类的执行核较厚，部署级治理需要由外层模块补齐。

02 启动与配置：CLI 是组装器，不是业务核心

Hermes 的启动过程可以理解为：

  1. 解析命令、模型和认证方式。
  2. 建立配置、workspace、session 和用户目录。
  3. 选择 provider transport 与模型 catalog。
  4. 加载 tool registry、MCP、skills、memory provider 和 context engine。
  5. 根据 local、Docker、SSH、Modal、Daytona 或 Singularity 选择执行后端。
  6. 把所有依赖注入 AIAgent，启动交互式或非交互式 loop。

最新文档中的插件发现顺序很有代表性：bundled、user、project 和 Python entry point 分层发现，项目插件还需要显式开关；内置插件默认不启用。这说明 Hermes 开始把“可扩展”与“默认执行第三方代码”分开。

03 Agent Loop：一轮调用其实是一个有预算的状态机

Hermes Agent Loop

可以把核心循环写成：

while not stop:
    context = context_engine.build(session, memories, tools)
    response = provider.stream(messages=context)
    events = parse(response)
    for event in events:
        persist(event)
        if event.is_tool_call:
            result = registry.execute(event, environment)
            persist(result)
            messages.append(result)
    stop = should_stop(session, budget, error, user_interrupt)

真正的工程难点在 should_stop 和 persist。Hermes 需要处理最大轮数、token/cost、模型错误、工具错误、用户中断、上下文压缩、无进展循环和 Gateway 重连。没有这些控制，一个 Agent 只是在重复调用模型。

工具结果必须先成为 session 事实，再进入下一次 prompt。否则“模型看到过某个结果”和“系统承认某个结果发生过”会分叉，resume 与评测都会不可靠。

04 Provider 抽象：兼容性不是只改一个 URL

Hermes Tool Registry

Hermes 同时面对 OpenAI-compatible、Anthropic、OpenRouter、Nous Portal、Bedrock 等 provider。差异不只在 endpoint，还包括：

  • tool call 的参数和 ID 格式；
  • reasoning、thinking budget 和 token usage；
  • 图片、文件和多模态消息；
  • system prompt、缓存和上下文上限；
  • 流事件的结束语义与错误格式。

因此 provider 层应该完成 transport、schema 和 usage 的归一化，而 Agent Core 只消费内部事件。模型 catalog 又是另一层：它解决“可以选择哪些模型”，不应和“如何发送请求”混在一起。Hermes 当前支持远程 catalog 不可用时回退到仓库快照，就是一种典型的配置容错。

05 Tool Registry 与执行环境：行动能力必须可治理

工具注册中心负责发现、schema、过滤、执行和错误转译。一个有效工具集通常是：

registered tools
  -> provider compatibility
  -> user / agent policy
  -> environment capability
  -> context budget
  -> effective toolset

Terminal 工具不应直接绑定本机 shell。Hermes 把 local、Docker、SSH、远程 GPU 和云端沙箱抽象为环境后端，使 Agent Core 可以保留同一套动作语义，而把文件、网络、进程和凭证边界交给环境实现。

但抽象层不等于隔离。Docker 挂载目录、SSH 凭证、环境变量和网络出口仍然决定实际风险。安全设计要记录“工具请求在哪个环境执行”，并将结果和环境身份一起持久化。

06 Memory 与 Skills：在线学习首先是外部状态管理

Hermes Memory Loop

Hermes 的“学习”至少包含四类状态：

状态内容作用
Session当前对话和工具轨迹恢复本次任务
Memory用户偏好、事实、经验跨会话召回
Skill可复用的流程和知识在新任务中复用方法
Transcript search过去会话的可检索片段找回具体证据

这四者不能合并。memory 是事实，skill 是过程，session 是事件，search 是索引。把所有内容都写进一个长 Markdown 文件，会降低可控性和检索精度。

写入也应有门控：不是每条对话都值得长期保存。一个可用的写路径是提取候选、标记来源和作用域、检查冲突、保存版本，再由后续使用反馈决定是否提升为 skill。

07 Context Engine：压缩是一次交接，不是简单摘要

Hermes Context Compression

当上下文接近限制时，context engine 要生成一个能让新窗口继续工作的交接包：

目标与验收条件
已完成的事实
文件和环境变化
失败尝试与原因
待办任务及优先级
仍然有效的约束

好的压缩应保存决定，不必保存所有过程；应保留证据指针，不必复制全部日志；应标记不确定性，不能把模型猜测变成事实。压缩完成后，旧 transcript 仍应可回溯，摘要只是当前 context 的投影。

08 Gateway、Subagent 和并行任务

Hermes Gateway

Gateway 把 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口映射到 session。它应该只负责接入、排队、鉴权和投递，不能把渠道细节渗透进 Agent Core。

delegate_task 一类的 subagent 能把上下文隔离、并行搜索和专门角色引入任务。但并行不等于更快：父 Agent 还要管理预算、取消、结果合并、重复工作和失败重试。适合把可独立验证的读取任务并行化，不要把共享写入任务无边界地分发出去。

09 Harness 工程：把“聪明”放到模型外面

Hermes Harness Engineering

Harness 不是具体执行器，而是模型周围的工程系统：

任务定义 + 工具协议 + 环境边界 + 状态持久化
       + memory + skills + evaluation + guardrails
       = 可长期运行的 Agent Harness

Hermes 的价值在于把这些能力都做成可观察的模块。模型换 provider，不必重写 memory；环境换 Docker，不必重写 loop；新平台接入 Gateway，不必复制 Agent Core。

10 进化能力：在线维护和离线优化是两条链

Hermes Self-Evolution

在线学习发生在任务运行期间：记住用户偏好、保存成功流程、记录失败经验、根据检索反馈更新 memory 或 skill。它改变的是下一次运行的外部状态。

离线 self-evolution 则更像数据工程和评测流水线：

任务 / 轨迹
  -> 结果与失败信号
  -> 反思或候选 skill
  -> 在基准任务上评估
  -> 选择改动
  -> 发布到 skill / prompt / policy 版本

这里最容易被夸大的地方是“自我进化”。如果没有固定任务集、回归评测、版本化和回滚，自动修改 skill 只是把 prompt 污染得越来越不可预测。真正可用的进化必须满足三点：改动可追踪，收益可度量，失败可回滚。

Hermes 的研究接口和批量轨迹生成，使它可以把产品 Agent 的执行记录转成训练或评测数据；但训练数据生成、在线 skill 更新和模型参数学习仍是不同层次，不能混为一谈。

11 适用场景、限制与阅读路线

Hermes 适合需要多 provider、可替换执行环境、个人长期记忆、消息网关或研究训练的团队。它不适合把未经审计的插件直接放进高权限生产环境，也不适合没有评测基础就开启自动 skill 自修改。

推荐阅读顺序：CLI/config -> AIAgent loop -> model_tools/tool registry -> memory/context engine -> environment backends -> gateway/session -> plugins -> self-evolution。先抓住一轮任务的事实流，再看学习闭环。

12 最后的判断

Hermes 的“进化”不是模型突然拥有了永久记忆，而是它把运行经验变成外部、可检索、可评估、可回滚的资产。这个判断也适用于其他 Agent：模型是推理引擎，harness 决定经验能否留下、下次能否被找到，以及改动是否值得保留。

参考资料