在人工智能代理领域，大多数系统仍然遵循「无状态」或「上下文窗口依赖」的设计范式 —— 每一次会话都是独立的信息孤岛，代理无法真正累积经验并从中受益。Hermes Agent 的出现打破了这一僵局。作为 Nous Research 推出的自进化代理框架，Hermes Agent 拥有内置的学习闭环：它能从成功完成的任务中提取知识并转化为可复用的技能，在后续会话中自动加载这些技能，并根据使用反馈持续优化自身的工作流。这种「边用边学」的能力使其区别于传统的技能框架（如 obra、superpowers）或静态的 harness builder 范式，成为首个真正具备运行时自进化能力的开源代理项目。
有界记忆库的设计哲学
Hermes Agent 的记忆系统并非简单的日志存储，而是一套经过精心设计的分层架构。其核心是将记忆分为两个严格受限的存储层：MEMORY.md 和 USER.md。MEMORY.md 承载代理自身的学习笔记，限制为 2,200 字符（约 800 个 token），用于记录环境事实、项目规范、工作流约定以及从错误中习得的教训；USER.md 则用于构建用户画像，限制为 1,375 字符（约 500 个 token），存储用户的沟通偏好、技术水平、工作习惯等个人信息。这两个存储文件位于 ~/.hermes/memories/ 目录下，每逢新会话启动时，内容会被渲染为系统提示词中的一个「冻结快照」—— 即在会话开始时一次性注入，之后在整个会话期间保持不变。
这种冻结快照的设计并非偶然。其背后的核心动机是性能优化：当系统提示词保持静态时，底层模型的前缀缓存（prefix cache）能够被充分利用，推理速度显著提升，同时减少 token 消耗。代理在会话过程中对记忆的任何修改都会被立即写入磁盘，但这些变更只在下一会话启动时才会生效。工具调用结果始终显示实时状态，但系统提示词中的记忆内容不会在会话中途刷新，从而确保了推理的连贯性与缓存命中率的稳定。
代理通过 memory 工具管理这两个存储，支持三种操作：add 用于添加新条目，replace 用于基于子字符串匹配替换现有条目，remove 用于删除过时信息。值得注意的是，系统并未提供显式的 read 操作 —— 记忆内容在会话启动时自动注入到上下文中，代理无需主动读取即可「看到」自己的记忆。这种隐式访问机制简化了记忆的使用模式，同时也通过安全扫描层防止提示词注入和凭证泄露等威胁。
技能自生成与运行时优化
如果说有界记忆是 Hermes Agent 的短期记忆系统，那么技能（Skills）就是其长期能力仓库。技能以结构化的 Markdown 文档形式存储在 ~/.hermes/skills/ 目录下，每个技能文件遵循 agentskills.io 开放标准，包含任务名称、简短描述、详细步骤、所需工具、常见陷阱以及验证检查点等信息。这种标准化格式使得技能可以在兼容的代理之间无缝迁移。
技能的自生成遵循明确的触发条件。Hermes Agent 并非在每次任务完成后都尝试创建技能，而是根据以下条件进行判断：单次任务调用了 5 个或以上的工具（表示复杂工作流）；从错误或失败中成功恢复（尤其是恢复路径不显而易见的情况下）；用户明确纠正了代理的执行方式或代理自己发现了巧妙的变通方案。满足上述任一条件时，代理会将该任务的成功执行路径封装为一个可复用的技能文件，并为其建立索引以便后续检索。
技能的独特之处在于其运行时自优化能力。与传统技能模板的静态性质不同，Hermes Agent 在执行过程中可以执行「技能动作」—— 包括应用（apply）、扩展（extend）、精炼（refine）或弃用（deprecate）某个技能。当代理发现现有技能的步骤序列存在更优解时，它会将更新写回同一技能文件，使该技能在后续使用中自动采用改进后的路径。这种闭环优化机制意味着代理的使用时间越长，其技能库的质量就越高，形成类似生物体「用进废退」的演化特性。
跨会话检索与记忆追溯
仅靠有限容量的 MEMORY.md 和 USER.md 显然无法承载所有的历史会话信息。为此，Hermes Agent 提供了会话搜索（session_search）功能作为其记忆体系的第三层。所有通过 CLI 和消息网关进行的会话都被持久化到 SQLite 数据库（~/.hermes/state.db）中，并借助 FTS5 全文搜索能力实现高速检索。当代理需要回忆特定话题时，它可以通过 session_search 工具查询历史会话，系统返回相关段落并由 Gemini Flash 模型进行摘要提炼，最终将关键信息注入到当前推理上下文中。
这种设计实现了「按需检索」与「固定记忆」的互补。持久记忆（约 1,300 个 token 的总容量）用于存放始终需要在场的高价值信息 —— 用户的关键偏好、项目的核心约定、代理自身的重要学习成果；而会话搜索则处理「几周前我们讨论过 X」的模糊回忆需求，容量无上限但需要额外的搜索和 LLM 摘要开销。对于系统设计者而言，理解这一分工至关重要：当记忆使用率超过 80% 时（系统会在提示词头部显示百分比），应当优先进行条目合并而非继续添加新信息；会话搜索则适合作为后备方案，用于检索非关键但可能相关的历史上下文。
工程化实践参数
将 Hermes Agent 的记忆机制落地到实际项目中时，以下参数和监控点值得特别关注。首先是记忆容量配置：在 ~/.hermes/config.yaml 中，可以通过 memory.memory_char_limit 和 memory.user_char_limit 调整两个存储的容量上限，默认值分别为 2200 和 1375 字符；增大容量会提升上下文中的信息密度，但也会线性增加每次会话的 token 消耗和推理延迟，建议在 80% 使用率阈值以上启动主动合并流程。其次是外部记忆提供者：Hermes Agent 提供了 8 种外部记忆插件（包括 Honcho、Mem0、RetainDB 等），可以通过 hermes memory setup 命令激活，这些提供者通常支持知识图谱、语义搜索和跨会话用户建模等高级特性，适合需要深度个性化记忆的场景。
对于技能系统的运维，关键是监控技能文件的更新频率与质量。技能的自优化机制虽然强大，但也可能导致技能库在迭代过程中出现逻辑冲突或性能退化，建议定期通过 hermes skills list 审查技能文件的版本历史，并在关键工作流上保留人工审核环节。在可靠性方面，会话搜索的稳定性依赖于 SQLite FTS5 索引的健康状态 —— 当数据库体积显著增长时，可以考虑使用 hermes sessions prune 清理过期会话或手动执行 VACUUM 命令优化存储。最后，回滚策略不可或缺：由于技能文件和记忆内容都存储在用户目录下的明文文件中，在重大版本升级前建议备份 ~/.hermes/ 目录，以便在记忆污染或技能退化时快速恢复。
与传统方案的差异
理解 Hermes Agent 的独特价值，需要将其置于更广阔的代理技术坐标系中加以审视。传统的 obra 或 superpowers 技能框架采用「设计时定义」模式 —— 技能由人工编写并预先注入，代理本身不具备修改技能的能力；archon harness builder 则提供了工具调用的编排能力，但同样缺乏从执行经验中学习的能力。Hermes Agent 的核心创新在于将学习行为从设计时转移到运行时 —— 代理自身成为记忆的策展人和技能的进化者，而非静态工具的被动执行者。这种自进化特性使其特别适合需要长期运行、持续适应用户习惯的自主任务场景。
资料来源：Hermes Agent 官方文档（hermes-agent.nousresearch.com/docs/）与 GitHub 仓库（github.com/NousResearch/hermes-agent）。