Dify 语音助手完整指南用 STT TTS 快速搭建语音交互应用【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify用 Dify 语音助手功能你的 WebApp 可以直接听懂用户说话、也能开口回答。录音上传识别成文字交给 LLM 处理回复再由文字转语音播回去——整条链路 Dify 都内置好了你只需要配两个模型。Dify 语音功能能力速览能做什么、边界在哪Dify 的语音能力拆成两条独立开关的链路语音转文字Speech-to-TextSTT和文字转语音Text-to-SpeechTTS。STT 把用户录的音上传给后端转成文本后进入正常的对话流程TTS 则把 LLM 的回答合成 MP3 音频流返回给前端播放。两者都复用模型管理Model Manager里你已配置的模型厂商凭据不用单独建一套密钥体系。项目STT语音转文字TTS文字转语音接口POST /audio-to-textPOST /text-to-audio支持格式mp3、m4a、wav、amr、mpga固定输出 MP3audio/mpeg大小限制单文件 ≤ 30MB无固定限制流式返回开关位置应用模型设置speech_to_text.enabledtext_to_speech.enabledvoice是否可单独关闭是两条链路互不影响是注意边界STT 只按文件后缀白名单校验mp3/m4a/wav/amr/mpgaog g、flac、aac 这类格式会被直接拒绝TTS 的音色选择依赖模型厂商提供哪些 voiceDify 本身不内置音色库。最短上手路径两步配置 两个接口调通最短路径只有三步全程在控制台操作不用写后端代码配厂商凭据到「模型供应商」页面接入任一支持 STT/TTS 的模型如 OpenAI 的 Whisper 和 TTS 系列填入 API Key。开应用开关进入目标应用 → 模型设置打开语音转文字和文字转语音TTS 侧选一个音色voice。验证调用用任意 HTTP 客户端发一次请求即可确认链路通。下面这段就是验证 STT 的最小请求——录音文件作为file字段上传返回的text字段即识别结果curl -X POST https://你的域名/web-apps/app_id/audio-to-text \ -H Authorization: Bearer API_KEY \ -F filerecording.mp3TTS 侧传 JSON 就行text和voice两个字段响应是 MP3 二进制流前端直接交给audio或URL.createObjectURL播放。也可以不传text而传message_id——Dify 会把该条历史消息的回复重新合成语音前端重播某条回答时很实用。配置背后的取舍enabled 和 voice 该怎么选配置项看着简单但有几个容易踩的决策点讲清楚代价再下手STT 的 30MB 限制是硬编码的FILE_SIZE 30见 api/services/audio_service.py。超过直接 413。如果业务需要更长的录音正确做法不是改源码而是在前端切片上传、多段拼接识别或先本地压缩再传。TTS 输出固定 MP3。content_typeaudio/mpeg写死在返回逻辑里好处是浏览器兼容性最好代价是如果你想要 Opus/AAC 这类更适合低带宽场景的格式得自己在网关层转码。voice 的默认值逻辑值得留意TTS 请求如果不显式传 voiceDify 会取应用配置里的 voice配置里也没选则回落到该厂商音色列表的第一个。这意味着你换厂商后默认声音会突变——想保持声音一致就在应用配置里显式指定 voice别依赖默认值。流式 TTS 有播放超时前端自动播放音频有 5 秒超时阈值api/constants/tts_auto_play_timeout.py弱网下用户可能遇到文字有了、声音没响。属于预期行为不是 bug。避坑手册现象 → 原因 → 处理现象上传音频返回 415 Unsupported audio type。原因格式白名单校验的是 MIME 类型映射后的audio/{ext}且白名单只有 mp3、m4a、wav、amr、mpga。另外代码里对audio/x-m4a做了别名修正但其他厂商上传的变体 MIME 不在保护范围。 处理前端录音统一转码为 mp3 或 wav 再上传。现象明明开了 STT调用却报 Speech to text is disabled。原因开关是按应用模式分别读取的——Chat 模式读AppModelConfigWorkflow/Chatflow 模式读的是 workflow 的features_dict。改了 A 处、应用走的是 B 处就会出现看起来开了其实没开。 处理确认你的应用类型在对应位置应用模型设置 or 工作流功能配置都打开开关。现象TTS 报 Provider not support text-to-speech 或 no voice available。原因该租户下 TTS 类型的默认模型实例没配或所选模型厂商当前没有返回任何音色。 处理到模型供应商页面确认 TTS 类别下有可用模型并检查 API Key 权限是否包含语音接口。现象识别准确率低。原因采样环境噪声大、或选用的 STT 模型不匹配目标语言比如用英文模型跑中文录音。 处理换支持对应语言的模型对录音做前置降噪长音频拆段识别比整段硬塞效果好。现象弱网下 TTS 无响应、播放卡顿。原因MP3 流式传输在带宽受限时首字节延迟高加上 5 秒自动播放超时直接放弃。 处理前端加点击播放兜底用户手动触发不受超时限制或在服务端对 TTS 响应加一层短 TTL 缓存同一答案的语音不重复合成。写在最后Dify 的 STT TTS 适合快速给现有 Chat/Workflow 应用加一层语音交互配置轻、链路内置、格式白名单和 30MB 限制明确可控如果你的场景涉及超长录音、低带宽格式或音色克隆需要在应用层自行补足。现在打开控制台把两条语音开关配上十分钟就能让应用开口说话。【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考