腾讯混元发布 Hy Realtime：实时语音不只会聊，现在还能唱歌和调用工具

腾讯混元在 11 月 13 日发布实时语音模型 Hy Realtime，并已将其接入元宝语音通话、腾讯客服等产品。新模型的核心变化有两个：一是加入 Agentic 工具调用能力，可以在语音对话中判断是否需要联网搜索；二是与腾讯音乐 TME 灵音 AI 团队合作，新增自然语言点歌和演唱能力。(ithome.com)

Hy Realtime 是腾讯混元面向低延迟语音对话场景推出的实时语音模型。 它接收用户连续输入的语音，结合上下文理解意图，再以带有语气、节奏和情感变化的语音进行回应，目标不是把“语音识别、文字问答、语音合成”简单串起来，而是让整个交互更接近人与人通话。

截至 2026 年 11 月 13 日，用户可以在最新版元宝 App 的语音通话功能中选择“初语”音色体验，也可以通过腾讯提供的网页 Demo 测试部分能力。腾讯表示，Hy Realtime 近期还将上线腾讯云并提供 API 服务，但尚未公布正式模型名称、调用价格、上下文长度、音频格式、并发额度和端到端延迟等开发者最关心的参数。(ithome.com)

重点不是“会唱”，而是语音模型开始执行任务

Agentic 工具调用是 Hy Realtime 本次更新中比唱歌更重要的能力。 Agentic 工具调用是指模型不仅生成回答，还能根据用户意图自主判断是否调用搜索、业务系统或其他外部工具，并把执行结果重新组织成自然语言回复。

传统语音助手通常采用固定命令模式：用户说“查天气”，系统触发天气接口；用户说“播放音乐”，系统触发播放器。这套机制能执行预设动作，但很难处理含糊表达、上下文省略和临时改口。

Hy Realtime 试图把工具决策交给模型。例如，用户先问“周末上海会下雨吗”，随后补一句“那帮我找个适合带孩子去的室内活动”，模型需要完成至少三步判断：

1. 从上下文中确定“周末”和“上海”；
2. 判断第一个问题需要查询实时天气，而不是依赖模型记忆；
3. 将天气结果带入第二个问题，再搜索或筛选室内活动。

腾讯披露，Hy Realtime 可以统一处理搜索决策、工具调用与最终回答，而不是把搜索做成一个需要用户手动触发的独立功能。这意味着语音交互的产品形态正在从“说话版聊天机器人”转向“可以边聊边办事的 Agent”。(ithome.com)

这项能力对腾讯尤其重要。腾讯拥有微信、元宝、腾讯客服、腾讯会议、腾讯文档、QQ 音乐以及大量企业服务，真正的优势并不只是训练一个声音更自然的模型，而是把语音模型接入搜索、音乐、客服工单和企业知识库。

如果工具调用足够稳定，用户未来对着元宝说一句“总结刚才会议里提到的三个风险，再查一下相关行业数据”，系统就可能同时完成上下文提取、联网搜索和语音总结。语音模型由此不再只是一个输入法，而会成为腾讯各类服务之间的自然语言调度层。

Hy Realtime 能听懂“说了一半”的话

不完整语音理解是指模型能够结合上下文，还原被省略、修正或中途打断的真实意图。 现实对话很少像文字提示词那样结构完整，人们会停顿、重复、吞字，也会在一句话还没说完时改变主意。

例如，用户可能会说：“帮我查一下明天去北京……算了，后天吧，上海到北京最早的。”一个只做逐句转写的系统容易保留多个互相冲突的条件，而实时语音模型必须理解“明天”已被“后天”覆盖，并从后半句补全出发地、目的地和排序条件。

腾讯称，Hy Realtime 针对口齿含糊、话说半截和中途纠正等情况提升了意图还原能力，同时增强了长对话中的多轮指令遵循和上下文管理。(ithome.com)

这类能力决定了语音助手能否真正进入客服和车载场景。客服用户不会按照系统预设的话术表达问题，驾驶者也不可能在开车时组织一段完整提示词。如果模型必须等用户说出格式标准、没有歧义的句子，所谓自然交互就仍然只是演示效果。

不过，腾讯目前没有公布公开测试集上的意图识别准确率，也没有给出打断恢复、噪声环境、方言理解和长时间通话的量化结果。官方展示可以说明模型已经具备能力，但还不能证明它在真实生产环境中比竞品稳定多少。

唱歌不是炫技，而是一种情绪表达接口

实时语音模型的唱歌能力是指模型能够理解自然语言点歌条件，并以包含旋律、节奏、咬字和情绪变化的歌声完成演唱。 它不是简单播放一段预先录制的音频，而是把对话上下文、歌曲检索和声音生成放进同一条交互链路。

Hy Realtime 支持按歌手、专辑、曲风、语种、发行年份和热度组合点歌，也能够承接前文继续筛选。例如，用户可以先说“来首英文民谣”，再补充“别太悲伤，最好是 2010 年到 2020 年之间的”，模型需要保留前一个条件并叠加新的限制。

腾讯表示，混元团队与 TME 灵音 AI 团队进行了深度 Co-Design，重点优化演唱的表现力、自然度和音乐性，包括咬字、气息衔接、旋律、节奏和情绪层次。内部专家 A/B Test 显示，Hy Realtime 在核心体验维度上具有明显优势，但腾讯没有公布对照模型、样本规模和具体胜率。(ithome.com)

从产品角度看，唱歌的价值主要有三层。

第一层是展示效果。唱歌比普通语音问答更容易让用户立即感知模型在音高、节奏和情绪上的差异，适合成为新模型的传播入口。

第二层是陪伴场景。故事、哄睡、语言学习和虚拟角色都需要比“把文字读出来”更丰富的声音表现，唱歌可以验证模型是否具备连续、可控的情绪表达能力。

第三层是腾讯音乐生态。与缺少音乐版权和曲库资源的模型厂商相比，腾讯拥有 TME 的内容、产品和声音技术积累，更有条件把点歌、演唱、推荐和会员服务连接起来。

但唱歌也是风险最高的能力之一。歌曲版权、音色授权、歌手声纹模仿和生成内容标识都需要明确边界。Hy Realtime 如果只是使用获得授权的曲库和通用音色，商业落地相对可控；如果未来允许用户指定现实歌手音色进行生成，则必须处理更复杂的授权与滥用问题。

与 GPT-Live、Qwen 和豆包相比，混元还缺一块关键拼图

全双工语音是指模型可以在输出语音的同时继续监听用户，并实时处理插话、打断和补充信息。 半双工系统更像对讲机，用户和模型轮流发言；全双工系统更像电话，双方能够自然重叠说话。

腾讯已经明确把双工交互列为 Hy Realtime 下一阶段的重点，这也说明当前版本的打断体验和并行处理能力仍有提升空间。(ithome.com)

目前主流实时语音产品的竞争已经从“能否语音问答”进入“能否持续交互和执行任务”的阶段：OpenAI 的 GPT-Live 强调全双工对话和后台 Agent 委派；Qwen 的实时模型支持 WebRTC、WebSocket、工具调用及多模态输入；豆包的实时语音模型则已经把全双工、唱歌和强角色表达拆成不同版本。(developers.openai.com)

| 模型或产品 | 实时语音 | 工具调用 | 唱歌 | 全双工方向 | 当前主要优势 | |---|---|---|---|---|---| | 腾讯混元 Hy Realtime | 支持 | 支持联网搜索决策 | 支持 | 官方称下一步重点提升 | 腾讯产品落地、TME 音乐协同、中文场景 | | OpenAI GPT-Live | 支持 | 支持委派后台 Agent | 未作为核心卖点 | 支持 | 全双工交互、打断处理、工具生态 | | Qwen 实时语音模型 | 支持 | 支持函数、MCP 与搜索 | 未作为统一核心能力强调 | 部分型号支持 | 音频、图像、视频统一输入与多协议接入 | | 豆包端到端实时语音 | 支持 | 依产品配置而定 | S2S-Omni 支持 | 有独立全双工版本 | 角色表达、消费级产品经验、授权曲库 |

这张表也暴露了 Hy Realtime 的现实位置：它在唱歌、中文表达和腾讯生态连接上有差异化，但在全双工、开发接口透明度和公开评测方面暂时没有形成明显领先。

尤其对开发者来说，“近期上线腾讯云”还不等于可以进入生产环境。一个实时语音模型是否可用，至少要看首包语音延迟、打断响应时间、连续会话时长、并发限制、函数调用成功率、音频协议和价格。腾讯目前没有公开这些数字，因此现阶段更适合把 Hy Realtime 看成已经完成产品验证、等待云服务规格落地的新模型，而不是可以立即替换现有语音技术栈的成熟方案。

客服可能是 Hy Realtime 最快产生收入的场景

语音客服 Agent 是能够通过电话或实时音频理解问题、查询业务系统并完成操作的自动化客服。 相比陪伴和唱歌，客服对工具调用的需求更明确，也更容易计算成本和收益。

用户拨打客服电话时，常见需求不是听一段知识库答案，而是查询订单、修改地址、取消服务或转接人工。这些任务都要求模型调用企业内部系统，并在执行敏感操作前进行身份验证和二次确认。

Hy Realtime 已经在腾讯客服上线，说明腾讯正在用真实业务流量验证其意图识别、长对话稳定性和工具调用能力。客服也是检验实时语音模型最严格的场景之一：用户表达不标准、环境噪声复杂、业务规则经常变化，而且错误操作会直接产生损失。

腾讯的优势在于能够同时控制模型、实时音视频基础设施和客服产品。腾讯 RTC 官方方案已经支持低延迟 AI 实时对话，Hy Realtime 加入后，腾讯可以把传输、模型、工具调用和客服系统打包成更完整的企业方案，而不只是出售一个语音生成接口。

真正的挑战则是成本。如果一次三分钟客服通话需要同时消耗实时音频输入、模型推理、语音输出和外部工具调用，单位通话成本可能明显高于传统 IVR。只有当自动解决率提升、人工转接率下降，并且总体成本低于人工客服时，实时语音 Agent 才能大规模进入企业预算。

腾讯下一步要补的是记忆和前后台协同

长期个性化记忆是指模型能够在获得用户授权的前提下，跨会话保留偏好、习惯和重要事实。 腾讯已经将长期个性化记忆列为 Hy Realtime 后续重点方向。

对语音助手而言，长期记忆比文字聊天更重要。用户不会愿意每次通话都重新解释自己喜欢什么音乐、常用哪个城市、孩子多大或企业账户属于哪个部门。如果模型能够稳定保存这些信息，元宝的语音通话才可能从一次性功能变成持续使用的个人助手。

前后台 Agent 交互是指前台语音模型负责维持自然对话，后台 Agent 同时执行耗时任务。 例如，前台模型可以先告诉用户“我正在查询订单”，后台 Agent 则调用订单系统、检查物流状态并申请售后，完成后再由前台模型用自然语音告知结果。

这种架构能解决实时语音 Agent 的核心矛盾：用户希望模型立即回应，但复杂任务需要数秒甚至更长时间。前台负责低延迟和情绪表达，后台负责推理、搜索与业务执行，两者并行工作，体验才可能接近真正的人类客服。

OpenAI Hub 观点：唱歌负责吸引用户，工具调用决定产品价值

Hy Realtime 是腾讯把语音生成、音乐能力和 Agent 执行能力合并到同一个实时入口的尝试。 它不是一次单纯的音色升级，也不是给元宝增加一个娱乐功能，而是在测试语音能否成为腾讯 AI 产品的主要交互方式。

唱歌会是最容易传播的能力，却不会是最重要的商业能力。用户可能因为一句“来首 2010 年代的英文民谣”第一次打开语音通话，但能否让用户留下来，取决于模型能不能稳定完成搜索、客服、会议和生活服务任务。

Hy Realtime 当前最大的短板不是不会做更多事情，而是缺少可验证的公开指标。腾讯需要在云服务上线时公布延迟、价格、并发、工具调用成功率和音频协议，并提供足够清晰的开发文档。否则开发者只能看到效果展示，无法判断迁移成本。

从发布时间看，腾讯正在明显加快混元的产品节奏。语音识别、同声传译、通用模型和实时语音能力正在逐渐汇合，而 Hy Realtime 承担的是最靠近用户的“声音界面”。

如果腾讯后续补齐全双工、长期记忆和前后台 Agent 协同，Hy Realtime 才会真正从“能说会唱的模型”变成“可以一直在线办事的语音 Agent”。在此之前，它是一款方向正确、产品落地速度很快，但仍需要用公开数据证明工程成熟度的实时语音模型。

参考来源

• IT之家：腾讯混元发布实时语音模型 Hy Realtime —— 发布信息、产品能力、上线范围及后续迭代方向。
• 知乎：腾讯混元 Hy ASR 3.0 Preview 语音识别模型资料整理 —— 用于区分实时对话模型与语音识别模型的能力边界。