在LangSmith中追踪语音代理

今天，我们宣布在LangSmith中推出Python集成，用于追踪四种流行的语音代理框架：Pipecat、LiveKit、OpenAI Realtime和Google ADK的Gemini Live。

语音代理正变得越来越实用，市场也在快速增长。这种增长得益于整个技术栈的进步：语音活动检测模型更加精确，减少了中断和尴尬的交互；语音模型听起来更富情感和自然；而LLM现在足够快速和智能，能够进行实时对话。

语音代理也需要可观测性。构建语音代理在很多方面与构建基于聊天的代理相似：语音代理调用模型、使用工具、维护状态、检索上下文并做出决策。在生产环境中扩展语音代理时，你需要了解语音管道中任何时刻发生的情况，以及能够与队友共享追踪、评估代理行为、调试错误并随时间改进代理——就像你对基于文本的代理所做的那样。

话虽如此，语音追踪和观察有一些独特的要求。通过此次发布，我们宣布了原生支持捕获和追踪语音交互，包括录制对话音频、追踪语音到文本和文本到语音的推理、突出显示中断等。

现在，你的文本和语音代理可以共存于一个地方，使用你已经设置的相同审查和协作工作流程。

语音代理架构主要有两种：“三明治”架构和语音到语音架构。在“三明治”架构中，代理由三个不同的推理组件链式组成：语音到文本（STT）、基于文本的代理和文本到语音（TTS）。每个轮次都流经这三个组件：用户的音频被转录，转录内容作为传统基于文本代理的输入，代理的输出被合成为语音供用户收听。良好的“三明治”语音代理可观测性需要能够捕获每个步骤的洞察：每个推理请求的元数据、输入和输出，跨STT、LLM和TTS的延迟分解以确定轮次延迟的来源，语音活动检测事件等。

相比之下，在语音到语音架构中，代理使用多模态模型构建，该模型原生处理音频输入并输出音频。使用这种架构，你的语音代理应用程序由通过双向WebSocket流式传输的事件组成：你将代表用户音频的音频事件发送给模型，模型返回工具调用、中断检测事件、转录、音频输出等。对于语音到语音，你需要捕获和检查在网络上发送和接收的事件，因为这些对于重建语音代理交互的真相和调试应用程序至关重要。

使用LangSmith，你可以追踪这两种架构，并获得生产对话的完全可观测性。

通过我们新的追踪集成，LangSmith捕获每个生产追踪中的关键运行。每个追踪集成只需几行代码即可设置，并让你完全了解语音交互过程中发生的情况，包括：完整的对话音频覆盖在追踪上；语音到语音模型事件，包含输入、输出和其他元数据；语音到文本推理追踪，包含延迟和其他元数据；文本到语音推理追踪，包含延迟和其他元数据；用户和代理的高级别轮次；语音活动检测事件；中断和重叠语音；模型输入和输出；工具调用、参数、结果和错误；语音管道每个阶段的时序。

我们捕获的每个事件和工作单元都出现在一个单一的追踪树中，这让你可以追踪交互如何从音频到代理动作再到口头响应。

现在就开始吧：为你的框架设置追踪：Pipecat集成文档、LiveKit集成文档、OpenAI Realtime集成文档、Gemini Live与Google ADK集成文档。或者探索一个可工作的示例：https://github.com/langchain-ai/voice-demo