Resumo Técnico: LACUNA: Agentes Seguros como Buracos de Programa Recursivos

Declaração do Problema

Os agentes atuais de Modelos de Linguagem de Grande Escala (LLM) enfrentam uma divisão arquitetural fundamental entre o tempo de execução que impulsiona o loop do agente e o código que o modelo escreve. Nas abordagens dominantes, como ReAct, o tempo de execução detém o controle do fluxo, o gerenciamento de contexto e o despacho de ferramentas, enquanto o modelo apenas emite chamadas individuais de ferramentas ou etapas de raciocínio. Em agentes de "código como ação", o modelo escreve código para compor ferramentas e lógica, mas esse código permanece distinto do tempo de execução.

Essa separação cria um dilema de segurança. Se o tempo de execução controlar estritamente o loop, o agente carece de expressividade. Se o modelo moldar o próprio tempo de execução para aumentar a expressividade, os riscos de segurança escalam: um modelo desviado por injeção de prompt, um erro de chamada de ferramenta ou uma falha parcial pode deixar o ambiente em um estado inconsistente ou comprometer o tempo de execução. Defesas existentes (sandboxes, interpretadores restritos, linguagens de política) são frequentemente fragmentadas, operando no tempo de execução ou em entradas, e nenhuma verifica uma ação gerada inteira contra o contexto do programa circundante antes que a execução comece.

Metodologia: LACUNA

Os autores propõem o LACUNA, um modelo de programação que fecha a divisão entre o tempo de execução do agente e o código escrito pelo modelo, preservando a segurança por meio de tipagem estática. O primitivo central é um "buraco" tipado no programa hospedeiro:

def agent[T](task: String): T

Mecanismo Central

1. Buracos Tipados: Uma chamada de agente atua como um espaço reservado onde o programa circundante espera estaticamente um valor do tipo T. O LLM é instruído a gerar código Scala que produz esse valor.
2. Compilação Consciente do Contexto: Quando a execução atinge a chamada agent, o LLM gera código com base na task em linguagem natural, no tipo esperado T e no escopo léxico ativo (variáveis, funções, ferramentas e imports disponíveis naquele ponto específico).
3. Verificação Pré-Execução: O código gerado é compilado pelo compilador hospedeiro (Scala 3) no contexto do programa circundante antes que ele seja executado.
   • Verificação de Tipos: O código deve produzir um valor do tipo T.
   • Verificação de Escopo: Todos os nomes utilizados devem estar no escopo.
   • Verificação de Capacidades: Se habilitado, a verificação de captura garante que o código acesse apenas recursos (arquivos, rede, ferramentas) explicitamente concedidos no escopo léxico.
4. Execução Tudo ou Nada: Se o código passar em todas as verificações, ele é executado. Se falhar (por exemplo, incompatibilidade de tipos, ferramenta ausente, acesso não autorizado), todo o trecho é rejeitado. Nenhuma execução parcial ocorre, prevenindo estados inconsistentes. Os diagnósticos do compilador são enviados de volta ao LLM para impulsionar um loop de nova tentativa.

Implementação

O protótipo é construído em Scala 3, aproveitando duas características específicas:

• Recompilação em processo: A capacidade de invocar o compilador dentro de um programa em execução para inserir e compilar uma string de código-fonte contra o contexto atual.
• Verificação de Captura: Um mecanismo para rastrear quais efeitos e recursos um trecho de código tem permissão para usar, aplicando segurança baseada em capacidades.

O primitivo agent é um wrapper fino sobre uma operação eval de nível inferior. Ele gerencia a construção do prompt (incluindo o código-fonte envolvente e as ligações disponíveis), chama o LLM, passa o resultado para eval e gerencia o loop de nova tentativa após falha de compilação.

Contribuições Principais

1. Um Modelo de Código como Ação com Garantias Estáticas: Um modelo onde o LLM escreve ações como código que roda como parte de seu próprio tempo de execução, verificado no local da chamada antes da execução.
2. Análise de Segurança: Demonstra que a rejeição pré-execução de nomes indisponíveis e incompatibilidades de tipos, combinada com execução atômica (sem execuções parciais), fornece fortes garantias de segurança. Mostra ainda como o escopo de capacidades limita a autoridade e o fluxo de informações do agente.
3. Expressividade via Fluxo de Controle Comum: Demonstra que chamadas de agentes aninhadas e construções de código padrão podem expressar padrões complexos de agentes (loops ReAct, sub-agentes, habilidades, decomposição paralela, planejamento multi-modelo) sem a necessidade de um protocolo de agente separado.
4. Avaliação Empírica: Uma realização em Scala 3 avaliada em casos de teste de verificador, BrowseComp-Plus (busca de informações difícil) e $\tau^2$-bench (conversas multi-turno usando ferramentas).

Resultados

A avaliação destaca o compromisso entre segurança, expressividade e capacidade do modelo:

• Segurança e Taxas de Rejeição: No BrowseComp-Plus, 8,6% das gerações foram rejeitadas antes da execução devido a erros de tipo ou escopo. O sistema teve uma média de 0,7 novas tentativas por consulta, com uma taxa de sucesso de compilação ponta a ponta de 91,4%. Isso confirma que o compilador bloqueia efetivamente ações mal tipadas ou fora de escopo.
• Desempenho em Tarefas Complexas:
  • BrowseComp-Plus: Usando o modelo deepseek-flash, o LACUNA alcançou 27,1% de precisão, comparável a agentes de base, enquanto impulsionava pesquisa genuína de múltiplos passos (média de 5,9 rodadas, 15,5 buscas).
  • $\tau^2$-bench: Em 392 tarefas em quatro domínios (Varejo, Companhia Aérea, Telecomunicações, Tel.-WF), o LACUNA resolveu 76,0% das tarefas com um modelo capaz, performando em par com um agente de chamada de ferramenta de referência.
• Dependência do Modelo: O sucesso do sistema depende fortemente da capacidade de codificação do modelo. Modelos mais fracos (por exemplo, gemini-3.1-flash-lite) lutaram em domínios complexos (por exemplo, 89% de taxa de rejeição em telecomunicações), levando a taxas de resolução mais baixas. A garantia de segurança mantém-se independentemente da competência do modelo (tentativas quebradas nunca são executadas), mas o progresso para se se o modelo não puder gerar código válido.
• Robustez Adversarial: Em testes de injeção de prompt (AgentDojo), a camada de capacidades confinou com sucesso as ações do agente ao seu escopo concedido. Mesmo quando influenciado por conteúdo injetado, o agente não pôde acessar recursos fora de seu escopo léxico.

Significado e Afirmações

O artigo posiciona o LACUNA não como um substituto para arquiteturas de agentes existentes, mas como uma base mais segura e flexível.

• Unificação de Execução e Raciocínio: Ao fundir a execução do programa e o raciocínio do modelo em um único processo onde o modelo escreve o fluxo de controle, o LACUNA permite que agentes sejam mais expressivos, mantendo as garantias de segurança da linguagem hospedeira.
• Segurança via Compilação: A contribuição principal é deslocar a segurança de sandboxes de tempo de execução para verificação estática pré-execução. Um trecho rejeitado deixa o ambiente intocado, e os diagnósticos do compilador impulsionam a autocorreção.
• Segurança de Capacidades: O sistema demonstra que a "menor autoridade" pode ser aplicada através de escopo léxico e verificação de captura, limitando o que um modelo adversarial ou errôneo pode fazer, mesmo que seja influenciado por injeção de prompt.
• Limitações Modestas: Os autores reconhecem que "bem tipado" não significa "correto" (erros semânticos não são detectados), que o sistema depende da proficiência de codificação do modelo (que varia por linguagem e domínio) e que o esgotamento de recursos (latência, recursão infinita) deve ser gerenciado via orçamentos de tempo de execução em vez de sistemas de tipos.

Em resumo, o LACUNA propõe que tratar ações de agente como buracos tipados em uma linguagem hospedeira estaticamente tipada permite um design de agente recursivo e expressivo onde a segurança é garantida pela correção do compilador, e não por heurísticas de tempo de execução.