编程 Hermes Agent 自进化架构深度解析：五个阶段闭环学习系统如何让 AI Agent 真正「越用越聪明」

2026-07-24 02:15:32 +0800 CST views 7

Hermes Agent 自进化架构深度解析：五个阶段闭环学习系统如何让 AI Agent 真正「越用越聪明」

Hermes Agent 是 2026 年开源 AI Agent 领域最值得关注的项目之一。它由知名开源 AI 实验室 Nous Research 推出，GitHub Stars 已突破 18 万，单日 Token 消耗量曾登顶 OpenRouter 全球榜首。与其耀眼的数据相比，更值得关注的是它背后的工程哲学：如何让一个 AI Agent 不只是被动响应，而是主动从每一次交互中学习、沉淀、进化？
本文从工程师视角，深度拆解 Hermes Agent 的核心技术架构，重点解析其「闭环学习系统」（Closed Learning Loop）的设计原理、记忆系统的工作机制，以及它与 OpenClaw 在工程设计路线上的根本分歧。

一、从「会做事」到「会成长」：为什么需要自进化 Agent？

在聊 Hermes Agent 之前，我们先正视一个现实问题：大多数 AI Agent，本质上都是「无状态的」。

你用 Claude Code 写了一个项目，下次打开时它不记得上次怎么配置的。你用 OpenClaw 完成了一个邮件自动化，下次跑它时它不记得上次踩过哪些坑。每次对话，对 Agent 来说都是「从零开始」——即便底层模型能力再强，这种「金鱼记忆」严重限制了它在长期任务中的效率。

主流 Agent 框架解决这个问题的方式主要有两种：

外挂记忆层：把历史对话、用户偏好、项目上下文以文本形式塞进上下文窗口。OpenClaw 走的就是这条路——MEMORY.md、AGENTS.md、HEARTBEAT.md，架构清晰、工程成熟。但代价是：上下文会无限膨胀，推理成本随之线性增长，而且大量低价值信息稀释了真正重要的决策上下文。

静态技能库：手工编写可复用的工具/技能，然后反复调用。Claude Code 的 /mcp、OpenClaw 的 skills 体系都属此类。问题同样明显：技能需要人工维护，无法从实战中自动生成。

Hermes Agent 的解题思路是：不要把记忆做成「存储层」，而要把它做成「学习系统」。

它的核心理念可以总结为一句话：每次交互都要产生价值，要么解决问题，要么产生知识——后者比前者更重要。

二、整体架构：从 Harness 到 Engine

在理解 Hermes Agent 的闭环学习系统之前，我们需要先厘清它的整体架构定位。

Hermes Agent 在 AI Agent 生态中属于 Harness（缰绳/驾驭框架）这一层。它的设计哲学是：不应该让 Agent 直接裸跑在大模型上，而应该给它套上一层有结构、有记忆、有安全边界的运行环境。

User Interface Layer
CLI / Telegram / Discord / Slack / WeChat / WeCom / QQBot / ...
                    |
                    v
Hermes Gateway
- Message routing  - Auth & permissions
- Session management  - Transport abstraction
                    |
                    v
Agent Core
+------------------+------------------+------------------+
|   Tool System    |  Memory System   |  Skill System    |
+--------+---------+--------+---------+--------+---------+
         |                      |                    |
         +----------+-----------+--------------------+
                    v
         LLM Inference Engine
                    |
                    v
         Closed Learning Loop
         (Execute -> Review -> Persist -> Inject -> Loop)

与 OpenClaw 的「网关模式」不同，Hermes Agent 的核心创新在于最底层的 Closed Learning Loop——这是一个让 Agent 持续自我改进的内核引擎，而不是简单的消息路由层。

三、Closed Learning Loop：五阶段闭环的工程实现

这是 Hermes Agent 最核心、也是最值得深入拆解的部分。

闭环学习系统的本质是：把 Agent 的每次任务执行，都变成一个可以提取、可沉淀、可优化的「学习事件」。整个闭环由五个阶段构成：

3.1 第一阶段：任务执行（Execute）

用户发起请求后，Hermes Agent 通过标准的 Agent 推理循环处理：理解意图 -> 调用工具 -> 观察结果 -> 继续推理 -> 输出响应。

在执行过程中，系统会完整记录所有中间状态：

class ExecutionTrajectory:
    user_message: str
    tool_calls: List[ToolCall]      # 所有工具调用记录
    tool_results: List[Any]          # 工具返回结果
    llm_responses: List[str]        # 模型中间推理步骤
    final_response: str              # 最终输出
    session_id: str
    timestamp: datetime

这些数据不只是日志——它们是后续三个阶段的学习原材料。

3.2 第二阶段：触发审查（Trigger）

不是每次交互都需要触发学习。Hermes Agent 使用两个计数器来控制触发时机：

Memory Nudge（记忆触发）：_iters_since_skill 计数器。默认每 10 轮对话触发一次，对当前会话轨迹进行记忆审查。评估标准是：是否出现了用户偏好、关键事实、或需要跨会话保留的环境信息。

Skill Nudge（技能触发）：_tools_since_skill 计数器。默认每 15 次工具迭代触发一次，评估标准是：是否完成了一个复杂的、可复用的工作流？

触发阈值是可配置的：

# ~/.hermes/config.yaml
learning_loop:
  memory_nudge_threshold: 10    # 每10轮对话触发记忆审查
  skill_nudge_threshold: 15     # 每15次工具迭代触发技能审查
  auto_create_skill: true       # 自动创建技能（无需人工确认）
  skill_quality_threshold: 0.7  # 技能质量评分阈值

这个设计很聪明：它把「学习」从主动行为变成了被动触发，避免每次交互都做昂贵的 LLM 调用来做自省，同时确保了足够的触发频率。

3.3 第三阶段：异步审查（Review）

一旦触发条件满足，Hermes Agent 会异步 Fork 一个轻量级审查 Agent，对执行轨迹进行多维度解构：

async def trigger_review(trajectory: ExecutionTrajectory):
    """触发异步审查，不阻塞主 Agent 响应"""
    
    # 主 Agent 立即响应用户，不等待审查结果
    response = await main_agent.respond(trajectory.user_message)
    
    # 后台 Fork 审查 Agent
    if should_trigger_memory_nudge(trajectory):
        asyncio.create_task(
            memory_review_agent.review(trajectory)
        )
    
    if should_trigger_skill_nudge(trajectory):
        asyncio.create_task(
            skill_review_agent.review(trajectory)
        )

审查 Agent 从三个维度进行分析：

记忆审查（Memory Review）：

提取关键事实：项目配置、技术栈、重要决策
识别用户偏好：沟通风格、输出格式、代码风格
判断是否需要跨会话保留：项目上下文、长期任务状态

# Memory Review Prompt (简化版)
MEMORY_REVIEW_PROMPT = """
你是一个记忆审查专家。请从以下交互轨迹中提取需要在未来会话中保留的信息：

1. **关键事实**：项目配置、技术栈、重要决策
2. **用户偏好**：输出格式偏好、沟通风格、编码习惯  
3. **上下文信息**：当前进行中的任务状态、已知约束

对于每条信息，评估：
- 置信度（0-1）
- 时效性（临时的 / 项目周期 / 长期）
- 存储位置（MEMORY.md / USER.md / 对话上下文）

只输出高置信度（>=0.8）且时效性>=项目周期的信息。
"""

技能审查（Skill Review）：

评估解决路径的通用性：这个问题下次遇到能直接套用吗？
识别可参数化的部分：哪些是硬编码？哪些应该抽象成变量？
计算技能价值分：参考了哪些外部资源？解决了什么类型的问题？

# Skill Review Prompt (简化版)
SKILL_REVIEW_PROMPT = """
你是一个技能提炼专家。请评估以下执行轨迹是否值得生成可复用技能：

执行过程：
{tool_calls_and_results}

请分析：
1. **可复用性**：这个工作流在什么场景下可以直接使用？
2. **参数化潜力**：哪些值是通用的（路径、关键词）？哪些是硬编码的？
3. **技能价值分**（0-10）：
   - 通用性 * 3 + 复杂度 * 3 + 节省时间 * 4
4. **技能描述**：用一句话说明这个技能做什么
5. **触发词**：什么场景下应该调用这个技能？

只对价值分 >= 7 的工作流生成技能。
"""

综合审查（Meta Review）：

反思错误模式：上次做错了什么？这次有没有重复？
生成优化策略：提示词怎么改可以减少迭代次数？
更新系统配置：要不要调整阈值？

3.4 第四阶段：知识固化（Persist）

审查结果通过两个通道写回系统：

记忆写入（通过 memory_tool）：

<!-- MEMORY.md 示例 -->
# Project Context
- 当前项目：订单履约系统重构
- 技术栈：Python 3.12 / FastAPI / PostgreSQL 16
- 数据库迁移方案：已确定用 Alembic，按模块分版本
- 性能目标：API P99 < 100ms（当前基线 240ms）

# User Preferences
- 喜欢分步骤推进，每次一个功能点
- 不喜欢过早优化，先跑通再调优
- 代码风格：类型注解必须加，docstring 简洁即可
- 输出格式：先说结论，再说原因，最后代码

技能生成（通过 skill_manage）：

# skills/invoice-reconciliation-workflow.yaml
name: "invoice-reconciliation-workflow"
description: |
  订单履约系统对账工作流：从数据库拉取订单和发票数据，
  按SKU维度比对差异，生成差异报告并通知相关人员。
trigger_keywords:
  - "对账"
  - "订单和发票"
  - "差异报告"
  - "reconciliation"
parameters:
  - name: start_date
    type: date
    required: true
    description: "对账开始日期"
  - name: end_date
    type: date
    required: true
    description: "对账结束日期"
  - name: output_format
    type: string
    default: "markdown"
    options: ["markdown", "csv", "html"]
    description: "报告输出格式"
implementation: |
  # Step 1: 获取订单数据
  orders = await query_orders(start_date, end_date)
  
  # Step 2: 获取发票数据
  invoices = await query_invoices(start_date, end_date)
  
  # Step 3: 按 SKU 比对
  diff = reconcile_by_sku(orders, invoices)
  
  # Step 4: 生成报告
  report = format_report(diff, output_format)
  
  return report
required_tools:
  - "database.query"
  - "filesystem.write"
  - "notification.send"
estimated_time_saving: "15-20分钟/次"

3.5 第五阶段：权重内化（Inject & Evolve）

这是 Hermes Agent 与其他框架最大胆的设计分歧所在。

主流 Agent 框架把学习成果存成「文档」——下次遇到类似场景，模型从文档中检索。但 Hermes Agent 还做了另一件事：通过强化学习把高频技能「内化」到模型的决策权重中。

具体来说，它使用 GRPO（Group Relative Policy Optimization）算法的变体：

class GRPOSkillEvolution:
    """基于 GRPO 的技能权重更新"""
    
    def __init__(self, model, skill_registry):
        self.model = model
        self.skills = skill_registry
    
    def evolve_skill(self, skill: Skill, trajectory: Trajectory):
        """
        GRPO 变体：将高频技能路径的决策概率提升
        """
        # 1. 从轨迹中提取「正确决策路径」
        optimal_actions = extract_optimal_path(trajectory)
        
        # 2. 收集同类型任务的轨迹分布
        task_family = self.skills.get_task_family(skill.name)
        trajectories = self.skills.get_trajectories(task_family)
        
        # 3. 计算优势函数（advantage）
        # 相比同类任务，这个技能的相对优势是什么？
        advantage = compute_advantage(
            skill_trajectory=trajectory,
            family_trajectories=trajectories
        )
        
        # 4. GRPO 更新：提升高优势路径的概率
        self.model.update_policy(
            skill_id=skill.name,
            advantage=advantage,
            optimal_actions=optimal_actions
        )
        
        # 5. 更新技能质量分
        new_quality = compute_quality_score(trajectory)
        self.skills.update_quality(skill.name, new_quality)

这意味着 Hermes Agent 不只是「记住」了怎么做某件事，而是调整了遇到同类问题时的决策倾向。从这个角度看，它已经接近了「持续学习」系统的范畴，而不仅仅是一个「记忆工具」。

四、三层记忆系统：SQLite + FTS5 + LLM 摘要

Hermes Agent 的记忆系统分为三层，每层有不同的存储格式和查询机制：

4.1 第一层：会话记忆（Session Memory）

存储在内存中，每个会话独立。当会话结束时，默认丢弃（除非显式标记需要保留）。

# 会话记忆的数据结构
class SessionMemory:
    conversation_history: List[Message]  # 当前会话的全部消息
    current_task_state: Dict              # 当前任务的状态机
    local_context: str                    # 本会话的即时上下文
    _iterations: int                      # 轮次计数器
    _tool_calls: int                      # 工具调用计数器

4.2 第二层：持久化记忆（Persistent Memory）

存储在 SQLite 数据库中，使用 FTS5 全文检索引擎：

-- 记忆数据库 schema
CREATE TABLE memories (
    id INTEGER PRIMARY KEY,
    category TEXT NOT NULL,          -- 'fact' | 'preference' | 'context'
    content TEXT NOT NULL,
    confidence REAL NOT NULL,        -- 0.0-1.0
    source_trajectory_id TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_accessed TIMESTAMP,
    access_count INTEGER DEFAULT 0
);

-- FTS5 全文索引
CREATE VIRTUAL TABLE memories_fts USING fts5(
    content,
    content_rowid='id',
    tokenize='unicode61'
);

FTS5 的使用非常关键。与简单的 LIKE 查询相比，FTS5 能支持：

语义相近词匹配：vector 能匹配 vectors、embedding、representation
布尔查询：python AND asyncio 精确匹配同时包含两者的记录
排名排序：按相关度而非创建时间返回结果

# 记忆检索实现
async def retrieve_relevant_memory(query: str, top_k: int = 5) -> List[Memory]:
    """基于查询检索最相关的记忆"""
    
    # 构建 FTS5 查询
    fts_query = build_fts_query(query)
    
    results = await db.execute("""
        SELECT m.*, bm25(memories_fts) as rank
        FROM memories m
        JOIN memories_fts fts ON m.id = fts.rowid
        WHERE memories_fts MATCH ?
        ORDER BY rank
        LIMIT ?
    """, [fts_query, top_k])
    
    # 更新访问统计
    for r in results:
        await db.execute(
            "UPDATE memories SET access_count = access_count + 1, "
            "last_accessed = CURRENT_TIMESTAMP WHERE id = ?",
            [r.id]
        )
    
    return results

4.3 第三层：LLM 摘要层（LLM Summary Layer）

当记忆量超过阈值时，系统会自动触发 LLM 摘要压缩：

async def compress_if_needed(memory_batch: List[Memory]):
    """当记忆条目超过阈值时，触发 LLM 压缩"""
    
    if len(memory_batch) < 20:
        return  # 不需要压缩
    
    # LLM 摘要：将 20 条细粒度记忆压缩为 3-5 条高层面洞察
    summary_prompt = f"""
    请将以下 {len(memory_batch)} 条记忆压缩为 3-5 条核心洞察，
    保留最重要的模式和偏好，丢弃细节：

    {format_memories(memory_batch)}
    
    格式要求：
    - 每条洞察一句话
    - 标注置信度（高/中/低）
    - 标注时效性（临时/项目周期/长期）
    """
    
    summary = await llm.generate(summary_prompt)
    
    # 替换细粒度记忆为摘要
    await db.execute("DELETE FROM memories WHERE id IN ?", 
                     [m.id for m in memory_batch])
    await db.execute("INSERT INTO memories (category, content, ...) VALUES ...", 
                     summary)

三层记忆的设计哲学：不要让模型记住所有事，而要让模型记住最重要的事。这是与 OpenClaw「全量记忆」路线最根本的分歧。

五、工具系统与 MCP 集成

Hermes Agent 内置了 47+ 工具，涵盖文件操作、代码执行、网络搜索、数据库操作等常见场景。但更值得关注的是它的 MCP（Model Context Protocol）集成架构。

5.1 MCP 在 Hermes 中的双重角色

MCP 在 Hermes Agent 中不是简单的「插件」，而是一个完整的工具发现与接入协议：

作为 MCP Client：Hermes 连接外部 MCP Server，获取文件系统、数据库、GitHub 等系统的能力。

# MCP Server 配置示例
mcp_servers:
  - name: "github"
    command: "npx"
    args: ["@modelcontextprotocol/server-github"]
    env:
      GITHUB_TOKEN: "${GITHUB_TOKEN}"
    enabled: true
    tools:
      - "github.list_repos"
      - "github.create_issue"
      - "github.search_code"

  - name: "postgres"
    command: "npx"
    args: ["@modelcontextprotocol/server-postgres"]
    env:
      DATABASE_URL: "${DATABASE_URL}"
    enabled: true
    tools:
      - "postgres.query"
      - "postgres.list_tables"

  - name: "playwright"
    command: "npx"
    args: ["@playwright/mcp@latest"]
    enabled: false  # 浏览器自动化，按需启用
    tools:
      - "playwright.navigate"
      - "playwright.click"
      - "playwright.screenshot"

作为 MCP Server：Hermes 自身也可以被 Claude Code、Cursor、Codex 等其他 Agent 调用，实现跨 Agent 协作。

# 暴露 Hermes 的能力给其他 Agent
hermes mcp serve --port 8765

# 其他 Agent 可以通过 MCP Client 连接并调用 Hermes 的能力
# 比如让 Claude Code 读取 Hermes 的会话历史

5.2 Tool Search：解决上下文膨胀问题

在 v0.11.0 中，Hermes 引入了一个非常巧妙的设计——Tool Search。

传统模式下，模型可见的 MCP 工具列表会随 MCP Server 数量线性增长。一个接入 20 个 MCP Server 的 Hermes 实例，可能让模型面对 200+ 工具——这不仅吃满了上下文窗口，还让模型在工具选择上犯迷糊。

Tool Search 的解决方案是：不把所有工具一次性给模型看，而是让模型按需检索。

# Tool Search 配置
tool_search:
  enabled: true
  deferred_tools:
    - "github.*"           # 全部 GitHub 工具
    - "postgres.*"         # 全部数据库工具
    - "playwright.*"       # 全部浏览器工具
  bridge_tools:
    - "tool_search"        # 搜索工具目录
    - "tool_describe"     # 加载工具完整 schema
    - "tool_invoke"       # 执行工具调用

启用后，模型的工具调用流程变为：

原始流程：模型 -> 直接调用 200+ 工具之一

Tool Search 流程：
  模型 -> tool_search("查询 GitHub 代码") 
       -> 返回匹配的工具列表（如 github.search_code, github.list_repos）
       -> tool_describe("github.search_code") 
       -> 获取完整参数 schema
       -> tool_invoke(...)

这个设计借鉴了向量检索的思想，但用在了工具发现层。它将「工具选择」从 O(n) 降为 O(log n)，同时降低了工具误调用的概率。

六、与 OpenClaw 的工程路线对比

把 Hermes Agent 和 OpenClaw 放在一起比较，是理解两者设计哲学的最快方式。

6.1 架构哲学的差异

维度	Hermes Agent	OpenClaw
架构定位	引擎模式：自进化运行时	网关模式：多渠道连接平台
记忆策略	选择性记忆 + LLM 摘要压缩	全量记忆 + 上下文扩展
技能生成	自动从轨迹生成，无需人工	手工编写，依赖 CLAUDE.md 模板
进化机制	GRPO 强化学习内化	人工维护，Skill Workshop
工具发现	Tool Search 按需检索	全部加载，统一上下文

6.2 Token 经济学的分歧

这是一个直接影响生产成本的核心差异。

OpenClaw 的「全量记忆」路线意味着：使用时间越长，MEMORY.md + 会话历史越长，上下文窗口消耗越大。半年后，单次任务的推理成本可能是第一周的 3-5 倍。

Hermes Agent 的「选择性记忆 + 摘要压缩」路线则试图解决这个问题：

def memory_value评估(memory: Memory) -> float:
    """
    评估一条记忆的长期价值
    决定它是否值得保留，以及保留在哪个层
    """
    recency_score = memory.access_count / MAX_ACCESS_COUNT
    uniqueness_score = 1 / similar_memory_count
    stability_score = 1 / change_frequency
    
    return (recency_score * 0.2 + 
            uniqueness_score * 0.5 + 
            stability_score * 0.3)

当记忆价值分低于阈值时，系统会自动删除它，而不是无限制堆积。这个设计让长期运行成本可控，但代价是：可能会丢失一些「还不知道有什么用」的有价值上下文。

这是一个经典的工程权衡：Hermes Agent 选择「更聪明地遗忘」，OpenClaw 选择「更保守地保留」。

6.3 谁更适合什么场景？

选 Hermes Agent：

需要长期运行的个人助理（日历、邮件、习惯追踪）
重复性高的工作流（每周对账、月度报告）
多项目并行管理（每个项目有不同的上下文）
对推理成本敏感（Token 费用是主要考量）

选 OpenClaw：

多 Agent 协作场景（需要跨 Agent 共享记忆）
社区技能生态优先（ClawHub 有丰富的现成 skills）
深度代码分析任务（上下文越完整分析越准确）
需要严格可控性的场景（人工维护确保行为可预测）

七、生产环境部署实战

7.1 最小化部署（$5 VPS）

# 一键安装（自动处理 uv、Node.js 等依赖）
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# 配置 API（以 OpenRouter 为例）
export OPENROUTER_API_KEY="sk-or-v1-xxxxx"
hermes config set model_provider openrouter
hermes config set model deepseek/deepseek-chat-v3

# 启动服务
hermes run

7.2 多实例隔离部署

# ~/.hermes/config.yaml
instances:
  work:
    memory_dir: "~/.hermes/work/memory"
    skills_dir: "~/.hermes/work/skills"
    mcp_servers:
      - "github"
      - "slack"
    notify_on: ["skill_created", "memory_updated"]
  
  research:
    memory_dir: "~/.hermes/research/memory"
    skills_dir: "~/.hermes/research/skills"
    mcp_servers:
      - "arxiv"
      - "web_search"
    model_provider: "openai"
    model: "gpt-5-turbo"

7.3 监控与日志

import prometheus_client as prom

SKILL_CREATED = prom.Counter(
    'hermes_skills_created_total',
    'Total skills created by Hermes Agent',
    ['skill_category']
)

MEMORY_ENTRIES = prom.Gauge(
    'hermes_memory_entries',
    'Number of persistent memory entries',
    ['memory_category']
)

LLM_COST = prom.Counter(
    'hermes_llm_tokens_total',
    'Total LLM tokens consumed',
    ['model', 'direction']
)

八、局限性与工程挑战

客观地讲，Hermes Agent 的设计也面临一些尚未解决的工程挑战：

8.1 技能质量边界

自动生成的技能，质量参差不齐。一个经过 5 次执行的成熟技能，可能在第 2 次执行时就被错误地「抽象」了，导致泛化过度。skill_quality_threshold 参数能在一定程度上缓解，但无法根治。

8.2 GRPO 内化的风险

用强化学习调整模型行为，是一条有风险的路。如果技能数据有偏差，错误的行为倾向会被持续强化，而不像文档那样容易被人工发现和修正。

8.3 与 OpenClaw 技能的兼容性

虽然 Hermes Agent 官方宣传与 OpenClaw 技能生态兼容（支持导入 .md 格式的 skills），但实际迁移中经常遇到路径引用不一致、工具名称冲突等问题。两者在设计哲学上的差异，让「拿来主义」并不总是顺滑。

8.4 记忆遗忘的边界判断

「什么时候该遗忘」这个问题，目前 Hermes Agent 用的是规则阈值（访问频率、置信度），但真正的智能遗忘应该理解语义。比如：「这个项目两个月没动了，但用户可能下周要重启它」——这种判断目前超出了规则系统的能力范围。

九、总结与展望

Hermes Agent 的出现，标志着开源 AI Agent 领域进入了一个新阶段：从「工具调用平台」向「自进化系统」的范式转移。

它的核心贡献可以归结为三点：

1. 闭环学习系统的工程化
把「从经验中学习」这件事，从理念变成了可运行、可配置、可观测的工程系统。五个阶段的划分、异步触发的设计、双通道写回的架构，每一个细节都透着工程老兵的务实。

2. 记忆系统的经济模型
不是无限堆记忆，而是主动评估记忆价值、压缩冗余信息、按需检索。这条路在短期可能丢失一些有用信息，但长期来看是可持续的。

3. 与 OpenClaw 的生态对话
Hermes Agent 和 OpenClaw 代表着两种截然不同的 Agent 工程哲学，它们的竞争与合作，将推动整个开源 Agent 生态向更成熟的方向演进。

展望未来，我们可以期待：

跨 Agent 技能共享：如果 Hermes Agent 的自动生成技能能和 OpenClaw 的 Skill Workshop 体系打通，整个社区的技能积累将进入加速模式
多模态记忆：当前记忆系统以文本为主，图像、音频、代码结构化信息的记忆压缩，仍是待攻克的领域
技能版本化：一个技能在进化过程中，会产生多个版本。如何管理技能的版本历史、支持技能回滚，是生产环境必须解决的问题

对于工程师而言，Hermes Agent 的源码（Python，909+ 文件）是一个非常好的学习样本——它比 OpenClaw（14000+ 文件）更易读，但功能深度不遑多让。建议从它的学习循环实现入手，理解它如何把「AI 自我改进」这件事做成了一个可工程化的闭环。

最好的 AI Agent，不是回答问题最多的那个，而是从每次交互中学到最多的那个。

参考项目：

GitHub: NousResearch/hermes-agent（MIT 协议）
文档：hermes-agent.ac.cn
对比研究：CSDN - Hermes Agent 与 OpenClaw 工程向对比与迁移建议

复制全文生成海报 Hermes Agent Nous Research AI Agent 自进化闭环学习系统 Skill Memory GRPO OpenClaw MCP