Esta publicación es una colaboración entre AWS y Pipecat.
La implementación de agentes de voz inteligentes que mantengan conversaciones naturales y similares a las humanas requiere la transmisión a los usuarios donde estén, a través de canales web, móviles y telefónicos, incluso en condiciones de mucho tráfico y de red poco confiables. Incluso los pequeños retrasos pueden interrumpir el flujo de la conversación, haciendo que los usuarios perciban que el agente no responde o no es confiable. Para casos de uso como atención al cliente, asistentes virtuales y campañas salientes, un flujo natural es fundamental para la experiencia del usuario. En esta serie de publicaciones, aprenderá cómo las arquitecturas de transmisión ayudan a abordar estos desafíos mediante el uso de agentes de voz de Pipecat en Amazon Bedrock AgentCore Runtime.
En la Parte 1, aprenderá cómo implementar agentes de voz de Pipecat en AgentCore Runtime utilizando diferentes enfoques de transporte de red, incluidos WebSockets, WebRTC e integración de telefonía, con orientación práctica de implementación y ejemplos de código.
Beneficios de AgentCore Runtime para agentes de voz
Implementar agentes de voz en tiempo real es un desafío: necesita transmisión de baja latencia, aislamiento estricto por motivos de seguridad y la capacidad de escalar dinámicamente a un volumen de conversación impredecible. Sin una arquitectura diseñada adecuadamente, puede experimentar fluctuaciones de audio, limitaciones de escalabilidad, costos inflados debido al sobreaprovisionamiento y una mayor complejidad. Para profundizar en las arquitecturas de agentes de voz, incluidos los enfoques en cascada (STT → LLM → TTS) y de voz a voz, consulte nuestra publicación anterior, Creación de asistentes de voz en tiempo real con Amazon Nova Sonic en comparación con arquitecturas en cascada.
Amazon Bedrock AgentCore Runtime aborda estos desafíos proporcionando un entorno seguro y sin servidor para escalar agentes dinámicos de IA. Cada sesión de conversación se ejecuta en microVM aisladas por seguridad. Se escala automáticamente para picos de tráfico y maneja sesiones continuas de hasta 8 horas, lo que lo hace ideal para interacciones de voz largas y de varios turnos. Cobra sólo por los recursos utilizados activamente, lo que ayuda a minimizar los costos asociados con la infraestructura inactiva.
Pipecat, un marco agente para crear canales de inteligencia artificial de voz en tiempo real, se ejecuta en AgentCore Runtime con una configuración mínima. Empaquete su canal de voz Pipecat como un contenedor e impleméntelo directamente en AgentCore Runtime. El tiempo de ejecución admite transmisión bidireccional para audio en tiempo real y observabilidad integrada para rastrear el razonamiento de los agentes y las llamadas a herramientas.
AgentCore Runtime requiere contenedores ARM64 (Graviton), así que asegúrese de que sus imágenes de Docker estén diseñadas para el sistema Linux/arm64.
Arquitecturas de streaming para agentes de voz en AgentCore Runtime
Esta publicación asume su familiaridad con las arquitecturas comunes de agentes de voz: específicamente el enfoque de modelos en cascada, donde se conectan modelos de voz a texto (STT) y texto a voz (TTS) en una canalización, y el enfoque del modelo de voz a voz, como Amazon Nova Sonic. Si es nuevo en estos conceptos, comience con nuestras publicaciones anteriores del blog sobre los dos enfoques fundamentales: en cascada y de voz a voz antes de continuar.
Al crear agentes de voz, la latencia es una consideración crítica, que determina qué tan natural y confiable se siente una conversación de voz. Las conversaciones requieren respuestas casi instantáneas, generalmente de menos de un segundo, de un extremo a otro, para mantener un ritmo fluido y humano.
Para lograr una latencia baja, debe considerar la transmisión bidireccional en múltiples rutas, que incluyen:
Cliente a agente: sus agentes de voz se ejecutarán en dispositivos y aplicaciones, desde navegadores web y aplicaciones móviles hasta hardware de borde, cada uno con condiciones de red únicas. De agente a modelo: sus agentes de voz dependen de la transmisión bidireccional para interactuar con los modelos de voz. La mayoría de los modelos de voz exponen API WebSocket en tiempo real, que el tiempo de ejecución de su agente o el marco de orquestación pueden consumir para entrada de audio y salida de texto o voz. La selección del modelo juega un papel clave para lograr una capacidad de respuesta natural. Seleccione modelos como Amazon Nova Sonic (o Amazon Nova Lite en un enfoque de canalización en cascada) que estén optimizados para la latencia y proporcionen un tiempo de obtención del primer token (TTFT) rápido. Telefonía: Para llamadas entrantes o salientes tradicionales manejadas a través de centros de contacto o sistemas de telefonía, su agente de voz también debe integrarse con un proveedor de telefonía. Esto generalmente se logra mediante una transferencia y/o una transferencia del Protocolo de interconexión de sesión (SIP), donde la transmisión de audio en vivo se transfiere desde el sistema de telefonía al tiempo de ejecución de su agente para su procesamiento.
En la Parte 1 de esta serie, nos centraremos en la conexión de Cliente a Agente y en cómo minimizar la latencia de red del primer salto desde su dispositivo perimetral a su agente de voz y exploraremos consideraciones adicionales en relación con otros componentes de la arquitectura del agente de voz.
Para ilustrar estos conceptos, exploraremos cuatro enfoques de transporte en red teniendo en cuenta:
Cómo interactúan los usuarios con sus agentes de voz (aplicaciones web/móviles o llamadas telefónicas) Coherencia del rendimiento y resiliencia en condiciones de red variables Facilidad de implementación Enfoque Descripción Coherencia del rendimiento Facilidad de implementación Adecuado para WebSockets Las aplicaciones web y móviles se conectan directamente a sus agentes de voz a través de WebSockets. Buenos prototipos simples y casos de uso livianos. Las aplicaciones web y móviles WebRTC (asistidas por TURN) se conectan directamente a sus agentes de voz a través de WebRTC. Excelentes casos de uso de producción media con latencia derivada de la conexión directa del cliente al entorno de ejecución retransmitida mediante recorrido transversal mediante retransmisiones alrededor de servidores NAT (TURN). WebRTC (administrado) Las aplicaciones web y móviles se conectan a sus agentes de voz a través de una infraestructura avanzada distribuida globalmente a través de WebRTC. Excelente (distribución global) Casos de uso de producción simples con optimización de latencia descargados a proveedores especializados con retransmisiones de medios y redes distribuidas globalmente. Ofrece capacidades adicionales como observabilidad y llamadas de múltiples participantes. Se accede a los agentes de Telefonía Voz a través de llamadas telefónicas tradicionales. Excelentes casos de uso de telefonía y contact center Medio. La latencia puede depender del proveedor de telefonía.
Enfoque de ejemplo: uso de transmisión bidireccional de WebSockets
Puede comenzar con WebSockets como el enfoque más simple: admite de forma nativa la mayoría de los clientes y AgentCore Runtime. Implemente agentes de voz de Pipecat en AgentCore Runtime utilizando conexiones WebSocket bidireccionales y persistentes para la transmisión de audio entre dispositivos cliente y la lógica de su agente.
La conexión sigue un sencillo flujo de tres pasos:
El cliente solicita un punto final de WebSocket: el cliente primero envía una solicitud POST a un servidor intermediario (/servidor) para obtener un punto final de conexión WebSocket segura. El servidor intermediario maneja la autenticación de AWS: el servidor intermediario en la interfaz prediseñada de Pipecat utiliza el SDK de AWS para generar una URL prefirmada de AWS SigV4 con credenciales integradas como parámetro de consulta. Por ejemplo: X?-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential= El cliente establece una conexión directa: utilizando la URL prefirmada y autenticada, el cliente se conecta directamente al agente en AgentCore Runtime y transmite audio bidireccional, sin pasar por el servidor intermediario para comunicaciones posteriores.
Utilice el transporte WebSocket de Pipecat para exponer un punto final en la ruta /ws según lo requiere AgentCore Runtime. La arquitectura separa la administración de credenciales de la lógica del agente para lograr un acceso seguro de los clientes sin exponer las credenciales de AWS directamente a las aplicaciones del navegador.
Para obtener más información, pruebe el ejemplo de código de Pipecat en AgentCore utilizando el transporte WebSockets.
Enfoque de ejemplo: uso de transmisión bidireccional WebRTC con asistencia TURN
Si bien WebSockets funciona para implementaciones simples, WebRTC puede ofrecer un rendimiento mejorado. Está diseñado para enviar audio mediante una ruta de red rápida y liviana que minimiza el retraso. Por lo general, utiliza UDP por su baja latencia y una experiencia más fluida en tiempo real, y proporciona una resiliencia mejorada en condiciones de red variables. Si UDP no está disponible, WebRTC recurre automáticamente a TCP, que es más confiable pero puede introducir ligeros retrasos: menos ideal para voz, pero útil cuando la conectividad está restringida. Esta confiabilidad proviene de los servidores Interactive Connectivity Establishment (ICE), que negocian rutas directas de igual a igual a través de NAT y firewalls, recurriendo a la transmisión de medios de transmisión a través de Traversal Usando Retransmisiones alrededor de servidores NAT (TURN) cuando no se pueden establecer conexiones directas.
Pipecat admite SmallWebRTCTransport para conexiones WebRTC directas de igual a igual entre clientes y agentes en AgentCore Runtime. En comparación con las arquitecturas WebRTC integrales que requieren servidores de medios dedicados (como unidades de reenvío selectivo o SFU), este transporte liviano puede ejecutarse directamente dentro de AgentCore Runtime, eliminando la necesidad de una administración compleja del servidor de medios.
En este escenario, el flujo de conexión funciona de la siguiente manera:
Señalización: el cliente envía una oferta de Protocolo de descripción de sesión (SDP) al servidor intermediario, que la reenvía al punto final /invoke/ en AgentCore Runtime. El controlador del agente @app.entrypoint procesa la oferta y devuelve una respuesta SDP que contiene capacidades de medios y candidatos de red. Establecimiento de conectividad: para establecer una conexión directa, tanto el cliente como el agente utilizan el protocolo de establecimiento de conectividad interactiva (ICE) para descubrir la ruta de red óptima. AgentCore Runtime admite el uso transversal de retransmisiones alrededor de conexiones retransmitidas NAT (TURN). El protocolo intenta la conectividad en este orden: Conexión directa: conexión de igual a igual utilizando direcciones de red local. Esta ruta no es compatible con AgentCore Runtime ya que el entorno de ejecución no se puede asignar a una dirección IP pública. Utilidades transversales de sesión para conexión asistida por NAT (STUN): utilice un servidor STUN para descubrir IP/puerto público a través de la traducción de direcciones de red (NAT) e intentar la conectividad directa. Esta ruta requiere tráfico UDP entrante y saliente que actualmente no es compatible ya que AWS NAT Gateways utiliza NAT simétrica, lo que impide que la conectividad directa basada en STUN tenga éxito. Transversal usando retransmisiones alrededor de una conexión retransmitida NAT (TURN): enrute los medios a través de un servidor de retransmisión TURN. Configure TURN utilizando servicios administrados (como Cloudflare o Twilio), Amazon Kinesis Video Streams (KVS) o soluciones autohospedadas (como coturn en su VPC). Esta ruta se recomienda en AgentCore Runtime configurado con una VPC (consulte los detalles a continuación). Conexión a través de VPC: una vez que se establece la conectividad, el tráfico se enrutará desde el cliente al entorno de ejecución a través de la VPC (más detalles en la siguiente sección).
Para obtener más información, pruebe el ejemplo de código de Pipecat en AgentCore utilizando el transporte WebRTC.
Configuración de AgentCore Runtime en VPC para conectividad WebRTC
El ejemplo de código muestra un agente de voz simple que utiliza WebRTC. Primero, configura las variables de entorno ICE_SERVER_URLS en ambos: 1) el servidor intermediario en la interfaz prediseñada de Pipecat (/server) y 2) el entorno de ejecución (/agent). Esto permite el tráfico bidireccional entre ellos.
A continuación, implementa sus agentes en AgentCore Runtime con la red VPC configurada para permitir el transporte UDP a los servidores TURN. Por seguridad, expone el tiempo de ejecución a una subred VPC privada, con una puerta de enlace NAT en la subred pública para enrutar el acceso a Internet, como se ilustra a continuación.
Con este enfoque, puede configurar servidores ICE para una conectividad WebRTC completa, tanto con STUN como con UDP con respaldo de TCP. Por ejemplo, puedes configurar TURN administrado por Cloudflare de la siguiente manera:
# Configurar agente/.env y servidor/.env ICE_SERVER_URLS=stun:stun.cloudflare.com,turn:turn.cloudflare.com:53,turn:turn.cloudflare.com:3478,turn:turn.cloudflare.com:5349
Uso de TURN nativo de AWS con Amazon Kinesis Video Streams (KVS)
Como alternativa totalmente nativa de AWS a los servicios TURN administrados, Amazon Kinesis Video Streams (KVS) maneja la infraestructura TURN sin dependencias de terceros. Proporciona credenciales TURN temporales y de rotación automática a través de la API GetIceServerConfig, evitando dependencias de terceros para el recorrido NAT. El flujo funciona de la siguiente manera:
Configuración única: cree un canal de señalización KVS. El canal se usa solo para el aprovisionamiento de credenciales TURN; su agente continúa usando el transporte WebRTC de Pipecat para señalización y medios. En el momento de la conexión: su agente llama a GetSignalingChannelEndpoint para obtener el punto final HTTPS y luego llama a GetIceServerConfig para recuperar las credenciales TURN temporales (URI, nombre de usuario, contraseña). Configure la conexión entre pares: pase las credenciales devueltas a su RTCPeerConnection como servidores ICE. El tráfico TURN fluye a través de la infraestructura administrada por KVS.
Consideraciones al utilizar TURN administrado por KVS
Factor KVS TURN administrado TURN de terceros nativo de AWS Sí, sin dependencia externa No, requiere una cuenta externa Administración de credenciales Rotación automática Manual o administrado por el proveedor Configuración Crear canal de señalización + llamadas API Configurar variables de entorno Lo mejor para implementaciones centradas en AWS Simplicidad o relaciones con proveedores existentes
Consideraciones adicionales:
Costo: Cada canal de señalización activo cuesta $0.03/mes. En un volumen bajo a moderado, esto es insignificante. Límite de velocidad: GetIceServerConfig está limitado a 5 transacciones por segundo (TPS) por canal. Para implementaciones de gran volumen que superen las 100 000 sesiones por mes, implemente una estrategia de agrupación de canales en la que distribuya las solicitudes en varios canales: canales_necesarios = ceil(pico_nuevas_sesiones_por_segundo/5). Sin PrivateLink: la VPC aún requiere salida de Internet (a través de la puerta de enlace NAT) para llegar a los puntos finales de KVS TURN. Vigencia de la credencial: las credenciales de KVS TURN son temporales y rotan automáticamente, por lo que no es necesario administrar la rotación de credenciales.
Para obtener más información, pruebe el ejemplo de código utilizando TURN administrado por KVS.
Enfoque de ejemplo: uso de WebRTC administrado en AWS Marketplace
Si bien WebRTC directo ofrece control, los proveedores de WebRTC administrados comúnmente proporcionan servidores TURN y SFU distribuidas globalmente para facilitar una conectividad confiable y un enrutamiento de medios de baja latencia. También proporciona funciones adicionales, como análisis y observabilidad integrados, y soporte para salas de múltiples participantes más allá de las conversaciones de agentes 1:1. Para agentes de voz de producción a escala, considere los proveedores administrados disponibles en AWS Marketplace, como Daily. Daily ejecuta su infraestructura WebRTC distribuida globalmente en AWS y ofrece múltiples modelos de implementación:
SaaS totalmente administrado: se conecta a la infraestructura alojada de Daily a través de puntos finales API públicos. Esto es ideal para implementaciones rápidas y entornos donde se prioriza la simplicidad operativa. En este escenario, su agente en AgentCore Runtime puede simplemente conectarse a la infraestructura WebRTC administrada a través de la Internet pública. Implementación de VPC del cliente: usted implementa los servidores de medios de Daily directamente en su VPC para lograr un control completo de la red y cumplir con estrictos requisitos de residencia de datos. En este escenario, configura AgentCore Runtime para VPC como se describe anteriormente. SaaS con AWS PrivateLink: se conecta a la infraestructura alojada de Daily y configura AWS PrivateLink para que el tráfico fluya a través de los puntos finales de VPC directamente a la infraestructura administrada de Daily sin atravesar la Internet pública, lo que reduce la latencia y al mismo tiempo mantiene el aislamiento de la red con respecto a la red troncal de AWS. En este escenario, configura AgentCore Runtime para VPC como se describe anteriormente.
Para obtener más información, comuníquese con su equipo de cuenta de AWS para explorar Daily en AWS Marketplace o pruebe el código de muestra usando Daily transport y su DAILY_API_KEY en la opción SaaS totalmente administrada.
Enfoque de ejemplo: utilizar un proveedor de telefonía
Si bien WebRTC se destaca para canales web y móviles, la transferencia de telefonía permite la integración tradicional de la red telefónica pública conmutada (PSTN) para centros de contacto, reemplazo de IVR y campañas salientes. Para una conversación en tiempo real, el tiempo de ejecución de su agente debe mantener un flujo de audio bidireccional persistente con sus modelos de voz, lógica empresarial y proveedor de telefonía. Estos proveedores ofrecen servicios de voz administrados que manejan la complejidad de la infraestructura telefónica tradicional a través de API simples. Dependiendo de las capacidades del proveedor de telefonía, la integración se realiza mediante el protocolo de inicio de sesión (SIP) o los protocolos de transmisión WebSocket o WebRTC. Los transportes y serializadores de Pipecat proporcionan conectores para la implementación.
Para obtener más información, consulte la Guía Pipecat sobre telefonía y creación de aplicaciones de voz impulsadas por IA: Guía de integración de telefonía.
Conclusión
AgentCore Runtime proporciona una infraestructura segura y sin servidor para escalar agentes de voz de manera confiable. En esta publicación, aprendió cómo la baja latencia es fundamental para las conversaciones naturales y consideraciones clave para diferentes modos de transporte: WebSockets, WebRTC asistido por TURN, WebRTC administrado e integraciones de telefonía, según sus requisitos de latencia, confiabilidad y uso. Al evaluar las opciones de transporte, comience de manera simple con WebSockets para crear prototipos rápidos, luego considere WebRTC con AgentCore en modo VPC o proveedores administrados para implementaciones de producción. Si sus agentes de voz tienen la intención de manejar casos de uso de telefonía o centros de contacto, considere las integraciones disponibles con proveedores de telefonía para su implementación.
En la Parte 2 de esta serie, explorará consideraciones adicionales más allá del transporte de red: cubrirá estrategias de transmisión a través de la comunicación de agente a modelo, ejecución de herramientas, memoria y recuperación para lograr una latencia óptima de un extremo a otro.
Comience con los ejemplos de código de Pipecat en AgentCore y el taller práctico a continuación y elija la capa de transporte que se ajuste a su caso de uso:
Para los equipos que prefieren un mayor control de la infraestructura, la Guía para crear agentes de voz en AWS en Amazon ECS también está disponible como opción de implementación en contenedores.
Recursos adicionales
Sobre los autores
Kwindla Hultman Kramer es cofundadora y directora ejecutiva de Daily, empresa pionera en infraestructura de inteligencia artificial multimodal, video y voz en tiempo real de baja latencia. Líder intelectual líder en inteligencia artificial de voz, creó el marco Pipecat de código abierto para agentes de voz de producción y comparte ideas en reuniones de inteligencia artificial de voz y en su cuenta X (@kwindla).
Paul Kompfner es miembro del personal técnico de Daily, donde forma parte del equipo que mantiene el marco de código abierto Pipecat. Es un experto en infraestructura de streaming y sistemas de agencia basados en voz. Con frecuencia colabora con AWS y el ecosistema de inteligencia artificial de voz para brindar soporte de primera clase para modelos de voz y plataformas de alojamiento para permitir una inteligencia artificial de voz escalable en tiempo real en Pipecat.
Kosti Vasilakakis es PM principal en AWS en el equipo de Agentic AI, donde ha dirigido el diseño y desarrollo de varios servicios Bedrock AgentCore desde cero, incluido Runtime. Anteriormente trabajó en Amazon SageMaker desde sus inicios, lanzando capacidades de IA/ML que ahora utilizan miles de empresas en todo el mundo. Al principio de su carrera, Kosti fue científico de datos. Fuera del trabajo, construye automatizaciones de productividad personal, juega tenis y explora la naturaleza con su familia.
Lana Zhang es arquitecta de soluciones senior en el equipo de servicios de inteligencia artificial de la organización mundial especializada de AWS, y se especializa en inteligencia artificial e inteligencia artificial generativa con un enfoque en casos de uso que incluyen moderación de contenido y análisis de medios. Se dedica a promover la IA de AWS y las soluciones de IA generativa, demostrando cómo la IA generativa puede transformar los casos de uso clásicos añadiendo valor empresarial. Ayuda a los clientes a transformar sus soluciones comerciales en diversas industrias, incluidas las redes sociales, los juegos, el comercio electrónico, los medios, la publicidad y el marketing.
Sundar Raghavan es arquitecto de soluciones en AWS y forma parte del equipo de Agentic AI. Dio forma a la experiencia de desarrollador de Amazon Bedrock AgentCore, contribuyendo al SDK, la CLI y el kit de herramientas de inicio, y ahora se centra en las integraciones con marcos de agentes de IA. Anteriormente, Sundar trabajó como especialista en IA generativa, ayudando a los clientes a diseñar aplicaciones de IA en Amazon Bedrock. En su tiempo libre, le encanta explorar nuevos lugares, probar restaurantes locales y disfrutar del aire libre.
Daniel Wirjo es arquitecto de soluciones en AWS, enfocado en startups de IA y SaaS. Como ex director de tecnología de una startup, le gusta colaborar con fundadores y líderes de ingeniería para impulsar el crecimiento y la innovación en AWS. Fuera del trabajo, Daniel disfruta caminar con un café en la mano, apreciar la naturaleza y aprender nuevas ideas.