issue: Mentioning a workspace model whose ID contains a space shows raw mention markup in channels

快速结论：这个报错通常出现在 Open WebUI 频道或频道子线程里，当被 @ 的工作区模型（workspace model）ID 含有空格时，消息渲染器识别不了这条 mention，于是把原始标记当成普通文本显示出来；模型本身仍会正常回复，说明只是前端显示层的问题。优先检查模型中是否存在带空格的 ID。

适用环境：Open WebUI v0.11.3，dev 检出至 8383bc7（后续修复版本为 8a19e2f867063256bb2836649e2fe80af41ef748）；安装方式为 Git Clone + Vite dev server；操作系统 Ubuntu 26.04.1 LTS x64；浏览器 Firefox；Ollama 0.33.3。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的方向是：服务端在 dev 提交 8a19e2f 后已拒绝在创建和更新时使用含空格的模型 ID，因此可优先尝试把出问题的 workspace model ID 改成不含空格的形式（例如把空格替换为连字符等非空白字符），并迁移或重建旧条目。

注意事项：上述处理只针对“ID 含空格”这一种触发条件；Issue 说明渲染器现在接受任何非空白 ID（包括括号），但含空白字符的 ID 仍会保持原始文本形式，且服务端已不再接受这种 ID。示例中带空格的 ID 来自用户自己的工具，并非 Open WebUI 默认生成，因此不是所有用户都会遇到。升级或改名后，历史消息里的旧 markup 不会自动重渲染。

问题场景

在 Open WebUI 的频道（channel）中，或在频道的子线程（thread panel）里，通过 @ 选择并提及一个 workspace model 后发送消息。如果该 workspace model 的 ID 中含有空格，发送出去的消息不会显示成带模型标签的 mention chip，而是原样展示存储的 mention 标记文本。示例中模型是一个基于 GGUF 的 workspace model，ID 为 hf.co/unsloth/Qwen3-30B-A3B-Instruct-2507-GGUF:UD-Q4_K_XL (Workspace)，其中在括号词语前有一个空格。服务端仍能正确解析该 mention 并让模型作答，因此功能上是通的，只有显示错误。提及 base model 时 chip 能正常渲染。

报错原文

issue: Mentioning a workspace model whose ID contains a space shows raw mention markup in channels

The sent message shows the full stored markup, the angle brackets, the ID, the pipe and the label, as plain text.

<@M:hf.co/unsloth/Qwen3-30B-A3B-Instruct-2507-GGUF:UD-Q4_K_XL (Workspace)|Qwen 3 30B A3B 2507 (UD-Q4_K_XL)> Show me a few example code snippets.

Issue 报告中没有日志输出（Nothing is logged），因此没有服务端报错栈可保留。

原因分析

最可能的原因是服务端和浏览器端对 mention ID 的解析规则不一致。服务端把 mention 的 ID 读作管道符 | 或右尖括号之前的全部内容，所以即使 ID 含空格也能定位到模型，这也解释了为什么模型可以正常回复。而浏览器端的消息渲染器只接受字母、数字、点、连字符、冒号和斜杠组成的 ID，遇到含空格的 ID 就无法匹配，于是把原文按纯文本输出。消息输入框的草稿恢复逻辑使用了同一套较窄的规则，所以带该 mention 的已保存草稿恢复后也会变成原始文本。Issue 同时说明，后续修复把行为收敛为：渲染器接受任意非空白 ID（包含括号），而服务端在创建和更新时直接拒绝含空白的模型 ID，即含空白 ID 不再被允许存在。

环境排查

确认 Open WebUI 版本：是否仍为 v0.11.3 或 dev 8383bc7 及之前的版本，是否已包含 8a19e2f 之后的变更。
确认安装方式：Git Clone 加 Vite dev server，还是其他安装方式，不同安装方式获得的代码版本可能不同。
确认触发提及的 workspace model ID 是否包含空格或其他空白字符；示例中空格位于 ID 末尾的括号词语前。
确认在 base model 上提及是否正常渲染，用于区分是通用渲染问题还是仅含空格 ID 的问题。
确认触发位置：频道正文与频道子线程是否表现一致。
确认浏览器环境（Issue 中为 Firefox），但不必然与浏览器有关。
Issue 中未提供 Python、CUDA、PyTorch、显卡及依赖版本信息，这些项目没有证据，无需作为本问题的排查项。

解决步骤

在 workspace model 列表中定位被 @ 的模型，检查其 ID 是否包含空格或其他空白字符。
如果 ID 含空格，优先尝试将其改为不含空白的 ID，例如把空格替换为连字符，或重新创建该 workspace model 再使用新 ID。
更新使用该模型的频道消息：旧消息中的 mention markup 仍然按原始文本存储，替换 ID 后需要重新发送或重新编辑以生成新的 mention。可优先尝试，但 Issue 未逐条验证这一操作的完整效果。
如果升级到包含 8a19e2f 提交的版本，创建和更新模型时会拒绝含空白的 ID，需要同时处理实例中已存在的旧含空格条目，否则这些旧模型仍可能以原始 markup 形式出现。
Issue 中提到示例中带空格的 ID 来自用户自己的工具，该工具已改为生成 -workspace 后缀并迁移旧条目；如果你有类似的自建生成工具，可参考这一做法，但这不是 Open WebUI 官方提供的迁移命令。

验证方法

用修改后的无空格 ID 的 workspace model 在频道中重新发送一条带 @ 的消息，确认显示为带模型标签的 mention chip 而不是原始 markup，并且模型仍然正常回复。再在同一频道的子线程中重复验证一次。同时可在输入框中保存含该 mention 的草稿，刷新后确认草稿恢复后仍显示为 chip。对于历史消息，如果仍显示原始 markup，需要确认是否使用了无空格 ID 重新发送。