最近好几个朋友来问我同一个问题WorkBuddy 接入了自定义模型配置也保存了但发消息过去就是死活不回复。有人以为是模型挂了有人以为是网络问题还有人直接把项目晾了两天没动。其实大部分情况下问题的根源根本不在模型本身而是接入链路里某个环节“静默失败”了。今天我把这套排查思路完整整理出来按顺序走一遍大多数问题十分钟内就能定位到。这篇内容适合谁看只要你是用 WorkBuddy 或类似工具接入自建模型、内部模型网关、开源模型的开发者或运维并且遇到“配置正常但对话无响应”的情况这篇文章可以直接当排查手册用。我尽量用现场实操的记录方式来写结合常见的 HTTP 状态码、日志现象和设置项帮你在不求助别人的情况下把问题找出来。1. 先判断问题类型是完全没响应还是“回了个寂寞”排查最忌讳一上来就改配置。先搞清楚现象属于哪一类方向才不会跑偏。我建议把“不回复”拆成两种形态一种是从界面看消息发出去了但 WorkBuddy 一直是“转圈”状态迟迟没有输出另一种是界面显示成功甚至显示已获取到回复但内容为空或者说只返回了一两句固定话术根本不是模型生成的内容。这两种情况的排查路径完全不一样。1.1 连请求都没发出去的典型表现如果你发送消息后WorkBuddy 这边一直显示“等待响应”或直接超时而且模型端没有任何访问记录那大概率是请求根本没到模型服务。这种情况常见原因有三类模型地址填错、鉴权信息没生效、请求被 WorkBuddy 内部拦截或路由到了错误的后端。判断方法很简单去模型服务所在机器上看访问日志。不管你是用 Nginx 转发、自建网关还是直接暴露服务端口都会有一条 access log。如果日志里连一条对应时间的记录都没有那就说明请求卡在 WorkBuddy 这一侧模型端是无辜的。1.2 请求发出去了但模型没有返回有效内容另一种情况更迷惑人模型端日志显示请求到达了模型也确实生成了内容但 WorkBuddy 界面上就是没有回复。这种问题大多出在响应格式解析、流式传输处理或内容过滤上。比如模型返回了正常的 JSON但 WorkBuddy 期待的是另一种结构又比如模型按流式逐字吐出内容但 WorkBuddy 没有正确处理流式结束标记导致一直在等待。我把这种状态叫作“回了个寂寞”——服务端明明干了活用户却什么都没看到。遇到这种情况千万别急着重启模型服务先把响应体完整抓下来看两眼比盲试管用得多。2. 配置层排查90% 的问题出在“你以为你配对了”配置项是排查的第一站也是翻车率最高的地方。很多人习惯把模型服务的地址、密钥复制粘贴进去后就不再检查偏偏这些字段里藏着大量细节。我见过太多案例模型名少了个版本号后缀或者接口地址多了个斜杠导致请求直接 404。2.1 模型名称和接口地址一字之差就是天壤之别先讲模型名称。WorkBuddy 在发起请求时会把你在配置页填写的模型名原样放进请求体里。这个名称必须和模型服务端注册的名字完全一致包括大小写、版本号、前缀后缀。比如你在模型服务里部署时叫“my-model-v2”配置里填成“my-model”服务端会直接报 model not found。接口地址的坑更多。绝大多数自建模型服务都习惯把接口挂在一个路径前缀下比如http://127.0.0.1:8000/v1/chat/completions你在 WorkBuddy 里填地址的时候有的配置项要求只填到根路径比如http://127.0.0.1:8000/v1程序会自动拼接/chat/completions有的配置项要求填完整路径比如http://127.0.0.1:8000/v1/chat/completions。这两种写法不能混用。填错的话请求要么打到不存在的路径上返回 404要么路径里出现双重拼接比如/v1/v1/chat/completions直接报路由错误。我建议的做法先在浏览器或命令行里用 curl 验证一次你填写的完整地址确认能通再填进 WorkBuddy。如果命令行都不通那 WorkBuddy 再怎么配都是白搭。2.2 API 密钥与鉴权方式不是填了 key 就一定认自定义模型服务的鉴权五花八门有的用静态密钥有的用动态令牌还有的干脆不需要鉴权。WorkBuddy 适配的是常见 API 鉴权方式也就是在请求头里带一个Authorization: Bearer 你的密钥。但如果你接的是内部自建网关网关可能要求的是自定义请求头比如X-API-Key或者TokenWorkBuddy 不支持自定义请求头那就会导致鉴权失败。鉴权失败的表现往往不是直接报 401有的模型服务为了安全会返回 200 但内容为空或者返回一个通用错误页。这就很坑了。排查时可以直接用 curl 模拟一次带鉴权的请求对比你在 WorkBuddy 里填的密钥是不是同一个能省很多时间。提示千万不要把测试用的临时密钥和生产密钥混在一起填。密钥里带空格、换行符是常见问题粘贴的时候容易带进去肉眼又看不出来。2.3 参数格式与模型兼容性多余字段也会让模型“装死”即使地址和密钥都正确请求还是有可能失败。原因可能是 WorkBuddy 默认会在请求体里带上一些参数比如temperature、top_p、max_tokens、frequency_penalty等。如果模型服务端不支持这些参数或者支持的取值范围不一样服务端可能直接拒绝请求也可能忽略但行为异常。比如你配置了temperature: 0.8但模型服务要求这个参数必须在 0 到 1 之间本来 0.8 没问题但如果 WorkBuddy 发送的是 0.8而模型服务端默认只支持 0 到 1那也没事。更多时候问题出在 WorkBuddy 发送了某个模型端完全没定义的字段比如logprobs或n部分严格实现的服务端会直接 400。我的建议先关掉 WorkBuddy 设置里所有的“高级参数”只保留最基本的模型名和消息内容跑一次测试。通了之后再逐步打开高级参数看到底是哪一个字段导致的问题。这个方法百试百灵。3. 接口协议兼容性为什么模型“明明单独调用正常”却接入失败到了这一步你可能会遇到一个非常费解的现象用 curl 直接调用模型服务一切正常回复又快又完整但在 WorkBuddy 里配置同样地址同样密钥依然不回复。这就说明配置层没问题问题出在协议兼容层。3.1 聊天补全协议的结构差异WorkBuddy 面向的是业界通用的聊天补全协议。这个协议有固定的消息结构一个基础请求长这样{ model: my-model, messages: [ {role: user, content: 你好} ], stream: false }大部分自建模型服务都实现了这个协议但实现程度差异很大。有的只实现了最基础的chat/completions端点没实现models列表端点有的对messages里的角色字段要求很严格比如要求角色名是human和assistant而不是user和assistant还有的模型服务对content类型有要求比如只接受字符串不接受数组形式的多段内容。WorkBuddy 是按照标准协议来发请求的它默认发的就是role: user、content为字符串。如果模型端不认这个格式返回 400 或 422WorkBuddy 就会直接判定为请求失败。有的模型服务更离谱遇到不认识的字段直接忽略但把整个响应当成空内容返回表现出来就是不回复。注意在对接任何自定义模型之前先去读一遍模型服务的接口文档确认它支持的是不是标准聊天补全协议。如果模型服务只提供了原始的文本生成接口没有做协议转换层那接入 WorkBuddy 前必须自己写一个适配层否则后面所有排查都白费。3.2 流式输出stream处理耐心耗尽与等不到结尾流式输出是“不回复”问题的高发区。WorkBuddy 默认会尝试用流式方式接收模型的回复也就是模型生成一段内容就发送一段。如果你在 WorkBuddy 配置里打开了流式开关但模型服务端没有按流式格式返回数据就会出问题。具体表现是这样的WorkBuddy 发起的请求里带有stream: true模型服务端收到后如果它不支持流式有的会忽略这个字段直接把完整的 JSON 一次性返回来有的会报错。WorkBuddy 如果一直在等流式数据的分隔标记而收到的却是普通 JSON它会一直等下去直到超时。用户看到的就是“转圈转到天荒地老”。还有一种情况是模型端确实返回了流式数据但格式不标准。标准的流式响应每个数据块以data:开头以双换行符结束最后以data: [DONE]结尾。有些自建模型服务没有做完整实现丢掉了结束标记WorkBuddy 就一直等不来“结束”同样表现为不回复。排查方法很简单打开 WorkBuddy 配置把流式开关关掉再发一次消息。如果立刻正常回复那问题就在流式处理上。要么让模型服务端修复流式实现要么在 WorkBuddy 侧关闭流式功能。3.3 工具调用与消息角色的兼容性暗坑如果你的 WorkBuddy 里配置了工具调用、插件或者技能市场那问题可能会更隐蔽。工具调用在请求里表现为一个tools字段内容是一段函数定义列表。模型服务端收到带tools的请求后如果支持工具调用会返回一个tool_calls字段表示它想调用某个工具。如果 WorkBuddy 配置了工具但模型服务端不支持或者两边函数定义的 JSON Schema 格式不一致就会出现 WorkBuddy 等模型回复、模型却在等工具结果的情况最后双方都“静止”了。我的踩坑经历是模型服务端虽然号称支持工具调用但它的返回格式里tool_calls的字段名多了一个下划线。WorkBuddy 解析不到就当成了没有工具调用意图继续等模型输出正文。模型端以为自己已经给出了工具调用指令就不会再生成正文了。两边互相等用户看到的就是不回复。遇到这种情况最快的处理方案把 WorkBuddy 里的工具功能全部关掉。如果关掉后恢复正常说明就是工具调用兼容性的问题。这时候再逐个排查工具定义格式而不是在那里干瞪眼。4. 运行时链路排查从日志到实测的全流程验证如果配置和协议都检查过了还是不行就进入链路排查阶段。这个阶段的核心思路是确定“请求到底断在哪一环”。我习惯把它分成三步看 WorkBuddy 日志、看模型端日志、用命令行还原请求。4.1 先从 WorkBuddy 的请求日志开始WorkBuddy 一般都有日志开关打开后会在后端记录每次请求的详细信息包括请求时间、目标地址、HTTP 状态码、响应耗时和错误信息。日志位置通常在安装目录下的logs文件夹或者通过管理界面查看。这一步要重点确认三件事请求有没有发出去、发到了哪个地址、收到的是什么状态码。如果请求压根没发出去日志里就不会有对应记录如果发到了错误地址日志里的 URL 路径会暴露问题如果状态码是 401 或 403则说明鉴权有问题如果是 500那就需要再深挖模型端。很多人跳过日志直接猜问题结果把配置改来改去越改越乱。4.2 用 curl 原样还原一次请求看日志只能确认 WorkBuddy 做了什么还不能定位模型端的情况。最直接的办法是用 curl 模拟 WorkBuddy 发出的请求。这样做的意义在于你可以人为控制每一个变量逐一验证。一个标准的验证命令长这样curl -X POST http://127.0.0.1:8000/v1/chat/completions \ -H Authorization: Bearer 你的密钥 \ -H Content-Type: application/json \ -d { model: my-model, messages: [ {role: user, content: 你好请回复这句话} ], stream: false, max_tokens: 512 }返回 200 且响应里有正常正文说明模型端完全正常问题出在 WorkBuddy 的配置或参数上返回 4xx则要仔细看错误信息里的具体原因返回 5xx说明模型服务内部异常。无响应或连接超时则要检查网络连通性和模型服务负载。我在实践中的一个心得curl 测试时尽量把请求体和 WorkBuddy 实际发的内容做到完全一致。有的模型服务对max_tokens这类参数很敏感你用别的值测试没问题不代表 WorkBuddy 发过去的那个值没问题。4.3 超时与重试机制慢被当成死自定义模型不像商业 API 那样几秒必回。如果你接的是本地部署的大模型尤其是单卡推理、没有做推理加速的情况下一个长问题的生成时间可能超过一分钟甚至三分钟。WorkBuddy 默认的连接超时和读取超时往往只有 30 秒左右超过就直接断开。断开之后用户看到的是请求失败或不回复但模型端其实还在吭哧吭哧地生成内容。更麻烦的是WorkBuddy 的自动重试机制会让你以为模型坏了。第一次请求超时重试再发一次模型端这时候可能正忙着处理上一次请求新请求只能排队结果又超时。几轮下来模型端的请求队列被堵死彻底表现为“不回复”。解决思路先确认模型生成一次回复的平均耗时然后去 WorkBuddy 配置里把超时时间调到明显高于这个数值。我一般会调到平均耗时的三倍以上。同时关掉自动重试或者把重试次数降到一次避免雪上加霜。5. 上下文与多轮对话的特殊坑模型不是哑了是被噎住了有时候单条消息测试一切正常一旦开始多轮对话模型就开始“假装沉默”。这种问题往往不在协议层而在上下文管理上。WorkBuddy 会把整个会话历史重新发送给模型服务每次对话携带的 token 数会越来越多当超过模型服务端的限制时问题就出现了。5.1 上下文窗口超限导致的“假死”模型服务端一般都有最大上下文长度限制。假设你的模型只支持 8192 token你们聊了几轮之后对话历史加上新消息已经超过 8500 token。按标准协议服务端应该返回一个显式的错误比如maximum context length exceeded。但有些模型服务实现得粗糙遇到超长输入时会直接返回空响应或者无限等待表现就是“不回复”。这种问题特别迷惑人因为从 WorkBuddy 界面上根本看不出是上下文超限。排查方法新建一个会话发一句简短的“你好”测试。如果新会话正常而长会话不回复十有八九就是上下文窗口被塞满了。解决思路在 WorkBuddy 设置里调低“最大历史轮数”或“最大历史 token 数”也可以定期清理旧会话。如果是自己的模型服务可以检查上下文窗口配置必要时对输入做截断处理。5.2 系统提示词与内容安全过滤的干扰自定义模型接入时很多人喜欢在系统提示词里写一堆复杂的角色设定。系统提示词会随每次请求一起发送给模型服务端。如果你的系统提示词触发了模型端的安全过滤机制某些模型服务会返回一个空回复或者是content: nullWorkBuddy 拿到后当成没有回复。还有一种情况是模型端本身挂了内容安全服务对某些关键词特别敏感。你测“你好”没问题但一旦消息里出现某些敏感词内容安全服务直接拦截返回空内容。这时候从模型端日志看请求是 200但响应体的choices[0].message.content是空字符串finish_reason却是content_filter。排查方法把系统提示词清空测试一次再换一句最简单的问候测试一次对照响应体里的finish_reason字段。看到content_filter就说明是内容安全机制在作怪跟 WorkBuddy 一点关系都没有。5.3 会话隔离与缓存改完配置为什么还是老样子还有一个经常被忽略的点WorkBuddy 的会话可能绑定了旧的模型配置。比如你从模型 A 换到模型 B修改了接入配置但用户端打开的会话还是挂在旧路由上。新配置只对新创建的会话生效。表现出来就是你改了配置再测发现依旧不回复以为改错了其实根本没走到新配置。另外一些代理层的缓存也可能导致问题。WorkBuddy 如果在网关层做了响应缓存同一个问题会直接返回缓存结果而不是重新请求模型。缓存结果如果是空内容那用户永远只会拿到空内容。遇到这种情况清缓存、新建会话、彻底重启 WorkBuddy 服务进程三件事一起做。我做接入调试的时候每次改完配置都会新建一个测试会话不在旧会话里反复试能省掉很多困惑。6. 常见问题速查表对着症状找原因排查经验积累下来我把高频现象整理成一张速查表方便你对照。这张表的价值在于大多数“不回复”问题并没有想象中复杂只是你还没把现象归到对应的类别里。现象可能原因快速处理方式界面一直转圈模型端无日志请求没到达模型服务检查接口地址、网络连通性、WorkBuddy 服务状态模型端有日志但返回 404接口路径错误或路径拼接重复用 curl 验证完整 URL 路径返回 401/403API 密钥错误或鉴权头不匹配核对密钥确认鉴权方式是否为 Bearer返回 400 或 422请求参数格式不兼容关掉高级参数逐步恢复测试返回 200 但内容为空内容被过滤或 finish_reason 异常检查系统提示词与安全过滤机制单条消息正常多轮后不回复上下文窗口超限清空会话或调低历史轮数上限打开流式后不回复关闭流式正常流式协议实现不兼容修复模型端流式实现或关闭 WorkBuddy 流式开关配置了工具/插件后不回复工具调用格式不兼容临时关闭工具功能测试请求超时模型端仍在计算超时时间设置过短调大超时阈值关闭自动重试修改配置后依然不回复会话路由缓存新建会话、清缓存、重启服务这张表不是万能的但覆盖了我在实践中遇到的九成场景。如果表格里没有你要找的答案那就老老实实按日志链路一步步查别跳过任何一步。7. 一点排查心得帮你少走弯路最后分享一个我反复验证过的工作方法接到“接入自定义模型后不回复”这类问题永远不要从“改配置”开始而是从“看日志”开始。先用日志确认请求有没有到达模型端再用 curl 还原请求最后才动手改设置。这个顺序能帮你绕开九成无效操作。再补充一个非常实用的测试习惯在 WorkBuddy 里准备一个专用的“测试模型”配置名字就叫test-mini只请求模型服务端最简单的模型只发一个字“好”。这个最小化配置专门用来验证链路是否通。链路通了你再切换成正式模型逐步打开流式、工具、长上下文等功能。这样做的好处是一旦出了问题你能立刻分辨是链路问题还是某个高级功能引入的问题而不会陷入“全都怀疑一遍”的泥潭。按照这个思路走一遍不敢说所有问题都能解决但至少能帮你把“不回复”这个问题缩小到一个可定位、可记录、可复现的范围内。剩下的就是耐心看响应体里的具体错误信息了。