Hermes Agent 深度解析：当 AI 学会「自我进化」——从四层记忆架构到技能自生成的工程全解

前言：为什么 Hermes Agent 让整个技术圈坐不住了

2026年的开源AI Agent领域，Hermes Agent绝对是一个绕不开的话题。这个由Nous Research团队打造的项目，自2026年2月底正式开源以来，短短两个月GitHub Star突破5万+，直接登顶Trending全站第一。在它之前，这个位置被OpenClaw占据。而Hermes Agent之所以引发如此强烈的关注，并不是因为它又做了一个"聊天机器人"——恰恰相反，它做了一件所有AI助手都没做到的事：让AI真正拥有「长记性」和「自我进化」的能力。

用过ChatGPT、Claude、Copilot的朋友都知道一个痛点：每次对话，AI就像失忆症患者一样完全不认识你。你告诉它你的代码风格、项目偏好、常用框架，下次对话它照样从头开始。那种"聊了100遍它还是陌生人"的感觉，我相信每个深度用户都体验过。

Hermes Agent彻底改变了这个局面。它不只是一个助手，而是一个会随你成长的"AI队友"——你用它越多，它就越懂你，越能提前帮你搞定事情。

但今天这篇文章不想做另一个"Hello World"式介绍。网上已经有大量文章告诉你"什么是Hermes Agent"和"怎么安装它"。本文要做的是从工程实现角度，把它的核心技术掰开了揉碎了讲清楚：四层记忆架构到底怎么用SQLite+FTS5实现？技能自生成的触发条件是什么？生成的Skill文件长什么样？它和OpenClaw的Skill体系本质区别在哪里？以及最重要的——这套架构对AI工具链的未来意味着什么？

如果你是一个工程师，想深入理解Hermes Agent的底层逻辑；或者你想基于它做二次开发、贡献Skill；或者你只是好奇"自我进化的AI"到底是怎么从论文变成生产级代码的——这篇文章就是为你写的。

一、背景：从「金鱼记忆」到「持久智能」

1.1 传统AI助手的记忆困境

在深入技术细节之前，我们先搞清楚为什么"记忆"这个问题这么难解决。

传统的AI助手（无论是大模型还是本地部署的），都面临一个根本性的架构限制：对话级别的上下文。你给AI的上下文窗口（Context Window）再大，也是单次会话级别的。你关闭对话，下次重新打开，AI就什么都不知道了。

这个问题的根源在于：AI模型的权重是固定的（即使是fine-tuning，也需要重新训练，成本极高）。模型不会"因为和你多聊了几句"就自动更新自己的知识。所谓的"个性化"，要么靠每次对话时人工塞入大量背景信息（体验极差），要么靠云端服务偷偷存储你的对话历史（隐私问题）。

这就导致了两个极端：

• 通用性AI：什么都会一点，但什么都要从零学起，不认识任何用户
• 定制化AI：需要大量工程投入，fine-tune、微调、 embedding，每次更新都成本不菲

1.2 Hermes Agent 的破局思路

Hermes Agent的核心创新，就是把"学习"这件事本身变成了AI的原生能力，而不是依赖外部系统或人工干预。

它的思路非常聪明：不改变底层模型的权重（那太贵），而是在模型之上构建一套持久化的记忆和技能管理系统。模型本身不需要"记住"任何东西——记忆和技能都存储在外层，模型通过查询这些外部存储来"想起来"应该怎么做。

这就好比人类的记忆：你的大脑（模型权重）负责推理和思考，但具体的事实、技能、偏好都存在外部记忆系统里（笔记、日记、肌肉记忆）。Hermes Agent就是给AI建了一套这样的外部记忆系统，而且这套系统还能自动增长——AI不只是读取记忆，还会把成功的经验写成新的"技能卡片"，下次直接调用。

这个设计理念，直接导致了它的核心架构：四层记忆 + 技能自生成。

二、架构总览：AI消息网关 + 技能执行层 + 决策层 + 进化循环

2.1 组件划分

从宏观架构来看，Hermes Agent由四大核心组件构成：

┌─────────────────────────────────────────────────────────┐
│                     Hermes Agent                         │
├─────────────────────────────────────────────────────────┤
│  AI消息网关 (AI Message Gateway)                        │
│    ↕ 12+ 平台接入 (Telegram/Discord/Slack/钉钉/飞书...) │
├─────────────────────────────────────────────────────────┤
│  技能执行层 (Skills Execution Layer)                    │
│    ↕ Markdown Skill文件 + 工具插件系统                   │
├─────────────────────────────────────────────────────────┤
│  核心大脑 (Core Brain)                                  │
│    ↕ 四层记忆架构 + LLM推理引擎                         │
├─────────────────────────────────────────────────────────┤
│  自我进化循环 (Self-Evolution Loop)                     │
│    ↕ 任务反思 → 技能生成 → 记忆更新 → 循环迭代           │
└─────────────────────────────────────────────────────────┘

这个架构的精妙之处在于：每个组件都是解耦的，可以独立替换和扩展。模型可以换成OpenAI、Claude、本地Ollama；记忆存储可以用SQLite也可以换成其他数据库；技能系统是文件系统级别的Markdown，直接编辑即可。

接下来我们逐层深入。

三、四层记忆架构：从「金鱼」到「过目不忘」

3.1 为什么需要分层记忆

你可能会问：为什么不是简单的"把所有对话都存下来"？这样做有两个致命问题：

1. 上下文膨胀：用得越久，历史数据越多，每次查询都要把大量无关信息塞进上下文窗口，成本急剧上升，推理速度下降
2. 信息噪音：你上个月查的一个bug和今天的项目完全无关，存下来只会干扰模型判断

Hermes的四层记忆架构，本质上是一个信息过滤和抽象系统。它模拟了人类记忆的层次结构：

• 短期记忆（工作记忆）：只保留当前任务相关信息
• 长期记忆（情景+语义+程序性）：经过提炼的、结构化的持久知识

每层记忆都有明确的职责和更新策略，确保信息既不丢失，也不会泛滥。

3.2 第一层：工作记忆（Working Memory）

工作记忆是临时存储层，对标人类认知中的"当前注意力"。它负责：

• 当前会话的对话上下文
• 正在处理的任务状态
• 正在编写的代码片段
• 最近的工具调用结果

实现方式：这一层完全在内存中，格式为标准的消息数组（Message Array），和传统AI对话的上下文完全一致。它的存在保证了单次任务执行的连贯性——你让AI"继续写刚才那个函数"，它知道你说的是哪个函数，因为工作记忆里还保留着这个上下文。

# 工作记忆的简化数据结构示例
working_memory = {
    "session_id": "uuid-v4",
    "current_task": {
        "description": "修复用户登录模块的OAuth回调问题",
        "status": "in_progress",
        "last_action": "analyzed OAuth flow, found token refresh issue",
        "files_modified": ["auth/oauth.py", "auth/token.py"],
    },
    "context_window": [
        {"role": "user", "content": "帮我看看登录后token过期的问题"},
        {"role": "assistant", "content": "让我分析一下OAuth流程..."},
        {"role": "tool", "content": "文件读取: auth/oauth.py"},
        # ... 更多上下文消息
    ],
    "active_files": ["auth/oauth.py"],
}

工作记忆的特点是会话结束时自动清空，但清空之前会发生一件关键的事：关键信息会被提炼并下沉到持久记忆层。这就是第二层和第三层的工作了。

3.3 第二层：情景记忆（Episodic Memory）

情景记忆是Hermes的"私人日记"——它记录了所有历史交互的"故事"，但不追求完整记录，而是经过LLM提炼的关键信息。

存储引擎：SQLite + FTS5

这是整个记忆系统最关键的技术决策。我们来详细拆解为什么这个组合如此重要。

SQLite作为嵌入式数据库，在本地AI工具场景下有几个无可替代的优势：

• 零运维：没有独立的数据库服务进程，直接文件级存储，Hermes装好就能用
• ACID保证：即使突然断电，数据库也不会损坏
• 轻量：完整的SQL引擎只有几MB，适合桌面/VPS部署
• 跨平台：iOS/Android/桌面/服务器通吃

但SQLite的原生LIKE查询对自然语言搜索能力有限——你想"找到之前讨论过GitHub Actions配置的那次对话"，用LIKE '%GitHub Actions%' 可能找不到"CI/CD workflow配置"这种同义表述。这就需要FTS5。

FTS5（Full-Text Search 5）是SQLite的全文本搜索扩展，支持：

• 分词器（tokenizer）：能将"authentication token refresh"分成["authentication", "token", "refresh"]等词项
• BM25排序算法：类似Elasticsearch的搜索相关性评分
• 短语搜索、前缀搜索、布尔搜索

这意味着你的搜索不依赖精确关键词匹配，而是真正的语义级检索。

情景记忆表结构设计：

-- 情景记忆表
CREATE TABLE episodic_memory (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    session_id TEXT NOT NULL,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    summary TEXT NOT NULL,        -- LLM提炼的会话摘要
    key_entities TEXT,            -- 关键实体：项目名、代码文件、API端点等
    user_preferences TEXT,        -- 本次会话中体现的用户偏好
    tools_used TEXT,              -- 本次用到的工具列表
    outcome TEXT,                 -- 任务结果：成功/失败/部分完成
    importance INTEGER DEFAULT 1,  -- 重要性评分（用于记忆淘汰）
    
    -- 全文搜索索引（核心！）
    fts_content TEXT NOT NULL    -- FTS5索引内容 = summary + key_entities
);

-- FTS5虚拟表
CREATE VIRTUAL TABLE episodic_fts USING fts5(
    fts_content,
    content='episodic_memory',
    content_rowid='id',
    tokenize='porter unicode61'   -- porter词干提取 + unicode61分词
);

-- 触发器：自动同步FTS索引
CREATE TRIGGER episodic_ai AFTER INSERT ON episodic_memory BEGIN
    INSERT INTO episodic_fts(rowid, fts_content) VALUES (new.id, new.fts_content);
END;

-- 典型查询：找"之前配置过CI/CD的那个项目"
SELECT session_id, summary, key_entities 
FROM episodic_memory 
JOIN episodic_fts ON episodic_memory.id = episodic_fts.rowid
WHERE episodic_fts MATCH 'ci OR "github actions" OR "CI/CD" OR workflow'
ORDER BY bm25(episodic_fts) 
LIMIT 5;

为什么这样设计？

你注意到一个细节：FTS5索引的是 summary + key_entities，而不是原始对话内容。这是因为原始对话太长太噪音，用LLM提炼后的摘要才是真正有价值的信息。

每段对话结束时，Hermes会调用LLM做一次"会话提炼"（Session Summarization）：

def summarize_session(conversation: list[dict]) -> dict:
    """将完整对话提炼为结构化的情景记忆"""
    prompt = f"""
    请提炼以下对话的关键信息，输出JSON格式：
    {{
        "summary": "一句话描述这次对话的主题和结果",
        "key_entities": ["具体项目名", "文件路径", "API名", "框架名"],
        "user_preferences": "本次对话中体现的用户偏好（如：喜欢用TS、倾向REST而非GraphQL）",
        "tools_used": ["本次使用的工具列表"],
        "outcome": "任务完成情况",
        "importance": 1-5的评分
    }}
    
    对话内容：
    {conversation}
    """
    # 调用LLM处理...

这个设计极度优雅：每次会话的信息都被压缩成结构化的"记忆卡片"，存进SQLite。检索时通过FTS5做语义级搜索，再也不会"聊过就忘"。

3.4 第三层：语义记忆（Semantic Memory）

如果说情景记忆是"我的经历"，那语义记忆就是"我知道的事实"——不依赖个人体验，而是从外部获取的客观知识。

在Hermes Agent中，语义记忆主要负责：

• 项目知识：代码架构、技术栈、约定俗成的开发规范
• 工具文档：你常用的API文档、命令行工具的帮助信息
• 领域知识：你所在行业的专业术语和概念

存储方式：语义记忆以**文档（Documents）**为单位组织，每个文档关联到特定的项目或主题。

# 语义记忆的数据结构
semantic_memory = {
    "documents": [
        {
            "doc_id": "proj-ai-platform-semantics",
            "project": "AI Platform Backend",
            "title": "微服务架构说明",
            "content": """
            本项目采用微服务架构：
            - auth-service: 鉴权服务，JWT RS256签名
            - user-service: 用户CRUD，基于PostgreSQL
            - notification-service: 消息推送，支持Email/SMS/WebSocket
            ...
            """,
            "auto_updated": True,  # 是否允许AI自动更新
            "last_updated": "2026-04-10T14:30:00Z",
            "confidence": 0.9,     # 置信度（用于判断是否需要重新获取外部信息）
        }
    ]
}

语义记忆有一个独特的设计：置信度机制。当AI发现某个文档里的信息和最新获取的事实不符时（比如你改了API接口但文档没更新），置信度下降，触发重新获取流程。这本质上是一个自我纠错的机制。

3.5 第四层：程序性记忆（Skills）——最核心的创新

程序性记忆是Hermes与所有其他AI助手的本质区别所在。它不是"记住了一个事实"，而是"学会了一个动作"——即如何完成特定类型任务的步骤。

在Hermes中，程序性记忆的物理形态是Markdown格式的Skill文件。

# Skill: github-pr-workflow
# 自动生成时间: 2026-04-12T15:23:00Z
# 触发原因: 成功帮助用户完成了一次完整的GitHub PR提交流程
# 置信度: 0.92

## 元信息
- 适用场景: 用户需要提交代码到GitHub仓库的场景
- 前置条件: GitHub CLI (gh) 已安装并登录
- 危险操作: 确认目标分支后再force push

## 触发条件
当用户提到以下任意关键词时触发此技能：
- "提交PR"
- "create pull request"
- "帮我把代码推上去"
- "发起代码审查"

## 执行步骤

### Step 1: 检查当前Git状态
```bash
git status
git branch

确保代码已经add和commit，没有未提交的修改。

Step 2: 创建或切换到特性分支

gh pr create --title "feat: [功能名称]" --body "## 改动说明\n- [改动点1]\n- [改动点2]\n" --base main

如果特性分支不存在，先创建：

git checkout -b feat/xxx

Step 3: 推送分支（如需要）

git push -u origin feat/xxx

Step 4: 描述规范

PR标题格式: type(scope): description
type: feat|fix|docs|style|refactor|test|chore
scope: 改动所属模块

注意事项

• 每次PR尽量保持原子性，一个PR做一件事
• commit message遵循Conventional Commits规范
• 如果有关联的issue，用 "Closes #issue号" 自动关联

进化记录

• 2026-04-12: 初始创建（从一次成功的PR操作中提炼）
• 2026-04-15: 增加force push的安全提醒

这就是Skill文件的真面目——**一份由AI自己生成的"操作手册"**。它的格式既便于人类阅读和修改（Markdown），也便于程序解析和执行。

与OpenClaw的Skill相比，OpenClaw的Skill是由人类开发者编写的，而Hermes的Skill是由AI在成功完成任务后**自动提炼生成的**。这是两条完全不同的路线。

---

## 四、闭合学习循环：从「完成任务」到「学会成长」

### 4.1 学习循环的完整流程

四层记忆架构解决的是"知识存储"问题，但真正让Hermes与众不同的是**闭合学习循环（Closed Learning Loop）**——它不只执行任务，还会从任务执行中学习，把学到的经验固化下来。

这个循环分两条并行轨道：

**轨道一：主动技能生成（程序性记忆自增长）**

任务执行完成
↓
LLM反思：这次成功经验的核心步骤是什么？
↓
生成技能文档（Markdown格式）
↓
写入 skills/ 目录
↓
下次遇到类似任务 → 直接调用技能 → 跳过试错

**轨道二：记忆系统持续更新**

对话结束
↓
LLM提炼：哪些信息值得进入情景记忆？
↓
SQLite写入（情景记忆）
↓
FTS5索引更新
↓
下次检索时可用

### 4.2 触发条件：何时触发自我进化？

不是每次任务执行都会触发学习循环，Hermes有一套**进化触发条件**：

```python
EVOLUTION_TRIGGERS = {
    # 任务完成后检查
    "task_completed": {
        "min_tool_calls": 15,           # 至少用15次工具调用
        "min_duration_minutes": 5,     # 至少耗时5分钟
        "complexity_threshold": 0.7,   # 任务复杂度评分≥0.7
    },
    
    # 工具调用模式
    "tool_call_pattern": {
        "repeated_patterns": 3,         # 同一操作重复3次 → 抽象为循环/函数
        "error_then_success": True,    # 先失败后成功 → 记录避坑经验
    },
    
    # 显式用户请求
    "user_request": [
        "记住这个",
        "保存为技能",
        "下次按这个流程来",
    ]
}

重点看第一条：当一个任务调用了15次以上工具、耗时超过5分钟、且复杂度够高时，Hermes会认为这是一个"值得提炼"的任务。这避免了对简单问答也生成Skill文件导致的记忆噪音。

4.3 LLM反思过程：Skill是怎么"写"出来的

当触发条件满足后，Hermes会调用一个专门的"反思提示词"让LLM生成Skill文件。这个过程可以类比为：AI在任务结束后，回顾自己的思考过程，把成功路径提炼成可复用的步骤。

SKILL_GENERATION_PROMPT = """
你是一位经验丰富的开发运维工程师。刚完成了一个复杂的GitHub PR提交流程。
请将这次成功经验提炼成一个可复用的Skill文件。

## 原始任务
{task_description}

## 执行日志（按时间顺序）
{tool_call_logs}

## 成功要素
{success_factors}

请按以下格式生成Skill文件：

# Skill: [技能名称]
# 自动生成时间: {timestamp}
# 触发原因: [为什么触发学习]

## 元信息
- 适用场景: 
- 前置条件: 
- 危险操作: 

## 触发条件
当用户提到以下关键词时触发此技能：
- [关键词1]
- [关键词2]

## 执行步骤
### Step 1: [步骤名]
[具体命令或代码]

### Step 2: [步骤名]
...

## 注意事项
...

## 进化记录
- {timestamp}: 初始创建
"""

这个提示词的设计本身就是一个工程亮点：把"反思"变成一个可工程化的过程。通过结构化的输出格式，确保LLM生成的Skill文件质量稳定、可解析、可执行。

4.4 进化反馈机制：如何避免「学坏」

如果AI基于一次错误的经验学会了"错误的技能"怎么办？这是自我进化系统最核心的工程难题。Hermes通过多层保障来应对：

第一层：置信度评分

每次生成的Skill都有初始置信度（基于任务执行的复杂度和成功率）。低置信度技能不会直接进入主动调用列表，只在"建议"层级出现。

SKILL_CONFIDENCE_CALCULATION = {
    "base": 0.7,
    "+task_complexity_high": 0.1,      # 高复杂度任务 +0.1
    "+first_attempt_success": 0.15,    # 首次执行即成功 +0.15
    "-required_retry": 0.1,            # 需要重试 -0.1
    "-error_count": 0.05 * errors,     # 错误次数扣分
    "max": 0.98,
    "min": 0.3,                        # 低于0.3的技能进入休眠
}

第二层：用户确认机制

对于重要技能，Hermes会请求用户确认后才将置信度提升到主动调用级别。

第三层：使用反馈循环

当一个Skill被调用并成功使用时，置信度提升；反之，如果调用后用户手动干预或批评，置信度下降并可能触发Skill重新生成。

五、跨平台接入与自动化调度

5.1 消息网关设计

Hermes Agent的另一大特色是跨平台消息接入。它通过统一的AI消息网关连接12+个消息平台：

这个设计的精妙之处在于：不管用户通过哪个平台发消息，AI接收到的都是统一的"消息对象"，与具体平台无关。切换平台只需要改配置，不需要改动核心逻辑。

# 统一的跨平台消息格式
class UnifiedMessage:
    def __init__(self, platform: str, raw_message: dict):
        self.platform = platform
        self.message_id = raw_message.get("id")
        self.user_id = raw_message.get("user_id")
        self.content = self._normalize_content(raw_message)  # 统一文本提取
        self.attachments = self._extract_attachments(raw_message)
        self.metadata = {
            "timestamp": raw_message.get("timestamp"),
            "channel": raw_message.get("channel"),
            "thread_id": raw_message.get("thread_id"),
        }
    
    def _normalize_content(self, raw: dict) -> str:
        """不同平台的消息格式统一转换为文本"""
        if self.platform == "telegram":
            return raw.get("text") or raw.get("caption", "")
        elif self.platform == "discord":
            return raw.get("content", "")
        elif self.platform == "slack":
            return raw.get("text", "")
        # ...

5.2 自动化调度：Cron + 自然语言任务

Hermes内置了一个基于自然语言的定时任务调度系统。传统Cron的问题是：你得记住Cron表达式。* * * * * 是什么意思？大多数人要查文档。

Hermes的解决方案是：自然语言定时。你说"每天早上9点给我发一份昨天的代码提交摘要"，Hermes自动翻译成对应的Cron表达式，生成定时任务，同时将任务逻辑封装为一个Skill。

# 用户输入
hermes schedule "每天早上9点给我发昨天GitHub提交的摘要"

# Herme自动转换为
# ┌───────────── 分钟 (0-59)
# │ ┌───────────── 小时 (0-23)
# │ │ ┌───────────── 日 (1-31)
# │ │ │ ┌───────────── 月 (1-12)
# │ │ │ │ ┌───────────── 星期 (0-6, 0是周日)
# 0 9 * * *

# 生成对应的Skill
# skill: daily-github-summary
# cron: "0 9 * * *"
# 执行: 调用GitHub API获取昨日提交 → LLM总结 → 发送报告

这个功能对于工程团队极其有用：自动化日报、周报、代码审查提醒、部署检查……所有原本需要写脚本+配置Cron的重复工作，变成了和AI"说一声"就能搞定的事。

六、与 OpenClaw 的本质对比：两条不同的演进路线

6.1 架构哲学的根本分歧

在AI Agent领域，OpenClaw和Hermes Agent是两条最具代表性的路线。它们的核心分歧在于：技能（Skill）到底应该谁来写？

OpenClaw 的路线：人来写技能

开发者/用户 → 编写Skill → 安装到Hermes → 调用

OpenClaw的Skill体系由社区和开发者贡献。Skill本质上是一种人给AI写的工具描述，定义了"在什么情况下调用什么工具"。

Hermes 的路线：AI自己写技能

AI完成任务 → 反思提炼 → 自动生成Skill → 调用

Hermes的Skill体系是由AI从成功经验中自主提炼的。人不写Skill，Skill由AI的实践经历"长出来"。

6.2 具体差异对比

6.3 这两条路线意味着什么

这个问题值得深入思考。两条路线代表了对AI Agent本质的两种不同理解：

OpenClaw的思路：AI Agent是一个工具平台，人类是工具的制造者和组织者。Skill就像App Store里的应用，由专业开发者打造，保证质量和覆盖面。

Hermes的思路：AI Agent是一个学习型系统，人类是使用者而不是工具制造者。最好的工具不是别人写的，而是AI在服务你的过程中，为你量身打造的。

从工程角度看，OpenClaw更适合企业场景——有团队维护、有定制需求、要和其他系统集成。Hermes更适合个人效率场景——个人开发者、自媒体运营者、小团队负责人，用AI来处理大量重复性工作。

有趣的是，两条路线正在相互靠近。OpenClaw社区里已经有人在探索让AI自动生成Skill；Hermes也在引入Skill的手动编辑机制，允许用户修改AI生成的技能文件。未来的顶级AI Agent框架，很可能是两者优势的结合：既有人类社区贡献的高质量基础Skill，又有AI从个人使用中生成的个性化Skill。

七、实战：从安装到调教自己的「AI分身」

7.1 快速安装

官方提供的一键安装脚本：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安装脚本会自动：

1. 检测并安装 uv（Astral的超快Python包管理器）
2. 克隆GitHub仓库
3. 创建Python虚拟环境
4. 安装所有依赖
5. 配置初始化

安装完成后，运行 hermes setup，按提示填入API Key即可。

7.2 配置多模型支持

Hermes支持多种LLM后端，配置在 ~/.hermes/config.yaml 中：

# 模型配置
models:
  primary:
    provider: "openai"
    model: "gpt-4o"
    api_key: "${OPENAI_API_KEY}"
  
  # 本地Ollama（隐私优先场景）
  local:
    provider: "ollama"
    model: "llama3.3:70b"
    base_url: "http://localhost:11434"
  
  # Claude备选
  claude:
    provider: "anthropic"
    model: "claude-sonnet-4-20250514"
    api_key: "${ANTHROPIC_API_KEY}"

# 记忆配置
memory:
  sqlite_path: "~/.hermes/memory.db"
  fts5_enabled: true
  retention_days: 365

# 技能配置
skills:
  auto_generate: true
  confidence_threshold: 0.7
  skill_directory: "~/.hermes/skills/"

7.3 手动触发技能生成

如果AI漏掉了某个值得提炼的经验，你可以手动触发：

用户: 记住，以后部署到生产环境前必须先在staging跑完整测试
Hermes: 明白了。我将把这条规范加入生产部署Skill。生成中...
      ✓ Skill已更新: deployment/production-safe
      - 增加了前置检查：staging完整测试流程
      - 自动继承原有的回滚步骤

7.4 查看和编辑AI生成的Skill

所有Skill文件都在 ~/.hermes/skills/ 目录下，用Markdown格式存储。你随时可以：

# 列出所有技能
ls ~/.hermes/skills/

# 查看某个技能
cat ~/.hermes/skills/github-pr-workflow.md

# 编辑优化
vim ~/.hermes/skills/github-pr-workflow.md

这是Hermes设计中最务实的地方：Skill是Markdown文本，人可以直接阅读和修改。不需要任何专用编辑器，不需要学习特定格式——打开文件，改，改完保存，AI下次就会用新版本。

八、性能与资源考量

8.1 记忆检索性能

对于大多数用户场景，SQLite + FTS5的性能完全够用：

• 单机场景下，1万条情景记忆的FTS5查询通常在10-50ms完成
• SQLite的WAL（Write-Ahead Logging）模式支持并发读写，不影响AI响应速度

但如果数据量超过10万条，建议：

• 将历史数据迁移到PostgreSQL + pgFrost的组合
• 定期归档低频访问的记忆到冷存储

8.2 LLM推理成本

Hermes的"反思"和"技能生成"都需要额外的LLM调用。这些调用的token消耗大约是：

• 会话提炼：约500-2000 tokens/次（取决于会话长度）
• 技能生成：约1500-5000 tokens/次（取决于任务复杂度）

建议用便宜的模型（如GPT-4o-mini）来做记忆提炼，用高质量模型做技能生成的核心推理。

8.3 存储空间估算

# 存储空间估算
def estimate_storage(conversations_per_day: int = 10, avg_conv_length: int = 50):
    daily_episodes = conversations_per_day
    daily_semantic_updates = 5
    daily_skills_generated = 0.2  # 平均每天0.2个新Skill
    
    episode_size_kb = 2      # 情景记忆每条约2KB
    semantic_doc_kb = 5      # 语义文档每条约5KB
    skill_file_kb = 3        # Skill文件每条约3KB
    
    daily_storage_mb = (
        daily_episodes * episode_size_kb / 1024 +
        daily_semantic_updates * semantic_doc_kb / 1024 +
        daily_skills_generated * skill_file_kb / 1024
    )
    
    yearly_mb = daily_storage_mb * 365
    print(f"每日新增: {daily_storage_mb:.2f} MB")
    print(f"每年新增: {yearly_mb:.1f} MB")
    print(f"10年后: {yearly_mb * 10 / 1024:.1f} GB")

一年下来不过几十MB的数据量，SQLite完全hold住。即使使用10年，总存储量也就在几百MB级别——这是本地存储的巨大优势，隐私完全自主。

九、局限性分析与工程反思

9.1 当前版本的核心局限

作为工程师，我们必须客观地评价Hermes Agent的局限性：

局限一：技能冲突与优先级

当多个Skill的触发条件重叠时，Hermes目前缺乏精细的优先级机制。比如同时匹配"代码审查"和"GitHub PR"两个Skill时，选择逻辑比较简单，可能导致执行流程不理想。这在Skill数量增长后会变得明显。

局限二：技能质量依赖任务质量

如果AI在某次任务中用了"不是最优"的方法完成了任务，它会把这种方法也提炼成Skill。这意味着低质量的任务经验会污染技能系统。置信度机制缓解了这个问题，但没有彻底解决。

局限三：跨域迁移能力有限

生成的Skill高度绑定特定领域和工具。"GitHub PR workflow"Skill不会自动变成"GitLab MR workflow"——需要用户手动调整或让AI重新生成。这在工具链经常切换的场景下有些不便。

局限四：多语言/多LLM的技能兼容性

如果用户在不同阶段用了不同的模型（GPT-4o vs Claude），生成的Skill中可能包含对特定模型能力的依赖假设。跨模型使用时有潜在的兼容性问题。

9.2 工程实现中的取舍

在阅读Hermes源码的过程中，有几个设计取舍让我印象深刻：

用SQLite而非更强大的数据库：团队选择了SQLite而不是PostgreSQL或更现代的向量数据库（如Chroma、PgVector）。表面看是"降级"，实际上对于目标用户（个人开发者和小型团队）来说，零运维的SQLite远比功能强大的向量数据库实用。这是典型的"够用就好"工程哲学。

Markdown而非YAML/JSON：Skill用Markdown存储而不是结构化的YAML/JSON。这在机器可读性上确实差一点，但换来了极强的人类可读性和编辑体验。考虑到Skill的核心价值就是"人可理解、可修改"，这个取舍非常值得。

技能生成而非模型微调：团队没有选择"用成功经验fine-tune模型"这条路，而是走了外部技能系统。这避免了fine-tune的高成本和不可逆性，但也有上限——当Skill数量爆炸时，检索和选择的开销也会上升。

十、展望：当所有AI Agent都学会「自我进化」

10.1 技能生态的雏形

Hermes Agent的出现，让我们看到了一个有意思的趋势：AI Agent的技能体系，正在从"人工编写"向"自动涌现"演进。

在传统软件生态中，开发者是技能的唯一创造者。用户使用开发者做好的工具。

在Hermes的思路中，AI开始成为技能的创造者。用户在使用AI的过程中，和AI一起"长出"了新的工具。

如果这个方向持续发展，未来的AI Agent技能体系可能是三层结构：

第一层：基础Skill包（人类专家编写，质量保证）
  ↕ 自动生成
第二层：个性化Skill（AI从用户使用中提炼，私人定制）
  ↕ 自动聚合
第三层：跨用户Skill共享（高质量个性化Skill被提炼为通用Skill）

第三层的实现还需要更多工程突破——如何保证从个人经验中提炼出的Skill有足够的泛化性？如何解决Skill的版权和归属问题？

10.2 记忆系统的未来方向

当前的四层记忆架构，核心还是"以任务为中心"的记录。更深远的方向是：

以人为中心的记忆：不只是记录"做了什么任务"，而是建立"用户画像"——用户的知识边界、技术偏好、工作风格、沟通习惯。当新AI助手接入时，直接读取这个画像，不需要重新学习。

多Agent共享记忆：当一个团队都在用同款AI Agent时，团队成员的经验能否汇总成一个"团队记忆"？某个工程师踩过的坑，团队其他成员不需要再踩一遍。

可验证的记忆：当前的记忆系统无法保证"事实正确性"。未来可能引入"知识图谱+外部验证"的机制，让记忆不只是"存储"，还有"确权"。

10.3 两条路线的融合

最后，我认为Hermes和OpenClaw代表的方向最终会走向融合：

• Hermes的自进化能力会进入OpenClaw生态：OpenClaw的Skill生态足够丰富，但缺乏"从实践中自动生长新Skill"的能力
• OpenClaw的工具生态会成为Hermes的技能来源：Hermes生成的Skill会越来越多，最终需要类似SkillHub的共享机制

未来的顶级AI Agent框架，可能是：OpenClaw的架构 + Hermes的自我进化 + 类似于Anthropic MCP的工具标准化。

这才是真正让人兴奋的图景。

结语：你的AI助手，终于开始认识你了

回到文章开头那个问题：为什么Hermes Agent让整个技术圈坐不住了？

因为它不只是在"回答问题"，它在"积累经验"。
因为它不只是在"执行命令"，它在"学会成长"。
因为它第一次让AI助手，真正有了"记忆"和"进化"的能力。

用过ChatGPT的朋友都知道那种无力感——每次新的对话，AI就像一个刚出场的失忆症患者。你得从头解释你的项目、你的偏好、你的工作方式。而Hermes彻底改变了这个局面：你用得越多，它就越懂你，下次你还没开口，它就已经在帮你处理那个你每次都要重复做的事情了。

这才是"AI助手"应该有的样子。

当然，Hermes目前还是Beta状态，技能冲突、跨域迁移、记忆质量验证等问题还需要在工程实践中逐步解决。但它指明了一个清晰的方向：AI不应该只是一个被动的工具，它应该是一个主动的、能学习的、会成长的伙伴。

当我们谈论"AI取代人类工作"的时候，Hermes给了另一个视角的答案：也许AI不是取代人类，而是放大人类的专业经验——你的十年踩坑总结，不应该只存在你一个人的脑子里，它应该变成一个可复用、可进化的系统，让后来者不必从零开始。

这，大概就是"自我进化的AI"最让人期待的地方。

参考资料

• Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
• Hermes Agent官方文档
• Nous Research官方博客
• SQLite FTS5文档: https://www.sqlite.org/fts5.html