Hermes：自进化长期运行智能体

智能体工程正在从"怎么写 Agent"转向"Agent 怎么运行、治理、恢复与验证"。Hermes 是这一转向的典型代表。

定义与定位

Hermes Agent 是 Nous Research 构建的开源"自进化 AI 代理"（Self-improving AI Agent）。需要特别指出的是，这里讨论的不是 Nous 的 Hermes 模型族，而是其开源 Agent 产品——一个可运行在 VPS、GPU 集群或 Serverless 环境中的自治代理。

Hermes 不是绑在 IDE 上的 Copilot，也不是单个 API 的聊天壳。它明确把自己定位为长期运行智能体：具备跨会话记忆、技能生成与自改进、消息网关、定时任务、子代理并行以及 MCP 扩展能力，能从单一网关连接 20+ 平台，并在多种终端后端上运行。

Hermes 的真正定位不是"Prompt + Tool Calling"的轻量封装，而是把目标、上下文、状态、工具、调度、恢复、审计与评估打包成一个可持续运转的 Agent Runtime。

与 OpenClaw 的关系

Hermes 与 OpenClaw 同属"自主智能体"阵营，但侧重点不同。OpenClaw 强调能力层的工程化封装与治理，Hermes 则更关注长期自治运行——跨会话记忆、自进化技能和后台调度。二者共同推动了 Agent 从框架走向运行时的范式转变。

范式转向：从对话到 Episode

传统框架与新范式的差别，不在"有没有工具调用"，而在工程单元从一次对话变成了一个可审计的 Episode。

维度	传统 Chat / Workflow 框架	Hermes 式自治范式
基本单位	单轮对话、图节点、工具链	长会话、任务 Episode、后台作业
状态管理	主要在 Prompt / Graph State	会话库、记忆、技能、任务状态、Lineage
运行环境	默认依附调用方进程	独立 Gateway、Cron、Sandbox、Backend
恢复机制	Retry / Replan 为主	Checkpoint、Rollback、Fallback、Session Resume
验证方式	最终答案或简单断言	测试、日志、Side Effects、结构化证据包
治理边界	Prompt Guardrails	权限审批、授权、能力隔离、审计追踪

这种转变的本质是：旧范式主要回答"怎么写 Agent"，新范式则回答"Agent 怎么运行、治理、恢复与验证"。

架构与执行循环

Hermes 的入口面分为 CLI、Gateway、ACP、Batch/API，再统一收敛到核心 AIAgent。其内部包括：

Prompt Builder：装配系统提示、用户目标、会话上下文
Provider Resolution：模型选择与 Fallback 策略
Tool Dispatch：工具调用分发与审批
Session Storage：SQLite + FTS5 会话存储
Runtime Backend：多种终端运行后端

Agent Loop

Hermes 的标准执行回路如下：

图 1: Hermes Agent Loop

这一循环可用伪代码概括：

while budget_left():
    prompt = build(goal, session, memory, skills, context_files)
    resp = model(prompt, tools=enabled_tools)
    if resp.tool_calls:
        obs = run_tools(resp.tool_calls,
                        approval=policy,
                        runtime=sandbox)
        session.append(obs)
        maybe_checkpoint(obs)
        continue
    persist(session, memory)
    return resp.text

状态层与检查点

Hermes 的状态层值得单独强调。其 state.db 使用 SQLite WAL、FTS5 与 Trigram 索引，并通过 parent_session_id 维护 Session Lineage。

在破坏性操作前，Hermes 会把工作目录快照到一个独立的 Shadow Git Store，然后允许通过 /rollback 恢复文件系统并回退对话上下文：

if destructive(op) and checkpoints.enabled:
    cp = shadow_git.snapshot(workdir)
result = execute(op)
if need_restore:
    shadow_git.restore(cp)
    session.undo_last_turn()

Shadow Git 检查点

Hermes 的 Shadow Git 检查点机制是一个重要的工程创新。它不是简单的"撤销"操作，而是把整个文件系统状态和对话上下文绑定在一起回退，确保 Agent 的行为始终可追溯、可恢复。

产品形态：Always-on Agent

Hermes 对应的是"Always-on Agent"形态：单个后台 Gateway 连接消息平台、执行 Cron、推送长任务状态，并允许后台会话、子代理与跨会话记忆。

将 Hermes 与其他代表性产品做横向对比，可以看到 Agent 形态的分化：

产品	形态	特征
Hermes	Always-on Agent	Gateway、Cron、跨会话记忆、子代理并行
Claude Code	开发者 Agent	终端/IDE/Web 共享引擎、Auto Memory、Skills、Background Agents
OpenAI Codex	云端异步代理	独立隔离环境、可读写仓库、跑测试与 Harness
Devin	专用软件工程代理	沙箱中拥有 Shell、编辑器和浏览器

从系统视角看，Hermes 既是一个 Productized Harness，也是通向 Agent Runtime 的中间形态——它在单 Agent 层面解决了运行时基座问题（观察、行动、反馈、验证、权限与记忆），为上层的多会话、多租户、调度与治理奠定了基础。

核心能力

Hermes 官方已给出的一套成熟工程清单，涵盖了 Always-on Agent 所需的关键能力：

FTS5 会话检索：基于全文索引的会话历史快速查找
Memory / Skills：跨会话持久化的记忆与可复用技能
Delegate Task：子代理任务委派与并行执行
工具并发：多工具调用并发执行
危险命令审批：破坏性操作的权限门控
容器隔离：工具执行环境的沙箱化
Allowlist 与 DM Pairing：平台接入的授权控制
Background Notifications：后台任务状态推送
Usage / Cost 统计：调用次数与成本追踪

安全边界

Always-on Agent 把消息、记忆、技能、调度和 Shell 折叠进同一 Authority Boundary，会形成新的 Prompt Injection 与 Confused Deputy 风险。仅靠 Shell 级 Permission Gate 并不足够——文件编辑同样可能绕过风险判定。在部署 Hermes 类系统时，必须仔细设计权限模型和隔离边界。

与智能体工程体系的关联

Hermes 的实践与本书其他章节形成了有机关联：

与「智能体架构与上下文工程」一脉相承——Hermes 把"上下文工程"向前推进成了"运行时工程"
与「智能体系统工程化」互补——Hermes 提供了一个从"可运行"到"可持续运转"的完整案例
与「OpenClaw」横向参照——二者分别从"能力治理"和"长期自治"两个维度推进了 Agent 的生产化
为「智能体运行时」章节提供了从 Agent 产品到 Runtime 基座的过渡视角

总结

Hermes 的重要性不在于它"又多了一个工具"，而在于它代表了一个工程范式的转变：Agent 不再只是一段代码，而是一个需要状态管理、检查点恢复、权限治理和跨会话记忆的自治系统。

从架构视角看，Hermes 展示了三个关键洞察：

工程单元从对话变成 Episode——需要持久化、恢复和审计
运行环境从调用方进程变成独立 Gateway——需要 Cron、Sandbox 和后台调度
治理从 Prompt 约束变成权限体系——需要审批、隔离和追踪

这三个洞察共同指向一个结论：智能体工程正在从框架走向运行时。而 Hermes，正是这一转向的关键样本。

参考链接

Hermes Agent GitHub 仓库 — 开源代码与文档
Hermes Agent 官方文档 — 架构、Agent Loop、Session Storage 等详细文档
Nous Research 官网 — 团队介绍与研究项目

创建于 2026/05/18 更新于 2026/05/18 2556 字阅读约 6 分钟