在传统 AI Agent 系统中，上下文窗口的局限性决定了每次会话都是一次独立的信息重建 —— 模型可以调用工具、执行多步推理，但无法将解决问题的过程沉淀为可复用的能力。Hermes Agent 尝试打破这一困境：它不仅是一个可以调用 40+ 工具的代理运行时，更是一套具备闭环学习能力的系统 —— 完成任务后自主生成技能文档，通过向量索引实现跨会话复用，结合用户建模与全文本搜索构建持续进化的记忆体系。

五层记忆架构的设计动机

Hermes Agent 的记忆系统并非简单的向量数据库加对话历史，而是针对不同时间尺度和信息类型设计的五层架构。理解每一层的职责边界，是掌握其自我改进机制的前提。

第一层是短期推理记忆，即上下文窗口本身。这是所有大语言模型共有的工作记忆，Hermes 在该层的策略是当上下文利用率达到 50% 时触发压缩（可配置），并将工具编排的迭代步骤上限默认设为 90 次。这一层的设计理念很明确：它是为当前会话临时存在的，会话结束后即被丢弃。

第二层是程序性记忆，也是 Hermes 最具原创性的能力 —— 技能文档（SKILL.md）。当代理完成一个复杂任务时，它会自主编写一份遵循 agentskills.io 标准的技能文档，包含前置条件、步骤流程、依赖工具和验证方法。这不是日志记录，而是结构化的程序性知识沉淀。技能文档存储在 ~/.hermes/memories/skills/ 目录，支持渐进式加载：元数据始终加载（约 100 tokens），激活时加载完整内容（建议不超过 5000 tokens），资源文件按需加载。

第三层是上下文持久化，通过向量存储对技能文档建立索引，使相似任务可以检索到已有的解决方案。这一层解决的是 “知识发现” 问题 —— 没有向量索引，代理只能通过精确名称调用技能；有了向量检索，代理只需描述任务特征，系统返回最匹配的结果。

第四层是用户建模，由 Honcho（Plastic Labs 开发）提供 dialectical reasoning（辩证推理）能力。该服务不存储原始对话，而是从对话中推导关于用户的 “心理理论” 快照 —— 例如 “用户拥有 10 年以上 Rust 经验”“用户偏好异步通信方式”。这是 Hermes 与其他记忆系统的本质区别：它记住的是结论而非过程。

第五层是全文本搜索（FTS5），基于 SQLite FTS5 对所有历史会话建立索引。与简单存储不同，Hermes 在索引前会先用 LLM 对会话进行摘要，避免原始日志的噪声污染。这一层解决跨时间的精确回忆问题 ——“上周二我做了什么？”“上次的认证服务错误是什么？”

自我改进机制的工程实现

Hermes 的闭环学习可以概括为一个确定性循环：任务执行产生经验，经验被抽象为技能，技能被索引供检索，下一次相似任务直接复用。具体触发条件是基于复杂度的启发式规则 —— 当迭代次数、工具调用数量或解决方案新颖度超过阈值时，系统自动创建 SKILL.md。阈值本身未公开文档化，这意味着技能创建行为在边界情况下不可预测。

技能创建时的 LLM 调用成本是可控的：每生成一份技能文档仅需一次 LLM 调用。相比之下，Mem0 在同一操作中需要两次调用（提取 + 决策），而 CrabTalk 则不需要额外调用。技能格式遵循 agentskills.io 规范，确保了 portability—— 在 Hermes 中创建的技能理论上可以在 11 个以上支持该标准的工具中使用。

技能检索时的配置参数在 ~/.hermes/config.yaml 中定义：

memory:
  memory_enabled: true
  user_profile_enabled: true    # 需要 HONCHO_API_KEY
  memory_char_limit: 2200       # MEMORY.md 约 800 tokens
  user_char_limit: 1375         # USER.md 约 500 tokens

迭代控制参数同样可调：工具编排的最大迭代步数默认 90，通过 max_iterations 配置项修改；上下文压缩触发阈值默认 50%，通过 compression_threshold 调整。

运行时策略更新的局限与权衡

当前架构存在一个设计选择带来的长期风险：五层记忆均无遗忘机制。技能文档在 ~/.hermes/memories/skills/ 中无限积累，FTS5 索引随每次会话线性增长，Honcho 推导的用户模型持久化存储，向量索引随技能数量扩大。官方文档明确指出这是有意为之 ——Hermes 赌的是 “更多记忆总是优于更少记忆”。

但这与认知科学中的艾宾浩斯遗忘曲线相悖。在实际部署中，当技能数量达到数千份、FTS5 日志累积数月后，检索质量的信号噪声比将面临考验。更棘手的是版本冲突检测缺失：两份技能文档可能给出矛盾的指导（例如 “始终使用 yarn” 对比 “始终使用 pnpm”），系统目前无法自动识别这种冲突。

针对这一风险，工程实践中有几条可行的缓解策略。首先，定期审计技能目录 —— 由于技能是明文存储的 SKILL.md 文件，可以编写脚本检测同名或描述相似的技能并合并。其次，配置 Honcho 的 token 预算以控制用户模型的膨胀速度 —— 默认的 user_char_limit: 1370 可以根据实际使用频率下调。第三，如果场景允许完全离线运行，可以禁用 Honcho（设置 user_profile_enabled: false），仅保留技能 + FTS5 的双层架构。

与其他记忆系统的架构对比

在开源 Agent 记忆系统的设计中，Hermes 的五层架构代表了最重的方案。Mem0 采用三层作用域模型（conversation、session、user），通过 LLM 提取管道决定信息归属，优势在于内置去重机制（cosine similarity 0.85 阈值）和显式的 DELETE 操作。CrabTalk 更为精简，仅使用 LanceDB+graph 的单层设计，依赖 agent 主动调用 remember/recall/compact 工具。

Hermes 的差异化价值在于程序性记忆 —— 这是其他系统未覆盖的能力维度。一个能够将多步骤问题解决方案封装为可复用技能文档的 agent，与只能记住零散事实的 agent，在复杂任务处理效率上有本质区别。但代价是运维复杂度：五个层次中任一层出问题都需要独立排查 —— 技能是否成功创建？是否被正确索引？Honcho 推导的结论是否准确？FTS5 是否返回了预期结果？

对于资源受限的部署场景（如 5 美元的 VPS），推荐的基础配置是：启用技能系统和 FTS5 搜索，禁用 Honcho 用户建模，关闭上下文压缩的自动触发（改为手动触发）。这样可以在保持自我改进能力的同时，将外部依赖和服务成本降到最低。

关键工程参数速查

部署 Hermes Agent 时，以下参数需要根据实际场景重点调优。上下文压缩阈值决定何时触发内存整理，建议值为 0.5（50%），但对于长程任务可以下调至 0.4 以提前释放空间。工具迭代上限默认 90 步，对于简单的单轮问答可以降低以节省 token，对于复杂的多步骤调试任务建议提升至 150 以上。技能文档的 token 预算建议控制在 5000 以内，超出后系统会渐进式加载而非一次性读入。Honcho 上下文获取延迟约 200ms，对实时性敏感的场景需要考量这一额外开销。

如果需要观察自我改进的实际效果，可以监控 ~/.hermes/memories/skills/ 目录下的文件增长率 —— 健康的自我改进系统在初期会快速增长，之后逐渐趋于平稳。如果发现技能数量呈线性无限增长，则需要介入人工审核或调整复杂度阈值。

资料来源：GitHub NousResearch/hermes-agent、openwalrus.xyz 博客对五层记忆系统的深度分析、agentskills.io 技能文档规范。