# 本地跑 Hermes + Qwen3.5-27B 全流程踩坑记录（低配显卡也行）

> 用集成显卡的普通笔记本，通过 Ollama CPU 推理 + WSL 环境，搭建本地大模型 Agent 平台并打通 tool calling 的完整实战记录。没有独显照样玩转本地 AI Agent。

## 前言

最近折腾了一把本地大模型 Agent 平台，目标很简单：**在 AMD AI MAX+ 64G内存（48G显存） 上跑一个能真正执行工具的 AI Agent**，不依赖云端 API，数据不出本机。

选型：
- **模型**：Qwen3.5-27B（Q4_K_M 量化，17GB 显存）
- **推理引擎**：Ollama
- **Agent 框架**：Hermes
- **运行环境**：Windows 11 + WSL2 (Ubuntu)

整个过程中踩了不少坑，这篇把关键问题和解决方案都记录下来，给同样在折腾本地 Agent 的朋友避坑。

---

## 一、硬件与环境

### 显卡情况

我的笔记本是集成显卡（8060s），没有独显。这意味所有推理都走 **CPU**，速度比 GPU 慢，但完全能用。

关键策略：**用 Q4 量化的中小模型**，控制在 CPU 内存能承受的范围内。

| 模型 | 量化 | 体积 | 运行方式 |
|------|------|------|----------|
| Qwen3.5-27B | Q4_K_M | ~17GB | CPU 推理，速度约 4-8 tok/s |
| Qwen3.5-35B | Q4_K_M | ~21GB | CPU 推理，MoE 架构，需要大内存 |

> 如果你有独显（哪怕是 RTX 3060 12GB），速度会快很多。本篇的方案对有无独显都适用。

### Python 环境

系统默认的 python 命令在 Windows 下经常有兼容性问题。建议用虚拟环境：

```bash
python -m venv /path/to/venv
venv\Scripts\pip install ollama requests flask
```

---

## 二、Qwen3.5 的 thinking 模式问题

### 问题描述

Qwen3.5 默认开启 thinking 模式。通过 OpenAI 兼容接口（`/v1/chat/completions`）调用时，**无法关闭 thinking**，导致返回的 `content` 为空，模型把所有内容都放进了 thinking 区块。

这对 Agent 框架来说是致命的——收不到模型输出，整个对话循环就断了。

### 解决方案

**必须用 Ollama 原生 API**（`/api/chat`）而不是 OpenAI 兼容接口，原生 API 支持通过请求参数直接关闭 thinking：

```python
payload = {
    "model": "qwen3.5-27b-q4-ctx64k",
    "messages": messages,
    "stream": False,
    "think": False  # 关键！原生 API 才支持这个参数
}
response = requests.post("http://localhost:11434/api/chat", json=payload)
```

关闭后模型返回正常的 `content`，Agent 才能正常工作。

---

## 三、搭建 Think-Proxy 代理层

### 为什么需要 Proxy

Hermes 要求模型提供 OpenAI 兼容的 `/v1/chat/completions` 接口。但我们又必须走 Ollama 原生 `/api/chat` 才能注入 `think: false`。

所以需要一个中间代理层，做三件事：
1. 接收 Hermes 的 OpenAI 格式请求
2. 转换为 Ollama 原生格式，注入 `think: false`
3. 把 Ollama 的响应转回 OpenAI 格式返回给 Hermes

### Proxy 架构

```
Hermes  →  Think-Proxy (127.0.0.1:11436)  →  Ollama (172.18.112.1:11434)
            接收 OpenAI 格式                      Ollama 原生 API
            转发 + 注入 think:false               /api/chat
            转回 OpenAI 格式
            转发 tools 参数 ⭐
            转回 tool_calls ⭐
```

### 关键实现细节

Proxy 用 Python Flask 实现，核心逻辑大约 100 行。这里说几个容易踩坑的点：

**1. tools 参数必须转发**

Hermes 发来的请求中包含 `tools` 字段（工具定义列表），这个必须原样转发给 Ollama。Ollama 的 `/api/chat` 接受的 tools 格式和 OpenAI 基本一致，可以直接传。

```python
ollama_payload = {
    "model": model,
    "messages": messages,
    "stream": False,
    "think": False,
    "tools": request_body.get("tools")  # 必须转发！
}
```

**如果不转发 tools，模型根本不知道有工具可用**，会把工具调用当成普通文本输出，形成"看起来像在执行但实际什么都没干"的现象。

**2. tool_calls 返回格式转换**

Ollama 原生 API 返回的 `tool_calls` 中，`arguments` 是 dict 类型，但 OpenAI 格式要求是 JSON 字符串：

```python
if "tool_calls" in ollama_response.get("message", {}):
    for tc in ollama_response["message"]["tool_calls"]:
        # Ollama 返回 dict，需要转成字符串
        tc["function"]["arguments"] = json.dumps(tc["function"]["arguments"])
    finish_reason = "tool_calls"  # 必须改！
```

**3. finish_reason 必须正确设置**

当有 tool_calls 时，`finish_reason` 必须设为 `"tool_calls"`（不是 `"stop"`），否则 Hermes 不会触发工具执行逻辑。

### 验证 tool calling

写好 Proxy 后，先单独验证 tool calling 是否正常：

```bash
curl http://127.0.0.1:11436/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5-27b-q4-ctx64k",
    "messages": [{"role": "user", "content": "列出 /tmp 目录下的文件"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "terminal",
        "description": "执行终端命令",
        "parameters": {
          "type": "object",
          "properties": {
            "command": {"type": "string"},
            "shell": {"type": "string"}
          }
        }
      }
    }]
  }'
```

正确响应应该包含 `finish_reason: "tool_calls"` 和具体的 `tool_calls` 数组。

---

## 四、WSL 终端 I/O 崩溃问题

### 问题描述

在 Windows CMD 中通过 `wsl -d Ubuntu -- hermes chat` 启动 Hermes Chat 时，会随机触发：

```
OSError: [Errno 5] Input/output error
```

进程直接退出，窗口关闭。

### 原因

Windows CMD 启动 WSL 时创建的终端管道不稳定，Hermes 使用的 `prompt_toolkit` 库在 flush 输出时触发 I/O 错误。

### 解决方案

**必须用 `bash -lc` 包裹命令**，加载完整的 login shell 环境：

```batch
@echo off
chcp 65001 >nul
title Hermes Chat
wsl -d Ubuntu -- bash -lc "hermes chat --yolo"
pause
```

加了 `pause` 是为了崩溃时能看到错误信息，而不是窗口直接消失。

---

## 五、Hermes 配置要点

### config.yaml 关键配置

```yaml
model:
  active: custom
  custom_providers:
    - name: custom
      base_url: "http://127.0.0.1:11436/v1"  # Think-Proxy 地址
      api_key: "ollama"
      model: "qwen3.5-27b-q4-ctx64k"

approvals:
  mode: auto  # 工具自动执行，不需要手动确认

terminal:
  backend: local
  shell: bash
  cwd: .
```

### 注意事项

1. **版本迁移会覆盖配置**：Hermes 升级时 `hermes config migrate` 会把自定义配置还原为默认值（模型改回 gemma4:31b、base_url 改回 docker 地址），迁移后必须手动恢复。

2. **approvals.mode 设为 auto**：如果是 `manual`，Hermes 执行每个工具前都要按 `y` 确认，体验很差。启动时加 `--yolo` 也可以跳过。

3. **Ollama 跨 WSL 访问**：Ollama 跑在 Windows 侧，WSL 里通过 `172.18.112.1:11434` 访问。这个 IP 是 WSL 的宿主机地址，可能因网络配置不同而变化，用 `cat /etc/resolv.conf | grep nameserver` 查看。

---

## 六、WSL Ghost Socket 问题

### 问题描述

WSL 有一个诡异的 bug：进程已经 kill 了，但端口仍然显示 `LISTEN` 状态。导致重启 Proxy 时端口被占用，新进程绑定失败。

### 解决方案

```bash
# 方法1：用 fuser 强制释放
fuser -k 11436/tcp

# 方法2：彻底重启 WSL
wsl --shutdown
```

建议在启动脚本里先 kill 旧进程再启动新的。

---

## 七、最终效果

跑通后的完整链路：

1. 在终端启动 `hermes_chat.cmd`
2. 对 Hermes 说："帮我查看系统内存使用情况"
3. Hermes 调用模型 → 模型返回 tool_call → Hermes 自动执行终端命令 → 返回结果给模型 → 模型输出人类可读的回答

**整个过程全自动，模型真正在"使用工具"而不是"假装使用工具"。**

---

## 总结

| 踩坑点 | 原因 | 解决方案 |
|--------|------|----------|
| content 为空 | Qwen3.5 thinking 模式 | 用 Ollama 原生 API + think:false |
| 工具不执行 | Proxy 没转发 tools 参数 | 转发 tools，转换 tool_calls 格式 |
| finish_reason 错误 | Ollama 返回 stop 而非 tool_calls | 有 tool_calls 时改为 "tool_calls" |
| WSL 终端崩溃 | prompt_toolkit I/O error | 用 bash -lc 包裹启动命令 |
| 配置被覆盖 | 版本迁移覆盖自定义配置 | 迁移后手动恢复 config |
| 端口占用 | WSL ghost socket | fuser -k 或重启 WSL |
| MoE 爆内存 | expert 层全量加载 | 用 Dense 模型（27B Q4），或换成更小的 7B/14B |

核心就一句话：**本地跑 Agent 不难，难的是中间每一层的格式转换都不能错。** Think-Proxy 虽然只有 100 行代码，但它桥接了 OpenAI 和 Ollama 两个不同的 API 协议，是整个链路能跑通的关键。即使没有独显，CPU 推理也完全够用，只是速度慢一些而已。

希望这篇能帮到正在折腾本地大模型 Agent 的朋友。有问题欢迎评论区交流。

---

*环境：Windows 11 + WSL2 Ubuntu | 集成显卡 8060s | Ollama CPU 推理 + Hermes + Qwen3.5-27B-Q4*


用集成显卡的普通笔记本，通过 Ollama CPU 推理 + WSL 环境，搭建本地大模型 Agent 平台并打通 tool calling 的完整实战记录。没有独显照样玩转本地 AI Agent。

本地跑 Hermes + Qwen3.5-27B 全流程踩坑记录

编程语言

如何在低配显卡笔记本上搭建本地AI Agent？本文分享使用Ollama CPU推理+WSL环境运行Qwen3.5-27B模型的完整实战经验，解决thinking模式、tool calling、WSL终端崩溃等关键问题，实现数据不出本机的本地AI Agent部署方案。

Windows

Docker

Python

Ubuntu

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

本地跑 Hermes + Qwen3.5-27B 全流程踩坑记录-腾讯云开发者社区-腾讯云

本地跑 Hermes + Qwen3.5-27B 全流程踩坑记录

本地跑 Hermes + Qwen3.5-27B 全流程踩坑记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐