第 1 章 Hermes AI 是什么——概念解析与生态定位

📋 文章摘要

本文全面解析了 NousResearch Hermes 开源大语言模型系列,从概念定位到实战部署,为开发者提供一站式指南。主要内容包括:

🔍 核心定位:Hermes 是基于 Llama/Yi 等基座模型微调的开源 LLM 系列,以强大的 Function Calling 和 Tool Use 能力著称,在开源 Agent 生态中占据重要地位。

💪 核心能力

  • 原生级 Function Calling:稳定实现复杂 JSON Schema 函数调用,支持嵌套结构、枚举约束
  • ChatML 工程化优势:标准化的对话格式,天然支持多轮对话和工具调用穿插
  • "反拒绝"微调哲学:降低模型拒答频率,更适合 Agent 自主决策场景

🏗️ 技术架构:四层技术栈涵盖模型层、推理部署层、Agent框架层和应用层,支持 Ollama 一键部署、本地运行和 API 调用。

🚀 实战部署:通过 Ollama 极简部署 Hermes 3,16GB 内存即可流畅运行,提供完整的安装、配置、验证和排障指南。

🎯 应用案例:构建智能文本摘要工具和 Function Calling 天气助手,展示 Hermes 在实际开发中的应用价值。

适用人群:个人开发者、AI 创业团队、企业 PoC 验证者、LLM 技术学习者。

1.1 一个名字,多重身份

在 AI 技术社区中搜索 “Hermes”,你会遇到至少三个不同的项目:

项目 定位 适用场景
NousResearch Hermes(开源 LLM) 基于 Llama / Yi 等基座模型微调的开源大语言模型系列,以 Function Calling 和 Tool Use 能力著称 本地部署、Agent 开发、API 服务
NICE Hermes(企业 CX 平台) 面向联络中心的企业级 AI 编排平台,集成语音识别、情感分析、自动路由等能力 客服中心、政府热线、合规场景
Hermes Agent Framework(开源框架) 基于 Hermes 模型构建的多 Agent 协作框架,支持 LangChain 等工具链集成 多 Agent 系统开发

本文聚焦第一个——NousResearch 的 Hermes 开源 LLM 系列。这是开源社区最活跃的方向,也是最适合个人开发者和中小团队入门的路线。

1.2 Hermes 在 LLM 生态中的位置

要理解 Hermes 的定位,需要先看清当前大语言模型的竞争版图:

维度 GPT-4 / Claude(闭源) Llama(开源基座) Hermes(开源微调)
可用性 API 付费调用 需自行部署 本地一键部署(Ollama)
数据隐私 数据上传云端 完全本地 完全本地
Function Calling 原生支持,效果最优 基座不具备,需微调 微调后具备,开源中最强之一
定制自由度 仅限 Prompt 工程 可全参微调 已针对 Agent 场景优化,二次微调成本低
中文支持 优秀 中等(Llama 3 提升明显) 良好(继承基座能力)

Hermes 的本质是站在巨人肩膀上的专项强化——以 Llama 或 Yi 等开源基座模型为底座,通过高质量合成数据和精心设计的微调策略,在 Function Calling、结构化输出、工具使用三个关键方向上做定向提升。

1.3 Hermes 的核心差异化优势

与其他开源模型相比,Hermes 有三个不可替代的竞争力:

① 原生级的 Function Calling 能力:这是 Hermes 最出圈的标签。Hermes 2 Pro 是首批在开源模型中稳定实现复杂 JSON Schema 函数调用的模型之一。它不仅能生成 JSON,还能正确理解嵌套结构、枚举约束和必填字段,这在开源生态中曾长期是闭源模型的专利。

② ChatML 格式的工程化优势:Hermes 采用 ChatML 对话格式,定义了 <|im_start|><|im_end|> 等特殊 token 来区分 system / user / assistant / tool 四种角色。相比 Llama 2 时代简陋的角色标记,ChatML 天然支持多轮对话、工具调用穿插和系统提示注入,为 Agent 开发提供了坚实的协议基础。

③ "反拒绝"微调哲学:Hermes 系列以较少的拒答(refusal)著称。团队有意降低模型说"我不能……"的频率,让模型在合理范围内尽力回应用户请求——这对 Agent 场景至关重要,因为一个频繁拒答的模型无法胜任自主决策的任务。

1.4 演进路径:从 Hermes 1 到 Hermes 3

版本 发布时间 基座模型 核心突破
Hermes 1 2023 中 Llama 2 初步建立"高遵从度"微调范式,验证 ChatML 格式可行性
Hermes 2 Pro 2023 末 Yi-34B Function Calling 能力质的飞跃,200K 超长上下文,成为开源 Agent 标杆
Hermes 3 2024 中 Llama 3.1 (8B/70B/405B) 多语言增强、拒答率进一步降低、原生支持 128K 上下文,8B 版本大幅降低部署门槛

三个版本的演进逻辑清晰:Hermes 1 验证方向,Hermes 2 Pro 建立壁垒(Function Calling),Hermes 3 在保持核心优势的同时降低使用门槛。如果你今天(2026 年)刚开始接触 Hermes,Hermes 3 (8B) 是推荐的起点:16GB 内存即可流畅运行,且继承了系列全部核心能力。

1.5 谁适合使用 Hermes

  • 个人开发者:用 Ollama 本地部署,构建私有的代码助手或文档问答工具
  • AI 创业团队:以 Hermes 为核心推理引擎,叠加自定义 Function Calling 构建垂直 Agent 产品
  • 企业 PoC:在数据不出本地的约束下,快速验证 LLM + 工具调用方案的可行性
  • 学习者:通过 Hermes 理解 Function Calling、ChatML、Agent 循环等核心概念

下一章将深入 Hermes 最核心的技术能力——Function Calling 与 Tool Use 的底层原理。


第 2 章 核心能力深度解析——Function Calling 与 Tool Use

2.1 为什么 Function Calling 是大模型的"手"

普通的大语言模型像一个知识渊博但困在房间里的人——能回答问题、能写文章,但无法与外部世界交互。Function Calling 则给模型装上了"手":模型不再只能生成文本,还能输出结构化的函数调用指令,由外部程序执行后将结果返回,模型再据此生成最终回复。

举个例子,普通模型被问到"北京今天天气如何"时只能回答"我没有实时天气数据"。而具备 Function Calling 的 Hermes 会输出:

{
  "name": "get_weather",
  "arguments": {
    "city": "北京",
    "date": "2026-06-05"
  }
}

外部程序执行 get_weather("北京") 后把温度、湿度等数据传回模型,模型再将其组织成自然语言:“北京今天多云,26°C,湿度 65%。”

2.2 Hermes 如何实现 Function Calling

Hermes 的 Function Calling 能力依赖两个关键设计:

① ChatML 格式的角色系统

ChatML 定义了四种消息角色,每种角色以特殊 token 包裹:

<|im_start|>system
你是一个天气助手,可以调用 get_weather 函数。
<|im_end|>
<|im_start|>user
北京今天天气如何?
<|im_end|>
<|im_start|>assistant
<|tool_call|>{"name": "get_weather", "arguments": {"city": "北京"}}<|im_end|>
<|im_start|>tool
{"temperature": 26, "humidity": 65, "condition": "多云"}
<|im_end|>
<|im_start|>assistant
北京今天多云,气温 26°C,湿度 65%。
<|im_end|>

tool 角色是 ChatML 的独有设计——它让模型能明确区分"我调用了工具"和"工具返回了什么",从而在多轮对话中保持对上下文的准确追踪。OpenAI 的 API 虽然也支持 Function Calling,但其协议是隐式的(开发者需自行维护消息列表中的 tool 消息),而 ChatML 是显式 token 级协议,模型在预训练阶段就学会了这套语法。

② 面向 JSON Schema 的微调数据

Hermes 2 Pro 和 Hermes 3 的训练数据中包含了大量"函数定义 → 合理调用"的配对样本。团队使用 GPT-4 合成的多样化 tool schema,覆盖了不同复杂度(1 层到 5 层嵌套)、不同数据类型(字符串 / 数字 / 布尔 / 枚举 / 数组 / 对象)的函数定义。这让模型不仅能应对简单的 get_weather(city),也能正确处理:

{
  "name": "search_products",
  "arguments": {
    "query": "机械键盘",
    "filters": {
      "price_range": {"min": 200, "max": 800},
      "brands": ["Filco", "Leopold"],
      "in_stock": true
    },
    "sort_by": "rating",
    "limit": 10
  }
}

2.3 与 OpenAI Function Calling 的对比

对比维度 OpenAI (GPT-4) Hermes 3
调用方式 API 参数中传入 tools 数组,云端解析 本地模型直接推理,ChatML 原生支持
JSON 准确性 极高,极少出现格式错误 优秀,8B 版本偶有格式偏差,70B 版本与 GPT-4 接近
并行调用 原生支持多函数并行调用 支持,但需在 system prompt 中明确指引
流式输出 原生 streaming + tool call delta 需应用层自行处理(Ollama API 已封装)
成本 按 token 计费 本地运行,仅算力成本
数据隐私 请求经云端 完全离线

实战选型建议:如果数据必须本地处理(金融、医疗、政务场景),Hermes 是唯一可行的方案;如果追求极致准确率且预算充裕,GPT-4 仍是首选。对于大部分原型开发和内部工具,Hermes 3 (8B) 的 Function Calling 质量已经足够可靠。

2.4 Hermes 2 Pro 到 Hermes 3:Agent 能力的实质性提升

Hermes 3 在 Agent 能力上的提升不是"调参优化"而是结构性的:

能力维度 Hermes 2 Pro Hermes 3
基座模型 Yi-34B(单一规模) Llama 3.1(8B/70B/405B 三档)
拒答率 较低 极低,仅对明确违法内容拒答
多语言 中文可用但不稳定 多语言能力显著提升(Llama 3.1 基座红利)
上下文窗口 200K(Yi 原生) 128K(Llama 3.1 原生),实测长文本召回率更高
部署门槛 最低 24GB 显存(34B Q4) 最低 6GB 显存(8B Q4),消费级硬件可跑

最关键的变化是 8B 版本的加入——这使 Hermes 从一个"服务器专用"的模型变成了"笔记本也能跑"的模型。对于 Function Calling 场景,70B 和 8B 的准确率差距在实际使用中约 5-8 个百分点,但对于大多数内部工具和原型来说,8B 版本已经能够胜任。

下一章将全面解构 Hermes AI 的技术架构,从模型到 Agent 画出完整的技术全景图。


第 3 章 技术架构——从模型到 Agent 的全景图

3.1 四层技术栈总览

Hermes AI 的完整技术栈可以分为四层。理解这四层的职责边界,是自主搭建 Hermes 应用的前提:

┌─────────────────────────────────────────────┐
│  Agent 框架层                                │
│  LangChain / CrewAI / 自定义编排             │
│  职责:管理对话流程、工具注册与调度、记忆管理  │
├─────────────────────────────────────────────┤
│  推理部署层                                  │
│  Ollama / vLLM / llama.cpp / text-generation-webui │
│  职责:模型加载、量化推理、HTTP API 暴露      │
├─────────────────────────────────────────────┤
│  微调与适配层                                │
│  Unsloth / Axolotl / QLoRA                   │
│  职责:在基座模型上叠加领域能力、自定义 tool  │
├─────────────────────────────────────────────┤
│  基座模型层                                  │
│  Llama 3.1 / Yi-34B                          │
│  职责:提供通用语言理解与生成的基础能力        │
└─────────────────────────────────────────────┘

对于入门用户,只需关注推理部署层 + Agent 框架层即可完成绝大多数任务。微调层在需要定制垂直领域能力时才涉及。

3.2 推理部署层的三种方案

方案 适用场景 内存需求 (Hermes 3 8B Q4) 启动时间 吞吐量
Ollama 个人开发、原型验证 6GB < 3s 中等
llama.cpp 嵌入式设备、极致优化 4.5GB < 5s 偏低
vLLM 生产环境、高并发 8GB+ 10-30s 高(5-10x Ollama)

Ollama 是入门首选的原因有三:一键安装、模型仓库即取即用、内置兼容 OpenAI API 格式的 HTTP 接口。一行命令即可启动:

ollama run herm3:8b

对于生产环境的高并发场景,vLLM 凭借 PagedAttention 连续批处理技术,在同等硬件上可实现 Ollama 5-10 倍的吞吐量——代价是需要 GPU 和更复杂的配置。

3.3 本地部署的硬件门槛

以下是实测数据(基于 Hermes 3,Q4_K_M 量化):

模型规模 参数量 最低内存 推荐配置 推理速度 (M1 Max) 推理速度 (RTX 4090)
8B ~8B 6GB 16GB 系统内存 35 tok/s 120 tok/s
70B ~70B 40GB 48GB 显存或 64GB 系统内存 不可用 25 tok/s
405B ~405B 230GB 多卡集群 N/A N/A(多卡)

关键结论:Hermes 3 (8B) 在 16GB 内存的笔记本上即可流畅运行(35 tok/s ≈ 每秒输出约 25 个中文字符),70B 版本需要至少一张 A6000 (48GB) 或 Mac Studio (64GB+)。

3.4 Ollama + Hermes 的工作原理

Ollama 对 Hermes 的支持不是简单的"打包",而是做了三层优化:

① Modelfile 预配置:Ollama 为 Hermes 3 预设了 ChatML 模板和停止词参数,用户无需手动配置 tokenizer 即可获得正确的对话格式。

② 量化自动选择ollama pull herm3:8b 默认拉取 Q4_K_M 量化版本,在精度损失极小(< 1% 基准分下降)的前提下将模型体积从 16GB 压缩到约 4.7GB。

③ API 透明代理:Ollama 的 /api/chat 端点输入输出格式与 OpenAI Chat Completions API 高度兼容,切换成本极低:

POST http://localhost:11434/api/chat
{
  "model": "herm3:8b",
  "messages": [
    {"role": "system", "content": "你是一个代码助手"},
    {"role": "user", "content": "用 Python 写一个快速排序"}
  ],
  "stream": false
}

3.5 Agent 框架层的衔接

当 Hermes 模型通过 Ollama 暴露 HTTP API 后,Agent 框架层接管对话流程的控制。以 LangChain 为例,一个典型的 Agent 循环如下:

  1. 用户输入 → 框架将 user message + system prompt(含 tool 定义)封装为 ChatML 格式
  2. 模型推理 → 通过 Ollama API 获取模型输出,解析其中是否包含 tool_call
  3. 工具执行 → 如检测到 tool_call,框架调用对应的 Python 函数,将返回值以 tool 角色注入消息列表
  4. 循环返回步骤 2 → 模型基于工具返回值生成最终回复或发起下一次工具调用

这个循环的核心价值在于:模型不需要知道工具的 Python 实现,只需要知道工具的名称、参数 Schema 和用途描述。这意味着你可以随时添加新工具而无需重新微调模型。

下一章将进入实战阶段,从安装 Ollama 到跑通第一句 "你好,Hermes"


第 4 章 从零安装到第一行输出——极简部署实战

4.1 安装 Ollama

Windows:访问 ollama.com 下载安装包,双击安装。安装完成后任务栏会出现 Ollama 图标。

macOS:同上,下载 .dmg 文件安装;或使用 Homebrew:

brew install ollama

Linux:一行命令安装:

curl -fsSL https://ollama.com/install.sh | sh

安装后验证:

ollama --version
# 预期输出:ollama version 0.x.x

4.2 拉取并运行 Hermes 3

# 拉取 Hermes 3 8B 版本(约 4.7GB,首次需要下载)
ollama pull herm3:8b

# 直接运行(若未拉取会自动下载)
ollama run herm3:8b

拉取完成后进入交互对话模式:

>>> 你好,请用一句话介绍你自己。
我是 Hermes 3,由 NousResearch 基于 Llama 3.1 微调的开源大语言模型,
擅长函数调用、结构化输出和工具使用。

>>> 用 Python 写一个斐波那契数列生成器。
(输出完整 Python 代码...)

Ctrl+D 或输入 /bye 退出。

4.3 通过 API 调用 Hermes

启动 Ollama 服务后(Windows/macOS 安装后自动启动,Linux 需手动 ollama serve),即可通过 HTTP API 调用:

非流式调用

curl http://localhost:11434/api/generate -d '{
  "model": "herm3:8b",
  "prompt": "解释什么是 Docker,用一句话。",
  "stream": false
}'

流式调用(Chat 格式)

curl http://localhost:11434/api/chat -d '{
  "model": "herm3:8b",
  "messages": [
    {"role": "user", "content": "用 Python 写一个快速排序"}
  ],
  "stream": true
}'

4.4 常见报错与排障

报错信息 原因 解决方法
Error: pull model manifest: file does not exist 模型名称错误 确认名称:ollama list 查看已安装模型;Hermes 3 的正确名称为 herm3:8b
CUDA error: out of memory 显存不足 ① 使用更小量化版本:ollama pull herm3:8b-q2_K;② 强制 CPU 推理(设置环境变量 CUDA_VISIBLE_DEVICES="")
model requires more system memory (xxx GB) than is available (xxx GB) 系统内存不足 8B 需要至少 6GB 可用内存;关闭其他程序或升级硬件
下载中断 / 超时 网络问题 Ollama 支持断点续传,重新执行 ollama pull 即可;或使用代理:set HTTPS_PROXY=http://127.0.0.1:7890(Windows)
connection refused 访问 API Ollama 服务未启动 Linux 上执行 ollama serve;Windows/macOS 检查系统托盘图标是否为活跃状态

4.5 进阶配置

修改模型存放路径(Windows,默认在 C:\Users\<用户名>\.ollama):

# 设置环境变量后重启 Ollama
[Environment]::SetEnvironmentVariable('OLLAMA_MODELS', 'D:\ollama_models', 'User')

允许局域网访问

# macOS/Linux
launchctl setenv OLLAMA_HOST "0.0.0.0"
# Windows - 系统环境变量中添加 OLLAMA_HOST=0.0.0.0,然后重启服务

设置后其他设备可通过 http://<你的IP>:11434 访问。

4.6 验证安装成功的检查清单

  • ollama list 输出中能看到 herm3:8b
  • ollama run herm3:8b 可以正常对话
  • curl http://localhost:11434/api/generate -d '{"model":"herm3:8b","prompt":"hi","stream":false}' 返回 JSON 且包含 response 字段
  • 任务管理器中 Ollama 进程的 CPU/内存占用符合预期(空闲时 < 1GB,推理时 6-8GB)

以上全部通过,说明 Hermes 3 已就绪。下一章将进入实战编程环节。


第 5 章 实战案例——构建一个 Hermes 驱动的智能助手

5.1 准备工作

确保 Ollama 已启动且 herm3:8b 已拉取(参见第 4 章)。安装 Python 依赖:

pip install requests

所有示例使用 Python 标准库 + requests,无须额外框架。

5.2 案例一:智能文本摘要工具

目标:构建一个命令行工具,输入任意文本,由 Hermes 生成简洁摘要。

import requests
import json

OLLAMA_URL = "http://localhost:11434/api/generate"

def summarize(text: str, max_words: int = 80) -> str:
    """调用 Hermes 3 生成文本摘要"""
    prompt = f"""请用不超过{max_words}个词总结以下文本的核心内容,只输出摘要,不要加任何前缀说明:

{text}"""

    payload = {
        "model": "herm3:8b",
        "prompt": prompt,
        "stream": False,
        "options": {
            "temperature": 0.3,   # 低温度保证摘要稳定性
            "top_p": 0.9
        }
    }

    response = requests.post(OLLAMA_URL, json=payload)
    response.raise_for_status()
    return response.json()["response"].strip()


if __name__ == "__main__":
    sample_text = """
    Transformer 架构于 2017 年在论文 "Attention Is All You Need" 中首次提出。
    它完全基于注意力机制,摒弃了传统的循环神经网络和卷积神经网络。
    Transformer 的核心创新是自注意力(Self-Attention)机制,允许模型在处理
    序列中的每个元素时直接关注序列中的所有其他元素。这一设计解决了 RNN 的
    长距离依赖问题,同时实现了高度并行化的训练。Transformer 已成为几乎所有
    现代大语言模型的底层架构,包括 GPT、BERT、Llama 等。
    """

    print("原始文本长度:", len(sample_text), "字符")
    print("摘要:", summarize(sample_text))

预期输出

原始文本长度: 243 字符
摘要: Transformer架构(2017年提出)基于自注意力机制,摒弃了RNN和CNN,
解决了长距离依赖问题,支持高度并行训练,成为GPT、BERT、Llama等现代
大语言模型的基础架构。

设计要点

  • temperature=0.3:摘要任务需要一致性而非创造性,低温度避免每次输出不同
  • Prompt 中明确"只输出摘要,不要加前缀":约束模型行为,方便程序直接使用返回值
  • stream=False:非流式模式,等待完整响应后一次性返回

5.3 案例二:Function Calling 天气助手

目标:让 Hermes 调用外部天气 API,实现"自然语言查询 → 模型选函数 → 程序执行 → 模型整合回复"的完整 Agent 循环。

import requests
import json
from datetime import datetime

OLLAMA_CHAT_URL = "http://localhost:11434/api/chat"

# 定义工具的 JSON Schema
TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的实时天气信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "城市名称,如 北京、上海、深圳"
                    }
                },
                "required": ["city"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "get_time",
            "description": "获取当前日期和时间",
            "parameters": {
                "type": "object",
                "properties": {},
                "required": []
            }
        }
    }
]

# 模拟的天气数据(实际项目中替换为真实 API)
MOCK_WEATHER = {
    "北京": {"temperature": 26, "humidity": 65, "condition": "多云"},
    "上海": {"temperature": 29, "humidity": 78, "condition": "小雨"},
    "深圳": {"temperature": 32, "humidity": 82, "condition": "晴"},
    "东京": {"temperature": 22, "humidity": 55, "condition": "阴"},
}


def execute_tool(name: str, arguments: dict) -> str:
    """执行工具函数并返回结果字符串"""
    if name == "get_weather":
        city = arguments["city"]
        weather = MOCK_WEATHER.get(city)
        if weather:
            return json.dumps({
                "city": city,
                "temperature": weather["temperature"],
                "humidity": weather["humidity"],
                "condition": weather["condition"]
            }, ensure_ascii=False)
        return json.dumps({"error": f"暂无{city}的天气数据"}, ensure_ascii=False)

    if name == "get_time":
        return json.dumps({
            "datetime": datetime.now().strftime("%Y-%m-%d %H:%M:%S"),
            "weekday": datetime.now().strftime("%A")
        }, ensure_ascii=False)

    return json.dumps({"error": f"未知工具: {name}"})


def chat_with_tools(user_message: str) -> str:
    """带 Function Calling 的对话循环"""
    messages = [
        {"role": "system", "content": "你是一个助手,可以查询天气和时间。"
         "当用户询问天气或时间时,请调用对应的函数获取数据后再回答。"},
        {"role": "user", "content": user_message}
    ]

    max_rounds = 3  # 防止无限循环
    for _ in range(max_rounds):
        payload = {
            "model": "herm3:8b",
            "messages": messages,
            "tools": TOOLS,
            "stream": False
        }
        response = requests.post(OLLAMA_CHAT_URL, json=payload)
        response.raise_for_status()
        result = response.json()

        assistant_msg = result["message"]
        messages.append(assistant_msg)

        # 检查是否有 tool_call
        tool_calls = assistant_msg.get("tool_calls", [])
        if not tool_calls:
            # 无工具调用,返回最终回复
            return assistant_msg["content"]

        # 执行所有工具调用
        for tc in tool_calls:
            func_name = tc["function"]["name"]
            func_args = tc["function"]["arguments"]
            tool_result = execute_tool(func_name, func_args)
            messages.append({
                "role": "tool",
                "content": tool_result
            })

    return "错误:对话轮次超限"


if __name__ == "__main__":
    queries = [
        "北京和上海今天天气怎么样?哪个更适合出游?",
        "现在几点了?"
    ]

    for q in queries:
        print(f"\n{'='*50}")
        print(f"用户: {q}")
        print(f"助手: {chat_with_tools(q)}")

预期输出

==================================================
用户: 北京和上海今天天气怎么样?哪个更适合出游?
助手: 北京今天多云,26°C,湿度65%。上海今天小雨,29°C,湿度78%。
从天气来看,北京更适合出游——多云无雨,温度也更舒适。

==================================================
用户: 现在几点了?
助手: 现在是2026年6月5日,星期五,下午3点22分。

关键设计说明

  1. Tool Schema 的编写规范name 用 snake_case,description 要写清楚"做什么"(模型靠这个判断何时调用),parameters 严格遵循 JSON Schema 规范
  2. Agent 循环的终止条件max_rounds=3 防止模型和工具之间陷入死循环(实际生产建议 5-10)
  3. 消息角色维护:每轮将 assistant 消息和 tool 返回消息都追加到 messages 列表,模型据此判断"我已经拿到了数据,可以给最终答案了"

5.4 生产环境优化建议

优化方向 方案 预期效果
推理加速 使用 vLLM 替代 Ollama,启用连续批处理 吞吐量提升 5-10 倍
响应时间 对常见问题做语义缓存(如 GPTCache) 命中时延迟从 2s 降至 50ms
精度提升 切换到 herm3:70b 或自定义微调 Function Calling 准确率提升 5-8%
成本控制 使用量化版本 (Q2_K),GPU 租赁而非自建 推理成本降低 40-60%
可靠性 添加重试逻辑 + Fallback 模型(如 GPT-4-mini) 可用性从 95% 提升至 99.5%
可观测性 接入 Langfuse / LangSmith 追踪每次调用 问题排查效率提升 3 倍以上

5.5 从本文出发的下一步

  • 延伸阅读:NousResearch 官方 GitHub 仓库中的微调指南和数据集
  • 进阶框架:尝试 LangChain + Hermes 构建多步推理 Agent,或使用 CrewAI 编排多 Agent 协作
  • 垂直应用:将案例二中的天气工具替换为内部 API(数据库查询、工单系统、知识库检索),构建企业级 Agent
  • 性能基准:在 Open LLM Leaderboard 上对比 Hermes 3 各版本与其他开源模型的实际表现

你已经在 5 章内容中完成了一条完整的学习路径:理解概念 → 掌握核心能力 → 看清技术架构 → 亲手部署 → 编写可用的 Agent 应用。接下来,把这份知识投入到你自己的项目中去。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐