OpenClaw 语音能力全面升级:覆盖 13 个 TTS 提供商,会话级控制与角色声线

TTS · 语音合成 · v2026.4.25 —— OpenClaw 在这一版本把语音能力 从单一实验后端推到了覆盖多场景的生产级体验，并同步重构了插件冷启动的 元数据路径。同时，OpenTelemetry 覆盖范围大幅扩展—— 模型调用、工具循环、harness 运行、exec 进程、内存压力等 指标均纳入了可观测性体系。

项目定位：个人 AI 助手的全渠道平台

OpenClaw 是一个运行在自有设备上的个人 AI 助手项目， GitHub 上 365K+ Stars。它的核心思路是 “把 AI 放在你已经在用的聊天工具里”——支持 WhatsApp、Telegram、Discord、微信、飞书、钉钉、Signal、 iMessage、Matrix、Google Chat 等 20+ 个消息渠道，并覆盖 macOS、iOS、Android 原生客户端。

这是一个纯 TypeScript 单体项目，同时管理了 LLM 推理、 多模态理解、函数调用、语音交互、定时任务等模块，通过轻量 Gateway 架构统一调度 AI agent 的输入输出。项目采用 MIT 许可， 核心开发团队活跃，社区贡献频繁——本版即汇聚了来自 leonchui、zoujiejun、vincentkoc 等数十位贡献者的独立提交。

在 v2026.4.25 之前，OpenClaw 的语音能力依赖单一 TTS 后端 且缺乏精细控制；本版彻底改写并拓展了这一能力层， 同时用冷持久化插件注册表重构了插件系统的基础设施。

场景：跨渠道的语音需求快速膨胀

使用个人 AI 助手的场景远比”文字问答”丰富得多。开车时希望语音 朗读最新回复、Telegram 上想听到自然的本地口音朗读、QQ Bot 里 期望自动转语音消息、飞书会议需要对外呼出——这些需求在旧版本里 要么不支持，要么需要手动拼凑。

此前仅有一个 TTS 后端可用，且无法按渠道或按 agent 切换声线。 当同一用户同时使用 WhatsApp 和 Telegram 时，语音配置也无法 细化到每个渠道，导致必须在不同平台上忍受相同的语音设置。 新版直接回应了这些限制——不仅覆盖主要渠道，还专门处理了 QQ Bot、飞书、BlueBubbles 等小众渠道的音频协议差异。

另一个实际痛点出现在跨会话的语音状态管理上。用户在一个群聊 开启了自动朗读，切到私聊后回到纯文本状态，但系统没有一个 统一的方式来”读出当前会话最近的全部回复”。这些场景堆积起来， 使 TTS 从锦上添花变为影响日常可用性的核心需求。同时，随着 LLM 回复越来越长，用户更倾向于让 AI”读给我听”而非自己滚动 阅读长文本块。在渠道侧，不同平台的音频格式差异也造成了兼容性 障碍——WhatsApp 要求 Ogg/Opus，微信偏好 AMR，飞书支持自有 音频协议。旧版的单一编码方式很难同时满足所有渠道。

本版能力：TTS 从单一引擎到完整生态

v2026.4.25 集中填充了 TTS 能力矩阵，覆盖以下四个维度。

多提供商无感切换。 新增 6 个内置 TTS 提供商： Azure Speech（支持 Speech 资源认证、SSML 转义、原生 Ogg/Opus 语音消息输出）、Xiaomi MiMo TTS（通过小米对话模型接口， 支持 MP3/WAV 以及 Opus 转换）、Local CLI（运行本地语音命令， 支持文件和 stdin 输入）、Inworld（流式合成， 支持 PCM telephony 输出）、Volcengine/BytePlus Seed Speech （API key 认证，原生 Ogg/Opus 和 MP3 输出）、 ElevenLabs v3（纳入内置模型目录）。加上已有的 OpenAI、 Microsoft（Edge 神经语音，免密钥）、Google Gemini 等， 总计 13 个。每个提供商独占其 API 认证方式、音频编码偏好和 telephony 输出格式，用户只需在聊天中指定 provider=xxx 即可即时切换，无需重启 gateway。

会话级自动朗读。/tts chat on|off|default 允许按会话 粒度开关自动语音朗读，覆盖了 Telegram、Discord 等消息渠道， 解决了”这个群我需要语音，那个群不需要”的细粒度控制需求。 /tts latest 则将当前会话的最新回复用语音读出来—— 典型”开车中快速听完”的入口，且带有重复播放抑制逻辑， 避免连续触发同一段音频。

角色声线与 per-agent 覆盖。 新引入的 TTS Persona 机制 允许绑定特定声线到特定 AI agent。通过 agents.list[].tts 可为每个 agent 指定不同语音角色，而 channels.<name>.accounts.<id>.tts 能进一步细化到 同一渠道的不同账号。Google Gemini 用 audio-profile-v1 提示包装承载语义，OpenAI 则通过 instructions 映射来传递 角色声线。/tts persona 命令让用户可在聊天中动态切换声线， gateway 端的结构体合并算法将全局配置、渠道覆盖、 agent 重载三级按优先级归并。

跨渠道音频投递统一。 新的 Opus 转码引擎确保非 Opus TTS 输出（MP3、WebM）在发送到 WhatsApp、飞书、Telegram 等渠道时 自动转为 Ogg/Opus 语音消息。Feishu 流式卡片告别了工具调用 密集型回复的重复输出问题。WhatsApp 的群聊语音转写满足提及 门控后方才投递，飞书的语音输入也做了统一的预转录去重。 还有一批渠道侧的精细修复：BlueBubbles 的自动 TTS 现在以 iMessage 语音气泡而非普通文件附件发出；Telegram 恢复了 不完整流式预览的兜底发送逻辑；QQ Bot 新增对语音消息的原生 支持——audioAsVoice 指令可将合成音频直接走 QQ 语音消息通道。

插件体系方面，本版将本地插件注册表迁移到冷持久化索引， 使启动阶段不再扫描所有安装目录来发现 provider manifest。 openclaw plugins list 直接从注册表快照读取，provider 发现、 安全审计、渠道分类等路径都从冷元数据开始。这一重构涉及 约 60 个 commit，大幅缩短了 Gateway 首次启动到可交互的时间。

原理简析：Provider 无关的 TTS 路由与冷注册表

这套 TTS 架构的核心设计是基于 Provider 接口抽象的分层调度。 每个 TTS 提供商作为独立 plugin 注册到冷持久化注册表中， 启动时不再遍历磁盘上的所有文件夹来寻找它们——插件元数据从 运行时解耦出来，变成可离线快照的索引。这使得 openclaw plugins list、channel 状态查询、安全审计、 provider 发现等路径直接从快照读取，不再触发 plugin 加载。

TTS Persona 的底层实现依赖于确定性 Provider 绑定合并。 /tts persona 设置的声线交互通过 gateway 端的结构体合并 算法，将全局 TTS 配置、渠道级覆盖、agent 级重载三层按优先级 归并，确保每个渠道发出的语音消息使用正确的 provider 和声线。 自动朗读的会话控制走的是消息中间件挂载点——在投递管道中 插入 TTS 检查阶段：会话开启自动 TTS 时，消息先经历合成阶段， 再以语音附件或原生气泡发出。工具返回的结果、流式对话片段、 /tts latest 重读都共享同一合成管道。

这套架构使得用户不翻配置文件，就能快速覆盖从 “一个语音给所有渠道”到”每个 agent 用不同声线”的完整光谱。 配合冷注册表让 TTS provider 的发现和加载路径比之前高效 一个数量级。v2026.4.25 让 OpenClaw 的语音能力真正追平甚至 超越了市面上多数商业 AI 助手的开箱体验。