Construyendo un Agente de Voz de Menos de 500ms: Arquitectura y Perspectivas de Rendimiento

Arquitectura y Rendimiento del Agente de Voz
Nick Tikhonov construyó un agente de voz desde cero que promedia ~400ms de latencia de extremo a extremo (parada del teléfono → primera sílaba). Esto incluye STT → LLM → TTS completo en el bucle con interrupciones limpias y sin respuestas precalculadas. La implementación superó la configuración equivalente de Vapi por 2× en latencia.
Ideas Técnicas Fundamentales
La clave fue darse cuenta de que la voz es un problema de toma de turnos, no un problema de transcripción. La Detección de Actividad de Voz (VAD) por sí sola falla; se requiere detección semántica de fin de turno. El sistema se reduce a un bucle con dos estados: hablando vs escuchando.
Las transiciones críticas son:
- Cancelar instantáneamente en interrupción
- Responder instantáneamente al final del turno
Requisitos Técnicos
STT → LLM → TTS debe transmitir. Las canalizaciones secuenciales son ineficaces para conversaciones naturales. El Tiempo al Primer Token (TTFT) domina todo en interfaces de voz: el primer token es la ruta crítica. El TTFT de ~80ms de Groq se identificó como la mayor mejora de rendimiento.
Consideraciones de Infraestructura
La geografía importa más que los prompts. Todos los componentes deben estar colocados o la latencia se vuelve prohibitiva antes de que el sistema comience a procesar. La construcción tomó aproximadamente un día y alrededor de $100 en créditos de API.
Por Qué los Agentes de Voz Son Desafiantes
Los agentes de voz representan un aumento significativo de complejidad en comparación con los agentes de texto. La orquestación es continua y en tiempo real, requiriendo una gestión cuidadosa de múltiples modelos simultáneamente. El sistema debe decidir constantemente si el usuario está hablando o escuchando, siendo las transiciones entre estos estados el aspecto más difícil.
Cuando el usuario comienza a hablar, el agente debe dejar de hablar inmediatamente: cancelar generación, cancelar síntesis de voz y vaciar cualquier audio en búfer. Cuando el usuario deja de hablar, el sistema debe decidir con confianza que ha terminado y comenzar a responder con el menor retraso posible.
Enfoque de Arquitectura
El desarrollador comenzó iterando sobre la arquitectura con ChatGPT fuera del editor para construir primero un modelo mental. Todo el problema se redujo a un solo bucle y una pequeña máquina de estados. La pregunta central que un agente de voz necesita responder es: ¿el usuario está hablando o escuchando?
Los dos estados son:
- El usuario está hablando
- El usuario está escuchando
Esta lógica de detección de turnos forma el núcleo de cada sistema de voz. La implementación está disponible en GitHub para referencia y desarrollo posterior.
📖 Read the full source: HN AI Agents
👀 Ver también

CRMy: CRM de Código Abierto y Motor de Contexto del Cliente para OpenClaw
CRMy es un CRM de código abierto y Motor de Contexto del Cliente (CCE) construido específicamente para agentes de OpenClaw. Incluye una CLI completa, un plugin para OpenClaw con 12 herramientas de CRM, un backend PostgreSQL y una implementación autohospedada con dos comandos.

El complemento OpenClaw agrega memoria persistente con el servidor Engram.
Un desarrollador creó un complemento de TypeScript que conecta agentes OpenClaw con Engram, un servidor de memoria basado en Go que utiliza SQLite con búsqueda FTS5. El complemento proporciona 11 herramientas, 4 ganchos de ciclo de vida y una recuperación automática que inyecta recuerdos relevantes en los prompts antes de cada turno del agente.

Gestión del contexto de IA con una tienda de conocimiento SQLite y herramientas MCP
Un desarrollador creó RunawayContext, un sistema con licencia MIT que almacena lecciones de proyectos en SQLite con FTS5 y sqlite-vec opcional, manteniendo el contexto por sesión por debajo de 3K tokens gracias a herramientas de consulta MCP y límites fijos en el código.

Configuración de OpenClaw en Máquina Virtual Ubuntu UTM con Acceso a API LLM y Ollama
Un usuario configuró exitosamente OpenClaw en una máquina virtual Ubuntu aislada en un Mac M3, con acceso tanto a Ollama local en macOS como a APIs externas de LLM como Gemini, Claude y DeepSeek. Los archivos de configuración de ejemplo y las notas de solución de problemas están disponibles en GitHub.