Hermes Agent

AI 助手为什么总是像金鱼一样，只有 7 秒记忆？

agent 的健忘

当你运行 “帮我部署一下昨天那个服务的新版本。” 时，有些 agent 会回复“好的！请问您要部署什么服务？需要什么样的配置？您希望使用什么命名规范？”

但你记得昨天明明很顺利的运行了，为什么这么短时间，agent 就不记得了

这就是当下绝大多数 AI Agent 的真实写照。它们就像那种你刚介绍完自己名字、下一秒就问"您贵姓"的社交灾难症患者。技术上，这叫"无状态"（Stateless）；通俗点说，这叫"不长记性"。

为什么"记住"这么难？

你可能会问：这不科学啊！我的聊天记录明明都保存在服务器上，为什么它就是"记不住"？

这里有个关键的技术误区需要澄清：存储 ≠ 记忆。

传统 AI Agent 的架构大致是这样的：

用户输入 → LLM API → 工具调用 → 返回结果 → （可选）存个日志

每次对话都是一次全新的 HTTP 请求。LLM 就像一个超级聪明但极度健忘的顾问，你每次咨询都要重新介绍背景、重新解释需求、重新建立上下文。即使你在系统提示里塞了一些"记忆文件"，那也是静态的、被动的、需要人工维护的。

更麻烦的是上下文窗口的限制。现在的模型虽然能处理几十万 token，但如果你真的把三个月的聊天记录塞进去，不仅成本爆炸，模型的注意力也会像在开大会时走神的你一样——"刚才说到哪了？"

所以，真正的"记忆"不是简单的数据存储，而是信息的结构化提取、索引、检索和动态整合。这就像是人类大脑不会记住每一秒的视觉信号，而是会提取模式、形成概念、建立联想。

而这，正是 Hermes Agent 的出发点。

Hermes Agent 是谁？

来自 Nous Research

如果 AI 助手要真正成为"助手"而不是"工具"，它需要具备什么能力？

他们的答案是：学习能力。不是训练阶段的学习，而是部署后的持续学习。

这听起来像是废话，但在工程实现上，这是两条完全不同的技术路线。

两条路线之争：编排中心 vs 学习中心

要理解 Hermes Agent 的创新，我们必须先看看当时的主流做法——以 OpenClaw 为代表的"编排中心"架构。

OpenClaw 的路线（编排中心）：

想象一个大型机场。你是旅客（用户），机场有无数的登机口（工具），无数的航线（任务流程）。机场的核心是一个中央网关（Gateway），它负责：

• 接收你的请求
• 检查你的身份
• 把 you 路由到正确的登机口
• 确保行李（数据）正确转运

这个设计的优点是显而易见的：模块化、可扩展、生态丰富。你可以轻松添加新的工具、新的渠道、新的技能。截至 2026 年 3 月，OpenClaw 的技能市场已经有超过 13,700 个技能。

但它有个根本性的限制：Agent 本身不会"成长"。

每次任务，你都要告诉它用什么技能、什么参数、什么流程。下次做同类任务，这些你还得再说一遍。它是工具，很好用，但不会"长记性"。

Hermes Agent 的路线（学习中心）：

现在想象的不是机场，而是一个实习生。

第一天，实习生什么都不会，你要手把手教他怎么做报表。但关键在于：他在学。第二次做报表，他可能还需要你提醒几个细节。第三次，他基本能独立完成。一个月后，他不仅能做报表，还能发现你之前流程里的问题并主动优化。

这就是 Hermes Agent 的核心设计哲学：Agent = 你给目标 + 它自己学 + 用久了比你自己还懂你。

解剖Hermes Agent 架构

极简的外表，精密的内心

先来看一张 Hermes Agent 的架构简图

┌─────────────────────────────────────────┐
│           用户输入层 (CLI/Gateway)        │
│    Terminal │ Telegram │ Discord │ ...  │
└─────────────────┬───────────────────────┘
                  ▼
┌─────────────────────────────────────────┐
│           Agent Core (核心引擎)          │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐  │
│  │ 推理模块  │ │ 工具调度 │ │ 状态管理  │  │
│  └────┬────┘ └────┬────┘ └────┬────┘  │
│       └─────────────┴─────────────┘     │
│              Agent Loop (执行循环)        │
└─────────────────┬───────────────────────┘
                  ▼
┌─────────────────────────────────────────┐
│           记忆与技能层                   │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐    │
│  │MEMORY.md│ │USER.md  │ │Skills/  │    │
│  │(事实记忆)│ │(用户画像)│ │(程序记忆)│   │
│  └─────────┘ └─────────┘ └─────────┘    │
│  ┌─────────────────────────────────┐    │
│  │      SQLite 会话存档 (全文检索)    │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘
                  ▼
┌─────────────────────────────────────────┐
│           工具执行层                     │
│  本地Shell │ Docker │ SSH │ API │ ...  │
└─────────────────────────────────────────┘

和 OpenClaw 最大的区别在于：没有中央网关。

在 Hermes 的架构里，Agent Core 是唯一的中心。Gateway（消息平台接入层）只是一个可选的附属模块，甚至不需要它，直接在终端输入 hermes 就能启动完整的 Agent 功能。

这种"同心增长式"（Concentric Growth）架构的设计理念是：把复杂度内化到 Agent 本身，而不是外化到编排层。

核心引擎：Agent Loop

这是 Hermes Agent 的心跳，每秒都在进行的决策-执行-反馈循环。官方文档把它描述为一个Closed Learning Loop（闭环学习循环），这个名字暗示了它的自我进化特性。

一个典型的循环流程是这样的：

用户输入 -》 模型推理 -》 工具调用 -》 结果反馈 -》 记忆更新 -》 技能进化

Step 1: 用户输入捕获

无论是来自终端的 hermes 命令，还是一条其他应用消息，输入都会被标准化为一个统一的 UserInput 对象。这里有个有趣的细节：Hermes 会记录输入的平台上下文（你是在手机上发的还是在电脑上？），因为这可能影响后续的工具选择（比如在手机上更适合用简单的命令，在电脑上可以跑复杂的脚本）。

Step 2: 上下文组装（Context Assembly）

这是整个系统最精密的部分。Hermes 不会简单地把所有记忆塞进提示词，而是进行分层检索和动态组装：

# 伪代码示意，基于源码结构
def assemble_context(user_input):
    # 1. 固定层：系统身份和工具定义（可缓存）
    system_prompt = load_default_identity() + load_tool_definitions()
    
    # 2. 记忆层：MEMORY.md + USER.md（轻量级，常驻内存）
    memory_context = load_frozen_memory()  # 约 500-1000 tokens
    
    # 3. 技能索引：当前可用的技能清单（动态加载）
    skills_index = load_skills_index()  # 只加载技能名和描述，不加载完整内容
    
    # 4. 会话历史：最近的对话（受上下文窗口限制）
    conversation_history = load_recent_history(max_tokens=4000)
    
    # 5. 动态检索：如果用户提到"上次那个项目"，搜索 SQLite 存档
    if needs_retrieval(user_input):
        relevant_sessions = search_session_archive(user_input.keywords)
        retrieved_context = format_retrieved_sessions(relevant_sessions)
    
    return combine_all_layers(system_prompt, memory_context, skills_index, 
                              conversation_history, retrieved_context)

关键洞察：保持提示词稳定以便缓存，把可变内容推到工具里。

注意到第 2 步的 load_frozen_memory() 了吗？MEMORY.md 和 USER.md 是"冻结"的——它们在会话开始时加载一次，之后不会频繁变动。这让系统提示词保持相对稳定，可以被 LLM 提供商的缓存机制优化，大幅降低 API 成本。

而需要动态检索的内容（比如"三个月前那个项目"），则通过 session_search 工具按需查询，而不是一直占用宝贵的上下文窗口。

Step 3: LLM 推理与决策

组装好的上下文被送到 LLM（可以是 OpenAI、Anthropic、OpenRouter 上的任意模型，甚至是本地 Ollama）。模型输出包含两部分：

• 思考过程：模型对任务的分解和规划
• 行动指令：要调用的工具名和参数

Step 4: 工具执行

Hermes 内置了 40+ 工具，涵盖：

• 系统工具：shell、文件系统、代码执行
• 开发工具：Git、Docker、SSH、浏览器自动化
• 通信工具：Telegram、Discord、Slack、邮件发送
• AI 工具：图像生成、语音识别、向量检索

工具执行支持多种后端环境：本地、Docker 容器、SSH 远程服务器、Serverless 平台（如 Modal）。这意味着你可以让 Agent 在你本地电脑上跑命令，也可以让它操作远程服务器，甚至可以在隔离的 Docker 沙箱里执行不可信代码。

Step 5: 结果反馈与状态更新

工具执行的结果（成功/失败、输出内容、耗时等）被反馈给 Agent，进入下一轮循环。如果是多步骤任务，这个过程会重复多次，直到任务完成。

Step 6: 记忆持久化与学习触发

这是 Hermes 最独特的部分。每次会话结束时（或定期触发），Agent 会执行：

• 记忆刷新：把本次会话的重要事实更新到 MEMORY.md
• 用户画像更新：基于本次交互更新 USER.md 中的偏好模型
• 技能生成判断：如果本次任务涉及 5 次以上工具调用且形成了可复用的模式，触发 Skill Learning
• 技能优化：检查本次使用的技能，根据执行反馈决定是否更新

记忆系统：四层架构

Hermes 的记忆系统不是单一的，而是四个层次的协同：

第一层：提示记忆（Prompt Memory）

• 载体：MEMORY.md + USER.md
• 特点：小而精，常驻上下文，约 500-1000 tokens
• 内容：用户是谁（后端工程师？产品经理？）、当前项目、技术栈偏好、沟通风格（喜欢详细解释还是直接给答案？）
• 更新频率：每次会话后增量更新

第二层：会话存档（Session Archive）

• 载体：SQLite 数据库，FTS5 全文检索
• 特点：海量存储，按需检索，不在默认上下文中
• 内容：完整的对话历史、工具调用轨迹、执行结果
• 查询方式：通过 session_search 工具，用户可以说"上次我们讨论的那个项目"，Agent 会自动检索相关会话

第三层：技能记忆（Skill Memory）

• 载体：~/.hermes/skills/*.md 文件
• 特点：程序性知识，按需加载，渐进披露（progressive disclosure）
• 内容：可复用的工作流，如"如何部署 Python 服务"、"如何分析日志文件"
• 独特之处：Agent 自己创建、自己更新、自己删除

第四层：用户建模（User Modeling）

• 载体：可选的 Honcho 方言建模层
• 特点：深度个性化，长期积累
• 内容：更复杂的用户画像，如决策模式、学习曲线、甚至情绪模式
• 实现：基于 Honcho 的开源用户建模技术

这种分层的精妙之处在于信息的分级管理。就像人类大脑不会把所有记忆都放到工作记忆里一样，Hermes 也不会把所有数据塞进 LLM 的上下文。重要的、高频的放第一层；海量的、需要精确检索的放第二层；程序性的、模式化的放第三层；深度的、建模驱动的放第四层。

技能学习循环——让Agent"长脑子"的秘密

Skill Learning Loop（技能学习循环）。

这是它区别于其他 Agent 的"杀手级特性"，也是"自我进化"承诺的工程落地。

什么是"技能"？重新定义这个概念

在传统的 Agent 框架（如 OpenClaw）里，Skill 是人工编写的功能模块。开发者写一段代码或 YAML 配置，描述"当用户说 X，执行 Y"，然后发布到技能市场，用户下载安装。

Hermes 对 Skill 的定义完全不同。在它的架构里，Skill 是程序性记忆（Procedural Memory）——不是外部插件，而是从经验中沉淀的内部能力。

官方文档的描述很直白：

• 完成复杂任务后，Agent 可以创建 Skill
• 试错后找到正确路径，可以保存成 Skill
• 用户纠正了做法，可以更新 Skill
• Agent 甚至可以删除过时 Skill

注意这里的"可以"。Skill 的创建不是强制性的，而是 Agent 的自主决策。这涉及到一个复杂的判断逻辑：这个任务值得记住吗？它是否形成了可复用的模式？保存的收益是否大于成本？

Skill 的生命周期：从诞生到进化

阶段一：原始任务执行（The Trigger）

假设你让 Hermes 完成这样一个任务：

"帮我分析一下我们 GitHub 仓库过去一周的提交记录，找出哪些文件变动最频繁，然后生成一份报告发到我的邮箱。"

这是一个复杂任务，涉及多个步骤：

• 调用 GitHub API 获取提交记录
• 分析文件变动频率
• 生成报告（可能是 Markdown 或 HTML）
• 调用邮件工具发送

Hermes 开始执行，调用各种工具，可能中间还失败了几次（比如 API 限流、格式不对），最终成功完成。

阶段二：模式提取与 Skill 生成（The Birth）

任务完成后，Hermes 的学习模块被触发。它会分析本次执行的轨迹：

• 调用了哪些工具？
• 工具的参数是什么？
• 执行的顺序和依赖关系？
• 哪些步骤是通用的、哪些是特定的？

如果判断这是一个可复用的模式（比如"分析 GitHub 仓库并生成报告"是一个常见需求），它会生成一个 Skill 文档：

# Skill: github-repo-analysis-report

## 描述
分析 GitHub 仓库的提交历史，识别高频变动文件，生成可视化报告并邮件发送。

## 触发条件
用户提到"分析仓库"、"提交记录"、"代码变动频率"等关键词。

## 执行流程
1. 使用 `github_api` 获取过去 7 天提交记录
   - 参数：repo_owner, repo_name, since_date
2. 使用 `code_analysis` 统计文件变动频率
   - 输入：提交记录 JSON
   - 输出：变动频率排序列表
3. 使用 `report_generator` 生成 HTML 报告
   - 模板：默认技术报告模板
4. 使用 `email_sender` 发送报告
   - 收件人：用户默认邮箱

## 参数配置
- days_back: 7 (默认)
- top_n_files: 10 (默认)
- report_format: "html"

## 优化记录
- 2026-04-01: 初始创建，执行成功，耗时 45s

这个 Skill 被保存到 ~/.hermes/skills/github-repo-analysis-report.md。

阶段三：Skill 的复用（The Reuse） 一周后，你又说："帮我分析一下前端仓库最近的代码变动。"

Hermes 的处理流程：

• 检索现有 Skills，发现 github-repo-analysis-report 匹配
• 加载 Skill 文档（不是完整内容，只是索引和描述）
• 在系统提示中声明："我有一个可用技能：github-repo-analysis-report，用于分析仓库提交记录"
• LLM 决策：使用这个 Skill
• 执行时，按 Skill 定义的流程调用工具，而不是重新推理

结果是：响应更快（不需要重新规划）、成功率更高（经过验证的流程）、用户体验更一致。

阶段四：Skill 的进化（The Evolution） 又过了一个月，你有了新需求："分析报告不错，但能不能把变动频率和 bug 引入率关联起来？我想知道哪些文件的变动最容易引入 bug。"

Hermes 执行这个新需求时，会：

1. 识别这是对现有 Skill 的扩展
2. 执行新流程（增加调用 bug 追踪系统的步骤）
3. 如果执行成功，更新 Skill 文档：

## 优化记录
- 2026-04-01: 初始创建
- 2026-05-01: 增加 bug 关联分析，调用 bugzilla_api，执行成功，用户反馈积极

Skill 就这样在使用中进化了。它不是静态的，而是活的、成长的、适应的。

技术实现：Skill Learning 的底层机制

触发机制

不是所有任务都会生成 Skill。Hermes 有一个启发式判断逻辑：

• 任务必须涉及 5 次以上工具调用（确保足够复杂）
• 任务必须成功完成（失败的经验不值得学习，除非是专门的错误处理 Skill）
• 任务必须展现出可复用的模式（通过分析工具调用的抽象程度来判断）

提取算法

当触发 Skill 生成时，Hermes 会：

• 轨迹压缩：把完整的工具调用序列（可能包含很多中间状态、错误重试）压缩成一个"清洁版"的执行图
• 参数泛化：把具体的参数值（如 repo_name="my-project"）泛化为变量（repo_name: string）
• 条件识别：分析用户输入的哪些部分触发了这个流程，形成"触发条件"
• 文档生成：用模板把上述信息格式化为 Markdown

存储与检索

Skills 以 Markdown 文件形式存储，这有几个好处：

• 人类可读：你可以直接打开看 Agent"学到"了什么
• 可编辑：你可以手动修改 Skill，教 Agent 更好的方法
• 版本友好：可以用 Git 管理 Skill 的进化历史
• 社区共享：符合 agentskills.io 开放标准，可以分享和导入

检索时，Hermes 使用渐进披露（Progressive Disclosure）策略：默认只加载 Skill 的名称和描述（占用很少 token），只有当 LLM 明确决定使用某个 Skill 时，才加载完整的执行流程。

反馈闭环

Skill 的进化依赖于执行反馈：

• 如果 Skill 执行失败，记录错误类型，下次触发重新学习
• 如果用户纠正了 Skill 的执行（"不对，你应该先检查环境变量"），触发 Skill 更新
• 如果 Skill 长期不被使用，标记为"可能过时"，Agent 可能主动询问用户是否删除

记忆的艺术——如何让 AI"记得住"又"记得正好"

Skill Learning 解决的是"程序性记忆"（怎么做），但 Hermes 还需要解决"陈述性记忆"（是什么）——用户是谁、项目背景、历史对话。

这是另一个技术挑战：如何在有限的上下文窗口内，最大化记忆的有效性？

人类记忆的启示：工作记忆 vs 长期记忆

认知科学告诉我们，人类记忆分为两层：

• 工作记忆（短期记忆）：容量极小（7±2 个信息块），用于当前思考
• 长期记忆：容量几乎无限，但需要编码才能存入，需要提取线索才能检索

Hermes 的记忆系统设计深受这个模型启发。

四层记忆架构的技术细节

第一层：提示记忆（MEMORY.md + USER.md）

这是"工作记忆"的等价物，始终保留在上下文中。

MEMORY.md 记录事实性信息：

# 记忆

## 当前项目
- 正在开发 Hermes Agent 的文档站点
- 技术栈：Next.js + MDX + Tailwind
- 部署在 Vercel

## 技术偏好
- 主要使用 Python 和 TypeScript
- 喜欢类型提示（type hints）
- 代码风格：Black formatter, 88 字符行宽

## 重要事实
- 公司对安全要求严格，所有代码必须经过 review
- 偏好异步编程，避免阻塞调用

USER.md 记录用户画像：

# 用户画像

## 角色
后端工程师，5 年 Python 经验，熟悉 K8s

## 沟通风格
偏好简洁的技术解释，不需要基础概念科普

## 常用工具
Docker, kubectl, GitHub CLI, Terraform

## 学习曲线
快速掌握新概念，但偏好有文档参考

这两个文件是冻结（Frozen）的——在会话开始时加载，之后保持不变。这让系统提示词稳定，便于缓存。

第二层：会话存档（SQLite + FTS5）

这是"长期记忆"的存储库。所有会话都被完整记录，包括：

• 用户输入和 Agent 响应
• 工具调用序列和参数
• 执行结果和耗时
• 情绪标签（如果有）

关键技术：FTS5 全文检索。当用户说"上次我们讨论的那个项目"，Hermes 不会瞎猜，而是执行 SQL 查询：

SELECT session_id, snippet, timestamp 
FROM sessions 
WHERE content MATCH '项目' 
ORDER BY rank 
LIMIT 5;

然后把检索结果注入上下文，让 LLM 基于实际的历史记录回答。

第三层：技能记忆（Skills/ 目录）

前面已经详细讲过，这是程序性记忆的载体。

第四层：用户建模（Honcho 集成）

这是可选的深度个性化层。Honcho 是一个开源的用户建模技术，通过分析长期交互模式，构建更复杂的用户画像：

• 你的决策模式（偏好快速决策还是深思熟虑？）
• 你的学习曲线（对新技术的接受速度）
• 你的情绪模式（什么时候容易沮丧，什么时候更开放）

这层更"重"，需要更多数据积累，但可以实现真正的"懂你"。

Nudge 机制：主动的记忆巩固

Hermes 有个有趣的设计叫 Nudge（轻推）——定期提醒 Agent 反思和保存记忆。

具体来说：

• 每 5-10 轮对话，Agent 会被提示："这次会话有什么值得记住的？"
• 每天结束时，Agent 可能会生成一个"今日总结"，更新 MEMORY.md
• 每周，Agent 可能会回顾本周的 Skills，考虑是否需要合并或优化

这就像是人类的记忆巩固过程——不是被动地等待信息沉淀，而是主动地整理、编码、存储。

疑惑

"自我改进"的根本缺陷。 这是我觉得最值得警惕的：Hermes 的 Agent 会在完成任务后自动评估结果、把经验编码成 Skill。问题是——Agent 几乎总是认为自己做对了。即使实际输出有错，它也会把错误的"经验"固化下来。Power user 管这叫"噩梦"：你手动改好了一个 bug，下次 Agent 又按旧 Skill 把错误改回去。

Token 开销问题。 有人测过，Hermes 每次 API 调用大约 73% 是固定开销（约 13.9K tokens 用于加载上下文和 Skill 库），真正干活的只占小头。对于个人开发者来说，这个 token 税不便宜。

追不完的“第一框架”

打开 GitHub 的 ai-agent Topic 页面：9,900 个仓库。

随便列几个 2026 年上半年"你应该关注"的 Agent 框架：LangGraph、CrewAI、AutoGen、LlamaIndex Agents、Mastra、Haystack、FastAgency、Semantic Kernel、Phidata、Composio、Multica…… 有人做过统计，至少 25 个以上进入过 Trending 或者被正经技术媒体推荐过。

每一个框架发布时的话术都长这样：

"We fundamentally rethought agent architecture." "10x faster than XX, 3x cheaper than YY." "The only agent framework you'll ever need."

然后一个月后，另一个框架冲上 Trending，上个月的"唯一框架"已经没人提了。Reddit 上甚至开始出现反趋势的帖子："I Stopped Using Frameworks — AI Agents Do It All Now."

这不叫技术进步。这叫框架疲劳（Framework Fatigue）。

现象	数据
GitHub ai-agent 仓库数	9,900+
2026 上半年主流 Agent 框架	25+
常见生产事故	重复调用 API、幻觉策略、死循环、覆盖用户编辑
反趋势信号	"停止使用框架"类帖子开始高赞

LangChain → AutoGen → CrewAI → OpenClaw，一个不落。每换一个框架，之前写的适配代码、踩过的配置坑、积累的调试经验就全废了。转头一看，半年过去了，我的实际产出并没有因为"用了更好的框架"而变多。