Resumo Técnico: Habilidade-como-Pseudocódigo (SaP)

Declaração do Problema

Agentes modernos baseados em LLM dependem de bibliotecas de habilidades — coleções de documentos procedimentais (geralmente Markdown) que os agentes recuperam e seguem durante a execução de tarefas. No entanto, essas bibliotecas são atualmente autoradas como prosa livre. Essa representação cria um gargalo significativo: o agente deve re-derivar tanto o esquema de entrada (o que a habilidade faz) quanto a sintaxe concreta de invocação (como chamá-la) a cada recuperação.

Os autores observam que esse formato rico em prosa induz um loop "confuso → re-recuperar → ainda confuso". Quando um agente emite uma ação parcialmente correta baseada em uma descrição em prosa, o ambiente frequentemente retorna feedback não informativo (por exemplo, "Nada acontece"). O agente então re-recupera a mesma prosa, falha em extrair o detalhe ausente e repete o ciclo. Esse loop impulsiona tanto falhas de tarefa quanto custos inflados de chamadas de LLM. Embora catálogos tipados como OpenAPI existam, eles não são a superfície de implantação padrão para habilidades de agentes, que permanecem em Markdown.

Metodologia: Habilidade-como-Pseudocódigo (SaP)

Os autores propõem Habilidade-como-Pseudocódigo (SaP), um pipeline automático que converte bibliotecas de habilidades em Markdown em pseudocódigo tipado com controle de qualidade determinístico. A ideia central é que dois sinais específicos encurtam o loop de recuperação-ação:

1. Um Contrato Tipado: Uma assinatura estruturada expondo o gatilho, esquemas de entrada/saída e pré/pós-condições.
2. Modelos de Ação Concretos: As sequências exatas de tokens que o ambiente aceita (por exemplo, move {obj} to {target}), distintas do contrato abstrato.

O Pipeline

O pipeline SaP processa uma biblioteca de habilidades pai (documentos Markdown) através de cinco etapas mais duas passagens de pós-verificador conscientes de LLM:

1. Analizador Sintático (Parser): Divide documentos Markdown em unidades procedimentais (seções sob títulos).
2. Propositor de Candidatos: Agrupa unidades de um ou mais pais em clusters candidatos com base em verbos, objetos e vinculação de código compartilhados, usando agrupamento baseado em embeddings.
3. Extrator de Contrato (LLM): Para cada cluster, uma única chamada de LLM redige um contrato tipado JSON estrito ($\kappa$).
4. Verificador (Determinístico): Um verificador determinístico de quatro verificações avalia o contrato rascunho. Um contrato é promovido apenas se passar em:
   • Cobertura: O gatilho e as strings de I/O do contrato devem estar presentes no texto da unidade pai.
   • Vinculação: Cada entrada obrigatória no contrato deve ter um intervalo correspondente no texto pai.
   • Substituição: A unidade pai deve ser sintaticamente substituível por um espaço reservado invoke(κ, args) sem quebrar o fluxo de controle.
   • Risco: O contrato não deve conter efeitos colaterais inseguros (por exemplo, rm -rf, egresso de rede não declarado).
5. Refatoração: Contratos validados são incorporados nas habilidades pai.
   • Extração de Vinculação (BE): Uma passagem de LLM que verifica se uma unidade específica é uma instância genuína do contrato e extrai as vinculações de argumentos específicas. Correspondências espúrias são descartadas.
   • Limpeza de Reescrita (RC): Uma passagem de LLM que detecta e reescreve conflitos residuais de prosa (por exemplo, um bloco de exemplo usando um verbo como put quando o ambiente requer move) para alinhar com o contrato verificado.

Substituição no Momento da Recuperação

No momento da inferência, o agente recupera um pacote de habilidades substituído em vez de prosa bruta. Para uma habilidade pai recuperada, o sistema substitui o conteúdo original por:

1. Modelos de Ação: Sequências de comandos concretas e executáveis com vinculações extraídas (colocadas primeiro).
2. Esqueleto Reescrito: A estrutura pai com espaços reservados invoke(κ, args).
3. Contrato Incorporado: A assinatura tipada e o esquema para a habilidade filha invocada.

Crucialmente, o sistema emprega um pool de recuperação apenas hierárquico. Contratos filhos promovidos são armazenados internamente e são apenas acessíveis através do espaço reservado invoke do pai. Expor filhos como resultados de nível superior independentes é evitado, pois priva o agente do contexto necessário (os modelos de ação do pai).

Contribuições Principais

1. Reenquadramento da Melhoria de Habilidades: O artigo reenquadra a otimização de bibliotecas de habilidades como um problema de conversão de prosa para pseudocódigo tipado com controle de qualidade determinístico, complementando trabalhos existentes de roteamento tipado que assumem que contratos já existem.
2. O Pipeline SaP: Uma arquitetura nova que apresenta um verificador determinístico de quatro verificações e duas passagens de pós-verificador conscientes de LLM (BE e RC), cada uma protegida por pós-verificações determinísticas para garantir segurança e consistência.
3. Interface de Recuperação Hierárquica: Um mecanismo de recuperação que entrega um pacote estruturado (contrato tipado + modelo concreto) por invocação, separando o "o quê" (contrato) do "como" (modelo).
4. Validação Empírica: Demonstração de que o SaP melhora simultaneamente as taxas de sucesso de tarefas e reduz custos de tokens/chamadas de LLM em comparação com a linha de base Graph-of-Skills (GoS).

Resultados

Experimentos foram conduzidos no conjunto de dados não visto ALFWorld (134 jogos) usando gpt-4o-mini e um subconjunto do SkillsBench (10 tarefas) usando gpt-5-codex.

• Desempenho no ALFWorld: Em três sementes (402 jogos pareados), o SaP venceu 82/402 jogos comparado a 47/402 para a linha de base GoS. Isso representa um aumento relativo de recompensa de 74% (McNemar $p = 8.2 \times 10^{-5}$).
• Ganhos de Eficiência: O SaP alcançou esses ganhos enquanto reduzia os tokens de entrada em 22,8%, os tokens de saída em 17,3% e as chamadas de LLM em 14,5% por jogo.
• Análise de Mecanismo: A melhoria é atribuída à quebra do "loop de recuperação-ação". Agentes SaP emitiram significativamente menos erros "Nada acontece" e solicitações de re-recuperação. A correção da ação pós-recuperação melhorou de 20,5% (GoS) para 29,3% (SaP).
• Ablação: Remover a separação hierárquica (expor filhos como resultados independentes) causou uma queda de 27% na recompensa, confirmando a necessidade da estrutura de pacote pai-filho. As passagens BE e RC foram mostradas reparando modos de falha distintos (membro de cluster espúrio e conflitos de sintaxe, respectivamente).

Significado e Alegações

O artigo alega que a própria representação em prosa, e não uma falta de fatoração, é o gargalo dominante para agentes LLM consumindo bibliotecas de habilidades. Ao automatizar a conversão de prosa para pseudocódigo tipado com verificação determinística, o SaP fornece aos agentes um sinal de "o quê" (contrato) e "como" (modelo) em uma única resposta.

Os autores posicionam o SaP como uma solução do lado do produtor para o problema de roteamento tipado. Enquanto trabalhos existentes assumem que contratos são escritos à mão, o SaP os recupera da prosa. A metodologia é apresentada como uma abordagem disciplinada onde cada extração de LLM é uma hipótese verificada por regras determinísticas, em vez de uma saída de caixa preta.

O artigo nota modestamente que, embora o pipeline seja suportado arquiteturalmente para APIs tipadas (OpenAPI), a avaliação empírica atual é limitada a bibliotecas Markdown. Além disso, o mecanismo de substituição é estático (sintático) em vez de dinâmico (expansão em tempo de execução), dependendo da interface de recuperação para fornecer contratos filhos sob demanda. Os resultados sugerem que, para bibliotecas de habilidades estáticas, o custo da conversão de prosa para estrutura pode ser pago no momento da indexação em vez de em cada recuperação, melhorando significativamente a eficiência e a confiabilidade do agente.