Clawdbot整合Qwen3-32B保姆级教程：Web网关18789端口调试全记录

优质文章学习记录

— 10 min read

Clawdbot整合Qwen3-32B保姆级教程：Web网关18789端口调试全记录

1. 为什么需要这个整合方案

你是不是也遇到过这样的问题：想用本地部署的大模型做聊天机器人，但发现直接调用Ollama的API在Web前端里跨域报错？或者Clawdbot配置完后一直连不上模型，控制台疯狂刷404？又或者好不容易跑起来了，发个消息却卡在“正在思考”半天没反应？

这正是我们搭建这套环境时踩过的坑。Clawdbot本身不直接对接Ollama，它需要一个中间层来处理协议转换、请求转发和端口映射。而18789这个端口，就是整个链路里最关键的“通关密码”——它不是随便选的，而是Clawdbot默认监听的Web网关入口。

整套方案的核心逻辑其实很朴素：

  • 你在浏览器里访问 http://localhost:18789，看到的是Clawdbot的聊天界面
  • Clawdbot收到你的消息后，不自己去算答案，而是把请求转给内部代理
  • 代理再把请求发到 http://localhost:8080（Ollama API地址）
  • Ollama调用本地的Qwen3-32B模型生成回复，原路返回

整个过程对用户完全透明，你只管打字，剩下的交给这三层接力。

我们不用Docker Compose写一堆yaml，也不搞Kubernetes集群，就用最轻量、最可控的方式——纯命令行+配置文件，每一步都能看见、能改、能查。

2. 环境准备与基础服务启动

2.1 确认系统前提条件

请先在终端里运行这几条命令，确认基础环境已就绪：

# 检查Node.js版本（Clawdbot需要18.x或更高） node --version # 检查Ollama是否已安装并运行 ollama list curl -s http://localhost:11434/api/tags | jq '.models[] | select(.name | contains("qwen3"))' # 检查Python是否可用（部分代理脚本依赖） python3 --version

如果ollama list没显示qwen3:32B，先拉取模型：

ollama pull qwen3:32B
注意：Qwen3-32B是大模型，首次拉取可能需要30分钟以上，请确保磁盘空间充足（建议预留25GB以上）。不要用qwen3:latest，必须明确指定:32B标签，否则可能加载错版本导致后续报错。

2.2 启动Ollama服务并验证API

Ollama默认监听127.0.0.1:11434，但Clawdbot需要的是标准HTTP API格式。我们先手动测试一下原始接口是否通：

curl -X POST http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32B", "messages": [{"role": "user", "content": "你好"}], "stream": false }' | jq '.message.content'

如果返回“你好！很高兴见到你”，说明Ollama工作正常。如果报错Connection refused，请检查Ollama服务是否真的在后台运行（ps aux | grep ollama）。

2.3 创建轻量代理层（关键步骤）

Clawdbot不能直连Ollama的11434端口，因为它的前端代码硬编码了/v1/chat/completions路径，而Ollama用的是/api/chat。我们需要一个“翻译官”。

我们不用Nginx或Caddy这种重型网关，写一个50行以内的Python代理脚本，保存为proxy_8080.py：

#!/usr/bin/env python3 import asyncio import json from aiohttp import web, ClientSession OLLAMA_URL = "http://localhost:11434/api/chat" TIMEOUT = 300 async def handle_chat(request): try: data = await request.json() # 将OpenAI格式转为Ollama格式 ollama_data = { "model": data.get("model", "qwen3:32B"), "messages": [{"role": m["role"], "content": m["content"]} for m in data.get("messages", [])], "stream": data.get("stream", False), } async with ClientSession() as session: async with session.post( OLLAMA_URL, json=ollama_data, timeout=asyncio.Timeout(TIMEOUT) ) as resp: if resp.status == 200: response_data = await resp.json() # 转回OpenAI兼容格式 openai_resp = { "id": "chat-" + str(hash(json.dumps(data)))[:8], "object": "chat.completion", "created": int(__import__('time').time()), "model": ollama_data["model"], "choices": [{ "index": 0, "message": {"role": "assistant", "content": response_data.get("message", {}).get("content", "")}, "finish_reason": "stop" }] } return web.json_response(openai_resp) else: return web.Response(text=await resp.text(), status=resp.status) except Exception as e: return web.json_response({"error": str(e)}, status=500) app = web.Application() app.router.add_post("/v1/chat/completions", handle_chat) web.run_app(app, host="127.0.0.1", port=8080, print=False)

赋予执行权限并后台运行：

chmod +x proxy_8080.py nohup python3 proxy_8080.py > proxy.log 2>&1 &

验证代理是否生效：

curl -X POST http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32B", "messages": [{"role": "user", "content": "用一句话介绍你自己"}] }' | jq '.choices[0].message.content'

看到Qwen3的回答，说明8080端口代理已就位。

3. Clawdbot部署与18789端口配置

3.1 下载并解压Clawdbot

Clawdbot是静态前端项目，无需编译。从官方GitHub Release下载最新版（截至2026年1月为v0.8.2）：

wget https://github.com/clawdbot/clawdbot/releases/download/v0.8.2/clawdbot-v0.8.2.zip unzip clawdbot-v0.8.2.zip -d clawdbot cd clawdbot

进入目录后，你会看到index.html和config.json两个核心文件。

3.2 修改config.json适配本地环境

打开config.json，重点修改以下三处（其他字段保持默认）：

{ "apiUrl": "http://localhost:8080/v1", "model": "qwen3:32B", "baseUrl": "http://localhost:18789" }

关键点说明：

  • apiUrl必须指向我们刚起的8080代理，不能写11434
  • model字段必须和Ollama里ollama list显示的名称完全一致（包括大小写和冒号）
  • baseUrl是Clawdbot自身服务的地址，也就是我们要监听的18789端口

3.3 启动Clawdbot Web服务

Clawdbot自带简易HTTP服务器，一行命令启动：

npx http-server -p 18789 -c-1
-c-1表示禁用缓存，避免配置修改后页面不刷新；-p 18789明确指定端口。不要用python3 -m http.server 18789，它不支持前端路由，会导致页面白屏。

启动成功后，终端会显示：

Starting up http-server, serving ./ Available on: http://127.0.0.1:18789 http://192.168.1.100:18789 Hit CTRL-C to stop the server

此时打开浏览器访问 http://localhost:18789，就能看到Clawdbot的聊天界面。

4. 18789端口调试全流程实录

4.1 常见连接失败的三种典型场景

我们把调试过程拆成三步，每步都对应一个真实报错截图（文中已引用），你可以对照自查：

第一步：浏览器能打开页面，但输入消息后无响应
→ 打开浏览器开发者工具（F12），切到Network标签页，发送一条消息
→ 查看/v1/chat/completions请求的状态码
→ 如果是Failed to load resource: net::ERR_CONNECTION_REFUSED，说明8080代理没起来，回到2.3节重启代理

第二步：请求发出，但返回400 Bad Request
→ 点开该请求，看Response内容
→ 如果是{"error":"model not found"}，说明config.json里的model名和Ollama不一致，重新核对ollama list输出

第三步：请求成功返回，但Clawdbot界面上显示“Error: Invalid response”
→ 这是格式不兼容的典型表现，说明代理脚本没把Ollama响应正确转成OpenAI格式
→ 检查proxy_8080.py中openai_resp构造部分，特别是response_data.get("message", {}).get("content", "")这一行是否取到了值

4.2 抓包验证完整链路（推荐用curl模拟）

为了彻底理清数据流向，我们跳过浏览器，用curl手动走一遍全流程：

# 1. 模拟Clawdbot向代理发请求（等效于前端AJAX） curl -X POST http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32B", "messages": [{"role": "user", "content": "今天天气怎么样？"}] }' # 2. 模拟代理向Ollama发请求（等效于proxy_8080.py内部调用） curl -X POST http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32B", "messages": [{"role": "user", "content": "今天天气怎么样？"}], "stream": false }'

如果第2步有返回，第1步没返回，问题一定出在代理脚本；如果两步都有返回，但Clawdbot仍报错，问题就在前端配置或网络策略。

4.3 日志定位法：三日志联动分析

当界面卡住时，同时查看三个日志文件：

日志位置查看命令关键线索
proxy.logtail -f proxy.log看是否有500 Internal Server Error或超时记录
http-server终端输出直接看启动终端看是否有404 Not Found或CORS警告
浏览器ConsoleF12 → Console看是否有Uncaught (in promise)错误

举个真实案例：某次调试中，proxy.log显示ReadTimeoutError，但Ollama本身响应很快。最后发现是代理脚本里TIMEOUT = 300写成了3000（单位是秒），导致等待3000秒才超时，前端早已放弃。改成300后问题解决。

5. 进阶优化与稳定性加固

5.1 让服务开机自启（Linux/macOS）

把两个服务做成systemd服务，避免每次重启都要手动拉起：

创建/etc/systemd/system/ollama-proxy.service：

[Unit] Description=Ollama to OpenAI API Proxy After=ollama.service [Service] Type=simple User=$USER WorkingDirectory=/path/to/your/proxy ExecStart=/usr/bin/python3 /path/to/your/proxy_8080.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload sudo systemctl enable ollama-proxy sudo systemctl start ollama-proxy

同理为Clawdbot创建clawdbot-web.service，用npx http-server启动。

5.2 内存与显存监控（Qwen3-32B专属）

Qwen3-32B在推理时会占用约20GB显存（A10G）或35GB内存（CPU模式）。建议加装监控：

# 实时查看Ollama内存占用 ollama serve & # 确保服务在前台运行，便于观察日志 # 在另一个终端运行 watch -n 1 'nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | head -1'

如果显存持续95%以上，考虑在config.json中添加流式响应开关（需Clawdbot v0.8.2+）：

"stream": true

这样Ollama会边生成边返回token，降低内存峰值。

5.3 安全加固：限制本地访问

18789端口默认只监听127.0.0.1，但如果你用http-server -a 0.0.0.0开放了外网，务必加一层基础认证：

# 安装带认证的http-server npm install -g http-server-auth # 启动时加用户名密码 http-server-auth -p 18789 -u admin -p your_secure_password

这样即使端口暴露，没有凭证也无法访问聊天界面。

6. 总结：从连不上到丝滑对话的六个关键点

回顾整个调试过程，真正卡住大家的从来不是技术多难，而是几个细节没对齐：

  1. 端口不是数字游戏：18789是Clawdbot约定，8080是代理中转站，11434是Ollama原生端口——三者缺一不可，且不能互换
  2. 模型名必须一字不差：qwen3:32B ≠ qwen3:32b ≠ qwen3-32B，大小写和符号都要严格匹配
  3. 代理是协议翻译器：不是简单端口转发，必须把OpenAI的JSON结构转成Ollama能懂的格式
  4. 日志要三端联动看：前端Console、代理log、Ollama终端，漏掉任何一环都可能误判
  5. 超时设置要合理：Qwen3-32B首token延迟可能达8秒，代理timeout至少设为30秒
  6. 验证要分层进行：先测Ollama原生API → 再测代理层 → 最后测Clawdbot界面，层层递进

现在，当你在浏览器里输入http://localhost:18789，敲下“你好”，看到Qwen3-32B用中文流畅回复时，你就已经完成了私有大模型聊天平台最关键的一步——不是调通了某个API，而是打通了从用户输入到大模型思考的完整信任链。

下一步，你可以尝试把config.json里的model换成qwen3:7B做对比，感受不同参数规模下的响应速度差异；或者把代理脚本改成支持多模型路由，让一个端口服务多个大模型。

技术落地的魅力，永远在于“原来如此”的顿悟时刻，而不是堆砌术语的幻觉。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 ZEEKLOG星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Read more

FPGA开发常用软件盘点：Vivado、Quartus、ModelSim全面对比

FPGA开发常用软件盘点：Vivado、Quartus、ModelSim全面对比

在FPGA开发过程中，EDA工具（Electronic Design Automation） 是工程师的生产力核心。不同厂商的FPGA芯片通常配套不同的开发工具，但在项目实践中，很多工程师往往会接触多种EDA软件。 本文将带你系统梳理三款FPGA开发中最常用的软件：Vivado、Quartus、ModelSim，从功能、适用场景、优缺点等多个维度进行全面对比，助你快速入门并合理选择。 一、Vivado —— Xilinx官方旗舰开发平台 1. 基本简介 Vivado是Xilinx（现为AMD）推出的综合性FPGA开发环境，主要面向7系列、UltraScale、Versal等高端FPGA器件。 它集成了综合、布局布线、时序分析、仿真、硬件调试等完整流程，是Xilinx FPGA开发的首选工具。 2. 核心功能 * RTL综合与实现：支持Verilog、VHDL和SystemVerilog，自动进行逻辑优化与布局布线。 * IP Integrator：可视化模块连接工具，适合SoC级设计。 * 仿真与调试：内置Vivado Simulator，也可外接ModelSim进行
【Agent】Claude code辅助verilog编程

【Agent】Claude code辅助verilog编程

摘要：在 2026 年，硬件描述语言（HDL）的开发门槛正在被 AI 重新定义。本文记录了一次硬核挑战：在不查阅任何寄存器手册、不手画状态转移图的情况下，仅凭 Claude Code 辅助，完成了一个包含 UART 通信、协议解析（FSM）及 PWM 控制的完整 FPGA 模块设计与验证。这是一次关于“AI 辅助芯片设计”的真实压力测试。 目录 1. 引言：Verilog 开发者的“中年危机” 2. 项目挑战：从串口到 LED 的全链路设计 3. 开发实录：Claude Code 的 RTL 设计能力 * 3.1

OpenClaw安装和接入飞书机器人完整教程

OpenClaw安装和接入飞书机器人分三大部分组织回答： 1）先讲环境准备和OpenClaw基础安装（分阿里云和本地Windows两种场景）； 2）再讲飞书机器人配置（包括应用创建、通道添加、事件订阅）； 3）最后讲验证和配置AI模型。 为了更直观，在部署方式对比、配置项说明等地方用表格呈现。 这是一份完整的OpenClaw安装及接入飞书机器人的教程。将涵盖从环境准备、OpenClaw部署（含阿里云服务器和本地Windows两种方式）、AI模型（以阿里云百炼为例）配置，到最终在飞书开放平台创建并接入机器人的全流程。 第一部分：准备工作与核心认知 在开始动手前，我们需要先了解 OpenClaw 是什么，并准备好必要的账号和工具。 1.1 什么是 OpenClaw？ OpenClaw（昵称“小龙虾”，曾用名 ClawdBot / Moltbot）是一个开源的个人AI智能体框架。它本身不具备推理能力，需要对接大语言模型（如阿里云百炼、七牛云、OpenAI等）的API。它的核心价值在于： * 真正的执行能力：能通过“技能”
【VR音游】音符轨道系统开发实录与原理解析（OpenXR手势交互）

【VR音游】音符轨道系统开发实录与原理解析（OpenXR手势交互）

VR音游音符轨道系统开发实录与原理解析 在 VR 音游的开发过程中，音符轨道系统是最核心的交互与可视化部分。本文结合一次完整的开发实录，分享从核心原理与设计到VR内容构建的完整过程，帮助读者快速理解音符轨道系统的实现思路。 文章目录 * VR音游音符轨道系统开发实录与原理解析 * 一、实录结果 * 二、VR内容开发步骤 * 1. 准备音符与交互逻辑 * 2. 创建谱面 * 3. 绘制音轨 * 4. 预制件与音频替换 * 三、原理解析（音符轨道系统） * 1. 音符轨道（Note Track） * 2. 轨迹调节与偏移控制 * 3. 音符触摸激活 * 4. 谱面编辑工具（Editor 功能） * 四、总结与展望 * 1. 成果回顾：从零到一的核心突破 * 2. 技术总结：核心设计理念 * 3. 开发难点与问题反思 * 4. 优化策略与改进方向 * 5.