语音助手：使用简单，构建困难

语音已成为应用人工智能中广泛采用的交互方式。

从呼叫中心到日程安排助手，语音智能体正以前所未有的规模进入各行业的生产应用场景。尽管语音交流看似自然，但要构建低延迟的对话式语音智能体，其难度却远超表面所见。

本文中，我们将探讨团队如何通过技术栈的三个不同层级实现语音代理产品化：核心基础设施层、框架与开发者平台层、以及端到端应用层。随后解析构建语音代理的核心技术挑战，并重点指出语音技术栈中持续存在的基础设施需求。

在 Greylock，我们始终致力于理解语音代理构建的技术架构，从而更深入地体会工程复杂性，更精准地评估该领域产品的技术深度与差异化优势。

语音技术栈的三层架构

实际部署语音助手的团队通常需要处理语音技术栈三层架构中的某一层。每一层都涉及独特的工程权衡与产品考量：

1. 1. 核心基础设施
      在这一层级运作的团队需要端到端地设计、构建和部署自己的语音架构，这涉及管理远超模型编排范畴的基础设施。他们必须统筹跨平台音频 SDK、实时监控、边缘环境部署等组件，通常还需内置检索增强生成（RAG）支持、外部系统集成及特定应用逻辑。虽然这种方式需要更深厚的基础设施和语音专业知识，但能提供最高级别的灵活性与控制权。

1. 1. 框架与开发者平台
      Vapi 和 Retell 等平台提供的框架能显著降低构建定制代理的难度，开箱即用支持函数调用、提示链和网络钩子功能。这类平台特别适合不愿投入工程资源从头搭建全套技术设施，但仍希望通过灵活可配置的基础模块快速实现落地的团队。

1. 端到端应用
   这一领域的企业通常自建核心基础设施，提供全功能语音代理服务，将客户支持、医疗保健和家庭服务等场景中的技术复杂性对终端用户隐藏。Netic、Cresta、Bland 和 Simple 等团队与终端用户紧密合作实施部署，通常需要接入知识库、API 和业务逻辑系统。工作流整合能力与强大的市场进入策略在此层级最为关键。

每种方法在速度、灵活性、集成开销和工程投入之间都代表着不同的权衡取舍。

语音代理技术解析

目前，大多数生产级语音系统通常采用三部分架构：(1)语音转文本(STT)模型，(2)大型语言模型(LLM)，(3)文本转语音(TTS)模型。多数 STT–LLM–TTS 架构会加入语音活动检测(VAD)层来判定用户何时开始及结束说话。VAD 通常运行在 STT 模型之前或同时工作，通过门控机制控制音频转录时机，从而减少不必要的计算和延迟。在 Deepgram 等系统中，VAD 直接集成到 STT 处理流程，会在流式传输时发出事件信号来标记语音开始、结束或话轮完成。部分架构还会实施 STT 后话轮检测，通过基于 transformer 的语义模型分析转录文本来判断用户话轮是否结束[ 文献 ]。

一种新兴的替代方案是采用端到端语音转语音（S2S）模型，这种模型能跳过从音频到文本再转回音频的中间转换步骤。这类模型通常具备更强的表现力和开箱即用的对话能力。尽管前景诱人，但由于幻觉风险增加、功能调用受限、推理速度较慢以及推理能力较弱等问题，S2S 系统目前尚未适用于大多数生产场景。

无论采用 STT-LLM-TTS 还是 S2S 架构，底层挑战依然复杂。要实现高质量实时语音交互，必须解决全技术栈的难题。以下列举若干技术考量要点，并着重指出架构中最关键的环节：

延迟

实现语音系统的实时延迟目标是一个多层次挑战。在任何后端处理开始前，WebRTC 等低延迟音频传输标准协议通常会在每个传输方向引入约 250 毫秒延迟，即便在理想条件下也会形成约 500 毫秒的基础延迟。后端处理中，STT、LLM 和 TTS 模型通常需要顺序调用，往往还伴随着可能涉及额外网络请求的函数调用。每个步骤都会累积延迟，使得系统难以维持在实时语音交互普遍接受的 700 毫秒阈值内。

为降低端到端响应时间，部分系统采用预测性技术，例如在语音结束检测器尚未完全确认用户发言完毕时就提前发送 LLM 请求。虽然这可能导致冗余的推理调用，但能显著改善平均延迟。这些设计选择体现了生产级语音代理在速度、成本与交互质量之间持续的权衡。

函数调用编排

函数调用功能使模型能够获取数据并执行操作。面对功能列表和业务逻辑上下文，语音助手不仅需要决定调用哪个功能，还需确定调用顺序、参数设置以及何时暂停以获取用户输入——这些决策往往在严格的延迟限制和非确定性环境中进行。这些函数调用可能包含转接决策、人工坐席升级、数据查询、多步骤任务以及复杂的分支工作流。

幻觉效应与防护机制

在高风险或受监管领域避免幻觉效应至关重要，尤其是当语音助手处理医疗保健、金融等高度监管行业的敏感工作流程时。防护机制对于确保回答可靠、安全且符合语境尤为关键。这不仅涉及对话幻觉（如错误事实、误导性推理或不安全回复），还包括语音特有的错误（如发音错误、不当语气或变调语音）。

打断与停顿

处理诸如”嗯”、”是的”、”等等”、”不”等打断性话语以及重叠语音，同时分辨用户是在与智能体对话还是与房间里的其他人交谈，这远非基础语音活动检测所能胜任。AI 系统需要检测到打断行为，理解打断期间的话语内容，并判断是暂停、修正还是完全放弃之前的回应。它还必须保持上下文记忆——比如记住自己正说到哪里——进而决定是继续原有思路，转向用户引入的新话题，还是并行处理两条对话线。这要求系统具备精准的实时校准能力和复杂的状态管理机制，以追踪并优先处理不同对话线程。半双工系统（仅允许单方发言）与全双工系统（支持双方同时发言）在这些挑战上存在显著差异，后者需要更先进的重叠语音处理和话轮转换机制。

语音细微差异

处理口音、非常见姓名、电话号码、地址及品牌术语时仍容易出错，尤其在嘈杂环境中更为明显。以汽车经销商语音代理为例，其应能正确发音汽车品牌名称，但这项功能并非文本转语音(TTS)模型的内置能力。其他典型场景包括：需将”9-1-1″读作”九一一”而非”九百十一”，或把”MIT”读作”M-I-T”而非”手套”。

背景噪声与多人说话检测

准确区分用户语音与其他说话者或环境噪音，对于实现精准转录和理解至关重要。现实环境中的音频信号往往混杂不清，而鲁棒的说话人分割技术在许多实际应用场景中仍是未解的难题。这些挑战不仅存在于日常对话场景。例如，语音代理还需学会处理交互式语音应答(IVR)系统、等待音乐以及其他非语音音频。

构建语音智能体时面临的挑战远不止这些。语音智能体仅实现精准的转录或拟人化发音是远远不够的，它还必须能处理语义模糊性、保持上下文连贯性、从被打断的对话中恢复，并精准应对各种边缘案例。在语音交互中，时机把握、发音或逻辑上的细微瑕疵都可能迅速降低用户体验。

语音技术栈的持久基础设施需求

无论团队是从零构建语音智能体，还是利用开发者平台与框架，抑或部署全托管应用，某些基础设施能力始终是根基所在。虽然当前系统采用语音转文字（STT）—大语言模型（LLM）—文字转语音（TTS）的架构，未来可能转向端到端原生（S2S-native）或其他架构，但核心需求将长期存在。

在与开发者和采购方的交流中，我们反复听到可靠性、质量、安全性和合规性是影响生产部署的关键门槛因素。开发者需要确信他们部署的智能体能在各种边缘场景中稳定运行，而采购方则寻求能在真实环境中实时评估与监控智能体行为的工具。这些诉求在监管严格的行业中尤为突出，因为合规与安全标准不容妥协。

可靠性与质量

无论模型性能如何提升，开发者仍需基础设施来确保智能体行为符合预期。实践中，可靠性与质量主要体现在三个方面：

1. 1. 语音本身的表现： 必须避免语音特有的幻觉现象，例如不合时宜的笑声、品牌名称或实体的错误发音、电话号码和账号的误读，以及缩略词的不正确发音。

1. 1. 对话内容、上下文记忆与执行动作： 确保智能体在各种条件和边缘案例中始终能正确解析、响应并执行操作步骤同样至关重要。像 Braintrust 这样的平台支持对智能体进行自动化评估，使团队能快速测试不同提示词和多轮对话场景。

1. 对话流畅性与通信可靠性： 语音智能体需要避免出现尴尬的停顿、话语截断或轮流发言时的中断。底层通信可靠性同样关键，包括处理丢包、重连和抖动等问题。无论模型性能如何，这些常被忽视的底层问题都会显著降低用户对语音智能体质量和响应速度的感知。

这些能力的结合使语音智能体能在金融服务和医疗保健等高度监管环境中运行——这些领域对安全性和合规性有着极高要求。

结论

语音正日益成为强大的软件交互界面，但构建高质量的语音代理在技术上仍面临挑战。从系统编排、延迟处理到实时音频操作与合规要求，这些挑战贯穿整个技术栈——解决方案亦是如此。无论团队聚焦基础设施层、开发者框架层还是应用层，产品化落地的门槛都相当高。

在 Greylock，我们投入大量时间深入理解语音系统的技术架构。这种深度认知使我们能更精准共情工程挑战，更严格评估产品深度，并始终领先于语音技术栈的演进趋势。

我们期待持续向奋战在语音基础设施和智能语音应用前沿的团队学习。如果您正致力于此领域，我们非常期待交流。欢迎通过 sophia@greylock.com 联系我。

感谢 Timothy Luong、Dave Smith、Catheryn Li、Andrew Chen、Ben Wiley、Arno Gau、Jason Risch、Jerry Chen、Corinne Riley 和 Christine Kim 的思想碰撞。