最近好几个朋友来问我同一个问题：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或者Token，WorkBuddy 不支持自定义请求头，那就会导致鉴权失败。

鉴权失败的表现往往不是直接报 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 或 422，WorkBuddy 就会直接判定为请求失败。有的模型服务更离谱，遇到不认识的字段直接忽略，但把整个响应当成空内容返回，表现出来就是不回复。

注意：在对接任何自定义模型之前，先去读一遍模型服务的接口文档，确认它支持的是不是标准聊天补全协议。如果模型服务只提供了原始的文本生成接口，没有做协议转换层，那接入 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: null，WorkBuddy 拿到后当成没有回复。

还有一种情况是模型端本身挂了内容安全服务，对某些关键词特别敏感。你测“你好”没问题，但一旦消息里出现某些敏感词，内容安全服务直接拦截，返回空内容。这时候从模型端日志看，请求是 200，但响应体的choices[0].message.content是空字符串，finish_reason却是content_filter。

排查方法：把系统提示词清空测试一次，再换一句最简单的问候测试一次，对照响应体里的finish_reason字段。看到content_filter就说明是内容安全机制在作怪，跟 WorkBuddy 一点关系都没有。

5.3 会话隔离与缓存：改完配置为什么还是老样子

还有一个经常被忽略的点：WorkBuddy 的会话可能绑定了旧的模型配置。比如你从模型 A 换到模型 B，修改了接入配置，但用户端打开的会话还是挂在旧路由上。新配置只对新创建的会话生效。表现出来就是你改了配置再测，发现依旧不回复，以为改错了，其实根本没走到新配置。

另外，一些代理层的缓存也可能导致问题。WorkBuddy 如果在网关层做了响应缓存，同一个问题会直接返回缓存结果，而不是重新请求模型。缓存结果如果是空内容，那用户永远只会拿到空内容。

遇到这种情况，清缓存、新建会话、彻底重启 WorkBuddy 服务进程，三件事一起做。我做接入调试的时候，每次改完配置都会新建一个测试会话，不在旧会话里反复试，能省掉很多困惑。

6. 常见问题速查表：对着症状找原因

排查经验积累下来，我把高频现象整理成一张速查表，方便你对照。这张表的价值在于，大多数“不回复”问题并没有想象中复杂，只是你还没把现象归到对应的类别里。

这张表不是万能的，但覆盖了我在实践中遇到的九成场景。如果表格里没有你要找的答案，那就老老实实按日志链路一步步查，别跳过任何一步。

7. 一点排查心得，帮你少走弯路

最后分享一个我反复验证过的工作方法：接到“接入自定义模型后不回复”这类问题，永远不要从“改配置”开始，而是从“看日志”开始。先用日志确认请求有没有到达模型端，再用 curl 还原请求，最后才动手改设置。这个顺序能帮你绕开九成无效操作。

再补充一个非常实用的测试习惯：在 WorkBuddy 里准备一个专用的“测试模型”配置，名字就叫test-mini，只请求模型服务端最简单的模型，只发一个字“好”。这个最小化配置专门用来验证链路是否通。链路通了你再切换成正式模型，逐步打开流式、工具、长上下文等功能。这样做的好处是，一旦出了问题，你能立刻分辨是链路问题还是某个高级功能引入的问题，而不会陷入“全都怀疑一遍”的泥潭。

按照这个思路走一遍，不敢说所有问题都能解决，但至少能帮你把“不回复”这个问题缩小到一个可定位、可记录、可复现的范围内。剩下的，就是耐心看响应体里的具体错误信息了。