一个 Agent 在上周解决过构建失败，本周遇到类似问题时，能否少走一次弯路？这个问题至少包含三件事：上次的过程有没有保存，有用的步骤有没有被提炼，本次执行能否找到并正确使用它们。聊天记录落盘只解决第一件事。

Hermes Agent 把这些工作放进同一个产品：消息入口、任务执行、持久记忆、技能维护和定时运行。到 2026 年 10 月，它又增加了桌面入口、基于 profile 的 Bot Mode、应用连接管理和更完整的插件体系。理解它需要同时看两条线：单次任务怎样运行，跨任务状态怎样积累。

这里讨论的是 Nous Research 的 Hermes Agent。同公司的 Hermes 模型系列是另一条产品线；Agent 可以调用不同提供方的模型，不能把产品名当成底层模型的固定选择。

资料截点为 2026 年 10 月 22 日，正式版本基准为 v0.22.4。 GitHub 发布时间为 10 月 21 日 18:49 UTC，即北京时间 10 月 22 日 02:49；固定源码提交为 4d04303818b61bf3aa09278af48356315515965b。以下依据官方发布记录、文档及静态源码，未安装或启动 Hermes，未验证运行性能。在线文档与固定源码不一致的地方，以对应版本的实现为依据。发布记录

从消息助手到有桌面入口的持久 Agent

最近几个月改变了什么

Hermes 的演进已超出增加工具和消息渠道的范围。几个节点能说明产品责任怎样扩大：

版本与实际 tag 发布说明中的主要进展 对架构的影响
v0.14.0，v2026.5.16 依赖减负、提供方代理与渠道扩展 减少安装负担，进一步分离推理接入与任务执行
v0.16.0，v2026.6.5 Desktop 与远程网关连接 交互窗口和执行机器可以分开
v0.18.0，v2026.7.1 /learn、/journey、带完成契约的 /goal 经验提炼与任务验收开始有明确的产品入口
v0.21.0，v2026.8.31 Bot Mode、Bot 间消息、定时任务连续性、子 Agent steering 长期角色、周期任务与临时委派形成不同的生命周期
v0.22.0 至 v0.22.4 稳定发布渠道、桌面分发、连接管理、本地推理，以及后续修复 运行时更新、权限、兼容性和数据维护成为核心工作

这张表采用发布说明中的版本标题，同时保留早期日期式 tag。两种命名不能直接互换；例如 v0.21.0 的发布链接实际位于 v2026.8.31。v0.14.0、v0.16.0、v0.18.0、v0.21.0

v0.22 系列值得关注的变化是稳定发布与开发分支的分离。正式版本、GitHub 的 main、桌面安装器内置的后端并非同一个交付物。v0.22.4 的说明明确列出 CLI、Microsoft Store、Docker 和 Hermes Cloud 的适用范围，同时说明普通 .exe、.dmg 安装器本轮没有同步更新，要等后续捆绑发行。看到仓库的 Latest 标记，不能据此认定所有桌面用户都已获得相同代码。v0.22.0、v0.22.4

版本演进也有回归成本。v0.21.2 的说明集中处理会话存储可靠性；v0.22.2 则承认前一补丁从错误提交构建，并修复由此引起的连接问题。另一个容易漏掉的变化发生在会话清理上：v0.22.0 曾宣布默认清理 90 天旧会话，v0.22.3 又恢复为主动开启。判断当前默认行为，需要顺着补丁版本继续核对。v0.21.2、v0.22.2、v0.22.3

桌面、本地模型与连接管理

桌面应用提供对话、会话列表、模型和能力配置，也能连接远端 Hermes。交互界面与执行环境分离后，关闭窗口和停止后端成为两件不同的事。v0.22.4 的桌面文档说明，本地界面连接统一网关，网关可以在窗口退出后继续存在；文档中的这一生命周期约定，不代表本文运行过该后端。桌面架构

Local Models 把本地推理的管理纳入产品：推理引擎使用 llama.cpp，运行时下载由固定清单和校验值管理，模型选择会考虑机器内存与上下文开销。Hermes 仍允许接入已有兼容端点。因此，“模型可本地运行”和“模型由 Hermes 托管”是两种配置，不应混写成同一个必要条件。本地模型文档

本地推理也不能单独证明整条任务链不出网。网页检索、远端 MCP、消息平台和外部记忆提供方都可能独立发送数据。评估数据位置时，需要分别列出模型、工具、记忆和消息四条路径。

Connectors 将托管应用连接和 MCP 配置集中展示，并支持同一应用的多个账号。这降低了配置分散程度，但连接成功仍只说明具备一条调用路径，不能代替具体工具的权限核查。v0.22.0 发布说明

Bot Mode 把 profile 变成长期角色

Bot Mode 的底层是 profile：每个角色维护对应的配置、记忆、技能与聊天历史。桌面在此之上添加名称、头像、固定 Bot Chat、群聊和 routines。凭证选择还存在共享登录和继承规则，不能仅凭 profile 推断账号完全隔离。v0.22.0 的发布记录就列出过根目录与命名 profile 登录隔离行为的回滚。Bot Mode、凭证行为变更

这与临时子 Agent 有明显区别。资料整理 Bot 可以长期保有偏好和技能。临时子 Agent 则接收具体任务，例如分别核查三个来源并返回结果。二者都可能调用同一种模型，差别落在状态归属与生命周期上。Profile、Bot 与子 Agent

例如，把“资料整理”和“代码审查”配置成两个 profile，可以分别维护技能和聊天历史；本次资料整理再分出两个检索子任务，并不会自动产生两个长期 profile。角色持久化、会话持久化和任务并行由不同机制负责。

一次任务经过哪些组件

入口、会话所有者与执行循环

Hermes 当前的入口包括经典 CLI、TUI、Desktop、消息平台、API 与 ACP。ACP 提供编辑器接入，因此“它只能作为消息机器人、不能进入 IDE”已经无法描述当前产品。ACP 与架构文档

v0.22.4 的会话存储文档把网关定义为正式会话记录的唯一写入所有者：CLI、桌面、定时任务和其他客户端向它提交输入；进程外的受管 worker 通过运行时接口写回，而不是各自打开数据库写入 transcript。同一宿主进程可以服务多个 profile，每个 profile 仍有独立数据库与状态目录。会话存储

这一职责划分解决的是多入口写入、恢复与身份归属。它并不意味着所有任务只能串行执行，也不意味着每个 profile 必须对应一个独立进程。任务并发、同一会话内的输入排序、数据库写入事务是三个不同问题。

图 1：Hermes 的任务入口、会话管理与执行边界。图中表示逻辑职责，不限定所有组件的部署进程。

flowchart TB
    accTitle: Hermes 任务入口与运行时职责
    accDescr: CLI、桌面和消息平台提交输入，网关确认身份与会话，Agent 循环调用模型和工具，结果通过会话所有者保存。
    E[CLI、桌面、消息与 API 入口] --> G[网关：身份、profile、会话与调度]
    G --> A[Agent 循环：组织上下文并执行任务]
    A --> M[模型提供方与协议适配]
    M --> A
    A --> T[工具分发与执行环境]
    T --> A
    A --> G
    G --> S[对应 profile 的会话存储]
    G --> O[结果投递到原入口]

AIAgent 仍由 run_agent.py 暴露，但主要循环已经分解到 agent/conversation_loop.py、agent/turn_*.py 等模块。提示词构造、提供方解析、工具调度、压缩和持久化各有协作模块。只盯着入口文件的行数，很容易忽略系统已经发生的拆分。架构目录说明

单次循环可以描述为：组装上下文，调用模型，分发工具请求，读取工具结果，决定继续或生成最终答复。这个局部循环采用同步编排，并不能推出外围系统没有队列或 RPC。当前网关会话文档明确讨论输入排队、恢复与进程外 worker 写回。网关本地会话、会话存储

磁盘上保存的不是一种“记忆”

Hermes 以 HERMES_HOME 定位当前 profile 的状态。普通 macOS、Linux 默认根目录是 ~/.hermes/；命名 profile 通常位于其 profiles/<name>/ 下。代码需要使用 profile 感知的路径解析，不能把默认目录写死为所有角色的共同数据库。状态目录规则

数据 主要内容 下一次使用方式
state.db 会话、消息、模型配置及相关状态 恢复会话、历史检索、压缩后的上下文维护
memories/MEMORY.md、USER.md 内置记忆中的事实、约定与用户相关信息 构造记忆快照，进入模型上下文
skills/ 可复用操作过程及辅助资料 发现技能，再按需要读取正文
config.yaml、凭证与 profile 元数据 模型、工具、路由、身份和权限配置 决定该角色能调用什么、代表哪个账号执行
定时任务与日志 调度状态、执行记录、诊断信息 后续触发、故障排查和成本分析

SOUL.md 描述助手的行为和表达约定，不等同于用户画像。state.db 保存发生过什么，也不自动等于经过筛选的经验。把这些都叫作 memory，容易在备份、权限和污染排查时找错对象。内置记忆、技能机制

共享核心不会自动合并 Telegram 与 Slack 对话

稳定版的会话键包含 profile 命名空间、平台、聊天类型及相应的聊天、线程或用户标识。Telegram 和 Slack 复用执行核心，并不让两个对话默认变成同一份 transcript。会话键实现

同一 profile 的长期记忆、技能和可访问历史可以跨会话复用；这与把正在进行的对话迁移到另一个入口不同。官方另有显式 handoff 机制，并要求目标平台、home channel 等条件满足。会话连续性应从身份映射和路由规则证明，不能从“支持多个平台”直接推出。会话交接文档

这个区别也影响权限。私人对话中的用户事实是否能进入群聊，需要由实际的上下文注入和授权策略决定；单纯把 transcript 分成不同 session，并不足以证明共享长期记忆已经按受众隔离。

经验怎样进入下一次任务

常驻记忆、历史检索与技能加载

内置记忆存储默认给 MEMORY.md 和 USER.md 分别配置 2200、1375 字符的容量。这是可以配置的默认值，用于约束经常注入上下文的内容规模。容量限制能控制开销，无法判断一条事实是否错误或已经过期。内置存储实现

普通记忆写入不会立刻把每个正在执行的提示词重写一遍。稳定源码在上下文压缩后使系统提示词失效，并重新加载磁盘记忆；新会话也会构造新的快照。因此更准确的描述是：常规运行保持快照稳定，新会话或压缩重建等边界再刷新。提示词重建实现

历史检索走另一条路径。v0.22.4 的 session_search 在 SQLite 中查找消息，支持发现、浏览和读取上下文；工具本身不调用 LLM 生成摘要。检索结果随后可以由当前 Agent 阅读和解释，但不能把它写成搜索工具内部已经完成的步骤。历史检索实现

Skills 存放程序性知识，例如某类故障怎样定位、某个文档流程怎样执行。技能的名称和描述用于发现，正文按需加载，避免把整个技能库一次塞进上下文。它与事实记忆、完整历史的内容粒度不同。技能文档

图 2：三种持久信息进入任务的不同路径。

flowchart TB
    accTitle: 记忆、历史与技能的召回路径
    accDescr: 文件记忆通过快照注入，历史通过检索返回，技能通过发现和按需加载进入任务；任务可写回候选知识，质量由后续评测确认。
    M[文件记忆：事实与约定] --> P[新会话或重建时形成快照]
    H[会话历史：发生过什么] --> Q[按查询检索实际消息]
    S[技能库：怎样执行] --> L[发现技能并按需加载]
    P --> A[当前任务上下文]
    Q --> A
    L --> A
    A --> R[执行结果与候选经验]
    R --> W[有条件地写入记忆或技能]
    W --> V[后续任务验证适用性与效果]

技能复盘有触发条件，也可能不产生新技能

自动技能创建需要拆成调度条件与模型判断。稳定源码默认以 10 次迭代作为技能复盘提醒间隔；累积达到阈值后，还要满足工具可用、有最终答复、未中断、未禁止后台复盘等条件。符合条件时，在答复后启动后台 review。触发默认值、结束阶段实现

这不是“每完成一个任务就生成一个技能”。迭代次数也不是用户发了十条消息或完成了十个任务。复盘可能发现已有技能足够，可能修改一处步骤，也可能没有值得持久化的结果。skill-only 的后台复盘还受工具白名单约束，不能据此推定它会顺便改写内置用户记忆。后台复盘工具范围

/learn 与 /journey 则让经验管理有了显式入口：前者用于从资料或流程中提炼技能，后者用于查看、编辑学习记录。它们提高了可见性，但“生成成功”仍只代表一份候选知识已经产生。v0.18.0 发布说明

以构建失败为例，一个技能若只记录“删除缓存再试”，可能在相似日志下反复触发，却掩盖真正的依赖冲突。更有用的技能应保存适用版本、诊断证据、操作前提和验证方式。经验是否提升能力，需要在下一次任务中被证明。

Honcho 是可选外部记忆提供方

Hermes 的内置文件记忆可以独立工作。Honcho 属于可选 memory provider；当前文档把它放在插件目录中，由 Plastic Labs 维护。客户端依赖 honcho-ai SDK，服务端可以是云 API，也可以自行托管。安装 SDK 与拥有服务端是两件事。记忆提供方、Honcho 服务配置

因此，数据位置需要随 provider 说明。内置记忆和技能保存在当前 profile 的文件系统，并不能保证启用外部用户建模后所有信息仍留在同一台机器。多个 Bot 需要共享记忆时，也应明确共享的主体、范围和访问控制，不能把它当成 profile 隔离的自然结果。

用户画像还有额外的正确性问题。一次临时要求可能被误写成长期偏好；同一个人的工作与私人场景可能需要相反的默认值。允许修改和撤销事实，与保存更多事实同样必要。

外部状态改进与权重训练分开讨论

核心记忆回路修改的是文件、技能和可检索记录。模型在后续调用中读取这些材料，行为便可能改变；这条链路不要求更新模型权重。ReAct、Reflexion 和 Voyager 分别提供了推理与行动、语言反馈、技能积累等研究先例，但机制相近不足以证明某项目直接继承了另一个项目的实现。ReAct、Reflexion、Voyager

Nous Research 另有独立的 hermes-agent-self-evolution 仓库。此次查阅的固定快照中，README 只把通过 DSPy、GEPA 优化 SKILL.md 标为已实现；工具描述、系统提示、代码演化和持续流水线仍标为计划。设计说明把它放在 Hermes 核心之外，明确排除权重训练，并让候选变更通过审核进入核心项目。Self-Evolution 阶段表、设计边界

这些材料说明研究方向正在扩展，不能据此把默认 Hermes 写成运行中自动改写自身代码的系统。项目宣称的 self-improving、文件被成功改写和任务表现提高，属于三个不同的证据层级。关于外部状态与权重的进一步区分，可参见《Self-Improving Agent 的边界》。

协作、插件和其他 Agent 的比较

长期 Bot 与临时委派的边界

delegate_task 创建拥有独立会话的子 Agent。稳定版构造子实例时设置 skip_context_files、skip_memory，因此不能假定它完整继承主 Agent 的长期记忆与所有项目上下文。委派者需要明确传入任务、必要材料、工作范围和返回要求。子 Agent 构造

该版本的默认最大并发子任务数为 10，默认最大生成深度为 1。源码根据是否启用编排以及当前深度推导 leaf 或 orchestrator，旧的 role 参数已被忽略；默认深度也不等于固定的三层硬上限。这些细节与部分在线文档的显式角色写法存在差异。委派配置、角色推导

工具权限同样按角色处理。leaf 禁止继续委派；符合条件的 orchestrator 可以保留 delegate_task。当前限制还覆盖直接写主记忆、用户澄清、发送消息、管理定时任务等工具，不能用“所有子 Agent 永远禁用相同工具”概括。子 Agent 工具集合

上下文隔离不会自动带来文件隔离。两个子任务若获得同一工作目录，仍可能修改同一文件。工作目录、文件所有权和合并验证必须单独安排；协调机制只能降低冲突概率，不能替代最终检查。

插件化扩大了能力，也扩大了审查面

当前插件接口覆盖工具、Hook、命令、消息平台、终端环境、模型提供方和记忆后端等扩展点。插件与 Skill 的区别在执行责任：Skill 主要提供过程性说明；插件可以注册代码、挂接事件和改变运行时能力。MCP 则提供接入外部工具服务的协议路径。插件接口

v0.22 系列把更多可选能力放入插件目录。目录中的审核记录、固定提交和依赖授权有助于解释安装对象，但它们并不构成插件永远安全的证明。审查需要覆盖实际代码、依赖、凭证、网络与后台行为。v0.22.4 对“没有依赖的插件跳过空授权提示”的修复，也说明启用插件和批准安装依赖是不同环节。插件目录、最新补丁

本地推理、远端模型和扩展工具之间仍有兼容性成本。模型支持某种 API 格式，不等于它在复杂工具调用、长上下文或技能遵循上表现相同。更换模型后，既有技能至少需要重新检查输出格式、工具选择与停止条件。

记忆机制适合逐项比较

会话存储、自动写入、跨渠道入口、技能生成和恢复能力并不处于同一条等级轴上。下表比较公开文档中的机制，不给产品排统一的“记忆成熟度”，也不声称完成过性能横评。

方案 已公开的记忆或技能机制 需要区分的边界
Hermes Agent 内置文件记忆、会话检索、技能管理与有条件的复盘；可选 memory provider 自动形成经验不保证经验正确；外部 provider 的数据位置另算
Claude Code 指令文件与 auto memory 并存，本地会话默认开启自动记忆，存在环境例外 自动记忆按仓库组织，不等于所有项目共享同一用户画像
OpenClaw 文件记忆、检索、压缩前写回和后台 dreaming；可配置多 Agent 路由 长期记忆整合与渠道会话隔离是不同机制
Crush Agent Skills 按需加载，初始化可生成 AGENTS.md 生成项目说明不能直接等同于自动经验复盘；也不能据此断言不存在其他记忆能力

Claude Code 已经不能被归纳为“只读取人手写的 CLAUDE.md”；OpenClaw 当前文档也明确介绍后台记忆整合。Hermes 的特点需要从实际的技能维护、入口组合和状态管理解释，单靠“其他产品会失忆”无法成立。Claude Code memory、OpenClaw memory、Crush README

OpenClaw 的多 Agent bindings 将渠道账号路由到不同工作区和状态范围，比较对象更接近 Hermes 的长期 profile；单次任务内的临时委派则是另一层。状态目录分开仍不自动构成严格的安全隔离，跨 Agent 访问还取决于权限配置。OpenClaw 多 Agent 路由

Crush 与当前 OpenCode 也应按不同项目识别，不能把历史仓库渊源当作当前替代关系。产品会持续演进，跨项目比较中最稳妥的单位是“某时点、某机制、某默认条件”。

用开发框架自建时，还要补哪些责任

LangGraph 的 checkpointer 保存 thread 内状态，store 支持跨 thread 数据；Spring AI 的 ChatMemory 与持久化 repository 管理消息存取。这些原语都可以参与构建长期 Agent。将框架统一标成“无长期记忆”，会漏掉它们已经提供的基础能力。LangGraph persistence、Spring AI Chat Memory

框架原语与交付一个 Hermes 类产品之间仍有距离。应用需要决定何时写入经验、如何筛选、如何召回、什么信息可以进入群聊，以及技能失效后如何撤回；消息适配、定时调度、凭证管理、桌面交互和升级恢复也需要负责人。

自建成本应按这些责任逐项估算。某框架有长期存储接口，并不能推出只需补少量工程；Hermes 使用自己的执行循环，也不足以证明通用框架的模块边界天然妨碍记忆管理。真正可比较的是已有系统能复用哪些能力，以及新增状态由谁维护。

长期运行怎样判断收益与代价

授权、执行隔离与秘密管理

消息发送者有权触发 Agent，不等于 Agent 有权执行任意命令；命令审批、插件能力和执行环境又各自承担不同责任。当前安全文档明确指出，命令 deny 规则不能当成完整的 shell 解释器或操作系统沙箱。容器是否约束住访问范围，还要看挂载、凭证和网络，而不能只看 backend 名称。安全模型

凭证也已不局限于一份 .env。当前文档支持 Bitwarden、1Password 和用户配置的命令式秘密来源，定义来源优先级、profile 选择和子进程环境过滤。外部秘密管理减少了本地静态密钥的维护面，但仍有引导凭证、授权范围和轮换失败等问题。秘密管理

v0.22.0 的安全修复记录还包含凭据脱敏、子进程秘密过滤、SSRF 防护和空签名秘密拒绝。这些是具体版本的修复记录，不能推导出整个运行时已经不存在安全缺陷。安全修复记录

技能和提示词属于输入材料，不能替代这些强制边界。把“禁止执行某操作”写进技能，有助于模型选择行为；是否真正限制住文件、网络或账号访问，需要从工具与环境的控制处验证。

清理、回滚和备份是不同操作

Hermes 已有项目 checkpoints 与 /rollback，当前文档说明需要主动开启。其对象是项目文件修改，不能直接视为整个 profile、数据库、凭证和外部服务状态的完整备份。文档还列出了嵌套 Git 仓库等恢复边界。检查点与回滚

会话清理管理的是历史保留；项目回滚管理的是工作区变更；灾难恢复则需要一份一致且可验证的状态副本。这三项即使都出现在同一工具里，也应分别验收。删除旧历史还可能影响经验追溯，保留多久需要与数据需求一起决定。会话清理默认值的变化

长期运行的成本至少有模型调用、工具调用、后台复盘、定时任务和存储几部分。低价宿主机只覆盖其中一项。一个没有明确停止条件的周期任务，或持续生成低质量技能的复盘流程，都可能增加成本而没有改善结果。

质量评审与运行监控可以同时存在

质量评审关心产物是否满足要求，例如文章引用是否支持结论、代码是否通过回归；运行监控关心任务是否失联、重试是否失控、状态是否停滞。它们可以在同一个系统中同时存在，没必要强行划成互斥的阶段。

若使用独立 Agent 做监督，协议应明确任务标识、状态、证据、重试预算与升级条件。监督者报告“运行正常”，不能替代产物验收；评审者给出“内容通过”，也不能证明定时任务下次还能成功触发。这是两条不同的完成条件。

长期收益需要可重复的对照

评估“越用越好”，可以固定模型与工具配置，选择一组重复但不完全相同的任务。先记录没有历史经验时的结果，再引入记忆与技能，对比成功率、工具调用次数、费用和人工纠正量。评估题目应与生成技能时使用的题目分开，避免把复述旧答案误判为泛化。

还需要故意放入一条过期经验：更改依赖版本、调整目录结构，或撤销一项偏好，观察系统能否发现条件已变、停止使用旧步骤并更新记录。只测试记忆带来的成功案例，看不到长期状态累积的主要风险。

验收问题 需要看到的证据
有没有记住正确事实 可定位到写入内容、来源和适用范围
有没有在正确任务中召回 本次上下文实际使用了对应记录，且没有越过受众边界
技能有没有改善执行 相同条件下的成功率、调用量或人工修正量变化
错误经验能否撤回 修改或删除后，后续任务不再依赖旧内容
重启与升级能否恢复 会话、定时任务与权限仍对应正确 profile，未重复执行已完成动作

Hermes 适合进入评估的场景，是持续发生、能积累可复用流程、并且值得维护长期状态的工作。对于一次性编码任务，现有工具若已满足验收要求，增加另一套常驻系统还会带来状态、凭证和升级成本。是否采用它，应由重复任务的效果和维护负担共同决定。

参考资料

版本记录以 v0.22.4 为截点，历史节点包括 v0.14.0、v0.16.0、v0.18.0、v0.21.0 与 v0.22.0。Hermes 核心的固定源码链接对应 4d04303818b61bf3aa09278af48356315515965b；Self-Evolution 单独固定于 0a929e3aa20e15cf04dc7c28492a7d41a5139125。在线产品文档可能继续变化。

运行时部分主要依据架构说明、会话存储、Bot Mode与插件接口。记忆部分同时对照存储实现、提示词刷新、技能复盘和会话检索，避免仅用功能简介推断具体触发时机。

外部比较采用各项目官方资料；Self-Evolution 的状态仅对应文中列出的独立仓库快照。所有效果判断均未使用本地 Hermes 运行结果。