Hermes Agent 是一个能够迭代学习的 Agent ——它从经验中创造 Skill，在使用过程中改进这些 Skill，推动自己学习知识，搜索自己过去的对话，并在整个会话中建立一个关于“你是谁”的深化模型。

解决了什么问题？

现有 Agent 一般都会被记忆问题、环境问题和能力问题所困扰，而这些正是 Hermes 试图解决的。

1. “阅后即焚”的无状态体验——记忆
   Agent 区别于其他 AI 对话的关键一点就是 Agent 应当需要有记忆。而 AI 的每个新会话窗口都像一张白纸，它们无法获取跨会话的信息，也不知道以往对话过的特定工作流，缺乏持久化的本地知识累积。
2. 被束缚在特定环境中——环境
   多数 Agent 都是在同一个终端中工作的，它们要么是在本地的某个IDE或CLI中，要么就是在网页端的对话中，它们无法无缝穿梭于通讯软件中和日常工作流。
3. 缺乏真正的进化闭环——能力
   几乎没有 Agent 是可以自我迭代的。那些传统 Agent 只能依赖开发者手动更新提示词或工作流来获取能力的提升，其自身缺乏通过实战经验反思、自我优化逻辑的能力。

Hermes 的优势

和 OpenClaw 一样，Hermes 也可以通过**网关（Gateway）**接入到各类通讯 App 中，并使用通讯 App 来向Hermes 发送指令，Hermes 再返回执行结果。通过这种形式，我们可以随时随地呼唤 Hermes 并让它执行任务。

Hermes 利用轻量级的文件系统（如 MEMORY.md 和 USER.md）维护持久化记忆。系统会通过内置的学习循环，把解决复杂报错的成功经验自动固化为全新的 Skills，确保它更加好用，随着时间推移越用越顺手。

核心技术亮点

1. 闭环学习与技能自增益 (Closed Learning Loop)
   Hermes 最有辨识度的能力之一，是它内建的学习闭环。它会在任务完成后结合对话上下文、操作过程与结果，自动回顾哪些经验值得沉淀为记忆或技能，并在后续任务中继续复用和更新这些技能。相比一次性回答型 Agent，Hermes 更像一个会积累方法论、逐步形成长期工作风格的系统。
2. 六种真实终端后端与可切换运行环境 (Multi-Backend Execution)
   为了在不同场景下执行代码、命令和自动化任务，Hermes 提供了六种终端后端：Local、Docker、SSH、Daytona、Singularity 和 Modal。这样的设计让它既能在本机运行，也能切换到容器、远程主机或云端环境中执行任务。它显著提升了隔离性、可迁移性和运维灵活度，但这些能力应理解为降低风险与增强控制，而不是“绝对安全”的保证。
3. 子智能体委派与并发协作 (Delegation & Parallelization)
   面对复杂任务，主 Agent 可以把问题拆分为多个独立子任务，并委派给隔离的子智能体并行处理。每个子智能体拥有独立的对话上下文、终端会话和工具执行环境；主 Agent 只接收总结后的结果，而不是把所有中间步骤都塞回主上下文。这种机制既能减少上下文污染，也有助于提升多步骤任务的处理效率。
4. 面向编辑器与开放模型生态的集成能力
   Hermes 支持 ACP（Agent Client Protocol），可以作为后端接入 VS Code、Zed、JetBrains 等现代编辑器，在熟悉的开发环境中完成代码修改、终端执行和交互式协作。模型接入层也比较开放，既可以连接本地兼容端点，也可以通过 OpenRouter 等服务接入云端模型，从而在成本、速度和能力之间做灵活取舍。
5. 训练与评测友好的轨迹数据能力 (Training & Eval Ready)
   Hermes 不只是生产力工具，也具备研究和训练基础设施属性。它可以按需保存包含对话、推理过程和工具调用结果的轨迹数据，并配套提供评测与训练环境，用于后续的监督微调、强化学习或基准测试。换句话说，Hermes 既能用于“做事”，也能为下一代 Agent 的训练和评估提供高质量样本。

记忆系统架构

人类记忆的三阶模型分为瞬时记忆、短期记忆和长期记忆，Hermes 的记忆系统结构和人类的十分相似：

• 短期记忆（Context Window / 上下文窗口）：
  • 对应人类的工作记忆。LLM（大语言模型）在当前对话中能看到的文字范围。如果对话过长，旧的信息会因超出窗口而被“忘掉”。
• 长期记忆（Vector Database / 向量数据库）：
  • 通过 RAG（检索增强生成）技术，将海量文档存入数据库。当需要时，AI 根据关键词检索相关片段，将其临时拉入“工作记忆”中。
• 持久化记忆与自进化（Hermes 的特色）：
  • USER.md / MEMORY.md：Hermes 会将用户的偏好和任务的阶段性成果记录在特定的本地文件中，确保即便重启，它也能“记起”你是谁以及项目进度。
  • 技能固化（Skill Library）：这是最高级的记忆——将成功的操作路径（Code/Prompt）保存下来。下次遇到类似问题，它不再重新推理，而是直接调用 Skill，这模仿了人类的程序性记忆。
  • **反思（Reflection）机制：**它会定期审视自己的记忆文件，剔除冗余，提炼核心知识，从而有效地对抗了“信息过载”和“记忆退化”。

具体地，Hermes 将数据信息分为了两种数据，热数据和冷数据：

热数据：每次对话前都要加载的，放在提示词里。

冷数据：按需检索的，放在SQLite里

1
2
3
4
5
6
7
8
9
10
11
12

┌──────────────────────────────────┐
│           热数据（提示词）          │
│   ┌─────────┐    ┌─────────┐     │
│   │MEMORY.md│ +  │ USER.md │     │
│   └─────────┘    └─────────┘     │
├──────────────────────────────────┤
│           冷数据（仓库）            │
│   ┌─────────┐    ┌─────────┐     │
│   │ SQLite  │ +  │ Skills  │     │
│   │ 历史库   │    │ 技能层   │     │
│   └─────────┘    └─────────┘     │
└──────────────────────────────────┘

这样做的好处是：提示词里的内容相对稳定，可以充分利用模型提供商的缓存机制，降低成本。

Hermes Agent 的运行流程

Hermes 虽然有很多入口，但最后都会汇到同一套 Agent 内核里去执行。你可以在命令行里用它，可以在终端 UI 里用它，也可以把它挂到编辑器或者消息平台上。但这些入口本质上更像“不同的外壳”或者“不同的接线方式”，真正负责理解上下文、调用模型、决定要不要用工具、以及把结果一步步做出来的，还是后面那套统一的执行链路。这样设计的好处很实际：能力不会因为入口不同而分裂，行为更一致，维护起来也更可控。

流程的第一步是接住用户输入，然后判断当前到底是在什么模式下运行。前端层各自处理自己的交互细节，比如终端界面怎么渲染、编辑器协议怎么收发、聊天平台消息怎么转发，但它们不会各自实现一套独立的 Agent。做完这一层分流之后，系统会进入统一的会话阶段：看看这是一个新任务，还是要接着上一次的上下文继续往下做。紧接着，它会把当前可用的配置加载进来，比如模型提供方、模型选择、启用哪些工具、当前工作目录在哪，以及这一轮任务允许使用什么能力。

再往下，就是把这些运行时信息组装成一个真正可工作的 Agent 实例。这里有一个很关键的设计：Hermes 不是把所有工具硬编码塞给模型，而是根据当前的工具集、注册表和运行环境，动态生成这一轮真正可用的工具清单。换句话说，模型每次看到的工具面板，都是当前环境下“真的能调、真的能执行”的那一组，而不是一个静态的大列表。这种做法一方面减少了模型误调用不存在工具的概率，另一方面也让同一个系统可以在不同场景下灵活裁剪能力。

核心部分是那个多轮循环。它每一轮都会先把系统提示词、历史消息和当前用户输入拼到一起，然后发给模型。模型返回之后，系统会先判断一个问题：这次返回的是最终答案，还是工具调用请求。如果已经是最终答案，那这一轮基本就结束了；但如果模型决定要调工具，事情就会进入 Agent 真正“动手干活”的阶段。这个阶段里，有些能力属于 Agent 自己维护的内部机制，比如 todo、memory、delegate 之类；另一些则会通过统一的分发层落到具体工具实现上，比如终端执行、文件读写、网页检索、浏览器操作、MCP 服务调用等。工具跑完之后，结果不会直接粗暴地吐给用户，而是先写回消息上下文，再交给模型继续下一轮决策。也就是说，Hermes 不是“模型回答一次，工具跑一次”这种单步模式，而是模型读工具结果、继续推理、再决定下一步的闭环模式。

这也是为什么它看起来更像一个真正的 Agent，而不是一个带插件的聊天机器人。因为工具执行结果本身就是后续推理的一部分。模型不是在真空里想问题，而是在持续读取环境反馈：终端命令有没有报错，文件改动是不是成功了，测试有没有通过，网页上搜到了什么，浏览器页面现在是什么状态。每一轮新信息都会重新进入上下文，推动下一轮决策。

这张图里还有两条很有工程味的支线。第一条是审批链路。对于高风险操作，系统不会默认一路放行，而是可以在执行前插入确认机制。这样做不是为了让流程变慢，而是为了把“自动化”和“可控性”放在一起。第二条是上下文优化链路。随着任务变长，对话历史会越来越大，所以系统会在必要时做上下文压缩、记忆注入和提示词缓存。前者是为了不把上下文窗口撑爆，后两者则是在尽量保留有效信息的同时，降低重复计算和重复传输的成本。你可以把它理解成：Hermes 不只是把所有历史原封不动扔给模型，而是在每次调用前，先做一次“上下文编排”。

当模型终于返回一个不再包含工具调用的最终回答时，这一轮任务才算真正收尾。系统会把会话历史、使用统计、标题之类的状态保存下来，然后再根据当前入口把结果回传出去：在命令行里显示出来，在终端 UI 里流式更新，在编辑器里渲染成可交互结果，或者发回聊天平台。

结语

Hermes Agent 的价值，不在于把 Agent 包装成一个无所不能的神话角色，而在于它把长期记忆、技能沉淀、真实执行环境、多端接入、调度自动化和研究基础设施，收进了同一套一致的工程内核里。它既可以是个人工作流助手，也可以是研究和训练下一代 Agent的实验底座。

如果说很多 Agent 仍然停留在“一次性回答器”的阶段，那么 Hermes 更像是在认真回答另一个问题：一个真正可长期使用的 Agent，应该如何在现实环境里积累经验、保持可控，并逐步长成一个越来越顺手的系统。

参考：

Hermes Agent 介绍