Resumo Técnico: Automatizando o Design de Arquiteturas de Agentes Incorporados

1. Declaração do Problema

Agentes incorporados (embodied agents) são atualmente construídos como composições desenhadas à mão de módulos de percepção, memória, planejamento e ação. Embora essa modularidade exponha um grande espaço de design arquitetural, os sistemas atuais dependem fortemente da intuição do pesquisador para determinar o armazenamento de informações, o processamento de observações e a conectividade dos modelos. À medida que os modelos de fundação e as ferramentas incorporadas se multiplicam, o espaço de arquiteturas plausíveis cresce mais rápido do que a iteração manual pode cobrir.

Embora a Busca de Arquitetura de Agentes (AAS - Agent Architecture Search) tenha sido aplicada a agentes de domínio de texto para automatizar o design de fluxos de trabalho, ela não foi sistematicamente avaliada em agentes incorporados perceptivos. Transferir a AAS para este domínio apresenta desafios únicos:

• Simuladores com Estado: Diferente dos agentes de domínio de texto que operam em chamadas sem estado (stateless) e baratas, os agentes incorporados interagem com simuladores com estado (stateful).
• Avaliações Ruidosas: Tarefas incorporadas produzem execuções (rollouts) de múltiplos episódios ruidosas, em vez de pontuações determinísticas.
• Falta de Primitivas: Não existe uma paleta pequena e composível de "primitivas de raciocínio incorporado" (ex: cadeia de pensamento/chain-of-thought) comparável aos operadores de domínio de texto. Em vez disso, os pontos de partida são sistemas complexos e publicados, como MapGPT ou VoxPoser.
• Traços Longos: As avaliações dependem de longos traços de execução envolvendo observações, ações, chamadas de ferramentas e saídas intermediárias do planejador.

A questão central é se o design de arquitetura pode ser automatizado para agentes incorporados e quais restrições emergem ao mover-se de programas de texto para agentes que atuam em ambientes 3D.

2. Metodologia

O estudo emprega uma abordagem baseada em sementes de método (method-seeded). Em vez de montar agentes do zero, a busca parte de arquiteturas de agentes incorporados publicadas e explora modificações de nível de grafo em torno dessas sementes. O framework consiste em dois substratos primários e três variantes de otimizadores.

2.1 Substratos

• Substrato de Executor (AGENTCANVAS): Um tempo de execução de grafo tipado representando agentes incorporados como grafos JSON de nós e conexões (node-and-wire) suportados por módulos Python.
  • Editabilidade: Suporta patches estruturados (adicionar arestas, trocar nós, substituir subgrafos) com verificações de compatibilidade de tipo antes de rollouts caros.
  • Instrumentação: Registra entradas/saídas externas e "migalhas de pão" (breadcrumbs) internas (decisões do planejador, prompts, autorrelatos) ao nível do episódio.
  • Escalabilidade: Nós dependentes do simulador são replicados entre trabalhadores (workers), enquanto nós de modelos de fundação permanecem como serviços únicos (singleton services).
• Substrato de Otimizador (Harness de Agente de Codificação): Um ambiente de agente de codificação de nível de repositório compartilhado (usando ferramentas como Claude Code) que permite aos otimizadores inspecionar arquivos, diagnosticar falhas e modificar tanto a estrutura do grafo quanto as implementações dos nós. Isso garante que todas as variantes tenham acesso igual a ferramentas de edição de código e registro (logging).

2.2 Variantes de Otimizador

Três políticas de busca distintas foram implementadas dentro do harness compartilhado:

1. ADAS: Um port do método original preservando propostas do tipo Reflexion, fitness de bootstrap-CI e um arquivo plano de adição única (append-only). Utiliza subagentes independentes para geração de propostas.
2. AFlow: Um port preservando seleção de pai por softmax-de-escore e memória de replay anti-repetição. Diferente da biblioteca original de fluxo de texto, esta versão busca mudanças estruturais livres sobre grafos de Executor tipados.
3. KDLoop (Laço de Destilação de Conhecimento): Um procedimento inovador projetado especificamente para o cenário incorporado. Ele cicla através de quatro fases:
   • THINK (PENSAR): Propõe experimentos marcados por eixos de intervenção (ex: prompt, topologia, memória de estado).
   • CRITIC (CRÍTICO): Verifica edições contra restrições e patches que falharam.
   • EXPERIMENT (EXPERIMENTAR): Aplica e avalia a edição.
   • DISTILL (DESTILAR): Escreve resultados (descobertas confirmadas, edições refutadas, conjecturas abertas) em memória tipada.
   • REFLECT (REFLETIR): Acionado em casos de estagnação para auditar o progresso e atualizar a cobertura do espaço de busca.

3. Configuração Experimental

A avaliação cobre uma matriz 3 × 4 de três otimizadores (ADAS, AFlow, KDLoop) através de quatro executores incorporados abrangendo três famílias de tarefas:

• Navegação de Linguagem-Visão (VLN): MapGPT (panorâmico), SmartWay (ação contínua).
• Questionamento Incorporado (EQA): ExploreEQA (ativo).
• Manipulação Condicionada por Linguagem (VLA): VoxPoser (zero-shot).

O fitness da busca é medido pela Taxa de Sucesso (SR) da tarefa sobre avaliações de simulador de múltiplos episódios. Para distinguir a seleção de tempo de busca da variância de verificação, os resultados são reportados como a média de três execuções pós-seleção.

4. Resultados Principais

4.1 Ganhos de Desempenho

A busca de nível de arquitetura pode produzir ganhos de taxa de sucesso direcionais e implantáveis:

• MapGPT: Tanto o AFlow (+7,6 pp) quanto o KDLoop (+7,1 pp) alcançaram ganhos significativos sobre o baseline (46,9% → ~54%), utilizando diferentes edições (regras de parada, controle de ação/action gating).
• ExploreEQA: AFlow (+4,7 pp) e KDLoop (+3,0 pp) mostraram melhorias modestas via reescrita de prompts e filtros de memória.
• SmartWay: ADAS alcançou +4,0 pp. O AFlow mostrou um ganho de +9,0 pp, mas isso foi posteriormente identificado como um resultado com vazamento de dados (leak-bearing) (conectando sinais de verdade fundamental do lado do avaliador ao agente), tornando-o não implantável.
• VoxPoser: ADAS e AFlow alcançaram ganhos (+3,7 pp, +3,9 pp). O KDLoop falhou em produzir uma reivindicação, detectando em vez disso uma falha compartilhada no substrato de registro (logging).

4.2 Restrições Identificadas

Os experimentos expuseram três restrições críticas específicas para AAS incorporado que são atenuadas em configurações de domínio de texto:

1. Ruído de Avaliação:

   • Pontuações de fitness de passagem única podem ser enganosas devido à variância de execução (rollout variance). Por exemplo, a "melhor" iteração do SmartWay-AFlow teve uma variância alta (38,7 ± 5,9%), exigindo múltiplas execuções para interpretação.
   • Seleção e verificação não são intercambiáveis; a seleção ingênua da melhor iteração é insuficiente para escalar o AAS incorporado.

2. Bacias de Edição Local (Local Edit Basins):

   • Otimizadores (ADAS, AFlow) tendem a ficar presos em bacias de edição local, modificando repetidamente o mesmo mecanismo (ex: topologia ou pipeline de observação) em vez de explorar abordagens qualitativamente diferentes.
   • Sem predicados de parada de nível de espaço ou rastreamento de histórico, as execuções de busca chegam ao limite de iteração com retornos decrescentes. O histórico tipado do KDLoop ajuda a mitigar isso, mas às vezes pode subexplorar bacias produtivas ao redirecionar a busca cedo demais.

3. Atribuição de Crédito Parcial:

   • Apesar do acesso a logs detalhados por episódio, os otimizadores comportam-se majoritariamente como otimizadores de métrica escalar.
   • Detecção de Vazamento (Leak Detection): Nas execuções do VoxPoser, ADAS e AFlow falharam em detectar um erro de traço de log ausente (um defeito do framework), focando apenas em pontuações escalares. Apenas o KDLoop inspecionou ativamente os logs para identificar o problema.
   • Identificação de Vazamento (Leak Identification): No SmartWay, a alta pontuação do AFlow só foi reconhecida como um "vazamento" (dependendo de informações do lado do avaliador) através de inspeção manual de nível de episódio, não por atribuição automática.

5. Significância e Alegações

O artigo caracteriza tanto a promessa quanto os limites atuais da busca de arquitetura automatizada para agentes incorporados.

• Promessa: O estudo demonstra que a AAS pode melhorar agentes incorporados do mundo real, produzindo mudanças funcionais no comportamento (ex: melhores regras de parada, controle de ação) em vez de apenas reestruturação superficial de fluxo de trabalho.
• Limites: A transição de texto para agentes incorporados introduz fricção significativa. Os autores alegam que o ruído de avaliação, as bacias de edição local e a atribuição de crédito incompleta são obstáculos fundamentais.
• Contribuição: A principal contribuição não é apenas um conjunto de executores melhorados, mas uma caracterização do regime de busca. O artigo argumenta que futuros sistemas de AAS incorporado devem ir além da otimização escalar para incluir:
  • Protocolos robustos de seleção vs. verificação (ex: pisos de reexecução).
  • Estruturas de memória que rastreiam eixos de intervenção e cobertura do espaço de busca.
  • Mecanismos de atribuição explícitos que verificam se os mecanismos propostos executam corretamente e se dependem de fontes de informação implantáveis.

O trabalho conclui que, embora o design automatizado seja viável, ele requer novas estratégias para lidar com a natureza ruidosa, com estado e complexa de agentes perceptivos em ambientes 3D.