1. 本地 OpenClaw 接 Ollama 后请求有响应却无输出的典型场景你遇到的这个现象其实很典型OpenClaw 的 Web 界面显示消息已发送Ollama 日志里也能看到请求进来了但页面上就是迟迟不吐字等半天没有任何回复内容。与此同时用 Chatbox 连同一个 Ollama 地址、同一个qwen2.5-coder:0.5b模型对话却完全正常。这种「一边通一边不通」的对比基本可以排除模型本身和 Ollama 服务的问题把矛头指向 OpenClaw 与 Ollama 之间的协议对接层。先把场景说清楚。OpenClaw 是一个本地优先的 AI 网关/客户端项目它本身不跑模型而是把请求转发给你配置的模型服务。Ollama 在本地127.0.0.1:11434上提供 OpenAI 兼容接口和原生/api/chat接口。Qwen2.5-Coder 是通义千问的代码专用系列0.5b是其中最小的量化版本适合 16G 内存、无独显的机器跑。问题就出在OpenClaw 默认可能按 OpenAI 的chat/completions流式格式去解析响应而 Ollama 在某些路径下返回的是 NDJSON每行一个 JSON 对象流字段结构不一样解析器读不到choices[0].delta.content于是前端一直等不到内容表现就是「有去无回」。这个场景适合谁适合所有在低配机器上折腾本地大模型、想用 OpenClaw 做统一入口但被流式解析坑到的人。核心检索词就是 OpenClaw 接入 Ollama 无返回、Qwen2.5-Coder 本地部署无输出、流式解析失败。下面我会按「先确认 Ollama 直连正常 → 再核对 OpenClaw 配置 → 用 curl 抓原始响应 → 看日志定位是流式还是上下文拼接」的顺序把每一步都写成可复制的操作。需要先建立一个判断如果 Chatbox 能通说明 Ollama 的 HTTP 服务、模型加载、端口监听都没问题。那 OpenClaw 这边要么是 Base URL 写成了不带/v1的裸地址导致走了原生接口要么是模型 ID 带了 Ollama 特有的 tag 而 OpenClaw 做了额外拼接要么就是流式开关和解析器不匹配。这三类原因覆盖了 90% 的「有响应无输出」。2. TaoToken 前置统一网关与模型 ID 的对照准备在动手排查之前建议先把「模型服务地址」和「模型 ID」这两个概念理清楚因为后面所有配置都围绕它们转。本地 Ollama 的地址是http://127.0.0.1:11434这是原生接口根路径如果要走 OpenAI 兼容格式通常要写成http://127.0.0.1:11434/v1。模型 ID 在 Ollama 里是qwen2.5-coder:0.5b带冒号和 tag这一点和云端 API 只写qwen2.5-coder不一样写错了就会 404 或者模型找不到。如果你后续想把本地模型和云端模型放在同一个入口里管理或者本地机器实在跑不动更大的模型可以准备一个云端兜底通道。TaoToken 提供 OpenAI 兼容的接口Base URL 是https://taotoken.net/api模型 ID 按平台文档填写即可。它的作用是当本地 Ollama 的0.5b回答质量不够、或者你想临时切到更强的代码模型时不用改 OpenClaw 的整体结构只换 Base URL 和 Key 就行。这一步不是必须的但对你这种「本地低配 想要可用代码助手」的场景很实用。具体准备三样东西。第一本地 Ollama 的服务地址确认是http://127.0.0.1:11434并且ollama list能看到qwen2.5-coder:0.5b。第二如果要用云端去控制台生成一个 API Key地址是https://taotoken.net/consoleKey 只在生成时显示一次复制保存好。第三想清楚 OpenClaw 里填的到底是原生地址还是兼容地址这决定了它用哪套解析逻辑。这里有个容易忽略的点OpenClaw 的--custom-base-url参数官方示例里给的是http://127.0.0.1:11434不带/v1。但很多客户端默认按 OpenAI 协议拼/v1/chat/completions如果 OpenClaw 内部拼路径的方式和你想的不一样就会打到 Ollama 不认识的路径上或者打到原生/api/chat上返回 NDJSON。所以第一步不是改配置而是先用 curl 把两种路径的原始返回都抓出来看确认字段结构再决定 OpenClaw 该填哪个地址。另外提醒一句本地 Ollama 默认只监听127.0.0.1如果你把 OpenClaw 跑在容器里或者另一台机器上需要设置OLLAMA_HOST0.0.0.0并重启服务否则连接会被拒绝。这个和「有响应无输出」不是同一个问题但排查时容易混在一起先确认网络可达再谈解析。3. 可复制配置OpenClaw 对接 Ollama 的完整片段这一节给你可以直接抄的配置。先确认 Ollama 在跑并且模型已拉取ollama list # 期望输出包含 # qwen2.5-coder:0.5b xxxxxxxx 0.5B ...如果没有先拉取ollama pull qwen2.5-coder:0.5b然后确认 Ollama 服务监听正常curl http://127.0.0.1:11434/api/tags # 返回 JSONmodels 数组里能看到 qwen2.5-coder:0.5b接下来是 OpenClaw 的启动命令。你原来的写法是openclaw onboard --non-interactive --auth-choice ollama \ --custom-base-url http://127.0.0.1:11434 \ --custom-model-id qwen2.5-coder:0.5b \ --accept-risk openclaw gateway run问题很可能出在--custom-base-url少了/v1或者 OpenClaw 的 Ollama provider 期望的是原生地址但解析器按 OpenAI 流式读。建议改成显式带/v1的兼容地址试一次openclaw onboard --non-interactive --auth-choice ollama \ --custom-base-url http://127.0.0.1:11434/v1 \ --custom-model-id qwen2.5-coder:0.5b \ --accept-risk openclaw gateway run如果 OpenClaw 支持配置文件方式找到它的 settings 文件通常在用户目录下的.openclaw/或项目config/里写入类似下面的 JSON。注意路径和字段名以你本地实际版本为准这里给的是结构参考{ providers: { ollama-local: { type: openai-compatible, baseUrl: http://127.0.0.1:11434/v1, apiKey: ollama, models: [ { id: qwen2.5-coder:0.5b, name: Qwen2.5 Coder 0.5B Local, contextWindow: 32768, maxTokens: 2048, stream: true } ] } }, defaultModel: qwen2.5-coder:0.5b }如果你要加云端兜底再加一个 provider{ providers: { taotoken-cloud: { type: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: 你的_API_Key, models: [ { id: 按平台文档填写的模型ID, name: Cloud Code Model, stream: true } ] } } }三件套对照表填错任何一项都会导致无输出项目本地 Ollama云端兜底Base URLhttp://127.0.0.1:11434/v1https://taotoken.net/apiAPI Key任意非空如ollama控制台生成的 KeyModel IDqwen2.5-coder:0.5b平台文档中的模型 ID配置改完重启 gateway。注意openclaw gateway run是前台运行日志直接打在终端方便你观察。如果你之前是后台跑的先停掉旧进程再起避免端口占用导致新配置没生效。还有一个关键开关stream。如果 OpenClaw 的流式解析器对 Ollama 的 NDJSON 支持不好可以先把stream设为false让它走一次性返回看能不能出内容。如果能出说明就是流式解析的问题再回头单独处理流式。这个二分法能帮你快速缩小范围。4. 验证请求curl 直连模型与查看日志定位问题排查的核心动作是「绕过 OpenClaw直接看 Ollama 返回的原始字节」。先测 OpenAI 兼容路径curl -N http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-coder:0.5b, messages: [{role: user, content: 写一个 Python 快排}], stream: true }-N关闭缓冲你能看到流式返回。正常的话每一行是data: {...}里面choices[0].delta.content会逐字出现。如果这里正常说明 Ollama 的兼容接口没问题问题在 OpenClaw 的解析或配置。再测原生路径curl -N http://127.0.0.1:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2.5-coder:0.5b, messages: [{role: user, content: 写一个 Python 快排}], stream: true }原生路径返回的是 NDJSON每行一个完整 JSON字段是message.content不是choices[0].delta.content。如果你发现 OpenClaw 填的是不带/v1的地址它很可能打到了这个原生接口而解析器却在找choices自然读不到内容前端就一直空着。这就是「有响应无输出」最常见的根因。接着看 OpenClaw 的日志。前台运行时终端会打印请求和响应。重点找这几类信息请求打到了哪个 URL、响应状态码、有没有解析异常、有没有stream相关的报错。如果日志里显示请求成功但解析后内容为空基本可以确认是字段不匹配。同时开一个终端看 Ollama 日志# Linux/macOS tail -f ~/.ollama/logs/server.log # Windows 在 %LOCALAPPDATA%\Ollama\ 下找日志Ollama 日志会显示收到的请求路径和模型加载情况。如果它显示POST /api/chat而不是/v1/chat/completions那就印证了路径问题。还有一个验证上下文拼接的方法发一条带系统提示和多轮历史的请求看模型是否只回了空。如果单轮能回、多轮不回可能是 OpenClaw 把 messages 数组拼成了 Ollama 不认识的格式比如把system角色放错位置或者把 content 拼成了数组。用 curl 模拟同样的 messages 结构对比返回就能定位是拼接问题还是解析问题。实测下来把stream先关掉、Base URL 带/v1、模型 ID 带完整 tag这三步能解决大部分无输出。如果还不行就把 curl 的原始返回和 OpenClaw 日志贴出来对比字段问题一定在两者的差异里。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth按报错对照排查效率最高。401 Unauthorized本地 Ollama 一般不校验 Key但如果你在 OpenClaw 里把apiKey留空某些版本的 OpenAI 兼容客户端会拒绝发送请求。填一个非空字符串比如ollama即可。如果是云端 provider401 说明 Key 错了或没带Authorization: Bearer检查控制台生成的 Key 是否完整复制。local proxy failed / connection refusedOpenClaw 连不上127.0.0.1:11434。先curl http://127.0.0.1:11434/api/tags确认 Ollama 在跑。如果 OpenClaw 跑在容器或 WSL 里127.0.0.1指向的是容器自身要改成宿主机 IP或者给 Ollama 设OLLAMA_HOST0.0.0.0后重启。Windows 上还要检查防火墙有没有拦 11434 端口。reading choices / cannot read property choices of undefined这是最典型的流式解析报错。OpenClaw 按 OpenAI 格式读choices但实际拿到的是 Ollama 原生 NDJSON没有choices字段。解决办法是把 Base URL 改成带/v1的兼容地址让 Ollama 返回 OpenAI 格式或者确认 OpenClaw 版本是否支持 Ollama 原生 provider选对 provider 类型。OAuth / token exchange failed如果你在 OpenClaw 里选了需要 OAuth 的 provider 类型但实际接的是本地 Ollama就会走到 OAuth 流程然后失败。把 provider 类型改成openai-compatible或ollama不要选带 OAuth 的云端类型。模型找不到 / model not found模型 ID 写成qwen2.5-coder少了:0.5b或者大小写不一致。Ollama 的模型 ID 区分 tag必须和ollama list输出完全一致。有响应但内容为空字符串请求通了返回 200但content是空。常见于maxTokens设得太小比如 1或者上下文窗口超限被截断。把maxTokens调到 2048 以上contextWindow按模型实际能力填。CC Switch / Cline MCP / Codex auth.json 场景如果你是在这些工具里配置同样要写全三件套。Base URL、API Key、Model ID 一个都不能少。Cline 的 MCP 配置里Ollama 的 Base URL 用http://127.0.0.1:11434/v1Model ID 用qwen2.5-coder:0.5b。Codex 的auth.json里如果配了自定义 provider也要保证base_url带/v1否则同样读不到choices。排查顺序建议固定成curl 直连 → 看原始字段 → 核对 OpenClaw 的 Base URL 和 provider 类型 → 看日志报错 → 关流式二分。按这个顺序走基本不会卡住。6. 语义一致 CTA把本地与云端入口统一起来本地 Ollama 跑qwen2.5-coder:0.5b的好处是零成本、离线可用缺点是 0.5B 的代码能力有限复杂任务容易答非所问。我的做法是本地做日常补全和简单问答遇到难题切到云端模型。OpenClaw 的 provider 机制正好支持这种切换你只需要在配置里保留两个 provider用的时候改defaultModel就行。云端通道的接入信息Base URL 用https://taotoken.net/apiKey 在https://taotoken.net/console生成模型 ID 按平台文档填。想先试试模型对话效果可以直接打开https://taotoken.net/models体验。如果你打算长期用 OpenClaw 做编码助手、或者接 Agent 工作流可以看看 Coding Plan地址是https://taotoken.net/coding-plan。接入文档在https://taotoken.net/docAPI Key 管理在https://taotoken.net/api-keys。用 Claude Code 的话Anthropic 兼容入口在https://taotoken.net/claude-code-anthropic。回到你的问题最可能的修复就是把--custom-base-url从http://127.0.0.1:11434改成http://127.0.0.1:11434/v1然后重启 gateway。改完先用 curl 确认/v1/chat/completions返回的是choices结构再在 OpenClaw 里发一条消息。如果还不吐字把stream设为false试一次能出内容就说明是流式解析去 OpenClaw 的 issue 里搜ollama stream找对应版本的补丁或配置项。这套流程走下来你那个「有去无回」的页面应该就能正常出字了。