接电话的不必是掌勺的：Open WebUI v0.12.0 的实时语音与日常运维
Open WebUI v0.12.0：Realtime 语音与干活模型分开，口说「好」不能批准工具；Tool Search 在官方测试实例上约省 57% prompt tokens。
用过对讲机的人都知道那种节奏：按住键说话，说完松开，再补一句「完毕」，然后站在原地等对面。话是一句不落地传过去了，可谁也不会把这叫作聊天，它更像两个人轮流往一口井里喊话。自托管的聊天前端过去做语音通话，大致也是这个节奏：你说完一段，先转写成文字交给模型，模型把整段回答写完，再交给 TTS 从头念一遍。能用，只是中间永远隔着一层，你总得等它憋完一整段话。
10 月 10 日，Open WebUI 官方博客发了 v0.12.0 的版本文章，标题里说的是一个会回话的声音，再配上一张脸。官方博客称，changelog 里有 40 多项新增、270 多项修复，东西很多，我没打算一条一条念。我把自己觉得要紧的挑出来，分成两半看：一半是通话本身变了样，另一半是几件不起眼、却每天都要碰到的运维小事。
先说通话。管理员把 Call mode 设成 Realtime 以后，负责跟你一来一回说话的，换成了 OpenAI 的 Realtime 语音模型，默认是 gpt-realtime-2.1-mini，声音默认用 marin。但官方博客说得很清楚，真正干活的，仍然是这场会话里你选好的那个模型，以及你给它配好的工具。也就是说，嘴和手分开了：开口应答的是一个专门说话的模型，查资料、调工具、出结论的，还是原来那一位。
打个比方，这有点像一家小饭馆。接电话订餐的人和后厨掌勺的人，要的本事本来就不一样：前者要反应快、口齿清楚，不能让电话那头干等；后者要的是手艺和灶火，慢一点不要紧，菜得做对。过去让大厨亲自接电话，菜谱背得再熟，拿起听筒也难免慢半拍，客人在那头只听见锅铲响。现在把接电话的活交给前台，大厨安心炒菜，这个分工说穿了就是常识。
这个分工的好处，按我的理解，在于你不用为了语音推倒重来。一个人在会话里已经挑好了模型，配好了工具，这些都不必动，语音这一层只是多加了一个前台。坏处也要说一句，这是我的推断：自托管的人里，有不少是在意数据走向才自己搭的，而官方博客写明对话这一层用的是 OpenAI Realtime 语音模型，那么在打开 Realtime 之前，值得先问一句，你的声音会经过哪里，这是不是你愿意接受的？
再说那张脸。这一版可以给语音通话挂一个 VRM 格式的 3D 头像，文件不超过 25MiB，还能配 VRMA 格式的手势动作。老派网民对头像这件事多少有点感情，论坛时代大家折腾签名档和头像，图的从来不是功能，而是让屏幕对面那团文字像一个具体的东西。有人会说这是花架子，我倒觉得无妨，人对着一张脸说话，总比对着一个输入框自在些，只要别指望一张脸替模型把答案变对。
这次更新里，有一句话值得多看两眼：口头同意不能批准工具调用。意思是，通话里模型要动用工具、需要你点头的时候，你在电话里说一声「好」「行」「可以」，并不算数。这条规矩乍看有些不近人情，既然都实时通话了，为什么还要你回去点一下？
我举一个假设的场景，下面这个人和这件事都是我编的，只为说明道理。假设有人一边在厨房切菜，一边开着语音跟模型商量事情，模型说要执行一个会改动文件的工具，问他行不行。恰好这时家里有人问他汤要不要加盐，他随口答了一声「嗯」。如果这一声「嗯」也能算批准，那这次改动到底是谁批的？是他，是那碗汤，还是收音的麦克风？说话是一件很松的事，有口误，有误听，有背景里别人的声音，它适合商量，不适合签字。
所以我理解这条规矩的分寸是这样的：语音负责把事情说清楚，批准这一下，要落到一个明确的、留得下痕迹的动作上。这是我的解读，官方博客给的是规则本身，没有展开讲理由。说「好」是聊天，点「批准」是签字，两件事不能混在一起，句号。
前面是热闹的部分，下面几件事不热闹，却是自托管的人每天真要面对的。第一件是登录。管理员现在可以强制所有人开启 MFA，用认证器生成验证码，另外配一组一次性的恢复码。这像是给门锁加了第二道锁，再给你几把只能用一次的备用钥匙，丢了手机还能进门，进过一次那把钥匙就作废。一个放在内网角落里没人管的聊天前端，往往比大家想的更容易被人摸进去，这句话算是我的常识判断。
第二件是共享。分享出去的聊天，现在可以打开 Allow replies，收到的人能在里面接着回复。按字面理解，过去分享更像是递出去一张照片，对方只能看；现在更像是把人请进屋里，坐下来接着聊。对一个小团队来说，这省去了把对话来回复制粘贴的麻烦，至于请谁进屋、开不开这扇门，仍然是分享的人自己决定的事。
第三件是版本。workspace 里的模型、工具、技能，每保存一次都会留一个版本，需要的时候可以把某个版本 Set as Production。写过东西的人都懂留底稿的好处，改坏了能退回去，心里才不慌。过去改一个系统提示词，改完觉得不对，想找回上一版只能凭记忆，现在至少有一份账可查，哪一版在线上跑、是哪一版出的问题，说得清楚。
第四件是一个实验功能，叫 Tool Search。工具一多，每个工具的定义都要塞进提示词里，长长一串，模型每次开口前都得先把这本说明书读一遍。Tool Search 的做法是把较长的工具定义延后加载，用得着的时候再取。官方博客称，在他们的测试实例上，同一个问题的 prompt tokens 从约 4728 降到了 2048。我自己算了一下，2048 除以 4728 约等于 43%，也就是省下了大约 57%。要提醒一句，这是官方在一个测试实例上、拿同一个问题测出来的数，你那里能省多少，取决于你挂了多少工具、定义有多长，别把它当成通用的折扣。
最后是升级前的两件事，官方博客专门点了出来。一是用 Milvus 的部署，这一版涉及 Milvus 的迁移，升级之前要先看清楚迁移说明。二是多实例部署，通过 Redis 走 websocket 的那几台，要一起升级，不能这台升了那台没升。按一般运维的常识，这类事情最怕的不是步骤复杂，而是你以为只是点一下「更新」，结果第二天早上才发现有人的聊天不再实时刷新了。先备份，先在一台测试机上走一遍，再动生产环境，这是老手艺人的笨办法，笨，但是省心。
把这一版放在一起看，我觉得它做的事其实很朴素。语音那一半，是承认会说话和会干活是两种本事，不必强求同一个模型两头兼顾；运维那一半，是承认一个工具真要每天用起来，就得有门锁、有底稿、有说明书怎么少读几页的办法。新功能总是热闹的那部分先被看见，可让一个自托管服务长期稳稳当当跑下去的，往往是后面这些不热闹的东西。
说回开头的对讲机。实时通话以后，我们大概不用再说「完毕」了，对面接话也快了，听起来更像一个人。只是到了真正要动手的那一刻，它还是会停下来，等你亲手点一下。说话归说话，签字归签字，快一点的那部分交给机器，慢下来的那一下留给自己，这样分，不是挺好么？
来源：Open WebUI 官方博客：v0.12.0（2026-10-10）。产品事实据该文；Tool Search 约省 57% 为按官方测试实例 4728→2048 自算，文中已注明非普遍折扣；假设场景与推断处正文已标明。