四层能力演进架构是自进化 Agent 的基石

Hermes Agent 在发布之初，最引人注目的承诺是“越用越好”。这听起来像一个美好的愿望，但工程上如何实现？答案藏在它的四层能力演进架构中。这不是四个并列的功能模块，而是一条递进的演进路径——每一层都在修补上一层的缺口:

• 记忆层解决“Agent 记不住”的问题
• 技能层解决“记住了但不会用”的问题
• 自进化闭环解决“会用了但不主动变好”的问题
• 上下文压缩层解决“想变好但装不下”的问题

我们将从 2026 年 4 月的架构文档和社区工程实践出发，拆解这条从静态存储到动态进化的完整链路。读完本章，你将理解自进化 Agent 的骨架设计，并能判断一个 Agent 系统是否具备真正的成长能力。

从静态记忆到动态技能

Hermes 的记忆系统不是简单的对话历史存储。它区分了两种关键的记忆形态:陈述性记忆（Declarative Memory）和程序性记忆（Procedural Memory）。前者存储“发生了什么”，后者存储“怎么做”。

当用户第一次让 Hermes“帮我部署这个 Next.js 应用到 Vercel”时，Agent 经历了从搜索文档、尝试命令、调试错误到最终成功的完整过程。在传统 Agent 中，这段经历会以对话历史的形式保留，下次遇到同样需求时，Agent 还得从头摸索。

Hermes 的不同之处在于：它会从这次成功的执行轨迹中提取出可复用的“技能”（Skill）。这个提取过程不是简单的日志归档，而是一次结构化转换:

从调研资料看，Skill 包含三个关键接口:

1. 触发条件（Trigger）: 决定了什么时候该调用这个技能
2. 参数模板（Parameter Schema）: 定义了执行时需要填充的变量
3. 校验逻辑（Validation）: 在技能执行前后验证环境是否符合预期

以部署场景为例，一个 deploy-vercel 技能可能包含:

• Trigger: 当用户提到“部署”且检测到项目根目录有 next.config.js 时
• Parameters: { project_path: string, vercel_token?: string }
• Validation: 执行前检查 Vercel CLI 是否已安装，执行后验证部署 URL 是否可访问

这种设计的工程价值在于：调用方式与执行逻辑解耦。同一个技能可以被用户手动触发、被另一个 Agent 子任务调用、或被定时任务激活，而不需要修改技能本身的实现。

视觉断点：技能提取的边界条件

并非每次成功执行都值得生成技能。社区实践表明，当满足以下条件时，技能提取才有正向收益:

• 执行步骤数 ≥ 3（过于简单的操作不值得封装）
• 用户后续重复使用过 ≥ 1 次（验证了可复用性）
• 执行过程中发生过错误修正（包含调试知识）

自进化闭环的触发与反馈

有了记忆和技能，Agent 已经能从经验中学习。但这里存在一个工程陷阱：谁来触发学习？

在大多数 Agent 系统中，“学习”是用户主动触发的：用户需要显式地告诉 Agent“记住这个”或“把这个保存为技能”。这在低频使用场景下勉强可用，但当 Agent 每天处理数十个任务时，依赖用户触发就会导致大量经验丢失。

Hermes 的答案是一个内部机制：Nudge（提醒/轻推）。这不是用户可见的命令，而是 Agent 在执行过程中定期产生的内部信号。根据架构文档的描述:

“每执行到一定轮次，系统会自动产生一个‘该复盘了’的内部信号，把学习从用户要主动触发变成 Agent 自己的本能。”

Nudge 机制如何工作？我们可以将其拆解为一个触发-评估-执行循环:

1. 触发时机: Agent 每完成 N 轮对话交互（从架构资料看，N 是可配置的，默认约为 5-8 轮）
2. 复盘内容: 回顾过去 N 轮中，哪些执行路径是新的、哪些错误被修正了、哪些决策产生了好的结果
3. 决策动作:
   • 如果发现新的成功执行模式 → 提议创建 Skill
   • 如果现有 Skill 在执行中失败过 → 标记需要优化
   • 如果用户反复纠正同一类错误 → 更新偏好模型

这里的关键设计在于 Nudge 的执行权限分级:

从当前调研资料看，Nudge 的设计哲学是“自动但不盲目”:Agent 主动发起学习,但对于高风险操作（如创建新技能），会保留人类确认环节，避免自动化学习导致技能库膨胀、质量下降。

这个闭环带来的实际效果是：使用频次越高，进化速度越快。一个每周使用 3 次的个人用户，和一个每天处理 50 个任务的团队机器人，后者的进化速度是前者的 5-10 倍——这正是自进化系统的理想特性。

上下文压缩作为使能器

前两层（记忆→技能，技能→进化）都指向一个方向:Agent 知道得越多，积累的经验越丰富，它就越有用。但这里存在一个硬件层面的硬约束：Token 预算。

LLM 的上下文窗口虽然在过去两年大幅扩展（从 4K 到 128K 甚至 1M token），但成本并未等比下降。当 Agent 积累了 100 次部署经验、500 条用户偏好、300 个对话片段时，把所有内容都塞进上下文既不经济也不高效。更糟的是，研究表明上下文过长反而会导致模型性能下降——LLM 倾向于关注首尾信息，中间部分会被“忽略”。

这就是第四层——上下文压缩——要解决的问题。Hermes 的上下文压缩不是简单的截断或摘要，而是一个分级压缩策略:

原始记忆（Raw Memory）
    ↓ 第一级压缩：结构化提取
结构化记忆（Structured Memory）  ← 针对陈述性记忆
    ↓ 第二级压缩：技能化
技能（Skills）                   ← 针对程序性记忆
    ↓ 第三级压缩：索引化
检索索引（Retrieval Index）     ← 按需加载

每一级压缩的目标不同:

• 第一级: 10:1 压缩比，从原始对话中提取关键事实、决策、错误信息
• 第二级: 将成功的执行模式压缩为技能模板，压缩比可达 50:1 以上
• 第三级: 不压缩内容本身，而是建立高效索引，让 Agent 能在 1 秒内从数千条记忆中检索出最相关的 Top-5

从工程实践看，第三级索引化的核心是向量嵌入（Vector Embedding）。每次原始记忆被压缩为结构化记忆时，系统会同时生成一个嵌入向量，存储到向量数据库中。当 Agent 需要回忆相关经验时:

1. 将当前任务描述转为嵌入向量
2. 在向量数据库中检索最相似的记忆
3. 仅将 Top-K 条记忆注入上下文

这使得上下文中的记忆信息始终保持高相关度、低 Token 占用。

视觉断点：上下文压缩的实际效果

根据社区实践数据（来源：Headroom 项目相关讨论）:

• 未经压缩的 Agent 上下文: 平均 12,000 token/次调用
• 经过三级压缩后: 平均 1,800-2,500 token/次调用
• Token 节省率: 80-85%
• 任务完成率: 未下降（部分场景因信息更精炼反而提升 3-5%）

为什么压缩层被放在最后一层？ 因为前三层在逻辑上为它提供了基础:

• 如果没有记忆层，就没有“需要压缩”的内容
• 如果没有技能层，程序性经验会以原始对话形式存储，压缩效率极低
• 如果没有进化闭环，记忆会不断膨胀但质量不提升，压缩只会丢失信息

四层之间是严格的前置依赖关系，这也是为什么 Hermes 将其设计为“递进架构”而非“并列模块”。

四层如何在实际运行中协作

以一个真实场景串联四层如何协同工作:

场景: 用户第二次让 Hermes 部署一个 Next.js 项目到 Vercel。

1. 记忆层: Agent 从向量数据库中检索到上次部署的记忆，发现当时遇到了“环境变量未配置”的错误，最终通过在 Vercel Dashboard 手动添加解决。
2. 技能层: 上次部署成功后，Nudge 机制已自动提取了 deploy-vercel 技能草稿。用户确认后，该技能包含了完整的部署步骤和环境变量检查项。
3. 进化闭环: 这次执行时，Agent 发现上次“手动添加环境变量”很耗时，于是尝试用 Vercel CLI 的 --env 参数自动传递。成功后，Nudge 机制再次触发，提议优化 deploy-vercel 技能，加入自动环境变量注入。
4. 上下文压缩: 对话上下文只加载了:结构化部署记忆（首次部署的关键信息）、当前项目的配置文件内容、以及 deploy-vercel 技能的参数模板。原始对话历史（包括当时用户抱怨“怎么这么麻烦”的情绪表达）已被压缩过滤，不占 Token。

结果是:第二次部署耗时从 15 分钟缩短到 3 分钟，Token 消耗降低了 60%，而 Agent 在没有用户任何额外指令的情况下，自主完成了技能优化。

本章核心结论

四层架构不是 Hermes 的“功能列表”，而是自进化 Agent 的必要条件。我们可以用一张对比表来理解每层缺失时的后果:

可操作的判断标准: 如果一个 Agent 系统声称具有“自进化”能力，你可以用它是否实现了这四层来快速验证:

• 检查它是否有结构化记忆系统（不只是对话历史）
• 检查它是否能从经验中提取可复用的技能
• 检查学习触发是自动的还是依赖用户手动操作
• 检查它在长期使用后 Token 消耗是否失控

从骨架到生态

理解了四层架构，你就看懂了自进化 Agent 的设计骨架。但一个完整的 Agent 系统不只是内部架构，还需要与外部生态协同。在下一章《Hermes 不是 LangChain 的替代品而是互补生态》中，我们将把视线从 Hermes 内部转向外部，看看它在整个 Agent 工具链中的生态位究竟在哪里——以及为什么它与 LangChain 不是二选一的关系，而是互为补充。