issue: Realtime call: spoken replies reach the chat model as assistant messages starting with “[Historical voice assistant transcript…]”, an

快速结论：在 Open WebUI 的 Realtime 通话中，语音助手的历史回复会以 assistant 消息形式回灌给聊天模型，并带有 [Historical voice assistant transcript; not current task status] 前缀；部分模型（如本地 Qwen）会把这个前缀当作自己的输出格式模仿，从而复读前缀、跳过工具调用。优先排查并调整模型侧的 Voice Mode 提示词。

适用环境：Open WebUI v0.12.3（Docker，基于官方 v0.12.3 镜像并加一个构建补丁），dev 分支 079fb19e75 同样存在；系统 Debian 13（trixie），内核 6.12；聊天模型由 vLLM v0.30.0 本地提供，模型为 Qwen3.8-27B NVFP4，启动参数含 --tool-call-parser qwen3_xml --reasoning-parser qwen3 --enable-auto-tool-choice，请求中设置 chat_template_kwargs.enable_thinking: false；未使用 Ollama。

最快修复方案：暂无确认的一步修复方案；维护者说明这属于模型行为差异而非 Open WebUI 缺陷，可优先尝试在界面设置的 Voice call prompt 中说明该前缀的含义，并声明当前处于通话中。

注意事项：维护者在多个模型上无法复现，因此该现象不保证对所有模型出现；自定义 Voice Mode 提示词只能缓解模型误解前缀的问题，并不能从源头移除该前缀（该前缀由后端 backend/open_webui/utils/middleware.py 约 1963 行拼接生成）。前缀的移除属于源码层面的改动，Issue 中未给出已验证的补丁。

问题场景

用户在 Open WebUI 中启用 Realtime 通话，聊天模型由 vLLM 本地服务提供（Qwen3.8-27B NVFP4），并开启 Web 搜索与 fetch-URL 工具、关闭 thinking。在通话中先与语音模型进行两轮问答（这两轮回复被保存为 voice 消息），随后提出需要联网搜索的问题，例如“搜索并分析西班牙最近五次大选结果”。此时聊天模型没有调用 search_web，而是在约 0.5 秒内直接给出回答，且回答开头带有 [Historical voice assistant transcript; not current task status] 前缀；语音模型又把这段前缀连同回答朗读出来。同一通话中的下一次交接（4.7 秒）再次出现相同前缀，并给出编造的选举数据，同样没有触发搜索。

报错原文

[Historical voice assistant transcript; not current task status]
Let me look that up so I can give you the results of the last five general elections.

同一问题的相关描述另见 #32311 的评论（前缀被朗读）。

原因分析

根据 Issue 描述，process_messages_with_output 会把每条语音回复作为 assistant 消息发送给聊天模型，其内容由 [Historical voice assistant transcript; not current task status]\n 加上对应 transcript 拼接而成（代码位置 backend/open_webui/utils/middleware.py 约 1963 行，v0.12.3 与 dev 一致）。在关闭 thinking 的本地 Qwen 模型上，这种带固定前缀的 assistant 历史容易被模型当作自身既有的输出格式并加以模仿，于是在下一次交接时沿用同样前缀，并倾向于跳过工具调用、直接作答。

使用 dev 镜像配合一个记录请求内容的假 OpenAI 兼容上游进行验证时，上游确实收到了两条形如 {"role": "assistant", "content": "[Historical voice assistant transcript; not current task status]\n…"} 的消息；开启 features.voice: true 时还会额外收到默认 Voice Mode 提示词作为 system 消息。这说明前缀是服务端注入的，用户浏览器侧无关。

维护者的结论是：这是模型侧的“困惑”，属于模型差异，而非 Open WebUI 的缺陷。该判断在多个模型上无法复现，因此具体触发条件可能取决于模型对 assistant 历史格式的敏感程度与工具调用训练数据。

环境排查

确认 Open WebUI 版本，Issue 在 v0.12.3 与 dev（079fb19e75）上均出现。
确认聊天模型服务方式与版本：vLLM v0.30.0，以及工具解析器参数 --tool-call-parser qwen3_xml --reasoning-parser qwen3 --enable-auto-tool-choice 是否正确生效。
确认请求侧是否设置了 chat_template_kwargs.enable_thinking: false，Issue 在关闭 thinking 时复现。
确认通话中是否已开启 Web 搜索与 fetch-URL 工具，以及工具是否在请求中实际提供给模型（Issue 的 Langfuse trace 显示 tool_count: 44，含 search_web 与 fetch_url）。
确认 features.voice 开关状态，因为它会影响默认 Voice Mode 提示词是否作为 system 消息下发。
换用其他模型复测，以判断是否为当前模型的格式模仿问题。

解决步骤

先按维护者建议，在界面设置的 Voice call prompt 中向聊天模型说明：[Historical voice assistant transcript; not current task status] 是历史语音转写标记，不是当前任务状态，也不应出现在回答中；同时声明当前处于通话中、需要正常使用工具。
保存提示词后，在 Realtime 通话中先进行两轮语音问答，再提出一个必须联网搜索的问题，观察回答是否仍带前缀。
若问题依旧，换用其他模型（例如维护者测试过的模型）对比，确认是否为当前 Qwen 模型对该前缀的过度模仿。
如需从源头处理，可评估 middleware.py 中前缀拼接逻辑的修改，但 Issue 中未提供已验证补丁，改动前需自行验证对语音交接流程的影响。

验证方法

在通话中提出需要搜索的问题后，检查聊天模型是否实际调用了 search_web（可借助 Langfuse trace 查看 provider_calls 与工具调用情况），以及回答文本是否不再以 [Historical voice assistant transcript; not current task status] 开头；同时确认语音模型朗读的内容中不再包含该前缀。