Hermes Agent 支持三种本地推理后端——Ollama 一键启动、LM Studio 可视化管理、vLLM 生产级吞吐。不需要任何云端 API，一台带 GPU 的机器就能跑完整的 Agent 体验。

但本地模型有一条铁律：Hermes 强制要求 64,000 tokens 最低上下文窗口，而 Ollama 默认只给 2,048 tokens。不做配置就启动，直接报错退出。

这篇指南覆盖三种后端的完整接入流程、模型选型矩阵、社区高频痛点的调优方案，以及我在 Mac mini 上实际运行的 GLM→DeepSeek→Gemini 三模型策略。

本文是 Hermes Agent 系列的本地模型专题。框架全景请回看 Hermes Agent 完全指南，成本相关细节参考 成本控制指南。

本地模型接入的三条路

Hermes 的模型接入走 OpenAI 兼容 API 协议——任何暴露 /v1/chat/completions 端点的推理后端都能直接接入。三种主流后端各有定位：

三者接入 Hermes 的配置方式完全一致：在 ~/.hermes/config.yaml 中指定 provider: custom + 本地端点 URL。区别只在推理后端本身的安装和模型管理方式。

💡 通俗讲：Ollama 像 Docker Hub 一样拉模型就能跑，LM Studio 像应用商店一样点选下载，vLLM 像 Nginx 一样面向生产流量。不管选哪个，Hermes 看到的都是同一套 API 接口。

Ollama 接入：从安装到跑通 Agent

Ollama 是最轻量的选择——一行命令安装，一行命令拉模型，一行命令启动。

硬件需求

纯 CPU 推理可行但慢——9B 模型在 8 核现代 CPU 上约 10 tokens/sec，31B 模型约 2-5 tokens/sec，每次响应需要 30-120 秒。

安装与验证

# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh

# 验证安装
ollama --version

# 确认服务正常运行
curl http://localhost:11434/api/tags

macOS 用户直接从 ollama.com 下载桌面应用，安装后自动启动后台服务。Windows 用户下载安装包，安装后 Ollama 作为系统服务在后台运行。

拉取模型

这是关键一步——不是所有模型都能完整使用 Hermes。Hermes 是 Agentic 助手，通过工具调用（Tool Calling）来编辑文件、运行终端命令、浏览网页。不支持工具调用的模型只能聊天，无法执行操作。

# 推荐拉取——完整 Agent 体验
ollama pull gemma4:31b

# 轻量替代（仅聊天）
ollama pull gemma2:9b

💡 通俗讲：工具调用就像给 Agent 一双手。没有工具调用的模型，Agent 只能动嘴不能动手——能回答你的问题，但不能帮你执行任何操作。

配置 64K 上下文（必做）

Hermes 强制要求 64,000 tokens 最低上下文窗口，而 Ollama 默认只给 2,048 tokens。不扩展上下文，Hermes 启动时直接拒绝。

提示词：生成 Ollama 64K 上下文 Modelfile 和创建命令

请帮我生成一个 Ollama Modelfile 和对应的模型创建命令。要求：

• 基础模型为 gemma4:31b（FROM 指令）
• 上下文窗口设为 64000（num_ctx 参数）
• GPU 层卸载设为 99（num_gpu 参数，尽可能多的层卸载到 GPU）
• Modelfile 写入 /tmp/Modelfile
• 用 ollama create 命令基于该 Modelfile 创建名为 gemma4-64k 的新模型

这段配置做了两件事：一是把上下文窗口从 Ollama 默认的 2,048 扩展到 Hermes 要求的 64,000；二是通过 num_gpu 99 让 Ollama 尽可能多地把模型层卸载到 GPU——有多少 VRAM 就用多少，剩余部分回落到 CPU。

为什么是 64K？ Hermes 的 Agent 管线需要在上下文窗口中同时容纳系统提示词（约 2K token）、工具 Schema 定义（2K-19K token，取决于配置）、对话历史（持续增长）和模型输出。2K 的默认上下文连系统提示词都放不下。64K 是 Hermes 团队测试后确定的安全下限——能容纳一次完整的 Agent 工具调用循环（提示词 + 多轮工具调用 + 结果解析 + 最终输出）。

Ollama 的 /api/show 陷阱——Ollama 的模型信息接口报告的是模型的"最大支持上下文"，不是你实际配置的 num_ctx。如果你通过 --num_ctx 64000 启动，但没有写进 Modelfile，Hermes 查询 /api/show 可能看到更大的数字，但实际推理时只有默认的 2048。务必通过 Modelfile 持久化上下文配置。

配置 Hermes 连接 Ollama

两种方式，效果一样。

方式一：交互式向导

hermes model
# 选择：Custom endpoint (enter URL manually)
# API base URL: http://localhost:11434/v1
# API key: ollama（或留空）
# Model name: gemma4-64k
# Context length: 64000

方式二：直接编辑配置文件

提示词：生成 Hermes 连接 Ollama 的配置

请帮我生成 ~/.hermes/config.yaml 中连接 Ollama 的模型配置。要求：

• 默认模型名为 gemma4-64k（前面创建的扩展上下文版本）
• Provider 设为 custom
• API 地址为 http://localhost:11434/v1（Ollama 默认端口）

这段配置告诉 Hermes 通过 OpenAI 兼容协议连接本地 Ollama 服务。provider: custom 表示使用自定义端点而非内置 Provider。

验证连接

hermes chat
# 输入任意问题测试推理
# 尝试 /tools 看工具是否加载
# 用 "帮我创建一个 test.txt 文件" 测试工具调用

如果看到 "Connection refused"，说明 Ollama 服务未启动：

# Linux
sudo systemctl start ollama

# macOS
# 打开 Ollama 桌面应用，或：
ollama serve

LM Studio 接入：可视化管理本地模型

LM Studio 是桌面应用，用 GUI 管理本地模型——下载、加载、切换都在图形界面完成。对不想折腾命令行的用户，这是更友好的选择。

安装与启动

1. 从 lmstudio.ai 下载对应平台的安装包（macOS / Windows / Linux）
2. 安装后启动应用
3. 在模型搜索栏搜索并下载模型（推荐 Gemma 4 或 Qwen 3.6）
4. 启动本地服务器：

# 命令行启动（也可以在 GUI 中启动）
lms server start --port 1234

LM Studio 默认端口 1234，与 Ollama 的 11434 不同。

配置 Hermes 连接 LM Studio

hermes model
# 选择 "LM Studio"
# 使用默认端口 http://localhost:1234/v1
# 从发现的模型中选择一个
# 如果 LM Studio 开启了服务器认证，输入 LM_API_KEY

或直接编辑 config.yaml：

提示词：生成 Hermes 连接 LM Studio 的配置

请帮我生成 ~/.hermes/config.yaml 中连接 LM Studio 的模型配置。要求：

• 默认模型名填 LM Studio 中实际加载的模型名（例如 gemma4-it）
• Provider 设为 lmstudio
• API 地址为 http://localhost:1234/v1（LM Studio 默认端口）

与 Ollama 配置的区别仅在于端口（1234 vs 11434）和 Provider 标识（lmstudio vs custom）。模型名要和 LM Studio 中实际加载的名称一致。

LM Studio 的独特优势

JIT 加载（Just-In-Time Loading）——LM Studio 在收到推理请求时才加载模型到内存，空闲时自动卸载。这对内存有限的机器特别实用，不需要模型常驻内存。

LM Link 远程连接——高性能主机跑模型，笔记本跑 Hermes。如果你有一台 GPU 工作站和一台出差用的 MacBook，LM Link 让你在咖啡厅也能用远程 GPU 推理。

模型测试便利性——LM Studio 的 GUI 让你在接入 Hermes 之前先测试模型的推理质量和响应速度，确认效果后再正式配置。可以在 LM Studio 中同时加载多个模型对比输出质量，选好了再接入 Hermes。

上下文长度配置——LM Studio 在模型设置面板中可以直接调整 Context Length 参数，不需要像 Ollama 那样创建 Modelfile。拖动滑块到 64000 即可满足 Hermes 的最低要求。但要注意内存：64K 上下文的 KV 缓存会额外占用数 GB 内存，确保你的机器有足够余量。

LM Studio 工具调用支持

LM Studio 0.3.6 及以上版本支持工具调用。具有原生 Tool Calling 训练的模型（Qwen 2.5+、Llama 3.x、Mistral、Hermes 系列）会被自动检测并显示工具徽章。其他模型使用通用回退方案，可靠性较低。

💡 通俗讲：LM Studio 和 Ollama 的关系，就像图形文件管理器和命令行的关系——功能差不多，操作方式不同。选哪个看你是喜欢点鼠标还是敲键盘。

社区反馈：LM Studio + Hermes 的常见问题

上下文长度不够——和 Ollama 一样，需要确保模型的上下文窗口 ≥ 64K。LM Studio 中可以在模型设置里调整 Context Length 参数。

Hermes 比 LM Studio 直接聊天慢——这不是 LM Studio 的问题，是 Hermes Agent 管线的开销。Hermes 需要注入系统提示词、工具 Schema、记忆上下文等额外 token，比 LM Studio 裸模型对话多消耗大量 token。后面性能调优部分会给出解决方案。

vLLM 接入：生产级推理吞吐

vLLM 面向生产部署——PagedAttention 内存管理、多 GPU 张量并行、连续批处理。如果你要在 GPU 集群上为多个 Hermes Agent 实例提供推理服务，vLLM 是正确选择。

安装与启动

vLLM 需要 NVIDIA GPU（CUDA 支持）和 Python 3.9+。安装前确保已正确安装 CUDA toolkit 和 PyTorch。

# 安装 vLLM
pip install vllm

# 启动 OpenAI 兼容 API 服务器
python -m vllm.api_server \
  --model NousResearch/Hermes-3-Llama-3.1-8B \
  --port 8000 \
  --max-model-len 65536

--max-model-len 65536 确保满足 Hermes 的 64K 上下文最低要求。如果 GPU 内存不够容纳这么大的上下文，vLLM 会在启动时报错并建议减小该值或启用量化。

配置 Hermes 连接 vLLM

# ~/.hermes/config.yaml
model:
  default: "NousResearch/Hermes-3-Llama-3.1-8B"
  provider: "custom"
  base_url: "http://localhost:8000/v1"

vLLM 的核心优势

PagedAttention——将 KV 缓存分割为固定大小的块，像操作系统管理虚拟内存一样动态分配。这意味着多个并发请求可以高效共享 GPU 内存，不会因为一个长对话占满 VRAM 而阻塞其他请求。

内置 Hermes 工具调用解析器——vLLM 内置 hermes_tool_parser 模块，专门为 NousResearch 的 Hermes Pro 模型系列提供工具调用解析支持。这不是通用的 OpenAI 格式兼容，而是针对 Hermes 模型的专属优化。

企业级部署案例——AMD Developer Cloud 和 NVIDIA DGX Spark 都有官方的 Hermes + vLLM 部署指南。AMD 用 Qwen3.5 在开发者云上免费跑 Hermes，NVIDIA 在 128 GB 内存的 DGX Spark 上用 Ollama 服务 qwen3.6:27b。

Docker 部署时的网络问题

社区高频踩坑：Hermes Docker 容器连接独立的 vLLM 服务器时，其他客户端正常但 Hermes 连不上。根因通常是 Docker 网络隔离。

解决方案：

提示词：生成 vLLM + Hermes 的 Docker Compose 配置

请帮我生成一个 Docker Compose 文件，同时运行 vLLM 推理服务器和 Hermes Agent。要求：

• vLLM 服务使用 vllm/vllm-openai:latest 镜像，暴露 8000 端口
• Hermes 服务使用 nousresearch/hermes-agent:latest 镜像，启动命令为 gateway run
• 两个服务加入同一个 bridge 网络（命名为 hermes-net），解决容器间网络隔离问题
• Hermes 服务配置 extra_hosts 映射 host.docker.internal 到 host-gateway
• Hermes 服务设置环境变量 HERMES_STREAM_TIMEOUT=1800（30 分钟流式超时，防止本地推理慢导致断连）

这段配置解决的核心问题是 Docker 网络隔离——社区高频踩坑：Hermes 容器和 vLLM 容器各自启动后，其他客户端能正常访问 vLLM，但 Hermes 连不上。根因是两个容器不在同一个 Docker 网络。通过共享 bridge 网络和 extra_hosts 映射，Hermes 容器可以正确解析并访问 vLLM 端点。另一个简单替代方案是直接用 --network host 模式跳过网络隔离。

更多 Docker 部署细节参考 Docker 部署指南。

模型选型矩阵：按硬件、任务和语言推荐

选错模型是本地部署最常见的失败原因。不是越大越好，也不是越新越好——关键是模型大小和你的硬件匹配，且支持工具调用。

按硬件选模型

按任务选模型

工具调用可靠性排名

这是 Hermes 社区最关注的维度——传统基准（MMLU、GSM8K）衡量的是模型"深度思考"的能力，但 Hermes 需要的是模型"调用正确的工具、读取结果、继续推进"的能力。两种能力高度相关但不完全等价。

社区 2026 年 5 月基准测试（19 个模型、25 个真实 Agent 任务）的关键结论：

1. 工具调用可靠性是核心分水岭——小模型（3B/7B）经常忽略工具调用指令或生成格式错误的调用
2. Hermes 内置 auto-repair——自动修复格式错误的工具调用，但修复成功率随模型变小而下降
3. 确定性调用顺序和失败恢复能力是评估本地模型的两个关键维度
4. 云端模型在推理密集任务上仍有绝对优势——Claude Sonnet 4.6 在工具调用可靠性上排第一，DeepSeek V4 Pro 是性价比之王

如果你想在自己的硬件上运行基准测试，社区开源了 hermes-bench——一个自托管的基准评估工具，提供可视化界面展示本地模型在 Agent 任务上的表现。Lambda 实验室也发布了 PinchBench，专门测量模型在 Agent 框架下的工具调用效率。

💡 通俗讲：挑本地模型，不是看谁在考试里分最高，而是看谁在实际工作中最靠谱——该打电话（调用工具）的时候不犹豫，接到回复（读取结果）后能继续推进。

性能调优：社区高频痛点解决方案

痛点一：响应太慢

症状：Mac Studio M1 Max 64 GB 内存，响应超过 20 分钟。

诊断步骤：

# 检查模型加载状态和 GPU 层卸载
ollama ps

# 输出示例：
# NAME            ID      SIZE    PROCESSOR
# gemma4-64k:latest  abc123  20 GB   40/80 GPU layers

根因与解决方案：

1. 模型太大导致内存交换——模型参数超过可用内存（含 VRAM），操作系统把部分数据交换到磁盘，推理速度从几十 tok/s 断崖式降到不足 1 tok/s。解法：换更小的模型，或增加内存。

2. 上下文窗口设太大——64K 已经是 Hermes 最低要求，再往上设（如 128K）会显著增加 KV 缓存的内存占用。不是越大越好。

3. GPU 层卸载不足——ollama ps 显示 GPU 层为 0 表示纯 CPU 推理。有 GPU 时确保 Ollama 正确检测到显卡：

# 检查 NVIDIA GPU
nvidia-smi

# Ollama 有 GPU 时自动卸载，12 GB GPU 跑 31B 模型约 40 层在 GPU、其余在 CPU

4. Apple Silicon 用户——确认使用 Metal 加速。Ollama 和 LM Studio 都原生支持 Apple Silicon Metal GPU 加速，但需要确保安装的是 ARM 原生版本而非 Rosetta 模拟。

痛点二：Hermes 比裸模型聊天慢

症状：同样的模型，LM Studio 直接聊天秒回，接入 Hermes 后要等很久。

根因：Hermes Agent 管线在每次请求中注入大量额外 token——系统提示词、工具 Schema 定义、记忆上下文、对话历史压缩。72 个工具的 Schema 定义就占约 19,210 tokens。

解决方案：工具延迟加载（tool_search）

提示词：生成 Hermes 工具延迟加载配置

请帮我生成 ~/.hermes/config.yaml 中的 tool_search 配置。要求：

• 模式设为 auto（自动按需加载工具）
• 匹配阈值 threshold 设为 0.1
• 常驻工具列表 pinned_tools 包含 7 个最常用工具：terminal、read_file、write_file、list_directory、send_message、memory、skills
• 非常驻工具在 3 轮对话后自动卸载（evict_after_turns: 3）

这段配置的核心思路是"按需加载"——不再一次性注入全部 72 个工具的 Schema 定义，而是只常驻 7 个最常用工具，其他工具在用户意图匹配时动态加载、3 轮不用后自动卸载。开启后，工具 token 消耗从 19,210 降到约 2,200，减少 89%，本地模型的响应速度会有质的提升。

其他减速方法：

• 用 /compress 命令定期压缩长对话
• 辅助模型（vision/compression）切到更轻量的选择
• 减少 pinned_tools 中不常用的工具

痛点三：模型不遵循工具调用指令

症状：发出"帮我创建一个文件"的指令，模型输出了一段代码文本而不是调用 write_file 工具。

根因：小模型（3B/7B）的指令遵循能力有限，经常忽略工具调用 Schema 或生成格式错误的 JSON。

解决方案：

1. 换更大的模型——gemma4:31b 是目前本地工具调用最可靠的模型
2. 依赖 Hermes auto-repair——Hermes 自动检测并修复格式错误的工具调用，但修复成功率随模型变小而下降
3. 设置 Fallback 到云端——本地模型处理不了时自动切换到云端模型

# ~/.hermes/config.yaml
fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4
  - provider: deepseek
    model: deepseek-v4-pro

痛点四：辅助模型限流导致压缩风暴

症状：主模型用 GLM Coding Plan，对话长了触发自动压缩。压缩任务默认跟主模型走，GLM 429 限流时压缩也挂了，Agent 丢失整个对话上下文。

根因：辅助任务（vision、compression）默认使用 auto 模式跟随主模型。主模型限流时，辅助任务连带失败。

解决方案：辅助模型显式配置独立 Provider

提示词：生成 Hermes 辅助模型独立 Provider 配置

请帮我生成 ~/.hermes/config.yaml 中的辅助模型配置，解决主模型限流导致辅助任务连带失败的问题。要求：

• 主模型为 glm-5.1，Provider 为 zai
• 视觉理解（vision）使用独立 Provider：google，模型为 gemini-2.5-flash
• 对话压缩（compression）使用独立 Provider：deepseek，模型为 deepseek-v4-pro
• vision 和 compression 必须各自配置独立 Provider，不能设为 auto 跟随主模型

这段配置的关键是让辅助任务和主模型在 Provider 层面完全解耦。默认的 auto 模式下，vision 和 compression 跟随主模型——主模型 429 限流时辅助任务连带失败，Agent 丢失整个对话上下文。显式配置独立 Provider 后，即使 GLM 限流，视觉理解照常通过 Gemini 运行，压缩照常通过 DeepSeek 运行。这是社区踩坑最多的问题，一旦配置正确就不再出现。

痛点五：CPU-only 推理超时

症状：没有 GPU 的机器上，Hermes 等半天然后超时断开。

根因：CPU-only 推理 31B 模型约 2-5 tok/s，每次响应需要 30-120 秒。Hermes 默认流式超时 120 秒不够用。

解决方案：

# ~/.hermes/.env
HERMES_API_TIMEOUT=1800    # 30 分钟全局超时
HERMES_STREAM_TIMEOUT=1800 # 30 分钟流式超时

Hermes 会自动检测本地端点并放宽超时（读超时从 120 秒提升到 1800 秒，过期流检测禁用），但如果在超大上下文上仍然超时，需要手动设置这两个环境变量。设置后 Hermes 在推理过程中即使长时间没有返回 token 也不会断开连接。

痛点六：模型常驻内存

症状：Ollama 空闲 5 分钟自动卸载模型，下次请求时重新加载要等 30-60 秒。

解决方案：

单次设置可以通过 Ollama API 把指定模型的 keep_alive 设为 24h：

curl http://localhost:11434/api/generate \
  -d '{"model": "gemma4-64k", "keep_alive": "24h"}'

如果需要全局持久化（每次重启 Ollama 都生效），则需要配置 systemd override：

提示词：生成 Ollama 模型常驻内存的 systemd override 配置

请帮我生成 Ollama 的 systemd override 配置，让模型常驻内存不自动卸载。要求：

• 创建 override 文件路径：/etc/systemd/system/ollama.service.d/override.conf
• 设置环境变量 OLLAMA_KEEP_ALIVE=24h（模型保持加载 24 小时）
• 设置环境变量 OLLAMA_NUM_PARALLEL=2（支持 2 个并行请求）
• 配置完成后执行 systemctl daemon-reload 和 systemctl restart ollama 使其生效

Gateway 场景（Telegram/Discord bot 24 小时在线）必须设置常驻，否则 Ollama 空闲 5 分钟自动卸载模型，下次请求要重新加载 30-60 秒。

Nous Portal：统一订阅网关

Nous Portal 是 Nous Research 的统一订阅服务，一次 OAuth 登录即可访问 300+ 前沿模型（Claude、GPT、Gemini、DeepSeek、Qwen、Kimi、GLM、MiniMax、Grok 等），同一订阅还覆盖 Tool Gateway（网页搜索、图像生成、TTS、浏览器自动化）。

设置只需一条命令：

# 新安装——OAuth + Provider + Gateway 一步完成
hermes setup --portal

# 已有安装——从列表中切换到 Nous Portal
hermes model

# 检查登录状态和路由
hermes portal info

Portal 对本地模型用户的价值：它不替代本地模型，而是作为云端 Fallback 的便捷入口。日常任务用本地模型（零成本），复杂任务通过 fallback_providers 自动切换到 Portal 上的云端模型。

提示词：生成本地模型 + Nous Portal 云端备用的混合配置

请帮我生成 ~/.hermes/config.yaml 中的混合模型配置，本地模型做主力、Portal 做云端备用。要求：

• 主力模型为 gemma4-64k，Provider 为 custom，API 地址为 http://localhost:11434/v1
• 在 fallback_providers 中配置 Nous Portal 作为备用：Provider 为 nous，模型为 anthropic/claude-sonnet-4
• 当本地模型返回错误或超时时，自动切换到 Portal 云端模型

这段配置实现"日常免费、复杂付费"的策略——90% 的日常任务走本地模型零成本，只有本地模型处理不了的复杂推理任务才自动 Fallback 到 Portal 上的云端模型。切换过程对用户透明，不需要手动干预。

Nous Portal 不定期推出限时免费模型，关注官网获取最新活动。

更多 Provider 接入：Gemini、Bedrock、NVIDIA NIM

除了本地推理后端，Hermes 还原生支持几个值得关注的云端/半本地 Provider。

Google Gemini

Hermes 内置原生 Gemini Provider——直接调用 Gemini API，不是通过 OpenRouter 中转。

# ~/.hermes/config.yaml
model:
  default: gemini-2.5-pro
  provider: gemini

# ~/.hermes/.env
GOOGLE_API_KEY=your-api-key

Gemini 的独特价值是视觉理解能力——作为辅助模型处理图片、视频和文档分析时，Gemini Flash 系列性价比极高。

AWS Bedrock

Hermes 内置原生 Bedrock Provider，使用 Converse API（不是 OpenAI 兼容端点）。

hermes model
# 选 Bedrock → 选区域 → 发现模型 → 开始对话

认证走标准 AWS 凭据链（boto3）——环境变量、~/.aws/credentials、IAM Role 都支持，无需手动设置 base_url。适合已有 AWS 基础设施的团队。

NVIDIA NIM

通过 build.nvidia.com 免费 API 访问 Nemotron 等开源模型，40 RPM 内免费、不需要信用卡。

提示词：生成 Hermes 连接 NVIDIA NIM 的配置

请帮我生成 Hermes 连接 NVIDIA NIM 的配置，包含 config.yaml 和 .env 两个文件的内容。要求：

• config.yaml 中 Provider 设为 nvidia，默认模型为 nvidia/nemotron-3-super-120b-a12b
• .env 中设置 NVIDIA_API_KEY 环境变量（格式为 nvapi- 开头）
• 说明如何通过设置 NVIDIA_BASE_URL=http://localhost:8000/v1 从云端切换到本地 NIM 端点

NVIDIA NIM 的特点是云端和本地可以无缝切换——默认走 build.nvidia.com 云端 API（40 RPM 内免费、不需要信用卡），需要切到本地时只加一行 NVIDIA_BASE_URL 环境变量指向本地端点即可。

翔宇实战：GLM→DeepSeek→Gemini 三模型策略

我在 Mac mini 上跑 Hermes v0.16.0（截至 2026 年 6 月的最新版本），模型策略不是纯本地也不是纯云端，而是智能分层——用最低成本覆盖全部使用场景。

三模型分工

以上价格和模型信息为撰文时数据，请以各平台官方当前定价为准。

完整配置

提示词：生成翔宇三模型策略的完整 Hermes 配置

请帮我生成完整的 Hermes 配置，包含 ~/.hermes/config.yaml 和 ~/.hermes/.env 两个文件。要求：

config.yaml 部分：

• 主力模型为 glm-5.1，Provider 为 zai（智谱 Coding Plan）
• 视觉辅助走独立 Provider：google，模型为 gemini-2.5-flash
• 压缩辅助走独立 Provider：deepseek，模型为 deepseek-v4-pro
• 工具延迟加载 tool_search：模式 auto，阈值 0.1，常驻 7 个工具（terminal、read_file、write_file、list_directory、send_message、memory、skills），非常驻工具 3 轮后卸载

.env 部分：

• 三个 API Key 环境变量：GLM_API_KEY、DEEPSEEK_API_KEY、GOOGLE_API_KEY
• GLM 国内端点：GLM_BASE_URL=https://open.bigmodel.cn/api/coding/paas/v4（国内直连延迟约 5 秒，不设时 Hermes 自动探测，首条消息额外慢约 3 秒）

策略逻辑

为什么不用纯本地？ 本地模型在复杂多步推理上和云端模型（Claude Opus / GPT-4o / DeepSeek V4 Pro）差距明显，超长上下文（100K-1M）也是云端的优势领域。日常任务本地够用，但复杂任务强行用本地模型会浪费大量时间在修复错误调用上。

为什么 GLM 是主力？ 智谱的 Coding Plan Max 是月度订阅制，5 台机器共享额度，在额度内使用边际成本为零。GLM-5.1 在编码和推理任务上表现稳定，中文理解有天然优势。国内直连延迟约 5 秒，全球端点约 20 秒——国内用户建议显式设置 GLM_BASE_URL 到国内端点。不设置时 Hermes 会自动探测端点，首条消息额外慢约 3 秒。

为什么 vision 独立走 Gemini？ 两个原因：(1) Gemini Flash 视觉理解能力强且便宜；(2) 独立 Provider 不受主模型限流影响。主模型 GLM 429 时，视觉任务照常运行。

为什么 compression 也要显式配置？ 默认的 auto 模式让压缩跟主模型走。主模型限流时压缩也挂，Agent 丢失对话上下文——这就是"压缩风暴"。显式配置 DeepSeek 作为压缩后端，彻底切断级联故障。

成本对比

三模型策略在 GLM 额度内等同于纯本地的零成本体验，额度耗尽后 DeepSeek 按量计费也很便宜。90% 的使用场景免费，只有复杂任务才产生少量成本。

本地 vs 云端：各自适合什么场景

不是所有任务都适合本地模型，也不是所有场景都需要云端 API。

本地模型擅长的场景

• 文件编辑和代码生成——9B+ 模型处理良好
• 终端命令执行——工具调用稳定时效果接近云端
• 网页浏览和信息提取——响应慢一些但功能完整
• Cron 定时任务——24 小时运行的后台任务不需要极快响应
• 多平台 Gateway——Telegram/Discord bot 日常问答
• 完全隐私——敏感代码库、内部文档不出本机
• 合规要求——金融、医疗等行业对数据出境有严格限制，本地推理是合规方案

云端模型更优的场景

• 复杂多步推理——70B+ 或 Claude Opus 明显更好
• 超长上下文——云端 100K-1M，本地默认低于 64K
• 快速响应——云端推理服务器有数十张企业级 GPU 并行，远快于消费级硬件
• 多模态理解——云端视觉模型（Gemini Pro、Claude Vision）的图像、视频理解质量远高于本地开源模型
• 并发推理——多个 Agent 实例同时推理时，云端按需扩容，本地 GPU 是固定资源

最佳策略：Fallback 混合模式

提示词：生成本地优先 + 云端降级的完整混合配置

请帮我生成 ~/.hermes/config.yaml 的完整混合模式配置，实现 90% 免费本地 + 10% 付费云端。要求：

• 主力模型为 gemma4-64k，Provider 为 custom，API 地址为 http://localhost:11434/v1
• 降级链 fallback_providers 按优先级排列：先尝试 OpenRouter 的 anthropic/claude-sonnet-4，再尝试 deepseek 的 deepseek-v4-pro
• 视觉辅助走独立 Provider：google，模型为 gemini-2.5-flash
• 压缩任务也走本地：Provider 为 custom，模型为 gemma4-64k，API 地址同主力模型

这段配置把前面所有策略组合到一起——日常任务全部走本地（零成本），主模型返回错误或超时时自动按 fallback_providers 顺序尝试云端模型，视觉任务走 Gemini Flash（便宜且强），压缩任务也留在本地避免产生额外费用。

Hermes 的 Fallback 机制是自动的——主 Provider 返回错误或超时时，按 fallback_providers 列表顺序尝试下一个，直到成功或全部失败。切换过程对用户透明，不需要手动干预。

配置优先级与密钥管理

理解 Hermes 的配置优先级链有助于排查问题：

1. CLI 参数——hermes chat --model anthropic/claude-sonnet-4（单次覆盖，优先级最高）
2. ~/.hermes/config.yaml——主配置文件（模型、工具、压缩等非密钥设置）
3. ~/.hermes/.env——环境变量回退（API Key、Bot Token 等密钥必须放这里）
4. 内置默认值——硬编码安全默认值（优先级最低）

铁律：密钥放 .env，其他一切放 config.yaml。两者都设了同一个非密钥配置时，config.yaml 为准。

会话内可以用 /model 斜杠命令在已配置的 Provider 间切换，但只影响当前会话。永久切换需要修改 config.yaml 或重新运行 hermes model。

常见问题

Hermes Agent 可以完全离线运行吗？

可以。通过 Ollama、LM Studio 或 vLLM 在本地运行开源模型，Hermes Agent 可以完全离线工作，不需要连接任何云端服务。所有推理计算发生在本机，数据不出内网。但本地模型必须支持工具调用才能获得完整的 Agent 体验——编辑文件、运行终端命令、浏览网页等操作都依赖工具调用协议。不支持工具调用的模型只能纯聊天。推荐 gemma4:31b 或 qwen3.6:27b。

对本地模型的最低上下文要求是多少？

64,000 tokens，这是硬性要求。Ollama 默认上下文只有 2,048 tokens，必须通过 Modelfile 扩展到 64K 并重建模型。不满足最低要求的模型在启动时会被 Hermes 直接拒绝。

本地跑 Hermes 需要什么硬件？

最低 8 GB 内存 + 4 核 CPU 可以跑 3B 模型（仅聊天）。完整 Agent 体验推荐 32 GB+ 内存 + 8 核 CPU + NVIDIA 8 GB+ VRAM。Apple Silicon Mac（M1/M2/M3/M4）统一内存架构是性价比之选，24 GB 机型可流畅跑 9B-14B 模型。

Ollama 和 LM Studio 有什么区别？

Ollama 是命令行工具，一行命令安装启动，适合服务器和 Docker 场景。LM Studio 是桌面 GUI 应用，适合需要可视化模型管理的用户。两者都通过 OpenAI 兼容 API 接入 Hermes，配置方式一致。

为什么 Hermes 比直接用 LM Studio 慢？

Hermes 的 Agent 管线注入了系统提示词、工具 Schema、记忆上下文等额外 token。72 个工具的 Schema 占约 19,210 token。开启 tool_search 延迟加载后降到约 2,200 token（减少 89%），同时用 /compress 定期压缩长对话。

本地模型不支持工具调用怎么办？

不支持工具调用的模型只能用于纯聊天。建议用 gemma4:31b（本地工具调用最可靠），或设置 fallback_providers 到云端模型处理 Agentic 任务。Hermes 内置 auto-repair 可以修复部分格式错误的工具调用，但修复率随模型变小而下降。

Nous Portal 和本地模型可以混用吗？

可以。推荐混合策略：日常任务用本地模型（零成本），fallback_providers 配置 Portal 云端备用，复杂推理自动切换。也可以让本地模型做主力，Portal 的 Gemini Flash 做视觉辅助。

Mac 用户跑本地模型有什么优势？

Apple Silicon 的统一内存架构让 GPU 和 CPU 共享同一块内存，不存在传统 PC 上的 VRAM 瓶颈。24 GB 机型流畅跑 9B-14B 模型，64 GB 机型可以跑 27B-31B。Metal GPU 加速已被 Ollama 和 LM Studio 原生支持，推理速度比纯 CPU 快数倍。

系列导航

• 上一篇：Hermes Agent 完全指南——框架全景、架构原理、核心能力
• 相关：成本控制指南——Token 优化、Provider 比价、辅助模型策略
• 相关：Docker 部署指南——容器化部署、Gateway 配置、网络方案
• 相关：Hermes Agent 深度测评——第一手使用体验和踩坑记录

下一步

• AI 编程实操课：Claude Code + Codex + Agent 工作流，覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包，跟着做就出成果。国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流
• 微信公众号：搜索「翔宇工作流」