大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



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”到底是怎么从论文变成生产级代码的——这篇文章就是为你写的。

---

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

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

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

这就导致了两个极端：

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

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

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

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

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

---

从宏观架构来看，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，直接编辑即可。

接下来我们逐层深入。

---

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

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

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

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

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

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

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

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

# 工作记忆的简化数据结构示例 working_memory = ,

"context_window": [ {"role": "user", "content": "帮我看看登录后token过期的问题"}, {"role": "assistant", "content": "让我分析一下OAuth流程..."}, {"role": "tool", "content": "文件读取: auth/oauth.py"}, # ... 更多上下文消息 ], "active_files": ["auth/oauth.py"], 

}

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

情景记忆是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做语义级搜索，再也不会”聊过就忘”。

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

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

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

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

# 语义记忆的数据结构 semantic_memory =

] 

}

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

程序性记忆是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，没有未提交的修改。

gh pr create –title "feat: [功能名称]" –body " 改动说明

• [改动点1]
• [改动点2] " –base main

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

  git checkout -b feat/xxx 

  git push -u origin feat/xxx 

  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）——它不只执行任务，还会从任务执行中学习，把学到的经验固化下来。

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

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

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

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文件导致的记忆噪音。

当触发条件满足后，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文件质量稳定、可解析、可执行。

  如果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重新生成。

  ---

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

  平台连接方式特色功能 TelegramBot API即时消息，支持附件 DiscordWebhook + Bot频道管理，语音集成 SlackWeb API企业集成，工作流 WhatsAppWhatsApp Business API私域消息 钉钉钉钉开放平台企业内部 飞书飞书开放平台协作场景 EmailIMAP/SMTP异步通知 MatrixMatrix Protocol去中心化 SignalSignal Protocol隐私消息 SlackWeb API企业集成 Custom WebhookHTTP通用集成

  这个设计的精妙之处在于：不管用户通过哪个平台发消息，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 = 

  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", "") # ... 

  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”说一声”就能搞定的事。

---

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

OpenClaw 的路线：人来写技能

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

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

Hermes 的路线：AI自己写技能

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

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

这个问题值得深入思考。两条路线代表了对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。

---

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

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即可。

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-" 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/"

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

用户: 记住，以后部署到生产环境前必须先在staging跑完整测试 Hermes: 明白了。我将把这条规范加入生产部署Skill。生成中…

 ✓ Skill已更新: deployment/production-safe - 增加了前置检查：staging完整测试流程 - 自动继承原有的回滚步骤 

所有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下次就会用新版本。

---

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

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

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

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

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

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

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

# 存储空间估算 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级别——这是本地存储的巨大优势，隐私完全自主。

---

作为工程师，我们必须客观地评价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中可能包含对特定模型能力的依赖假设。跨模型使用时有潜在的兼容性问题。

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

用过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