B.5 管理与排查接入
前面我们讲了怎么把自己想用的模型接进 WorkBuddy，从选择平台、填写配置，到发送消息、处理文件，整个过程已经走了一遍。
前面我们讲了怎么把自己想用的模型接进 WorkBuddy，从选择平台、填写配置，到发送消息、处理文件，整个过程已经走了一遍。
但大家用的平台和模型不一定相同。你自己配置的时候，可能测试连接就没通过；也可能已经用了一段时间，后来发消息又报错了。屏幕上出现一串数字和英文，这时候就容易拿不准：哪里填错了？是不是没钱了？还是模型那边出了问题？
接入外部模型以后，WorkBuddy 要把请求交给你选的平台处理。能不能正常使用，既跟配置有关，也跟平台的账户余额、请求限制和服务状态有关。所以，报错以后要先弄清楚是哪一类问题，再决定改哪里。
这一节就是留给大家查问题的。遇到报错，再回来找到相应的说明；现在用着没问题，就先跳过，不用专门记这些数字。
B.5.1 报错以后，先看什么
报错里的数字叫“错误码”，后面通常还会跟着原因说明。数字可以帮我们找到大致方向，但具体哪里出了问题，还要看后面那段话。
比如下面这张图，我们看输入框上方的报错提示。
图里圈出来的是 403，旁边写着“鉴权失败”，并提示检查 API Key、模型 ID 和接口地址。看上面一句“当前服务异常”还不够，下面这条提示才给出了具体的检查方向。
再看一下出错的位置。是填完配置点“测试连接”时出错，还是消息发出去以后出错？是一直不能回复，还是文字能回、调用工具时才失败？把这个过程说清楚，我们才好往下查。
下面结合这张截图和 DeepSeek 官方记录的错误来说明。403 按图里的提示讲，其余错误码按 DeepSeek 的说明讲；用其他平台的，也要结合那个平台的具体提示来看。
| 屏幕上的错误码 | 先看哪一部分 |
|---|---|
| 400、422 | B.5.2，检查格式、参数和兼容问题 |
| 401、402，以及图中的 403 | B.5.3，检查账户与接入信息 |
| 429、500、503 | B.5.4，查看请求限制和服务异常 |
| 拿不准，或者处理后还是失败 | B.5.5，切换模型或带上信息求助 |
B.5.2 400、422：发过去的内容不符合要求
模型平台接收请求，也有自己的格式要求。配置里填的内容、软件传过去的参数，要符合它的要求，才能继续处理。
DeepSeek 的 400 表示请求格式有问题，422 表示参数不合法。遇到这两种提示，先看后面的说明有没有点名某个字段。它指出哪一项，就对照那一项查，不要把所有配置都重新填一遍。
需要改配置时，点击对话框里的模型名称，打开“配置自定义模型”。进去后能看到已经保存的模型列表，找到你正在使用的那条，再进入编辑。手动填写的字段怎么对照，回看 B.3 就可以。
这里要分清：有些内容是你在配置框里填的，有些是软件在请求过程中传过去的。看到一个不认识的字段，不代表你漏填了一个输入框。
比如，DeepSeek 官方记录过一种 400：带工具的请求没有正确传回思考内容。相关字段叫 reasoning_content。这涉及软件和模型之间的信息传递，普通用户不用自己写代码补它。
你的提示也提到这类字段，就保留完整报错，按 B.5.5 的方式求助。我们要核对的是具体兼容问题，不能光凭“400”就叫你重新买套餐。
确定是自己填错的内容，改好保存后，先发 B.4 那条简单的文字请求。能收到正常回复，再试文件任务。只有前一步恢复了，才继续看后一步。
B.5.3 401、402、403：账户与接入信息问题
外部模型平台要通过 API Key 识别你的账户，再按账户的余额或额度提供服务。所以，配置地址填好了，账户这边也要能正常使用。
看到 401，先看密钥。 DeepSeek 用这个提示表示密钥验证失败。回到模型配置，核对选中的供应商和填入的 API Key，确认你使用的是这个平台的密钥。修改后保存，再发一条简单消息，看是否恢复回复。
看到图里这种 403，按提示核对接入信息。 这张图显示的是自定义模型鉴权失败，要检查 API Key、模型 ID 和接口地址是否与所用服务的接入说明一致。它没有指出具体是哪一项错了，所以不能直接认定是密钥失效，更不能认定要充值。核对后还是失败，就保留这条提示和图里的 Trace ID（方便客服查找这次请求的编号），一起提交反馈。
看到 402，去看余额。 打开申请 API Key 的平台，进入账户的用量或余额页面。用 DeepSeek 的，就看 DeepSeek 平台上的 API 余额。
这里别看错地方：你在 WorkBuddy 里还有积分，不代表外部模型账户也有余额。先看清是哪个平台提示不足，再决定要不要补充费用，或者换回内置模型继续用。
如果账户显示正常，报错却一直没有消失，就把提示保留下来，联系这个平台的客服。不要为了试错反复充值。
B.5.4 429、500、503：请求受限或服务异常
有时候配置一直没改，之前也能用，后来却突然失败了。除了账户问题，还要看是不是请求太频繁，或者平台那边暂时处理不了。
429 是请求频率受限。 平台觉得请求来得太快，这时候再连续点击发送，只会继续增加请求。先减少同时发出的任务，过一会再试。
500 是服务端发生错误，503 是服务端繁忙。 这两类提示先按服务异常处理，稍后重试。它们不能证明你把密钥填错了，也没有一个固定的等待时间能保证恢复。
再试的时候，先发一条简单消息。能收到回复，说明这条请求已经成功；然后再继续原来的工作。一直报错，就记下发生时间和完整提示，交给服务商支持排查。
手头的事情着急，也可以先切回内置模型。点击输入框里的模型名称，在列表中选一个内置模型。选完看一下输入框，显示的名称已经换过来了，再发送任务。
原来的任务涉及文件操作，就先打开结果文件夹，看看已经生成了什么。把完成到哪一步说清楚，再让模型继续，别直接把整个任务重跑一遍。
B.5.5 处理后还是不行，怎么求助
按前面的方法处理过，还是报错，先把情况留完整。你不用自己判断出最终原因，只要让帮你看的人知道发生了什么。
把完整报错截图发到社群，再说明用的是哪个平台、哪个模型、WorkBuddy 是什么版本，以及在哪一步失败。是刚配置就不能用，还是之前用过、现在不行了，也说一下。截图里记得遮住完整 API Key。
只有一个错误码，我们还要来回问；把这些背景带上，就能直接沿着失败的那一步查。表里没有的错误，也按这个方式发过来，不用硬套前面的解释。
暂时排查不好，可以先换一个可用模型继续做事，原来的配置保留着。确定配置填错了，再进入模型设置编辑；确定以后不再使用，才删除那条配置。
这里还有一个区别：在 WorkBuddy 里删除模型配置，只是把这条配置移除了。要让 API Key 本身失效，还要回服务商平台撤销密钥。
以后再遇到报错，你就回来对照这一节看。能明确处理的，处理后用简单任务验证；拿不准的，带上完整提示和出错过程，我们一起看。