Custom AI Translation / Dictionary fails with HTTP 400 on some third-party models (Android) and extracts thinking content (PC)

Issue 报告：Custom AI Translation / Custom AI Dictionary 调用部分第三方模型异常

标题

Custom AI Translation / Custom AI Dictionary 调用部分第三方模型异常：Android 返回 HTTP 400，PC 翻译提取到 thinking 内容，且不同模型表现不同

前置确认

• 我已经安装了最新开发版的 Koodo Reader，这个问题仍然存在
• 我已经搜索了已有的 issue 列表，没有找到类似的 issue
• 我已经阅读了 Koodo Reader 的帮助文档，仍然无法解决

操作系统或浏览器

• Windows 11（桌面版 / Electron）
• Android（移动版）

Koodo Reader 版本

最新开发版

我遇到的问题

在阅读器内选中文本，使用内置的 Custom AI Translation（自定义 AI 翻译）或 Custom AI Dictionary（自定义 AI 词典）功能，三方服务指向第三方大模型 API（硅基流动 / 日日新 / MiniMax）时出现异常。配置方式：先在 AI 设置中配置模型与用途，再在翻译/词典的三方服务中选择自定义 AI 翻译/词典。Chat Assistant（阅读助手对话）功能正常，仅翻译/词典受影响。

Android 版表现

• 硅基流动 / 日日新 返回：fail to build prompt, no user query found in messages（HTTP 400）
• MiniMax 返回：invalid params, chat content is empty (2013)（HTTP 400）
  • 完整响应：{"type":"error","message":"{\"type\":\"error\",\"error\":{\"type\":\"bad_request_error\",\"message\":\"invalid params, chat content is empty (2013)\",\"http_code\":\"400\"},\"request_id\":\"06c821fbb424cde2b2a3d7ef701e7a12\"}","xhrStatus":400,"xhrState":3}
• 使用不支持 thinking 模式的模型（如 Hunyuan-MT-7B）时报错

PC 版表现

• 使用不支持 thinking 模式的模型（如 Hunyuan-MT-7B）时，词典和翻译报错（提示"不支持 thinking"）
• 使用支持 thinking 模式的模型时，翻译功能提取到的是 thinking 内容（<think>...</think> 思考过程），而不是实际翻译结果

模型层面的差异观察

• DeepSeek：Android 和 PC 均正常
• Qwen（硅基流动）：正常
• Hunyuan-MT-7B（硅基流动）：异常
• SenseNova 6.7 Flash-Lite（日日新）：异常
• MiniMax M3：异常

复现步骤

1. 打开一本电子书
2. 选中一段文本
3. 点击弹出菜单中的「翻译」或「词典」
4. 在三方服务中选择「Custom AI Translation」/「Custom AI Dictionary」
5. 该服务指向硅基流动 / 日日新 / MiniMax 之一
6. 触发请求 → 出现上述异常

截图或录像（可选）

无

图书文件（可选）

无

---

分析结论（仅怀疑，不确证）

以下为基于源码与各模型官方文档的初步怀疑，供参考：

1. 怀疑与请求参数注入有关：chatStream 的请求体在 model / messages / stream 之外，还会根据 providerId 注入附加参数（如 thinking:{type:"disabled"} 或 enable_thinking:false）。不同模型对这些非标准参数的容忍度不同——部分模型（DeepSeek/Qwen）可能忽略未知参数而正常工作，部分模型（SenseNova/M3/Hunyuan-MT-7B）可能因校验严格而返回 400。这或许能解释为何同一功能在不同模型上表现差异。

2. 怀疑与 SSE 流式响应结构有关：各模型对"思考过程"的 SSE 字段名与内容时序并不统一：

   • DeepSeek 思考字段为 reasoning_content，且最终 content 有答案
   • SenseNova 6.7 Flash-Lite 官方文档显示思考字段为 reasoning，且思考阶段 content 为空、先输出大量 reasoning
   • Koodo 的流式解析目前只读取 delta.content，未处理思考字段。这可能导致：思考阶段拿不到内容（表现为空响应 / chat content is empty），或某些模型把思考内容放进 content 而被当作答案（表现为提取到 thinking 内容）

3. 怀疑请求格式在部分模型上不被接受：Hunyuan-MT-7B 是纯翻译模型，DeepSeek/Qwen 是通用对话模型，它们在输入格式预期上可能有差异；MiniMax M3 是推理模型且接口/header 与常规 OpenAI 兼容端点可能略有不同。

参考资料（可对照各模型格式）

各模型官方文档：

• OpenAI（GPT 系列）：https://platform.openai.com/docs/api-reference/chat （reasoning_effort 参数）
• DeepSeek：https://api-docs.deepseek.com/ （reasoning_content 字段，无请求侧 thinking 参数）
• Grok / xAI：https://docs.x.ai/docs/api-reference （thinking:{type} 参数）
• SenseNova（日日新）：https://github.com/OpenSenseNova/SenseNova6.7/blob/main/API.md （SSE 思考字段为 reasoning）
• MiniMax：https://platform.minimaxi.com/document/ChatCompletion （推理模型接口 / header 要求）
• 硅基流动（SiliconFlow）：https://docs.siliconflow.cn/cn/userguide/introduction
• Qwen（通义千问）：https://help.aliyun.com/zh/model-studio/getting-started/models （enable_thinking 参数）

开源 API 网关项目（逐家适配各模型请求/响应格式，可对照差异）：

• one-api：https://github.com/songquanpeng/one-api （源码 relay/channel/ 下按厂商分适配器）
• new-api：https://github.com/QuantumNous/new-api ；文档：https://docs.newapi.pro （推理模型深度支持，源码 relay/channel/ 下按厂商分适配器）
• LiteLLM：https://github.com/BerriAI/litellm （按模型分文件，如 litellm/llms/sensenova.py、minimax.py、deepseek/）
• Cherry Studio：https://github.com/CherryHQ/cherry-studio （多模型客户端，含各模型流式解析实现）
• OpenRouter：https://openrouter.ai/docs （多模型聚合 API）

期望官方检查的方向（仅建议，不限定方案）

• 建议核查翻译/词典请求体构造时，是否对不同 provider 一视同仁地注入附加参数，以及这些参数是否为对应模型官方支持的标准参数
• 建议核查流式响应解析时，是否兼容不同模型在思考字段（reasoning_content / reasoning）与 content 时序上的差异
• 建议对比 DeepSeek/Qwen（正常）与 SenseNova/M3/Hunyuan-MT-7B（异常）在请求参数与 SSE 响应上的实际差异，以确认根因