Dify语音交互：从零到能听能说的最短路径

Dify语音交互从零到能听能说的最短路径【免费下载链接】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 用自然语调回答这是你在 Dify 上可以跑通的效果。Dify 是一个开源的 Agentic 工作流开发平台语音转文字STT与文字转语音TTS能力已内置于应用体系中。按本文操作约 30 分钟可从克隆仓库走到听到第一句语音回复。 能力边界速览先对齐预期避免配置到一半发现能力不在功能项开箱即用需手动配置备注语音转文字STT部分配置语音识别模型 应用内开启功能开关仅接受 mp3、m4a、wav、amr、mpga 五种格式单文件上限 30MB文字转语音TTS部分配置 TTS 模型 选择音色返回音频流具体音频格式取决于所选模型控制台语音输入是配置好模型后无应用对话页自动出现语音入口Service API 调用是创建应用 API 密钥走/v1/apps/{app_id}/audio-to-text与/text-to-audio实时流式对话否—当前为文件上传方案不支持边说边传多模型切换是在模型管理页改默认模型更换提供商不改代码即时生效⏱ 最短可用路径以下是从克隆仓库到听到第一句语音回复的最短步骤共 5 步克隆仓库并启动全部服务docker/docker-compose.yaml 定义了整个部署栈git clone https://gitcode.com/GitHub_Trending/di/dify cd dify/docker docker compose up -d浏览器打开http://localhost/install完成初始化并创建管理员账号。在「模型管理」页添加一个支持语音的提供商如 OpenAI的 API 密钥并将其设为语音转文字、文字转语音两类的默认模型。新建一个 Chatbot 或 Workflow 应用在「功能设置」中开启语音转文字与文字转语音并为 TTS 选一个音色。用 curl 调用下面两个接口各验证一次听到语音回复即打通全链路。Dify 可视化编辑器中配置语音功能 核心机制拆解语音转文字输入客户端上传的音频文件格式限 mp3、m4a、wav、amr、mpga大小不超过 30MB。处理服务端读取音频字节流交给当前工作空间的默认语音识别模型执行识别。输出语音对应的纯文本随后进入 LLM 或工作流节点。主要提供商与模型对照提供商模型延迟特征适用语言OpenAIwhisper-1中等90 种以上AzureSpeech 服务whisper 系列较低企业级稳定多语言GoogleSpeech-to-Text较低支持流式输入多语言Groqwhisper-large-v3-turbo低推理快多语言阿里云Paraformer较低中文优化中文为主服务端核心逻辑在 api/services/audio_service.py格式校验、大小限制与模型调用都在这里。避坑提醒⚠️ 音频超过 30MB 或格式不在白名单 → 上传前先压缩或转成 mp3 / wav ⚠️ 调接口报「语音转文字未启用」 → 回应用「功能设置」把 speech to text 开关打开不启用该功能接口直接报错 ⚠️ 中文识别准确率偏低 → 把默认 STT 模型换为 Paraformer 等中文优化模型文字转语音输入待合成的文本通常就是 LLM 生成的回答以及可选的音色参数。处理服务端调用默认 TTS 模型未显式指定音色时自动取该模型音色列表的第一个。输出音频流响应Content-Type 由服务端根据音频内容自动判定客户端按流播放即可。提供商模型延迟特征适用语言OpenAItts-1alloy / echo / nova / shimmer 四种音色中等多语言AzureNeural TTS数百种音色较低多语言GoogleCloud TTS较低多语言国内提供商硅基流动、火山等各自 TTS 模型较低中文为主避坑提醒⚠️ 音色不符合预期 → 在功能设置里显式指定 voice不要依赖「取第一个音色」的默认行为 ⚠️ 拿到的音频文件无法播放 → 先查响应 Content-Type容器格式mp3 / ogg 等随模型变化别写死扩展名 一个完整案例走通以电商售后客服机器人为例按时间线走一遍。用户说「我的订单到哪了」0–1s客户端把这段录音 POST 到/v1/apps/{app_id}/audio-to-textService API 需携带应用 API 密钥。1–3s默认 STT 模型把语音转成文本工作流进入后续节点。3–5sLLM 节点结合知识库RAG基于文档检索增强生成检索订单物流信息并生成回答。5–7s回答文本送入 text-to-audio 接口TTS 模型合成语音客户端播放。用户听到「您的订单预计明天送达」。注意这是文件上传方案整段录音传完才识别不是实时链路。两个关键接口的最小调用密钥换成自己的curl -X POST http://localhost/v1/apps/your-app-id/audio-to-text \ -H Authorization: Bearer app-xxxxxx \ -F filequestion.wavcurl -X POST http://localhost/v1/apps/your-app-id/text-to-audio \ -H Authorization: Bearer app-xxxxxx \ -H Content-Type: application/json \ -d {text: 您的订单预计明天送达。} \ --output reply.mp3接口定义见 api/controllers/service_api/app/audio.py。 性能与稳定性指标健康范围触发动作STT 往返耗时 3s检查提供商延迟与音频文件大小TTS 出声耗时 2s精简文本或换低延迟模型音频接口错误率 1%核查提供商密钥配额与网络超 30MB 音频占比 5%前端加压缩避免打满上限前端压缩上传前转成 16kHz 的 mp3通常可减小体积一半以上同时降低网络等待与格式报错概率。缓存与降级把高频固定问答营业时间、退货政策的合成音频直接缓存复用长尾问题才走 LLM TTS成本和延迟都能摊薄。Docker Compose 部署的 Dify 架构✅ 落地检查清单今天就能做docker compose 拉起服务并完成初始化页添加 OpenAI 等语音提供商的 API 密钥建应用开启 STT / TTS 开关并选定音色用 curl 验证两个接口听到第一句语音回复本周可以做把 Service API 接入你的前端或客服系统挂载知识库RAG提升回答准确率换中文优化的 STT 模型与中文音色做对比测试把音频接口的耗时与错误率接入现有监控需要评估后再做实时流式对话边说边传不用等录完当前是文件上传方案需要自建录音与分段上传语音克隆与情感化合成取决于所选提供商模型是否支持高可用负载均衡与自动扩缩容单节点 docker compose 面向开发验证生产需评估多副本架构离线语音处理需自托管模型服务如本地 whisper用户说完话几秒后听到 AI 自然语调的回答——这条最短路径到此打通。想确认服务端如何调度模型从 api/services/audio_service.py 读起准备上线前把「需要评估后再做」一档逐条过一遍。【免费下载链接】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），仅供参考