构建一个能在半秒内应答的电话语音智能体
这篇文章登上了 Hacker News 首页！任务：作者构建了一个自定义语音智能体编排层，以替代 Vapi 等现成平台。工作流程包括连接 Twilio 进行电话通信，使用 Deepgram Flux 进行流式转录和轮次检测，使用 Groq 进行低延迟 LLM 推理，以及使用 ElevenLabs 进行文本转语音。系统采用流式管道，LLM 生成的令牌立即转换为音频，并包含在用户打断时取消生成和清空缓冲区的逻辑。作者从基本的 VAD 原型迭代到完整的生产就绪技术栈，重点优化了地理位置邻近性和模型选择。；工具：custom-built or unnamed agent。人工角色：原始帖子没有说明人如何参与。；局限：构建自定义编排层需要大量的工程努力来处理边缘情况，如打断、网络延迟和状态管理。现成平台提供了难以复制的可观测性、可靠性和配置选项。性能提升严重依赖于服务的地理位置共存和特定的模型选择（例如，使用 Groq 以获得低首令牌延迟）。这种方法适合对延迟有特定要求或需要深度控制语音管道的团队。。
工具
custom-built or unnamed agent
Agent Work Atlas 发布日期:
概述
这篇文章登上了 Hacker News 首页！
工作流程
作者构建了一个自定义语音智能体编排层，以替代 Vapi 等现成平台。工作流程包括连接 Twilio 进行电话通信，使用 Deepgram Flux 进行流式转录和轮次检测，使用 Groq 进行低延迟 LLM 推理，以及使用 ElevenLabs 进行文本转语音。系统采用流式管道，LLM 生成的令牌立即转换为音频，并包含在用户打断时取消生成和清空缓冲区的逻辑。作者从基本的 VAD 原型迭代到完整的生产就绪技术栈，重点优化了地理位置邻近性和模型选择。
原文报告的结果
自定义实现达到了约 400 毫秒的端到端延迟，比同等配置的 Vapi（约 840 毫秒）快两倍。作者报告称，对话感觉更自然、响应更迅速，且打断处理干净利落。构建过程耗时约一天，API 额度花费约 100 美元。源代码已发布在 GitHub 上。
人工角色
原始帖子没有说明人如何参与。
局限
构建自定义编排层需要大量的工程努力来处理边缘情况，如打断、网络延迟和状态管理。现成平台提供了难以复制的可观测性、可靠性和配置选项。性能提升严重依赖于服务的地理位置共存和特定的模型选择（例如，使用 Groq 以获得低首令牌延迟）。这种方法适合对延迟有特定要求或需要深度控制语音管道的团队。
试一试
我想构建一个自定义语音智能体原型，以测试相对于现有平台的延迟改进。 **输入：** - 电话服务提供商：Twilio（使用 [可替换的 Twilio Account SID 和 Auth Token]） - STT/轮次检测：Deepgram Flux（使用 [可替换的 Deepgram API Key]） - LLM：Groq llama-3.3-70b（使用 [可替换的 Groq API Key]） - TTS：ElevenLabs（使用 [可替换的 ElevenLabs API Key]） - 目标：实现低于 500 毫秒的端到端延迟。 **步骤：** 1. 设置一个带有用于 Twilio 的 WebSocket 端点的 FastAPI 服务器。 2. 实现流式管道：Twilio 音频 -> Deepgram Flux -> Groq LLM -> ElevenLabs TTS -> Twilio 音频。 3. 添加逻辑，当 Deepgram 检测到“开始轮次”（用户打断）时，立即取消 LLM 生成和 TTS 合成。 4. 将服务器部署在与 API 提供商相同的区域（例如，欧盟或美国东部），以尽量减少网络跳数。 5. 运行单个示例对话的干测试，以测量延迟并验证打断处理。 **交付物：** - 一个可工作的原型代码库。 - 将自定义构建与基线 Vapi 设置进行比较的延迟报告。 **保障措施：** - 未经人工审查打断逻辑，不得部署到生产环境。 - 初始试验使用测试电话号码。 - 在前 100 次交互期间密切监控 API 成本。
来源报告未经独立核验。发布日期为本站案例发布日期，并非原始文章日期。