1. 为什么要在内网把 Hermes-Agent 接到本地 Ollama
如果你正在做企业内部工具、涉密文档处理，或者单纯不想让对话内容离开自己的机器，那 Hermes-Agent 默认走云端模型这条路就会很别扭。它开箱对接的是 OpenRouter、OpenAI 这类在线服务，意味着两件事：一是每次调用都要出网，二是请求内容会经过第三方服务器。对于内网开发机、隔离网段、离线演示环境来说，这基本等于不可用。
Hermes-Agent 本身是一个偏 Agent 编排的框架，它负责工具调用、任务拆解、多轮规划，真正干“说话”这件事的是背后的 LLM Provider。Ollama 则是一个把大模型跑在本地的运行时，一条命令拉模型、一个本地 HTTP 端口对外提供兼容接口。把这两者接起来，就得到「本地 Agent + 本地模型」的完全离线架构：Agent 的规划逻辑在本地，模型的推理也在本地，整条链路不碰外网。
这套组合适合谁？我梳理了三类：第一类是做内网办公助手的开发者，数据不能出机房；第二类是经常在没有稳定外网的环境里做演示的人，比如展会、客户现场；第三类是想省掉 API 调用成本、又愿意用本地算力换隐私的团队。需要提前说清楚的是，离线运行对硬件有要求，8B 级别的模型大概需要 8GB 以上内存才跑得比较顺，70B 级别则要 32GB 甚至更多，显存和内存要提前盘算。
这篇内容我会按“先装 Ollama、再配 Hermes、然后验证、最后排障”的顺序走，每一步都给可复制的命令和配置片段。中间会顺带提一下 TaoToken 在需要临时对照云端模型行为时的用法，但主线始终是离线。你跟着做，最后能在一个断网的终端里看到 Hermes 正常回复。
2. 前置准备：Ollama 服务地址与模型名怎么定
在动 Hermes 之前，先把 Ollama 这一侧跑通，不然后面报错会分不清是谁的问题。Ollama 的安装脚本在 Linux、macOS、WSL2 上通用，Windows 原生建议走 WSL2，避免路径和端口上的麻烦。
安装并启动服务：
# Linux / macOS / WSL2 通用安装 curl -fsSL https://ollama.com/install.sh | sh # 启动服务，前台运行方便看日志 ollama serve # 想后台跑就加 & ollama serve &启动后确认版本，再拉一个轻量模型。llama3:8b 大约 4GB，是离线场景里比较稳的起点：
ollama --version ollama pull llama3:8b拉完之后，用一条 curl 确认本地接口是通的。Ollama 默认监听11434端口，接口路径是/api/chat：
curl http://localhost:11434/api/chat -d '{ "model": "llama3:8b", "messages": [{"role": "user", "content": "ping"}], "stream": false }'如果返回一段 JSON，里面有message.content字段，说明 Ollama 这一侧没问题。这里有两个关键值要记下来，后面配 Hermes 会反复用到：服务地址http://localhost:11434，模型名llama3:8b。模型名必须和你ollama list里显示的完全一致，大小写、tag 都不能错，这是后面 404 类报错的高发点。
关于模型选择，我给一个按内存的对照，方便你对号入座：
| 本地内存 | 推荐模型 | 说明 |
|---|---|---|
| 8GB | llama3:8b、qwen:7b-chat | 能跑，响应偏慢，适合轻量对话 |
| 16GB | llama3:8b-instruct、mistral:7b | 指令跟随更好，Agent 调用更稳 |
| 32GB+ | llama3:70b-instruct、mixtral:8x7b | 质量接近云端，但首次加载慢 |
需要提醒的是，Agent 场景对“指令跟随”要求比普通聊天高，因为模型要按格式输出工具调用意图。所以优先选带-instruct或-chat后缀的版本，纯 base 模型容易输出跑偏。
如果你手边暂时没有合适的本地模型，又想先验证 Hermes 的配置结构是否正确，可以临时用 TaoToken 的模型对话页对照一下请求格式，确认字段名没写错，再切回本地。它的模型对话入口在 https://taotoken.net/api ，不过离线场景下这一步只是辅助，最终还是要回到 Ollama。
3. 可复制配置：Hermes-Agent 侧连接参数怎么写
这一节是核心，配置写对了，后面基本就顺了。Hermes-Agent 的配置有两种方式：CLI 向导和手动改配置文件。新手建议先用向导跑一遍，理解字段含义后再手动微调。
先激活 Hermes 的虚拟环境（手动安装的用户），并安装 ollama 的 Python 依赖：
source ~/.hermes/venv/bin/activate pip install ollama方式一，CLI 向导。执行后按提示选 provider 为 ollama，模型填你拉取的名称：
hermes model # 1. LLM Provider -> 输入 ollama # 2. Model -> 输入 llama3:8b # 3. 确认保存 -> 输入 y方式二，手动编辑~/.hermes/config.yaml。这是更可控的做法，推荐你直接照抄下面这段，把模型名换成自己的：
llm: provider: ollama model: llama3:8b ollama: base_url: http://localhost:11434 temperature: 0.7 max_tokens: 4096如果你更习惯 JSON 风格的配置，或者你的 Hermes 版本读取的是settings.json，等价写法如下，字段名保持一致：
{ "llm": { "provider": "ollama", "model": "llama3:8b", "ollama": { "base_url": "http://localhost:11434", "temperature": 0.7, "max_tokens": 4096 } } }这里三个参数要重点说。base_url指向本地 Ollama，离线场景下必须是localhost或127.0.0.1，不要写成局域网 IP，除非 Ollama 跑在另一台机器上。temperature控制随机性，Agent 做工具调用时建议压到 0.3 到 0.5，减少格式漂移；纯聊天可以放到 0.7。max_tokens决定单次生成上限，4096 对多数 Agent 任务够用，设太大反而拖慢响应。
改完配置后重启 Hermes 让配置生效：
hermes stop hermes如果你在配置里同时保留了云端 provider 的字段，记得把 provider 明确改成 ollama，否则 Hermes 可能仍按旧配置去连外网。这一点在混合环境里特别容易踩，配置文件的优先级要自己确认一遍。
4. 验证请求：一次离线对话怎么确认全程不出网
配置写完不代表成功，必须做一次可观测的验证。我的做法是分两步：先看 Hermes 能不能回，再看网络有没有出。
第一步，在 Hermes 交互界面里发一条测试指令：
hermes # 进入交互后输入： 你好，我是内网用户，测试本地 Ollama 对接如果正常返回中文回复，说明链路通了。此时另开一个终端看 Ollama 日志，能看到模型被调用的记录：
journalctl -u ollama -f # 或者前台启动时直接看 ollama serve 的输出第二步，验证“不出网”。最直接的办法是在断网环境下重跑一次。你可以临时把网卡关掉，或者用防火墙规则只放行本地回环，然后重复上面的对话。如果还能正常回复，就证明请求没有依赖外网。
更严谨一点，可以用ss观察 Hermes 进程的连接目标：
ss -tnp | grep hermes正常情况下你只会看到指向127.0.0.1:11434的连接，不应该出现任何外部 IP。如果看到陌生的公网地址，说明配置里还残留着云端 provider，需要回去检查config.yaml。
这里插一句，如果你在验证阶段想对比一下同一个 prompt 在云端模型上的表现，可以用 TaoToken 的模型对话页快速跑一次，地址是 https://taotoken.net/api ，但对比完记得把配置切回 ollama，别让云端字段留在生产配置里。离线验证的判定标准只有一个：断网后仍能回复。
5. 常见报错排查：401、连接失败、choices 读取异常
离线对接的报错其实就那么几类，我把高频的列出来，对照着查基本能定位。
第一类，Could not connect to Ollama或connection refused。这几乎都是 Ollama 服务没起来，或者base_url写错。先确认ollama serve在跑，再确认端口是 11434，最后确认配置里写的是http://localhost:11434而不是别的。注意不要写成https，本地服务没有证书，写 https 会直接握手失败。
第二类，401 Unauthorized或invalid api key。这个报错在离线场景里出现，通常意味着 Hermes 还在按云端 provider 的逻辑发请求，带上了鉴权头。检查config.yaml里 provider 是不是真的改成了 ollama，有没有旧的api_key字段残留。Ollama 本地接口不需要 key，任何鉴权字段都应该清掉。
第三类，reading choices或choices field not found。这是响应解析失败，根因多半是模型名对不上，Ollama 返回了错误 JSON，Hermes 却按正常结构去读choices。解决办法是ollama list看真实模型名，逐字符核对配置里的model字段。另外，部分 Hermes 版本对 Ollama 的响应格式适配不完整，如果确认模型名没错还报这个，升级 Hermes 到较新版本。
第四类，local proxy failed或代理相关报错。这说明环境变量里配了 HTTP 代理，Hermes 把本地请求也走了代理，结果代理连不上本地回环。检查http_proxy、https_proxy环境变量，把localhost和127.0.0.1加进no_proxy：
export no_proxy="localhost,127.0.0.1"第五类，OAuth 相关报错。如果你之前用云端 provider 登录过，Hermes 可能缓存了 OAuth token，切到 ollama 后仍在尝试刷新。清掉缓存目录里的凭据文件，或者重新执行一次hermes model走完整向导覆盖旧配置。
第六类，回复乱码或逻辑混乱。这不是连接问题，是模型问题。换成-instruct版本，把temperature降到 0.5 以下，必要时重新ollama pull一次，排除模型文件损坏。
排查时有个通用思路：先 curl 直连 Ollama 确认服务本身正常，再看 Hermes 日志确认它发到哪、收到什么。把这两段对齐，问题基本就浮出来了。
6. 需要云端对照或长期跑 Agent 时的接入选择
离线跑通之后，有些场景你还是会需要云端模型：比如本地算力不够跑大参数模型，或者要做多轮复杂 Agent 任务、本地模型规划能力跟不上。这时候可以把 TaoToken 作为对照和补充接进来，它的接口是 OpenAI 兼容格式，配置结构和上面几乎一样，只是把base_url和model换掉。
如果你要长期跑编码类 Agent，或者需要更稳定的工具调用能力，可以看下 Coding Plan，入口在 https://taotoken.net/api 。配置时同样要写全三件套：Base URL、API Key、Model ID，缺一个都会报鉴权或模型找不到。API Key 在控制台生成，地址是 https://taotoken.net/api-keys ，接入文档在 https://taotoken.net/doc ，里面有各语言的请求示例，照着改字段就行。
需要强调的是，云端和本地是两套独立配置，别混在同一个 provider 块里。我的做法是给本地和云端各留一份配置文件，用的时候切换，避免离线环境里误连外网。对于内网部署，最终交付的配置里只保留 ollama 这一段，云端字段全部移除，这样即使环境变量被污染，也不会意外出网。
最后给一个实用技巧：把 Ollama 的模型缓存目录挂到空间大的盘上，默认路径在~/.ollama/models，模型多了很占地方。迁移后记得改OLLAMA_MODELS环境变量，再重启服务。这样你换模型、试新版本时不会把系统盘撑爆。
