AnovaX: A Local, Multi-Agent Voice Assistant with LLM Planning, Typed Executors, and Adaptive Recovery

Resumo Técnico: AnovaX – Um Assistente de Voz Local e Multiagente

Declaração do Problema
Os assistentes de voz para desktop atuais (ex: Siri, Alexa, Google Assistant) dependem de pipelines na nuvem que transmitem áudio bruto para fora do dispositivo e oferecem um conjunto fixo e fechado de habilidades. Embora os modelos de linguagem de grande escala (LLMs) tenham resolvido o problema da compreensão da linguagem natural, os sistemas existentes falham em fornecer visibilidade, controle ou a capacidade de agir diretamente no ambiente desktop local. Os usuários não conseguem inspecionar o raciocínio por trás de um comando, adicionar habilidades personalizadas facilmente ou garantir que o áudio e os dados pessoais permaneçam locais. Existe uma lacuna para um sistema que seja prioritariamente local, capaz de interagir com aplicações desktop reais (abrir, digitar, teclas de atalho) e totalmente inspecionável por um operador humano.

Metodologia
O AnovaX é um assistente de voz local implementado em aproximadamente 1.800 linhas de Python e um arquivo HTML. Ele roda inteiramente na máquina do usuário, tratando o desktop como sua superfície de ação. A arquitetura do sistema consiste nos seguintes componentes principais:

1. Entrada e Controle de Palavra de Ativação: Uma thread de segundo plano utiliza a biblioteca SpeechRecognition para ouvir uma frase de ativação específica ("anova" + palavra de gatilho). Apenas frases reconhecidas são roteadas para o mecanismo de planejamento; conversas ambientes são descartadas.
2. Planejador de LLM (Caminho Estático): A lógica central utiliza um LLM (Gemini) para gerar um plano JSON único contendo uma sequência de chamadas de ferramentas, uma resposta falada final e atualizações de memória opcionais. O prompt do sistema impõe um esquema JSON estrito.
3. Filtro de Segurança de Dois Estágios: Antes da execução, cada plano (incluindo subplanos recursivos) passa por:
   • Restrições ao nível de prompt: Instruções explícitas no prompt do sistema para evitar ações perigosas.
   • Implementação ao nível de Python: Uma função safety_check() que valida contra uma lista de permissões (whitelist) de ferramentas permitidas, uma lista de negação (denylist) de palavras-chave perigosas (ex: rm -rf, sudo) e limites no tamanho do plano (máximo de 8 etapas, 2 níveis de recursão).
4. Orquestrador Multiagente: Em vez de um executor linear, o plano é despachado para um orquestrador Python que gera classes de agentes tipados.
   • Agentes Tipados: Dez classes de agentes específicos (ex: AppAgent, TypingAgent, BrowserAgent) correspondem às ferramentas. Cada um possui limites de Tempo de Vida (TTL) específicos, políticas de tentativa de reexecução (retry) e bloqueios de recursos.
   • Concorrência: Os agentes são agrupados e executados em um pool de threads limitado (capado em 8 trabalhadores). Ferramentas de leitura (ex: get_time, screenshot) são paralelizadas; ferramentas de entrada (digitação, clique) são serializadas via bloqueios de kb_mouse e tts para evitar condições de corrida (race conditions).
   • Planejamento Recursivo: Um MetaAgent permite que o LLM delegue subobjetivos de volta a si mesmo, limitado a dois níveis de aninhamento.
5. Loop de Recuperação Adaptativo: Se uma etapa "central" falhar (ex: um aplicativo falha ao abrir), o sistema muda do caminho estático para um loop de recuperação autônomo.
   • Este loop utiliza um prompt compacto no estilo ReAct para gerar um novo lote de ações.
   • Inclui paralelismo especulativo: enquanto o LLM decide o próximo passo, o sistema pré-executa ferramentas de leitura do plano original falho em segundo plano, ocultando a latência.
   • O loop é limitado (máximo de 6 turnos, 20 agentes totais) e reexecuta o filtro de segurança em cada iteração.
6. Memória e Observabilidade:
   • Memória de três camadas: Histórico de conversa baseado em RAM, estado da sessão (aplicativos abertos recentemente) e um repositório de fatos persistente em JSONL.
   • Companheiro Móvel: Um servidor Flask expõe o assistente via WiFi local. Ele transmite eventos do ciclo de vida dos agentes (via Server-Sent Events) e a tela do laptop (via MJPEG) para um celular, permitindo controle de voz remoto e verificação visual das ações.

Principais Contribuições
O artigo apresenta o AnovaX como uma descrição de sistema em vez de um estudo de benchmark, destacando quatro contribuições primárias:

• Orquestrador Multiagente Local: Um sistema onde um LLM planeja uma vez, e um processo pai em Python despacha agentes filhos tipados e limitados com políticas de tentativa de reexecução e bloqueios específicos, em vez de deixar o LLM controlar diretamente o SO.
• Filtro de Segurança de Dois Estágios: Um mecanismo de defesa robusto combinando instruções de prompt com uma lista rigorosa de permissões/negações baseada em Python que se aplica tanto aos planos estáticos quanto aos gerados recursivamente.
• Recuperação Adaptativa com Paralelismo Especulativo: Um mecanismo de recuperação que lida com falhas centrais através de um loop ReAct limitado enquanto executa simultaneamente ferramentas de leitura em segundo plano para mascarar a latência do LLM.
• Observabilidade Total e Controle Remoto: Um design que espelha cada transição de estado do agente para um dispositivo móvel e transmite a tela do desktop, permitindo que o usuário verifique as ações remotamente sem que o LLM acesse diretamente o teclado.

Resultos e Avaliação
A avaliação é qualitativa, baseada em um único laptop Windows 11 com 16GB de RAM.

• Capacidade: O sistema lida com sucesso diversas tarefas, incluindo lançar aplicações, digitar em janelas focadas, buscas na web, tirar capturas de tela e executar comandos compostos de múltiplas etapas (ex: "abrir calc, digitar 21+21, pressionar enter"). Ele recusa corretamente comandos perigosos (ex: deletar pastas).
• Latência: A latência de ponta a ponta é dominada por componentes dependentes de rede (Reconhecimento de Fala do Google: 0,6–1,4s; planejamento do Gemini: 0,7–2,0s). O orquestrador local adiciona um overhead negligenciável (<0,05s).
• Estudos de Ablação:
  • Desativar o LLM (fallback por regex) reduz a capacidade para comandos simples, mas mantém a segurança.
  • Desativar a memória quebra a resolução de contexto (ex: "digitar em isso").
  • Desativar os bloqueios causa condições de corrida em tarefas de digitação de múltiplas etapas.
  • Desativar o loop de recuperação resulta em falha permanente em erros menores (ex: nome de app incorreto), enquanto o loop consegue se adaptar.

Significância e Alegações
Os autores afirmam que o AnovaX demonstra que um "assistente de poucos milhares de linhas de código, legível" é suficiente para abrir aplicações, digitar nelas, coordenar ações concorrentes e recuperar-se de falhas sem depender de pipelines na nuvem para a execução de ações. A significância não reside em algoritmos inovadores, mas na razão e arquitetura: combinar uma única chamada de planejamento de LLM com um tempo de execução multiagente, tipado e limitado, e um filtro de segurança rigoroso.

O artigo afirma explicitamente que o objetivo não é competir com assistentes comerciais em escala ou precisão, mas mostrar que um sistema pode ser construído onde:

1. O áudio e os fatos pessoais permanecem locais (a menos que o usuário opte por compartilhar).
2. O assistente age em aplicações desktop reais.
3. Cada chamada de ferramenta é inspecionável, validada por lista de permissões e rejeitável.
4. O sistema é totalmente controlado a partir de um dispositivo remoto (celular) enquanto o usuário observa a execução em tempo real.

Os autores reconhecem limitações, incluindo a natureza "cega" do executor (sem percepção de tela), a dependência de APIs de nuvem para fala e planejamento (embora alternativas locais sejam mencionadas como trabalho futuro), e os riscos inerentes do streaming MJPEG e da autenticação baseada em PIN. Eles enfatizam que o design atual prioriza a legibilidade e a auditabilidade sobre a obtenção de ganhos marginais de precisão.