从记忆到技能的跃迁是自进化 Agent 的关键路径

在上一章我们确立了一个核心原则：记忆检索让历史信息从默认参与者变为条件参与者。但当 Agent 连续处理了十几次 API 集成任务，每次都要重新推理“先读文档、再检查环境依赖、然后写测试用例”这一套流程时，你会清楚地感受到——记忆只解决了“记住”，没有解决“复用”。真正让自进化 Agent 区别于普通聊天机器人的，是将重复的成功模式从记忆升华为可复用的技能。

2026 年 4 月，Hermes Agent 的源码仓库中新增了一个关键模块：Curator 后台进程。这个进程不参与对话，不调用 LLM，它只做一件事——周期性扫描记忆快照，识别可技能化的行为模式，自动归档低频 Skill，修剪失效实例。这一设计标志着自进化 Agent 从“会记录的机器”正式跨入“会学习的学徒”阶段。

让我们用一组实测数据来理解这个跃迁的含义。根据社区测试文档记录，在一次典型的自动化运维任务中：

这里的核心变化不是“更快了”，而是 Agent 不再每次都从头推理。它像人类一样，在反复操作后形成了“肌肉记忆”——这就是技能跃迁的本质。

本章的核心问题：Agent 如何完成从记忆到技能的跃迁？这个过程的工程实现包含三个关键子环节。

经验的识别与聚类：Agent 如何发现相似任务

记忆快照（frozen snapshot）是 Hermes 记忆系统的独特设计。传统的对话上下文会在 token 预算不足时被压缩或丢弃，而 Hermes 采用 MemoryStore/MemoryManager/MemoryProvider 三层架构，在每次任务完成后生成不可变的记忆快照，同时冻结其对应的 prompt prefix cache。这让高频访问的记忆段落驻留在 LLM 的 KV cache 中，既保护完整性，又节省 75% 的重复计算成本。

但冻结快照的真正价值不在存储，而在聚类分析。Curator 进程会持续运行以下逻辑：

1. 任务签名提取：对每个记忆快照生成向量嵌入，提取任务类型标签（如 api_integration、db_migration、log_analysis）
2. 相似度计算：将新快照与历史快照进行余弦相似度匹配
3. 聚类阈值判定：当同类任务累计出现 3 次以上，且操作步骤重叠度超过 60%，触发技能提案

这里的工程难点在于“多少算相似”。过早聚类会生成通用性差、缺乏抽象度的技能；过晚聚类则无法及时释放记忆压力。Hermes 当前的默认策略是 3 次相似任务触发提案，然后交由用户确认（或 Agent 自主裁决，取决于配置），这是一种偏保守的设计——优先保证技能的可靠性，而非覆盖率。

Skill 模板生成与参数化：从具体到通用的跃迁

一旦聚类完成，Agent 需要将具体的操作序列转化为通用模板。这个过程的本质是从实例中剥离具体参数，保留操作骨架。

以一次 API 集成任务为例，记忆快照中的记录可能是：

"读取了 Stripe API 文档 v2024-12，检查 Python 环境已有 stripe 7.0.0，编写了 payment_intent 接口的集成测试，涉及参数 amount=1000, currency='usd'。"

Skill 模板需要将其抽象为：

# Skill 模板伪代码结构
def api_integration_skill(api_name, api_version, env_check_list, test_target, test_params):
    """
    通用 API 集成流程
    - 读取 api_name + api_version 文档
    - 检查 env_check_list 依赖
    - 编写 test_target 的集成测试，使用 test_params 参数
    """

Hermes 的 Skill 系统采用 agentskills.io 开放标准定义模板格式，所有 Skill 遵循统一的 frontmatter 结构：

---
name: api-integration-v2
version: 2.0.1
parameters:
  - api_name
  - api_version
  - env_check_list
  - test_target
  - test_params
triggers:
  - "integrate * API"
  - "add API client"
  - "connect to * service"
dependencies:
  - curl
  - python>=3.10
---

这里的关键设计是 triggers 字段。它不是关键词匹配，而是嵌入向量匹配——当用户任务描述与某个 Skill 的 trigger 样本向量相似度超过阈值时，Skill 被自动加载。这让 Skill 的调用不再依赖开发者显式声明，而是 Agent 在运行时的自主决策。

对比一下记忆与技能在调用机制上的差异：

技能存储与版本控制：组织方式与演进机制

在 Hermes 的文件系统中，所有 Skill 统一存储在 ~/.hermes/skills/ 目录下。这个目录不只存放 Agent 自生成的 Skill，还包括：

• 官方捆绑技能：全新安装时从代码仓库复制的基础能力
• Hub 社区技能：通过 hermes skills install official/<category>/<skill> 安装
• 自进化技能：Agent 在实际任务中自动提炼的技能

文件的物理组织方式遵循分类目录结构，例如 communication/1-3-1-rule.md（决策框架）、blockchain/chain-data-query.md（链上数据查询）等。

版本控制是技能演进的工程基石。当 Agent 在第五次执行 api-integration-v2 时发现某个步骤需要调整（比如依赖检查命令从 pip freeze 改为 pip list --format=json），它不会直接修改现有 Skill，而是：

1. Edge 版本的 Skill 记录修改建议
2. 生成 api-integration-v2.1.0-edge，继续执行任务
3. 如果 edge 版本在后续 3 次任务中表现优于正式版，自动提升为 v2.1.0
4. 旧版本归档到 archived/ 目录，而非删除

这个流程由 Curator 的后台 archive 和 prune 操作支撑。归档让版本演进有迹可循，不会出现“升级后回不去”的困境；修剪则定期清理 30 天以上未被调用的边缘版本，控制目录膨胀。

~/.hermes/skills/
├── autonomous-ai-agents/
├── blockchain/
├── communication/
├── creative/
├── self-evolved/           # Agent 自生成技能
│   ├── api-integration-v2.0.1.md
│   ├── api-integration-v2.1.0.md
│   └── archived/
│       └── api-integration-v1.5.0.md
└── optional-skills/        # 未激活的技能池

这种设计解决了自进化 Agent 的一个核心矛盾：既要持续进化，又要稳定可预测。版本控制确保 Agent 不会因为一次失败的技能调整而丧失已有能力，同时为模型提供了“退回已知可行版本”的安全阀。

结论：记忆到技能的跃迁改变了什么

从当前调研资料和社区实测看，记忆到技能的跃迁完成了三个根本性改变：

1. 复用性取代了重复推理：Agent 从“每次都重新想”变为“直接调用已验证的流程”，这点在前文的 token 消耗对比中已充分体现
2. 渐进披露让技能不占用推理预算：与记忆的全量检索不同，Skill 只在触发时才展开详细步骤，这让 Agent 可以持有上百个 Skill 而不会超出上下文窗口
3. 版本演进让改进可逆：记忆只能追加，技能可以升级、回滚、归档——这让自进化变成了可控的迭代，而非不可逆的漂移

需要明确的是，从当前调研资料看，Hermes 的 Skill 自动生成流程仍依赖于记忆快照的质量——如果 Agent 在记忆阶段记录的摘要过于简略（例如连续运行后 MEMORY.md 保持在 800 tokens 以内，但记录了 1200 余条执行摘要，具体存储形式需另行核查），技能提炼的准确性会受到影响。这是一条实践的工程路径，而非理论上的完美解。

操作建议：如果你正在构建自进化 Agent，按以下优先级推进：

1. 先确保记忆冻结快照机制运行稳定（聚合 3 次以上同类任务的完整摘要）
2. 配置 Curator 的集群阈值和触发条件（建议初期设为 3 次相似任务、60% 步骤重叠）
3. 建立 Skill 版本目录和归档策略（避免 edge 版本堆积）
4. 在内部测试闭环中跑完“记忆积累→技能提案→参数化执行→版本回滚”的完整循环，再开放给用户

下一章，我们将聚焦 Skill 的内部结构。技能不仅是一个 YAML 文档或一段提示词，它有自己的生命周期——从创建、激活、执行到归档或退役。我们将详细定义 Skill 的结构、进化的触发条件和版本提升规则，让你能够像设计 API 一样设计 Agent 的技能单元。