Version line

v2 — Go rewrite (1.x), main-v2 (active development)

Exact version

1.3

What happened?

问题描述

在 Desktop 的聊天模型选择器中，当前会显示 TTS / STT / ASR 等音频模型。

这些模型不是普通 Chat / Agent 对话模型，但现在会和聊天模型混在同一个列表里，用户可能误选为默认聊天模型，导致对话或 Agent 调用失败。

Steps to reproduce

1. 打开 Desktop 客户端
2. 进入模型选择器 / 默认模型下拉框
3. 配置或选择 Mimo Provider
4. 打开模型下拉列表
5. 观察模型列表

当前表现

模型列表中除了正常聊天模型外，还出现了音频相关模型，例如：

• mimo-v2.5-asr
• mimo-v2.5-tts
• mimo-v2.5-tts-voice...

这些模型会和 mimo-v2.5、mimo-v2.5-pro 等聊天模型一起显示在聊天模型选择器中。

期望表现

聊天模型选择器应该只显示可用于 Chat / Completion / Agent 对话的模型。

应过滤掉：

• ASR / STT 模型
• TTS 模型
• speech 模型
• audio-only 模型
• transcription 模型
• voice-only 模型

影响

如果用户误选这些音频模型作为默认聊天模型，可能导致：

• 聊天请求失败
• Agent 执行失败
• Provider 返回模型能力不支持
• 模型列表混乱，用户难以区分哪些模型能用于对话

建议修复方向

在 Provider 模型发现或模型列表归一化阶段增加模型能力过滤。

聊天模型选择器只应保留 chat / completion / reasoning / code / text generation 类型模型。

音频模型应从聊天模型列表中过滤掉，尤其是模型名或能力中包含以下关键词的模型：

• tts
• stt
• asr
• speech
• audio
• transcription
• voice

同时，自动刷新模型列表时也应使用同样的过滤逻辑，避免音频模型重新进入聊天模型列表。

补充复现结果：

如果选择 mimo-v2.5-tts 作为聊天模型并发送普通消息，会直接触发 HTTP 400：

Parameter Incorrect: parameter messages[0] system role is not allowed for TTS model

因此这不是单纯的列表展示问题，而是会实际导致聊天请求失败。

Steps to reproduce

1. 打开 Desktop 客户端
2. 进入聊天页面或默认模型配置区域
3. 打开聊天模型下拉列表
4. 选择 Mimo Provider
5. 观察模型列表
6. 可以看到 mimo-v2.5-asr、mimo-v2.5-tts、mimo-v2.5-tts-voice... 等音频模型也出现在聊天模型列表中
   补充：CLI 侧也存在同类问题。因此修复不应只在 Desktop 前端下拉框过滤，最好在 Provider 模型发现 / 模型归一化的共享层处理，保证 Desktop 和 CLI 的聊天模型候选列表一致。

OS / platform

windows11

Relevant logs or output

Malformed request (HTTP 400): the request body was rejected. This is likely a bug — please report it if it persists.
data:{"error":{"code":"400","message":"Param Incorrect","param":"messages[0] system role is not allowed for TTS model","type":""}}