WorkBuddy报400protocol，本质原因是代理环境变量污染了API请求路由。 400protocol报错的本质：客户端读取协议配置失败 “400 Cannot read properties of undefined (reading ‘protocol')”——WorkBuddy在发起API请求时，试图读取某个对象的protocol属性，但该对象未定义。这意味着客户端获取到的配置信息不完整或格式异常，请求无法正常发送。 模型API要求完整的HTTP协议协商，任何环节的配置异常都会导致请求被服务端拒绝。 积分能用≠模型API正常：两套通道的差异 积分查询走的是WorkBuddy内部服务接口，通信路径短、不依赖外部模型API。而模型调用需要客户端向模型服务商（如DeepSeek、Kimi等）发起请求，涉及完整的HTTP协议协商。 代理环境变量一旦介入，WorkBuddy构建请求时读取到的协议配置就可能被污染，导致请求格式异常。 高频诱因：代理环境变量残留 根据社区同类问题的排查经验，核心诱因是Shell配置文件中残留的代理环境变量（HTTP_PROXY/HTTPS_PROXY）。很多用户日常使用Clash、Surge等代理工具，关闭后环境变量未同步清理，WorkBuddy发起API请求时仍尝试通过失效代理路由，触发400错误。 部分用户还反馈从v4.10.4升级到v4.20.4后出现此问题——新版本对请求参数格式更严格，代理残留更容易暴露。 排查顺序应为：先代理变量，次版本兼容性，后自定义模型配置。 排查优先级：代理环境变量残留（最高频）→ 版本升级兼容性 → DeepSeek V4新协议适配 → 自定义模型配置错误。

代理残留是最常见原因，纯本地操作不受影响，积分功能正常。 高频触发场景 场景一：代理环境变量残留（占比最高）。关闭Clash、Surge等代理工具后，~/.zshrc或~/.bash_profile中的HTTP_PROXY/HTTPS_PROXY变量未清理，WorkBuddy调用模型时仍尝试通过失效代理路由——代理地址不可达或请求格式异常，服务端直接返回400。 场景二：DeepSeek V4模型配合工具调用。deepseek-v4-pro和deepseek-v4-flash默认开启思考模式，API返回中包含reasoning_content字段。触发工具调用时该字段需在后续请求中完整回传，WorkBuddy尚未完成对该字段的适配，第二轮API请求参数校验失败触发400。 场景三：自定义模型配置字段错误。自定义模型时name填成了API不匹配的值，或useCustomProtocol设为true但未补齐完整请求路径，首次调用即触发400。 场景四：版本升级后兼容性变化。从v4.10.4升级到v4.20.4后，新版本对请求参数格式要求更严格，旧版本中被容忍的配置偏差变成了硬性错误。 不会触发400protocol的场景 纯本地操作（文件处理、工作空间管理、任务看板）不涉及外部API调用，不受代理环境或协议问题影响。积分查询和领取走WorkBuddy内部服务接口，不经过模型API，即使模型调用报400，积分功能仍正常工作。使用内置模型且不触发工具调用时，触发400protocol的概率也较低。 排查优先级建议：代理环境变量（占绝大多数）→ DeepSeek V4+工具调用 → 自定义模型配置 → 版本升级兼容性。