聊 Agent 框架之前，先问一个问题：你用过的那些 AI 助手，有哪个真正“记住”过你？

大部分产品就是一轮对话，说完就忘。下次再来，你得重新介绍自己、重新解释上下文、重新交代偏好。本质上，它们是生成器，不是代理。

Hermes Agent 想解决的就是这个问题。

---

Hermes 到底是什么

一句话定义：它是一个面向长期运行的通用 Agent 框架。

它不是单纯的大模型聊天界面，也不是只服务于 IDE 的代码助手，而是一个把这些能力组合起来的系统：

• 大模型推理
• 工具调用
• 长期记忆
• 经验沉淀
• 多平台接入
• 定时自动化
• 子代理协作
• 多实例隔离

你可以把它理解成：

以大模型做决策，以工具系统做执行，以 memory 和 skills 做长期增强，以 gateway、cron、profile 做运行基础设施的 Agent 框架。

---

它想解决四个问题

Hermes 不是为“回答一次问题”设计的。它要让 Agent 具备四种能力：

能思考。 靠大模型做任务分解、判断、规划。

能动手。 靠工具系统真正去干活——读写文件、跑命令、操作浏览器、发消息、调外部系统。

能记住。 靠 memory 和 session history，跨会话保留用户信息和历史上下文。

能成长。 靠 skills，把每次成功经验沉淀成可复用的工作流。

这四样叠在一起，才是一个真正的 Agent。

---

从系统层面看，Hermes 分六层

第一层：交互入口层

这是用户或外部系统进入 Hermes 的入口。

典型入口包括：

• CLI

• 本地终端直接和 Hermes 对话

• Gateway

• Telegram / Discord / Slack / Email 等平台接入

• Cron

• 定时任务触发 Hermes

• Webhook / API / MCP

• 外部系统把事件或请求送入 Hermes

这一层的职责

它不负责“智能推理”，而负责：

• 接收输入
• 标准化消息
• 选择会话
• 把请求送入 Agent 核心
• 将结果返回给对应平台

你可以把它理解成 Hermes 的 I/O 层。

第二层：Agent 核心决策层

这是 Hermes 的大脑。

这一层的本质是一个 Agent Loop：

1. 接收用户目标
2. 组装上下文
3. 调用模型
4. 如果模型要求调用工具，就执行工具
5. 把结果重新反馈给模型
6. 直到得出最终答复

这是 Hermes 最核心的机制

它和普通聊天系统最大的区别在于：

• 普通聊天系统：用户提问 → 模型输出
• Hermes：用户提问 → 模型判断 → 工具执行 → 模型再判断 → 多轮迭代 → 输出

所以 Hermes 不是“单轮生成器”，而是“带反馈闭环的执行代理”。

第三层：上下文增强层

这一层决定 Hermes 不是“裸模型”，而是“带环境与经验的模型”。

包括三类关键能力：

1. Prompt / 规则注入

给模型提供：

• 身份和行为规范
• 当前运行环境
• 工具使用规则
• 平台限制
• 安全边界

2. Memory 注入

给模型提供跨会话稳定信息：

• 用户偏好
• 项目习惯
• 环境事实
• 长期约束

3. Skills 注入

给模型提供“已有经验”：

• 某类任务怎么做
• 哪些坑需要避开
• 哪种流程验证过有效

这一层的作用是：

让模型不是“从零开始思考”，而是在已有知识、规则、经验和记忆的基础上工作。

第四层：工具执行层

这是 Hermes 的“手和脚”。

Hermes 的工具层负责把模型的意图转换为真实动作。

例如：

• 文件操作
• shell 执行
• 浏览器操作
• Web 搜索
• 图片/语音能力
• 任务管理
• 记忆写入
• 会话检索
• 子代理调用
• 消息发送
• 定时任务管理

这一层为什么重要

因为 Agent 真正和世界交互，不是靠模型“想象”，而是靠工具执行。

所以 Hermes 的本质不是“大模型产品”，而是：

大模型 + 工具运行时

第五层：状态与持久化层

Hermes 并不是每次启动都“失忆”。

它需要持续保存很多状态：

• 会话历史
• session 索引
• 用户记忆
• 技能库
• 配置
• 认证信息
• 日志
• 定时任务
• profile 级隔离状态

这一层的作用

它保证 Hermes 具备“长期连续性”。

没有这一层，Hermes 只是一次性聊天工具； 有了这一层，Hermes 才能成为真正的长期代理系统。

第六层：运行基础设施层

这层是让 Hermes 可以在复杂环境中稳定运行的基础设施。

包括：

• Provider 抽象
• Toolset 开关
• Profile 隔离
• Cron 调度
• Gateway 服务化
• MCP 接入
• 多平台路由
• 子代理协作
• 安全与审批机制

这一层让 Hermes 从“一个单机助手”上升为“一个可部署、可运营、可自动化的 Agent 平台”。

---

Hermes的运行模型：不是聊天，而是闭环执行

再强调一次，这是理解 Hermes 的关键。

普通聊天系统：

 
1

用户输入 → 模型生成 → 返回答案

hermes：

这意味着什么？

1. 回答不是一次性生成的

Hermes 的结果往往来自多次模型调用和多次工具执行。

2. 工具结果是推理的一部分

工具不是外挂，而是 Agent Loop 的组成部分。

3. Hermes 的“智能”是系统智能，不只是模型智能

最终效果来自：

• 模型能力
• 工具能力
• 上下文注入质量
• memory
• skills
• 持久化状态
• 平台基础设施

---

三个长期能力模块：这才是 Hermes 的护城河

Hermes 和很多 Agent 最大的区别，不在“能不能调工具”，而在它有明显的长期增强机制。

Memory：长期事实记忆

Memory 保存的是 跨会话稳定有效的信息。

例如：

• 用户偏好中文
• 用户喜欢简洁回答
• 某项目使用某种测试框架
• 某环境有特定限制

它的作用

减少用户重复说明，让 Hermes 在未来会话中延续上下文。

本质：

Memory 是 用户和环境的长期状态层。

Session History：历史过程记忆

这和 memory 不一样。

它记录的是：

• 某次会话做过什么
• 讨论过什么
• 任务是怎么推进的
• 之前结论是什么

它的作用

支持：

• 会话恢复
• 历史搜索
• 上下文接续

本质

Session history 是 过程状态层。

Skills：经验记忆

Skills 保存的不是“用户是谁”，而是“任务怎么做”。

例如：

• 如何配置 Hermes 本身
• 如何完成某类 GitHub 工作流
• 如何做 MCP 集成
• 如何处理某类故障

它的作用

让 Hermes 把过去一次次解决问题的方法沉淀下来，以后直接复用。

本质：

Skills 是 程序化经验层。

---

Memory / History / Skills 三者怎么分工

这是理解 Hermes 的重点。你可以把它们记成：

• Memory = 人和环境
• History = 过程和记录
• Skills = 方法和经验

这三者加起来，形成 Hermes 的长期能力基础。

---

Hermes 的工具架构：不是工具列表，而是工具运行时

Hermes 的工具系统有两个非常重要的架构特点。

第一，按 Toolsets 分组，不是平铺暴露。

Hermes 使用 toolsets，而不是默认把所有工具都给模型。

例如：

• terminal
• file
• browser
• web
• vision
• memory
• delegation
• cronjob
• messaging

为什么这样设计？因为这解决了三个问题：

• 权限控制（不同场景不应给相同能力）
• 上下文控制（工具 schema 太多会影响模型判断效率）
• 任务定制（研究任务、代码任务、自动化任务所需能力不同。）

所以 Hermes 的工具系统本质上是：

带权限边界和场景裁剪的执行能力总线

第二，声明式调用，命令式执行。

模型看到的是：

• 工具名字
• 参数结构
• 工具描述

但真正执行的是系统内部的具体 handler。

这意味着模型只负责“决定调用什么”， 系统负责“真正把事情做掉”。

这使 Hermes 具备非常清晰的职责分离：

• 模型负责决策
• 工具层负责执行
• Agent Loop 负责协调

---

Hermes 的平台架构：为什么能接 Telegram、Discord、Slack

Hermes 并不是为某一个 UI 设计的。 它的架构天然支持多平台接入。

它的设计方式是“智能内核 + 平台适配层”

智能内核负责：

• 推理
• 工具
• memory
• skills
• agent loop

平台适配层负责：

• 接消息
• 发消息
• 处理线程/频道/会话映射
• 适配平台权限和格式

这种架构的意义

这意味着 Hermes 的“脑子”不依赖具体平台。 CLI、Telegram、Discord、Slack 只是不同入口。

所以你可以把 Gateway 理解成：

把外部消息平台统一接入 Hermes 内核的适配层

这是一种非常标准且健壮的架构方式。

---

Hermes 的自动化架构：为什么它不只是聊天工具

Hermes 有两个很重要的自动化方向：

Cron——时间驱动

定时触发 Hermes 去做任务：

• 每天汇总新闻
• 定期扫描博客
• 定时生成报告
• 周期性运行脚本
• 定时检查外部状态

架构意义：

它把 Hermes 从“被动响应型”扩展成“主动调度型”。

Webhook——事件驱动

让外部系统通过事件触发 Hermes，例如：

• 某服务发来 webhook
• 某平台状态变化
• 某自动化系统需要 Hermes 处理输入

架构意义：

它把 Hermes 变成工作流中的一个可编排节点。

---

Hermes 的协作架构：子代理与多代理雏形

Hermes 不只支持单代理，还支持任务下发。

子代理（delegation）

主代理可以把任务拆出去交给独立上下文的子代理执行，再把结果汇总回来。

这样做的价值：

• 降低主会话上下文污染
• 并行化子任务
• 把复杂问题模块化

为什么这很重要？

这说明 Hermes 的设计方向不是“单线程聊天机器人”， 而是在向 多代理协作框架 靠拢。

虽然它不一定是完整的 MAS 平台，但已经具备明显的 orchestration 思想。

---

Hermes 的隔离架构：Profiles

Profiles 是 Hermes 很工程化的一点。

每个 profile 都可以拥有独立的：

• config
• memory
• sessions
• skills
• cron jobs
• 认证信息

这带来的架构价值

1. 多工作区隔离（工作 / 个人 / 实验环境互不干扰）
2. 多租户思路（相当于不同逻辑实例共享同一程序骨架）
3. 风险控制（不同 profile 可以配置不同模型、工具、策略）

所以 Profiles 让 Hermes 不只是“一个 Agent”， 而是“一个可运行多个 Agent 实例的框架”。

---

Hermes 的外部扩展架构：MCP 与插件思路

Hermes 并不试图内建世界上所有能力。 它提供外部扩展机制。

MCP 的意义

MCP 可以理解为：

把外部能力标准化接入 Hermes 的接口层

这样一来，Hermes 可以把外部系统的能力也暴露成工具。

架构好处

• 外部能力接入统一
• 工具生态可扩展
• 核心框架不必膨胀

Hermes 的目标不是“自己实现一切”， 而是做一个 可以持续吸纳外部能力的 Agent 宿主环境。

---

Hermes 的安全与治理逻辑

因为 Hermes 可以真正执行命令，所以它天然需要治理机制。

核心治理维度包括：

• 工具启用/禁用
• toolset 范围限制
• 命令审批
• secrets redaction
• PII redaction
• 平台隔离
• profile 隔离
• 新会话重载配置

Hermes 从一开始就不是“玩具型聊天产品”， 而是考虑了真实执行风险的 Agent 系统。

---

Hermes的四根支柱

如果把 Hermes 看成企业级 Agent 框架，核心就四根柱子：

1. Agent Loop——带反馈闭环的执行系统，不是聊天器
2. Tool Runtime——能真正干活，不只是能说
3. Long-term Context System——memory + history + skills，能持续成长
4. Runtime Infrastructure——gateway + cron + profiles + MCP，能长期运行、跨平台接入

---

Hermes和一般 Agent 框架比，特别在哪

如果你是从架构角度比较，我认为 Hermes 最鲜明的不是“有工具”，因为很多 Agent 都有工具。

Hermes 更特别的地方在这几个方面：

1. Skills 机制很强

把经验结构化沉淀为可复用知识。

2. Memory + Session + Skills 三层长期系统比较完整

不是只有短期上下文。

3. Gateway 很重

不是只为本地 CLI 设计，而是天然多平台。

4. Cron / 自动化能力更系统化

不是临时脚本，而是内建调度思路。

5. Profiles 让它适合长期、多实例运行

不是“一次性助手”。

---

最后

别把 Hermes 想成聊天机器人，也别只把它想成 AI 编程助手。

最准确的类比是：

Hermes 更像一个 Agent Operating Layer（代理操作层）

它位于：

• 上层：用户、平台、外部系统
• 中层：大模型推理
• 下层：本地系统、网络工具、外部服务

它做的事情是：

• 连接这些层
• 提供统一执行循环
• 维护长期状态
• 提供扩展机制
• 支持多入口运行

三句话收尾：

• Hermes 的核心不是聊天，是 Agent Loop + Tool Runtime。
• 长期价值不只来自模型，来自 Memory + Skills + Session History。
• 它不是单机助手，是支持多平台、自动化、隔离运行和扩展接入的 Agent 框架。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】