Hermes 模型系列 (Nous Research Hermes: SFT 型 Function-Calling 模型)

1. 定义

Hermes 是 Nous Research 在开源基座模型（Llama、Qwen 等）上做 SFT（有监督微调） 得到的开源模型系列，以强大的 function-calling（函数调用）/ 结构化输出 著称，是 Agent 场景里”特别会调用工具”的一类模型。

记忆钩子：基座模型是”毛坯”，SFT 是”装修”——Hermes 是把毛坯专门装修成”精装、且最懂怎么用工具”的房子。foundation_model.md 里说 “Hermes 是 SFT 的产物”，就是这个意思。

2. 核心概念 / 版本脉络

版本	基座	关键能力	说明
Hermes 2	Llama 2 等	通用指令遵循	OpenHermes 数据集训练的基础版
Hermes 2 Pro	Llama 3 (8B/70B)	Function Calling + JSON Mode	在清洗后的 OpenHermes 2.5 上，新增 FC 与结构化输出数据的 retrain 版
Hermes 3	Llama 3.1 (8B/70B/405B)	推理增强、Agent 能力、FC	主要用合成数据训练，推理与 agentic 能力显著提升

OpenHermes 数据集：由 Teknium 构建的大规模高质量指令数据集，是 Hermes 系列的”教材”，决定了它通用的指令遵循能力。
Function Calling：给定 JSON Schema 描述的函数，模型能稳定输出符合 schema 的调用请求（参数不跑偏）。
JSON Mode / 结构化输出：强制模型只输出合法 JSON，方便程序解析，是 Agent 工具调用、数据抽取的基础。
Hermes-Function-Calling 仓库：官方给出的 FC 运行时，用递归循环生成函数调用 → 通过 Python 脚本执行 → 把返回数据再喂回模型，支持标准 FC 与 JSON Mode。

3. 工作原理（在 Agent 里的位置）

Hermes 本身只是”会推理 + 会按 schema 输出工具调用”的模型，不自带执行环境：

用户意图
   │
   ▼
[系统/脚手架] ←── 工具定义 (JSON Schema) 注入 system prompt
   │
   ▼
Hermes 模型 ─── 输出 function_call (符合 schema 的参数)
   │
   ▼
[执行器] 调用真实函数 / API（Hermes-Function-Calling 用 Python 跑）
   │
   ▼
返回结果 ──► 拼回上下文 ──► Hermes 继续推理（递归循环，直到任务完成）

模型只负责”决定调哪个函数、填什么参数”；真正的执行、权限、渠道接入是 Agent 框架（harness）的事。见 agent_harness.md 与 openclaw.md。

4. 基本用法（接入方式）

Hermes 通过 OpenAI 兼容接口 暴露，因此任何支持 OpenAI API 的 Agent 框架都能直接把它当 backend（本地用 vLLM / Ollama / llama.cpp 起服务即可）。

# 以 OpenAI SDK 调用 Hermes 的 function calling 为例
from openai import OpenAI
 
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")  # 本地 Hermes 服务
 
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询某城市天气",
        "parameters": {  # JSON Schema：Hermes 据此填参
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]
 
resp = client.chat.completions.create(
    model="NousResearch/Hermes-3-Llama-3.1-8B",
    messages=[{"role": "user", "content": "北京今天天气如何？"}],
    tools=tools,          # 关键：把工具 schema 交给模型
    tool_choice="auto",
)
# resp.choices[0].message.tool_calls → 符合 schema 的结构化调用

5. 对比辨析表

维度	基座模型 (Base)	通用 Instruct 模型	Hermes
训练阶段	预训练	+ SFT/RLHF	+ SFT（OpenHermes 等）+ FC 专项数据
强项	续写/概率	聊天/指令	工具调用 / 结构化输出 / Agent
输出可控性	低	中	高（JSON Mode 强约束）
适合	继续预训练	对话产品	需要调用外部工具的 Agent

6. 典型工作流

要做一个”能查数据库 / 调 API / 跑脚本”的 Agent → 选擅长 FC 的模型。
本地用 vLLM/Ollama 部署 Hermes，得到 OpenAI 兼容端点。
把工具用 JSON Schema 描述好，注入 Agent 框架（如 openclaw.md 的 Tool 体系）。
跑 ReAct 式循环：模型出 tool_call → 框架执行 → 结果回灌 → 模型继续，直到完成。

7. 应用视角：把 Hermes 绑进 IM，当你的 7×24 监工 / 脚本执行器

记忆钩子：上面几节都在讲”Hermes 是什么模型”；这一节讲”别人实际怎么把它用起来”。你会觉得它很像 OpenClaw——原因见 7.4：OpenClaw 是把”框架 + 模型”打包好的整机，Hermes 只是被塞进去的那颗大脑。

7.1 为什么能绑进 IM：本质就是”换了个输入输出管道”

Hermes 对外只暴露 OpenAI 兼容的 /v1/chat/completions（本地用 vLLM/Ollama 起服务，或远程推理端点）。IM 渠道在这里只是个文本管道，不做智能：

IM (飞书 / Telegram / iMessage)
   │  收到用户消息
   ▼
[桥接层 Bot] ──HTTP──► Hermes (OpenAI 兼容端点)
   │                      │  ReAct 循环：出 function_call
   │                      ▼
   │                [执行器] 跑 shell / 脚本 / 调 API（Hermes 不自己跑）
   │                      │  结果回灌上下文
   │◄──── 回复文本 ────────┘
   ▼
回发到同一个 IM 会话

关键点（和 openclaw.md 一致）：IM 渠道负责收发，Hermes 负责”理解意图 → 决定调哪个工具 → 填参数”，执行器（harness）负责真跑。所以”绑在飞书里监工”= 用一层 harness 把 Hermes 包住再接 IM。

7.2 三种常见 IM 接入方式（桥接长啥样）

渠道	接入机制	备注
飞书 / Lark	自建应用 + 事件订阅（webhook 回调 / 长连接）	需 app_id/secret，群里 @机器人触发
Telegram	BotFather 建 bot 拿 token，Bot API 轮询或 webhook	最易上手，个人 bot 基本零审核
iMessage	无官方 bot API，靠 BlueBubbles 等桥接把 iMessage 转成 HTTP 事件	macOS 常驻，本质还是”转发管道”

落到代码里三种渠道都是同一件事：拿一条文本 → 调一次 Hermes → 把返回显示回去。渠道只是外壳。

7.3 两类典型玩法：监工 & 脚本执行器

监工（被动 / 定时触发）：配合 cron 类 Skill 或系统 crontab，周期性唤醒 Hermes。例如”每天 9 点抓竞品官网改了啥 / 盯某服务端口是否活着 / 看下载目录有没有新文件”，异常就推到你 IM 群。模型在这里做的是”判断是否报警 + 把结果说成人话”，真正抓取是工具干的。
脚本执行器（主动指令）：你在 IM 发一句自然语言，如”把 /tmp 里大于 100M 的日志打包发我”。Hermes 用 function calling 把这句话映射成一条 shell 命令或 Python 脚本（参数取自你的原话），执行器跑完把 stdout / 产物回传。这就是把 Hermes 当”自然语言 → 命令”的翻译层。

7.4 它为什么”像 OpenClaw”：别把大脑和机器人搞混

你直觉觉得 Hermes 像 OpenClaw，是因为两者的部署形态重合（都是”模型 + IM + 能跑命令”），但层级不同：

维度	Hermes	OpenClaw
是什么	模型引擎（SFT 出的 Instruct 模型）	Agent 框架 / harness（Gateway + 渠道 + 权限 + Skills）
能不能自己收发 IM	不能，只跑推理	能，自带多渠道 Gateway
能不能自己跑脚本	不能，只产出 tool_call	能，带执行器与权限沙箱
关系	被塞进框架当”大脑”	把模型（Hermes 或别的）当”大脑”用

准确说法：OpenClaw 是”装了 Hermes（或别的模型）的机器人”，Hermes 是那个机器人脑子里负责思考和调工具的部分。 你说的”绑在飞书/Telegram/iMessage 里监工”，其实是用 OpenClaw 这类 harness（或你自己写的几十行 bot）把 Hermes 包了一层再接 IM。

7.5 想自己搭个最小版？核心就三块

模型端点：本地 ollama run hermes3 或 vLLM 起 OpenAI 兼容服务。
执行器：一个能跑 shell/脚本的 ReAct 循环（可复用 openclaw.md 的 Tool 体系，也可自己写小 loop 调 client.chat.completions 并解析 tool_calls）。
IM 桥：飞书 webhook / Telegram token / iMessage 桥接，把消息两端对上。

轻量场景其实不用上 OpenClaw 全家桶：一个 Telegram bot + Hermes 端点 + 几个白名单命令就能当个人监工。OpenClaw 的价值在”多渠道聚合 + 权限沙箱 + Skills 生态”，要管很多渠道/工具时才显出来。

8. 常见误区

❌ “Hermes 是基座模型” → 错。它是 SFT 之后的 Instruct/工具型模型，底座是 Llama、Qwen 等。
❌ “function calling 是模型自己执行的” → 错。模型只产出”调谁+填什么参”的结构化请求，真正执行由 harness（如 OpenClaw）完成。
❌ “任意模型都能稳定 FC” → 不一定。FC 需要专项 SFT 数据训练，通用聊天模型容易参数跑偏、JSON 不合法；这正是 Hermes 的差异化价值。

9. 延伸阅读 / 关联概念

foundation_model.md：基座 → SFT → Instruct 的关系，Hermes 被点名作为 SFT 产物示例
tool_calling.md：function calling 的通用机制与 schema
openclaw.md：关系——OpenClaw 这类 Agent 框架通过 OpenAI 兼容接口接模型，Hermes 可作为其”会调用工具的发动机”之一
agent_harness.md：框架负责执行/权限/渠道，模型只负责决策
sft.md：（计划中文档）SFT 微调过程详解

第二大脑 / Knowledge Bank

探索

hermes