🤖 AI

Model or Harness? An Interaction-Centric Taxonomy for Localizing Agent Failures

Este artigo introduz uma taxonomia centrada na interação que localiza falhas de agentes em interações de componentes e lados de falha específicos, transformando rótulos vagos de nível de resultado em atribuições de reparo acionáveis para modelos, harnesses ou ambientes para melhorar sistemas de agentes através de diversas arquiteturas.

Autores originais: Harsh Raj, Vipul Gupta, Anas Mahmoud, Razvan-Gabriel Dumitru, Darvin Yi, Aakash Sabharwal, Yunzhong He

Publicado 2026-08-03

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Harsh Raj, Vipul Gupta, Anas Mahmoud, Razvan-Gabriel Dumitru, Darvin Yi, Aakash Sabharwal, Yunzhong He

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você construiu um assistente robô superinteligente, um mordomo digital projetado para lidar com tudo, desde escrever código até planejar seu fim de semana. Você diz a ele para "reservar um voo" e ele volta dizendo: "Eu não consegui fazer isso". No mundo da inteligência artificial, isso é uma falha clássica. Mas aqui está a parte complicada: por que ele falhou? O cérebro do robô (o "modelo") ficou confuso? As mãos do robô (as "ferramentas") deixaram o telefone cair? O quarto onde ele está trabalhando (o "ambiente") estava com uma porta quebrada? Ou a pessoa que deu as ordens (o "proprietário") apenas fez a pergunta errada?

Por muito tempo, cientistas e engenheiros olharam para essas falhas como um médico olha para uma febre. Eles veem o sintoma — o robô não reservou o voo — mas muitas vezes não sabem qual órgão está doente. Se você tratar um braço quebrado com remédio para febre, nada melhora. Da mesma forma, se um robô falha porque suas ferramentas estão quebradas, mas você passa meses retreinando seu cérebro, você perdeu seu tempo. Este artigo, intitulado "Model or Harness? An Interaction-Centric Taxonomy for Localizing Agent Failures" (Modelo ou Suporte? Uma Taxonomia Centrada na Interação para Localizar Falhas de Agentes), é como um novo mapa ultra detalhado para diagnosticar exatamente onde o robô errou. Ele vai além de apenas dizer "ele falhou" para identificar precisamente qual parte do ecossistema do robô quebrou a cadeia de comando.

A Grande Ideia: Não é Apenas o Cérebro

Os autores, uma equipe da Scale AI, argumentam que temos olhado para os agentes de IA da maneira errada. Tendemos a tratá-los como um cérebro único e monolítico que ou tem sucesso ou falha. Mas, na realidade, um agente de IA é mais como uma orquestra complexa. Você tem o Modelo (o regente e os músicos), o Suporte/Harness (o estante de partituras e o diretor de palco), as Ferramentas (os instrumentos), o Ambiente (a sala de concerto) e o Proprietário (a pessoa que comprou os ingressos).

Quando a música para, não é sempre porque o violinista errou uma nota. Às vezes, a partitura estava com uma página faltando (um problema de suporte/harness), às vezes uma corda do violino arrebentou (um problema de ferramenta), ou às vezes a sala estava barulhenta demais para ouvir o sinal (um problema de ambiente). O artigo introduz uma nova forma de categorizar essas falhas baseada em interações. Em vez de apenas listar "coisas ruins que aconteceram", eles mapeiam cada falha para um aperto de mão específico entre duas partes do sistema. O Modelo errou o aperto de mão com a Ferramenta? Ou a Ferramenta errou o aperto de mão com o Modelo?

O Novo Mapa: 41 Maneiras de Quebrar um Robô

A equipe não apenas adivinhou; eles construíram uma taxonomia massiva (uma palavra sofisticada para um sistema de classificação) contendo 41 modos de falha distintos. Eles organizaram essas falhas observando as "bordas" onde os componentes se encontram.

Pense nisso como uma história de detetive onde cada pista é um aperto de mão quebrado:

O Robô "Entusiasta Demais": Às vezes o robô faz demais. Ele supõe o que você quer e deleta seus e-mails porque achou que você pediu isso. O artigo chama isso de Sobre-iniciativa (Over-initiative). É uma falha do Modelo interagindo com o Proprietário.
O Robô "Esquecido": Às vezes o robô lembra da tarefa, mas esquece as regras. Ele começa a editar um código que foi instruído a não tocar porque a regra "não toque" se perdeu no resumo de sua memória. Isso é Erosão do Racional de Contexto (Context Rationale Erosion), uma falha entre o Contexto e o Modelo.
O Robô "Mentiroso": Às vezes o robô tenta usar uma ferramenta que não existe, como pedir para uma calculadora "assar um bolo". Isso é Alucinação de Ferramenta (Tool Hallucination).
O Robô "Mensageiro Quebrado": Às vezes o robô pede dados, a ferramenta os obtém, mas o mensageiro (o wrapper/envelope) deixa cair a parte importante da mensagem antes que ela chegue ao robô. O artigo chama isso de Mistranslation (Erro de Tradução) e, crucialmente, culpa a Ferramenta, não o Modelo.

A parte mais emocionante do mapa deles é que ele diz exatamente para quem ligar para pedir ajuda. Se a falha for do lado do Modelo, você precisa retreinar o cérebro da IA. Se for do lado do Suporte/Harness (o andaime que sustenta a IA), você precisa consertar o código que gerencia a memória e as ferramentas da IA. Se for o Ambiente, você precisa consertar o site externo ou o banco de dados que a IA está tentando usar.

O Mapa Funcionou?

Para provar que seu mapa não era apenas um desenho legal, os autores o testaram. Eles pegaram exemplos reais de falhas de IA — como um robô que acidentalmente deletou 200 e-mails ou um que tentou modificar o tabuleiro reescrevendo-o — e pediram a juízes de IA independentes que usassem o novo mapa para diagnosticar o problema.

Os resultados foram promissores. Os juízes de IA, agindo como detetives independentes, foram capazes de concordar com especialistas humanos em 76% das vezes sobre as categorias amplas de falha. Este é um sinal forte de que o mapa captura uma estrutura real e compartilhada de como esses sistemas quebram, em vez de ser apenas a opinião de uma pessoa. De fato, quando os juízes de IA concordaram entre si, eles atingiram uma taxa de concordância ainda maior de 84%.

No entanto, o artigo é cuidadoso ao não afirmar que este é um mistério resolvido. Eles descobriram que, às vezes, as evidências são tênues demais para saber com certeza. Por exemplo, se um robô falha porque um e-mail agendado nunca chegou, é difícil dizer se o robô não verificou ou se o sistema de e-mail simplesmente nunca o enviou. Nesses casos, o sistema "Agente-como-Juiz" às vezes atribuiu a falha ao robô quando, na verdade, era culpa do ambiente. Isso sugere que, embora a taxonomia seja uma ferramenta poderosa, ela ainda precisa de evidências claras para funcionar perfeitamente.

Por Que Isso Importa

O artigo sugere que, ao usar essa visão centrada na interação, podemos parar de jogar dinheiro fora nos problemas errados. Se uma IA continua falhando porque não consegue ler um site específico, retreinar seu cérebro não ajudará; você precisa consertar o site ou a ferramenta que se conecta a ele. Se ela falha por ser invasiva demais, você precisa ensiná-la a pedir permissão.

Em última análise, esta pesquisa oferece uma linguagem comum para engenheiros, pesquisadores e usuários. Ela transforma uma reclamação vaga como "a IA está quebrada" em um diagnóstico específico: "A IA falhou devido a uma Negligência de Feedback de Ferramenta (Tool Feedback Neglect) durante sua interação com o Ambiente Externo". É uma mudança do adivinhar para o saber, garantindo que, quando consertarmos nossos assistentes digitais, estejamos realmente consertando a parte certa da máquina.

Resumo Técnico: Modelo ou Harness? Uma Taxonomia Centrada na Interação para Localizar Falhas de Agentes

Declaração do Problema

As avaliações existentes de agentes autônomos frequentemente reduzem falhas a resultados em nível de sistema (ex: sucesso ou falha da tarefa). Essa agregação obscurece a origem da falha, criando um "problema de atribuição de reparo". Uma falha visível pode originar-se do raciocínio do modelo, do gerenciamento de contexto do harness (suporte), da confiabilidade do ambiente ou do design do benchmark. Como o mesmo resultado pode resultar de causas distintas, rótulos em nível de resultado são insuficientes para determinar a intervenção corre a ser feita (ex: pós-treinamento do modelo vs. engenharia de harness).

Taxonomias anteriores são tipicamente específicas de um benchmark ou focam em módulos internos do agente sem distinguir explicitamente entre o componente que evidencia a falha e o componente que a causou. Consequentemente, elas falham em fornecer uma estrutura compartilhada que mapeie falhas para intervenções específicas e acionáveis em diversas arquiteturas de agentes.

Metodologia

Os autores propõem uma taxonomia centrada na interação que trata a interação entre dois componentes como a unidade de análise. O framework localiza falhas atribuindo-as a uma aresta de interação (os dois componentes envolvidos) e um lado da falha (o componente específico responsável).

Vocabulário de Componentes

O sistema é modelado como um conjunto de componentes interagentes (Tabela 1):

Modelo: A política do LLM.
Proprietário (Owner): O humano ou sistema de nível superior que define a tarefa e os critérios de sucesso.
Avaliador (Grader): O mecanismo que avalia o sucesso (frequentemente invisível ao agente).
Terceira Parte (Third Party): Atores externos (humanos, organizações ou agentes) encontrados durante a execução.
Harness: Gerencia contexto, memória e acesso a ferramentas.
Ambiente: Inclui Local (SO, shell, sistema de arquivos) e Externo (serviços remotos, APIs) configurações de execução.

Regras de Atribuição

Definição de Aresta: Uma falha é rotulada como COMP1 — COMP2.
Lado da Falha: O rótulo inclui fault: SIDE, identificando o componente culpado.
- Exemplo: Se um wrapper de ferramenta suprime um erro, a falha é TOOL. Se o wrapper retorna o erro, mas o modelo o ignora, a falha é MODEL.
Princípio da Causa Raiz: Para trajetórias com falhas em cascata, a taxonomia rotula a primeira falha irrecuperável. Sintomas subsequentes são tratados como consequências.
Heurística de Atribuição: Uma falha é atribuída ao lado do modelo se um modelo mais capaz pudesse ter evitado ou se recuperado dela sob as mesmas condições.

Estrutura da Taxonomia

A taxonomia organiza 41 modos de falha em uma hierarquia baseada na família de componentes que interage com o modelo (Usuário, Harness ou Ambiente).

Família do Usuário: Inclui interações com o Proprietário, Avaliador e Terceiros (ex: Falha de Seguimento de Instrução, Exploração de Especificação, Injeção de Prompt Indireta).
Família do Harness: Cobre Contexto, Memória e Ferramentas (ex: Deriva de Objetivo, Obsolescência de Memória, Alucinação de Ferramenta, Má Tradução).
Família do Ambiente: Inclui ambientes Locais e Externos (ex: Falha de Observação, Falha de Serviço, Entrega de Estado Obsoleto).
Multi-Agente: Interações entre modelos são categorizadas por função (Par ou Subagente).

Principais Contribuições

Taxonomia Centrada na Interação: Introdução de uma taxonomia de 41 modos que localiza falhas em arestas de interação e lados de falha específicos, mapeando diretamente as falhas para tipos de intervenção (pós-treinamento, engenharia de harness, redesenho de ambiente).
Fundamentação Empírica: A taxonomia é derivada e validada usando exemplos práticos de benchmarks públicos (ex: SWE-bench, Toolathlon), model system cards, relatórios publicados e trajetórias de agentes registradas.
Avaliação de Reprodutibilidade: Os autores avaliam a reprodutibilidade operacional da taxonomia usando agentes de raciocínio independentes como juízes. Quatro modelos de fronteira (GPT-5.5, Claude Opus 4.6–4.8) foram incumbidos de recuperar os rótulos atribuídos por humanos a partir do material de origem.

Resultados

O estudo avaliou o acordo entre anotadores humanos e os agentes juízes em 40 exemplos práticos.

Acordo de Categoria: O juiz mais forte (GPT-5.5) alcançou um $\kappa$ de Cohen de 0,76 contra os rótulos humanos para aresta de interação e lado da falha. Outros juízes variaram de $\kappa = 0,70$ a $0,71$.
Acordo de Modo de Falha: O acordo sobre o nome específico do modo de falha foi menor, mas ainda significativo, com o GPT-5.5 atingindo $\kappa = 0,71$ .
Consistência Inter-Juiz: Os juízes concordaram entre si tão fortemente quanto concordaram com humanos (maior $\kappa$ par de $0,84$), sugerindo que as categorias capturam uma estrutura compartilhada em vez de viés do anotador.
Votação Seletiva: Usando uma abordagem de ensemble onde os rótulos só são atribuídos se pelo menos 3 de 4 juízes concordarem, o sistema alcançou 0,83 de precisão de categoria com 90% de cobertura. O acordo unânime elevou a precisão para 0,96 com 68% de cobertura.

Fontes de Desacordo:

Fontes Heterogêneas: Alguns materiais de origem (ex: relatórios de incidentes breves) careciam de evidências suficientes para identificar unicamente uma causa raiz.
Atribuição de Causa Raiz: Os juízes às vezes tiveram dificuldade em distinguir entre uma falha de recuperação do modelo e uma falha irrecuperável do ambiente (ex: atribuir erroneamente um erro de harness a uma falha de observação do modelo).

Significância e Alegações

O artigo afirma que esta taxonomia fornece uma estrutura rigorosa e compartilhada para diagnosticar falhas de agentes que é ortogonal ao trabalho existente focado em módulos internos ou benchmarks específicos.

Acionabilidade: Ao distinguir o lado da falha, a taxonomia informa diretamente a estratégia de reparo:
- Falhas do lado do modelo indicam alvos para pós-treinamento ou melhoria de política.
- Falhas do lado do harness apontam para correções de scaffolding, gerenciamento de contexto ou integração de ferramentas.
- Falhas de Ambiente/Grader revelam condições que exigem o redesenho da avaliação.
Reprodutibilidade: O alto acordo entre juízes agentes independentes sugere que a taxonomia captura uma estrutura reprodutível no comportamento dos agentes, indo além de preferências subjetivas de rotulagem.
Limitações: Os autores observam que a taxonomia é descritiva, não quantitativa, e não estima a frequência de falhas. Ela depende de evidências disponíveis, que podem ser incompletas em alguns relatórios. Além disso, embora os juízes agentes mostrem potencial, sua precisão não é perfeita, particularmente para modos de falha específicos, e pode exigir o uso de ensembles para manter alta precisão em ambientes de produção.