User's blog

Implantação de Agentes de Voz com Pipecat e Amazon Bedrock AgentCore Runtime – Parte 1

Written by

Make.com Service User

in

Introdução aos Desafios de Agentes de Voz em Tempo Real

Implantar agentes de voz inteligentes que mantêm conversas naturais e semelhantes às humanas é uma tarefa complexa. Esses sistemas precisam transmitir áudio para usuários em múltiplos canais — aplicações web, móveis e telefônicas — mantendo responsividade mesmo sob tráfego pesado e condições de conectividade instáveis. Pequenos atrasos podem interromper o fluxo conversacional, fazendo o agente parecer não responsivo ou pouco confiável.

Para casos de uso como atendimento ao cliente, assistentes virtuais e campanhas de outbound, manter um fluxo conversacional natural é essencial para a experiência do usuário. A série de artigos sobre este tema explora como arquiteturas de streaming ajudam a resolver esses desafios usando agentes de voz Pipecat no Amazon Bedrock AgentCore Runtime.

Nesta primeira parte, você aprenderá como implantar agentes de voz Pipecat no AgentCore Runtime usando diferentes abordagens de transporte de rede — incluindo WebSockets, WebRTC e integração telefônica — com orientações práticas de implantação e exemplos de código.

Benefícios do AgentCore Runtime para Agentes de Voz

Implantação de agentes de voz em tempo real apresenta desafios significativos: é necessário garantir streaming com baixa latência, isolamento rigoroso para segurança e capacidade de escalar dinamicamente conforme o volume de conversas varia de forma imprevisível. Sem uma arquitetura bem projetada, você pode enfrentar jitter de áudio, limitações de escalabilidade, custos inflacionados por sobre-provisionamento e maior complexidade operacional.

Para compreender melhor as arquiteturas de agentes de voz, incluindo abordagens em cascata (conversão de fala para texto → modelo de linguagem → conversão de texto para fala) e processamento direto entre falas, consulte o artigo anterior sobre construção de assistentes de voz em tempo real com Amazon Nova Sonic comparado a arquiteturas em cascata.

O Amazon Bedrock AgentCore Runtime resolve esses desafios fornecendo um ambiente seguro e serverless para escalar agentes de IA dinâmicos. Cada sessão de conversa é executada em microVMs isoladas para segurança. O serviço faz auto-scaling para picos de tráfego e mantém sessões contínuas por até 8 horas, sendo ideal para interações de voz longas com múltiplas voltas. Cobra apenas pelos recursos efetivamente utilizados, minimizando custos associados a infraestrutura ociosa.

O Pipecat, um framework para construir pipelines de IA de voz em tempo real, funciona no AgentCore Runtime com configuração mínima. Você empacota seu pipeline de voz Pipecat como um container e o implanta diretamente no AgentCore Runtime. O runtime suporta streaming bidirecional para áudio em tempo real e oferece observabilidade integrada para rastrear o raciocínio do agente e chamadas a ferramentas. Uma consideração importante: o AgentCore Runtime requer containers ARM64 (Graviton), então certifique-se de que suas imagens Docker foram compiladas para o sistema linux/arm64.

Arquiteturas de Streaming para Agentes de Voz no AgentCore Runtime

Este artigo pressupõe familiaridade com arquiteturas comuns de agentes de voz, especificamente a abordagem de modelos em cascata, onde você conecta modelos de conversão de fala para texto (STT – Conversão de Fala para Texto) e texto para fala (TTS – Conversão de Texto para Fala) em um pipeline, e a abordagem de processamento direto entre falas, como Amazon Nova Sonic. Se você é novo nesses conceitos, comece com os artigos anteriores sobre as duas abordagens fundamentais: cascata e processamento direto entre falas antes de prosseguir.

Na construção de agentes de voz, a latência é uma consideração crítica que determina o quão natural e confiável é uma conversa por voz. As conversas exigem respostas quase instantâneas, tipicamente em menos de um segundo de ponta a ponta, para manter um ritmo fluido e semelhante ao humano. Para alcançar baixa latência, você precisa considerar streaming bidirecional em múltiplos caminhos:

  • Cliente para Agente: Seus agentes de voz serão executados em dispositivos e aplicações variadas, desde navegadores web e apps móveis até hardware de borda, cada um com condições de rede únicas.
  • Agente para Modelo: Seus agentes de voz dependem de streaming bidirecional para interagir com modelos de fala. A maioria dos modelos de fala expõe APIs WebSocket em tempo real, que seu runtime de agente ou framework de orquestração pode consumir para entrada de áudio e saída de texto ou fala.
  • Telefonia: Para chamadas tradicionais de entrada ou saída tratadas através de centros de contato ou sistemas telefônicos, seu agente de voz também deve ser integrado com um provedor de telefonia. Isso é tipicamente realizado através de transferência de handoff e/ou Protocolo de Interconexão de Sessão (SIP – Protocolo de Iniciação de Sessão), onde o stream de áudio ativo é transferido do sistema telefônico para seu runtime de agente para processamento.

A seleção do modelo desempenha um papel fundamental para alcançar responsividade natural. Escolha modelos como Amazon Nova Sonic (ou Amazon Nova Lite em uma abordagem de pipeline em cascata) que são otimizados para latência e oferecem tempo rápido até o primeiro token (TTFT – Time-to-First-Token).

Abordagens de Transporte de Rede

Nesta primeira parte, nos concentramos na conexão Cliente para Agente e em como minimizar a latência de primeira volta de rede entre seu dispositivo de borda e seu agente de voz. A seguir, exploramos quatro abordagens de transporte de rede, considerando performance, resiliência e facilidade de implementação:

  • WebSockets: Aplicações web e móveis conectam-se diretamente aos agentes de voz via WebSockets. Performance consistente adequada, implementação simples, ideal para prototipagem e casos de uso leves.
  • WebRTC com TURN: Aplicações web e móveis conectam-se aos agentes via WebRTC com assistência de servidores de retransmissão (Traversal Using Relays around NAT – TURN). Performance excelente, implementação média, adequado para casos de produção com latência reduzida via conexão direta do cliente ao runtime com retransmissão via servidores TURN.
  • WebRTC Gerenciado: Aplicações web e móveis conectam-se aos agentes através de infraestrutura avançada e distribuída globalmente via WebRTC. Performance excelente com distribuição global, implementação simples, adequado para casos de produção com otimização de latência terceirizada para provedores especializados com rede distribuída globalmente e retransmissão de mídia. Oferece capacidades adicionais como observabilidade e chamadas multi-participante.
  • Telefonia: Agentes de voz são acessados através de chamadas telefônicas tradicionais. Performance excelente, implementação média, adequado para centros de contato e casos de telefonia. Latência pode depender do provedor de telefonia.

Implementação com WebSockets

Você pode começar com WebSockets como a abordagem mais simples: suporta nativamente a maioria dos clientes e o AgentCore Runtime. Implante agentes de voz Pipecat no AgentCore Runtime usando conexões WebSocket persistentes e bidirecionais para streaming de áudio entre dispositivos cliente e sua lógica de agente.

A conexão segue um fluxo simples de três etapas:

  • Cliente solicita um endpoint WebSocket: O cliente primeiro envia uma solicitação POST para um servidor intermediário (/server) para obter um endpoint seguro de conexão WebSocket.
  • Servidor intermediário manipula autenticação AWS: O servidor intermediário na interface pré-construída Pipecat usa o AWS SDK para gerar uma URL pré-assinada AWS SigV4 com credenciais incorporadas como parâmetro de consulta.
  • Cliente estabelece conexão direta: Usando a URL pré-assinada autenticada, o cliente conecta-se diretamente ao agente no AgentCore Runtime e transmite áudio bidirecional, contornando o servidor intermediário para comunicações subsequentes.

Você usa o transporte WebSocket do Pipecat para expor um endpoint no caminho /ws conforme exigido pelo AgentCore Runtime. A arquitetura separa gerenciamento de credenciais da lógica do agente, permitindo acesso seguro do cliente sem expor credenciais AWS diretamente a aplicações de navegador.

Para saber mais, experimente o exemplo de código Pipecat no AgentCore usando transporte WebSockets.

Implementação com WebRTC e Assistência TURN

Embora WebSockets funcione bem para implantações simples, WebRTC pode oferecer performance melhorada. É projetado para enviar áudio usando um caminho de rede rápido e leve que minimiza atraso. Geralmente usa UDP por sua baixa latência e experiência mais suave em tempo real, oferecendo resiliência melhorada através de condições variáveis de conectividade. Se UDP não estiver disponível, WebRTC retorna automaticamente para TCP, que é mais confiável mas pode introduzir pequenos atrasos — menos ideal para voz, mas útil quando a conectividade é restrita.

Essa confiabilidade vem dos servidores de Estabelecimento Interativo de Conectividade (ICE – Interactive Connectivity Establishment), que negociam caminhos diretos ponto-a-ponto através de NATs e firewalls, retrocedendo para retransmissão de mídia via servidores Traversal Using Relays around NAT (TURN) quando conexões diretas não podem ser estabelecidas.

O Pipecat suporta SmallWebRTCTransport para conexões WebRTC ponto-a-ponto diretas entre clientes e agentes no AgentCore Runtime. Comparado a arquiteturas WebRTC abrangentes que exigem servidores de mídia dedicados (como Unidades de Encaminhamento Seletivo), esse transporte leve pode ser executado diretamente dentro do AgentCore Runtime, eliminando a necessidade de gerenciamento complexo de servidores de mídia.

Nesse cenário, o fluxo de conexão funciona da seguinte forma:

  • Sinalização: O cliente envia uma oferta de Protocolo de Descrição de Sessão (SDP – Session Description Protocol) para o servidor intermediário, que a encaminha para o endpoint /invoke/ no AgentCore Runtime. O manipulador @app.entrypoint do agente processa a oferta e retorna uma resposta SDP contendo capacidades de mídia e candidatos de rede.
  • Estabelecimento de Conectividade: Para estabelecer uma conexão direta, tanto o cliente quanto o agente usam o protocolo ICE (Interactive Connectivity Establishment) para descobrir o caminho de rede ideal.

O AgentCore Runtime suporta conexões retransmitidas via TURN. O protocolo tenta conectividade nesta ordem: conexão direta ponto-a-ponto (não suportada no AgentCore Runtime, pois o ambiente runtime não pode ser atribuído a um endereço IP público), conexão assistida por STUN (requer tráfego UDP bidirecional, não suportado atualmente), e retransmissão via TURN (recomendada).

Para aprender mais, experimente o exemplo de código Pipecat no AgentCore usando transporte WebRTC.

Configuração do AgentCore Runtime com VPC para Conectividade WebRTC

O exemplo de código demonstra um agente de voz simples usando WebRTC. Primeiro, você configura variáveis de ambiente ICE_SERVER_URLS em ambos: 1) o servidor intermediário na interface pré-construída Pipecat (/server) e 2) o ambiente runtime (/agent). Isso permite tráfego bidirecional entre eles.

Em seguida, você implanta seus agentes no AgentCore Runtime com VPC configurado para permitir transporte UDP para servidores TURN. Para segurança, você expõe o runtime para uma subnet VPC privada, com um NAT Gateway em uma subnet pública para rotear acesso à internet.

Imagem original — fonte: Aws

Com essa abordagem, você pode configurar servidores ICE para conectividade WebRTC completa, com suporte a STUN e UDP com fallback para TCP. Por exemplo, você pode configurar TURN gerenciado por Cloudflare da seguinte forma:

# Configure agent/.env and server/.env
ICE_SERVER_URLS=stun:stun.cloudflare.com,turn:turn.cloudflare.com:53,turn:turn.cloudflare.com:3478,turn:turn.cloudflare.com:5349

TURN Nativo da AWS com Amazon Kinesis Video Streams

Como alternativa totalmente nativa da AWS a serviços TURN gerenciados, Amazon Kinesis Video Streams (KVS) gerencia infraestrutura TURN sem dependências de terceiros. Fornece credenciais TURN temporárias e com rotação automática via API GetIceServerConfig, evitando dependências de terceiros para travessia NAT.

O fluxo funciona da seguinte forma:

  • Configuração única: Crie um canal de sinalização KVS. O canal é usado apenas para provisionamento de credenciais TURN — seu agente continua usando o transporte WebRTC do Pipecat para sinalização e mídia.
  • No momento da conexão: Seu agente chama GetSignalingChannelEndpoint para obter o endpoint HTTPS, depois chama GetIceServerConfig para recuperar credenciais TURN temporárias (URIs, nome de usuário, senha).
  • Configure a conexão par: Passe as credenciais retornadas para sua RTCPeerConnection como servidores ICE. O tráfego TURN flui através da infraestrutura gerenciada por KVS.

Considerações ao usar TURN gerenciado por KVS:

  • É nativo da AWS sem dependência externa.
  • Gerenciamento de credenciais com rotação automática.
  • Configuração via criação de canal de sinalização e chamadas de API.
  • Ideal para implantações centradas em AWS.
  • Custo: Cada canal de sinalização ativo custa 0,03 dólares/mês. Em volume baixo a moderado, isso é negligenciável.
  • Limite de taxa: GetIceServerConfig é limitado a 5 transações por segundo por canal. Para implantações de alto volume excedendo 100.000 sessões por mês, implemente uma estratégia de pool de canais distribuindo requisições entre múltiplos canais.
  • Não há suporte PrivateLink: a VPC ainda requer egresso à internet via NAT Gateway para alcançar endpoints TURN do KVS.
  • Credenciais TURN são temporárias e com rotação automática, sem necessidade de gerenciar rotação.

Para saber mais, experimente o exemplo de código usando TURN gerenciado por KVS.

Implementação com WebRTC Gerenciado

Embora WebRTC direto ofereça controle, provedores de WebRTC gerenciados comumente fornecem servidores TURN e Unidades de Encaminhamento Seletivo (SFUs – Selective Forwarding Units) distribuídas globalmente para facilitar conectividade confiável e roteamento de mídia com baixa latência. Também fornecem recursos adicionais como análises integradas e observabilidade, e suporte para salas multi-participante além de conversas 1:1 com agentes.

Para agentes de voz em produção em escala, considere provedores gerenciados disponíveis no AWS Marketplace, como Daily. A Daily executa sua infraestrutura WebRTC distribuída globalmente na AWS oferecendo múltiplos modelos de implantação:

  • SaaS Totalmente Gerenciado: Você conecta à infraestrutura hospedada da Daily via endpoints de API pública. Ideal para implantação rápida e ambientes onde simplicidade operacional é priorizada. Nesse cenário, seu agente no AgentCore Runtime pode simplesmente conectar-se à infraestrutura WebRTC gerenciada via internet pública.
  • Implantação em VPC do Cliente: Você implanta os servidores de mídia da Daily diretamente em sua VPC para controle completo de rede e conformidade com requisitos rigorosos de residência de dados. Nesse cenário, você configura AgentCore Runtime para VPC conforme descrito acima.
  • SaaS com AWS PrivateLink: Você conecta à infraestrutura hospedada da Daily e configura AWS PrivateLink para que o tráfego flua através de endpoints VPC diretamente para a infraestrutura gerenciada da Daily sem atravessar a internet pública, reduzindo latência mantendo isolamento de rede. Nesse cenário, você configura AgentCore Runtime para VPC conforme descrito acima.

Para saber mais, entre em contato com sua equipe de conta AWS para explorar Daily no AWS Marketplace ou experimente o exemplo de código usando transporte Daily na opção SaaS totalmente gerenciada.

Integração com Provedores de Telefonia

Enquanto WebRTC se destaca para canais web e móvel, a transferência telefônica permite integração tradicional da Rede Telefônica Pública Comutada (PSTN – Public Switched Telephone Network) para centros de contato, substituição de IVR e campanhas de outbound. Para conversa em tempo real, seu runtime de agente deve manter um stream de áudio persistente e bidirecional com seus modelos de fala, lógica de negócio e provedor de telefonia.

Esses provedores oferecem serviços de voz gerenciados que lidam com a complexidade da infraestrutura telefônica tradicional através de APIs simples. Dependendo das capacidades do provedor de telefonia, você se integra a eles usando Protocolo de Iniciação de Sessão (SIP – Session Initiation Protocol) ou protocolos de streaming WebSocket ou WebRTC.

Os transportes e serializadores do Pipecat fornecem conectores para implementação. Para saber mais, consulte o Guia Pipecat sobre Telefonia e o Guia de Integração de Telefonia para Aplicações de Voz Alimentadas por IA.

Conclusão

O AgentCore Runtime fornece infraestrutura segura e serverless para escalar agentes de voz confiáveis. Neste artigo, você aprendeu como baixa latência é crítica para conversas naturais e considerações-chave para diferentes modos de transporte: WebSockets, WebRTC com assistência TURN, WebRTC gerenciado e integrações telefônicas, com base em seus requisitos de latência, confiabilidade e uso.

Ao avaliar opções de transporte, comece simples com WebSockets para prototipagem rápida, depois considere WebRTC com AgentCore em modo VPC ou provedores gerenciados para implantações em produção. Se seus agentes de voz pretendem lidar com casos de telefonia ou centros de contato, considere integrações disponíveis com provedores de telefonia para sua implementação.

Na Parte 2 desta série, você explorará considerações adicionais além do transporte de rede: cobrindo estratégias de streaming através de comunicação agente-para-modelo, execução de ferramentas, memória e recuperação para alcançar latência ótima de ponta a ponta.

Comece Agora

Acesse os exemplos de código e workshop prático:

Para equipes que preferem mais controle de infraestrutura, a Orientação para Construir Agentes de Voz na AWS no Amazon ECS também está disponível como opção de implantação containerizada.

Recursos Adicionais

Fonte

Deploy voice agents with Pipecat and Amazon Bedrock AgentCore Runtime – Part 1 (https://aws.amazon.com/blogs/machine-learning/deploy-voice-agents-with-pipecat-and-amazon-bedrock-agentcore-runtime-part-1/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts