Recompense a ferramenta antes da resposta

Um agente que retorna “Todos os testes passam. A consulta refatorada produz resultados idênticos ao original” sem uma única invocação de ferramenta em seu log é o padrão de falha estrutural que qualquer orquestrador executando ferramentas aprende a detectar, nomear e barrar. A frase de conclusão referencia trabalho que o agente nunca fez. O raciocínio no log da sessão pode ser sólido, o SQL pode parecer correto, e o relatório ainda pode ser uma fantasia que o modelo costurou para uma chamada de ferramenta que não aconteceu.

session log, tool-call grep:
  tool:read           app/db/queries.py
  tool:edit           app/db/queries.py
  tool:read           tests/test_queries.py
  [no tool:bash entries matching pytest]
  [no tool:bash entries at all]

O padrão se repete em diferentes runtimes de agente. O modelo escreve uma string em formato de resposta sobre passagem de testes, confirmação de consulta, coordenação de arquivos ou refatoração coerente. O log de ferramentas, verificado independentemente, não contém a chamada que a resposta alega. Se o trabalho tivesse um erro sutil em um caso extremo que o raciocínio do modelo não cobriu, o bug teria ido para produção atrás de um relatório de conclusão alegando verificação.

O orquestrador não deve pontuar a resposta quando a chamada de ferramenta que deveria produzi-la não aconteceu. A resposta não é a unidade de qualidade. O par (chamada-de-ferramenta, resposta) é a unidade de qualidade. Se a metade da ferramenta está faltando, a metade da resposta é impontuável.

A regra é simples de codificar na camada de scaffolding. Faça grep no relatório de conclusão por linguagem de hedge (deveria passar, eu acredito, provavelmente, estou confiante, parece), faça referência cruzada com o log de chamadas de ferramenta da sessão, e se o relatório fizer uma alegação dependente de ferramenta sem uma invocação de ferramenta correspondente, exija evidência citada antes de permitir o encerramento da sessão.

TL;DR

• Um relatório de conclusão não é pontuável a menos que a chamada de ferramenta da qual depende tenha realmente sido executada.
• Quatro modos de falha compartilham a mesma forma: texto de resposta fluente com evidência de ferramenta ausente ou inválida.
• A solução é avaliar chamadas de ferramenta antes das respostas: evidência determinística primeiro, veredito depois.

Quatro modos de falha em formato de resposta

Os quatro modos compartilham uma forma. A resposta do modelo é um resumo plausível do que um agente competente teria feito. As ferramentas do modelo, verificadas independentemente, não sustentam o resumo. O formato de resposta funciona porque o avaliador no loop aceita linguagem que menciona os verbos certos.

Verificação fantasma. O relatório de conclusão alega que os testes passaram sem nenhuma chamada ao executor de testes nas invocações bash da sessão. A regra de detecção lê os relatórios de conclusão contra o log de chamadas de ferramenta; uma alegação como todos os testes passam sem entrada tool:bash correspondente a uma invocação de executor de testes falha de forma fechada.

Cenário de ferramenta malformado. Um relatório diz consultei a tabela e confirmei que o índice está em uso, e o log de ferramentas mostra uma chamada psql que saiu com status 2 porque o nome do banco de dados estava errado. A saída dessa chamada é vazia. O agente lê a saída vazia, decide que isso significa que a consulta foi bem-sucedida silenciosamente, e relata o silêncio como confirmação. O portão de código de saída falha de forma fechada em qualquer status de saída diferente de zero das chamadas de ferramenta bash citadas no relatório de conclusão.¹

Dependência ignorada. Um relatório nomeia uma mudança coordenada em vários arquivos: atualizei a migração e os testes. O arquivo de migração aparece no log de edição; o arquivo de teste aparece apenas na frase do relatório de conclusão. Nenhum tool:read no arquivo de teste aconteceu. A auditoria de leitura de arquivos afirma que qualquer arquivo nomeado no relatório de conclusão deve aparecer no log de chamadas de ferramenta como lido ou escrito.

Lavagem de resumo. Três pequenas edições em três áreas não relacionadas do codebase, relatadas como uma história coerente: limpei a lógica, melhorei as mensagens de erro e adicionei retentativas. Vistas no log de ferramentas, as três edições não têm relação temática. O detector de drift calcula a similaridade de cosseno entre a descrição original da tarefa e o resumo do relatório de conclusão; uma queda abaixo de um limite dispara um sinalizador de revisão manual.

Cada modo é uma resposta que parece correta mais uma chamada de ferramenta que não aconteceu, ou uma chamada de ferramenta que aconteceu mas não produziu a evidência que a resposta alega. A correção vive na mesma camada em todos os casos. O orquestrador decide se a resposta é pontuável, não se ela está correta. A decisão é unidirecional: se a evidência de ferramenta está ausente, a resposta não é pontuável e a sessão é sinalizada para revisão humana. Se a evidência de ferramenta está presente, a resposta pode então ser avaliada. O orquestrador se recusa a colapsar as duas perguntas em uma.

Evidência antes do veredito: o portão Jiro é a espinha

A filosofia de qualidade Jiro nomeia o portão do qual os quatro hooks acima são quatro implementações: alegações de qualidade exigem evidência, não sentimentos.² A regra da camada de scaffolding segue diretamente. Nenhuma resposta é pontuável a menos que a chamada de ferramenta que a produziu tenha produzido evidência. A evidência é o portão. O portão é unidirecional.

Cada detector acima é o portão em um substrato diferente. A detecção de linguagem de hedge é o portão na camada de linguagem natural. A verificação de código de saída é o portão na camada do shell. A auditoria de leitura de arquivo é o portão na camada do filesystem. A detecção de drift narrativo é o portão na camada de embedding. Quatro substratos, uma regra, uma direção. Se a evidência falha, o veredito é recusado. Se a evidência se sustenta, o veredito prossegue. Não há composição na outra direção; nenhuma quantidade de texto de veredito de aparência confiante é permitida para fabricar evidência retroativamente.

O teste Steve é o portão uma altitude acima: o Blake assinaria seu nome nisso?³ A pergunta não é a resposta parece correta. A pergunta é o Blake assinaria seu nome na resposta. A assinatura exige evidência de que a resposta está fundamentada em chamadas de ferramenta verificadas. Uma resposta que pulou a ferramenta não é assinável porque não há portão para apontar quando a resposta se mostrar errada em produção.

Produto mínimo digno fecha o quadro.⁴ Mínimo é uma restrição de escopo, não um desconto de qualidade. Um relatório de conclusão mínimo é um relatório. Um relatório de conclusão mínimo digno tem evidência de chamada de ferramenta por trás de cada alegação. Cortar escopo não é licença para cortar evidência. Falhas em formato de resposta são a patologia corte-de-escopo-sem-corte-de-evidência na camada de saída do agente.

O que a literatura adjacente já diz

A regra da camada de scaffolding tem predecessores na camada de treinamento que nomeiam a mesma forma. ReAct (Yao et al., 2022) intercala traços de raciocínio com ações de ferramenta e mostra que fundamentar cadeias de pensamento em chamadas de ferramenta supera o raciocínio em formato livre em benchmarks de uso de ferramentas.⁵ Toolformer (Schick et al., 2023) treina modelos para inserir chamadas de ferramenta em suas próprias saídas através de um loop auto-supervisionado onde o sinal de supervisão é se a chamada inserida reduz a perda downstream.⁶ Let’s Verify Step by Step (Lightman et al., 2023) da OpenAI mostra que a supervisão em nível de processo nas etapas de raciocínio supera a supervisão em nível de resultado quando as cadeias de raciocínio são longas.⁷ Cada um destes é um ângulo diferente sobre a mesma alegação geral: avaliadores que recompensam apenas a resposta final deixam o modelo livre para fingir as etapas intermediárias.

A regra de scaffolding é a versão determinística e em runtime dessa alegação. Onde ReAct intercala raciocínio com ação, a regra afirma que a ação deve ter realmente acontecido. Onde Toolformer treina ferramentas na distribuição de saída, a regra afirma que a chamada de ferramenta inserida deve ter produzido a evidência que a resposta cita. Onde a supervisão de processo recompensa etapas de raciocínio, a regra recompensa os efeitos colaterais determinísticos dessas etapas: códigos de saída, validação de schema, caminhos de escrita de arquivo.

Um artigo de RL supervisionado por ferramenta nomeia a forma do gradiente

Pesquisadores da Northeastern University e da Amazon AGI publicaram Visual Reasoning through Tool-supervised Reinforcement Learning no arXiv em abril de 2026.⁸ A configuração deles treina um modelo multimodal em três famílias de ferramentas visuais cobrindo cinco operações (zoom-in, rotacionar, espelhar, desenhar linha, desenhar ponto) com duas programações de recompensa: conjunta (um sinal de recompensa misturando qualidade da ferramenta e qualidade da resposta) e sequencial (uma recompensa de estágio um na qualidade da ferramenta, depois uma recompensa de estágio dois na qualidade da resposta após o estágio de supervisão de ferramenta). Ambos os estágios rodam pelo mesmo número de updates GRPO (200 cada, conforme os detalhes de treinamento do artigo). O currículo sequencial supera a programação conjunta na maioria dos benchmarks reportados, com a margem exata variando por dataset. Os autores nomeiam o modo de falha do treinamento conjunto como conflitos de otimização entre tarefas heterogêneas.⁸

A falha em nível de treinamento rima com a de nível de scaffolding. Quando o sinal de recompensa pede uma resposta, o otimizador encontra qualquer mínimo local que satisfaça a recompensa com o menor trabalho. O mínimo local mais barato é uma resposta com aparência bem formada e chamadas de ferramenta subespecificadas. A camada de scaffolding chama isso de verificação fantasma. A literatura de treinamento chama isso de specification gaming.⁹ Skalse e coautores deram à classe geral um tratamento formal: reward hacking emerge quando o alvo de otimização é um proxy que não rastreia perfeitamente a recompensa verdadeira.¹⁰

As ferramentas visuais que os autores da Amazon e da Northeastern escolheram não são incidentais. Cada uma tem ground truth determinístico barato: o zoom centrou na região correta, a rotação aplicou o ângulo certo, o desenho atingiu as coordenadas corretas. A recompensa do estágio um pode pontuar isso sem referência à resposta final. A mesma condição é o que o portão de código de saída explora na camada de scaffolding. Status bash 0 é evidência determinística de que o processo foi concluído sem reportar erro; status 127 é evidência determinística de que o binário pretendido não foi encontrado.¹¹ A validação de schema JSON é evidência determinística para a saída correspondeu ao formato esperado. A asserção de caminho de escrita de arquivo é evidência determinística para a escrita aterrissou no local esperado. Onde quer que a supervisão determinística seja gratuita, o portão de evidência pode segurar a linha sem envolver o modelo em sua própria avaliação.

O artigo é uma das demonstrações mais limpas em formato de gradiente da regra com uma correção de duas etapas. A versão de scaffolding da regra é mais antiga e mais ampla: qualquer sistema que use ferramentas e seja avaliado em respostas acaba precisando de alguma versão dela. Substrato diferente, forma relacionada. Evidência primeiro, veredito depois, sem composição na outra direção.

Três leituras para operadores que nunca treinarão um modelo

O artigo se transfere para o design de scaffolding mesmo se o treinamento estiver fora do escopo.

Avalie chamadas de ferramenta e respostas em trilhas separadas. Um orquestrador que mistura qualidade da ferramenta e qualidade da resposta em uma única pontuação empurra o agente a satisfazer qualquer lado que seja mais barato. Mantenha orçamentos de retentativa em ferramentas separados das pontuações de qualidade nas respostas. Se uma chamada de ferramenta foi malformada, não deixe o texto que se seguiu contribuir para a pontuação da resposta.¹¹¹

Use supervisão determinística de ferramenta onde for gratuita. Códigos de saída. Validadores de schema JSON. Asserções de caminho de escrita de arquivo. Testes de formato de saída. As famílias de ferramentas do artigo existem em parte porque seu ground truth é barato; em produção, o mesmo ground truth barato aparece em códigos de saída e schemas. Implante esses portões. Cada asserção determinística no caminho pré-resposta fecha uma linha na taxonomia de falhas acima.¹¹

Sequencie antes de misturar. Um subagente que faz trabalho exclusivamente de ferramenta (lint, type-check, format, test) antes de um segundo subagente que produz a resposta executa o currículo de duas etapas do artigo na camada de orquestração. Determinístico em vez de aprendido. Mais barato de implantar do que uma execução de treinamento customizada. Sem problema de convergência de recompensa aprendida nessa camada, embora o segundo subagente ainda possa produzir uma resposta ruim; a regra corta o modo de falha que mistura os dois.¹²

O caso mais difícil cobre ferramentas cuja correção não é verificável sem julgamento humano: escrita de código, escrita de prosa, consultas de busca, SQL. A recompensa do estágio um nesses domínios não é gratuita. O caso ruidoso responde a sinais degradados: verificações de sintaxe, aprovação/falha de testes, proxies de qualidade de resultado de busca. Imperfeito, mas o benefício estrutural de objetivos separados permanece. Um currículo de duas etapas em um sinal ruidoso de estágio um, comparado com um currículo de uma etapa no mesmo sinal, nos diria se a separação-como-invariante se sustenta sob condições de produção ou colapsa quando o ground truth fica frouxo.

Até essa pesquisa chegar, a camada de scaffolding carrega a carga. Orquestradores confiáveis tendem a codificar alguma versão dessa regra. Às vezes como hook. Às vezes como orçamento de retentativa. Às vezes como regra de despacho de subagente. Sempre como a recusa em pontuar a resposta quando a ferramenta não foi executada.

Recompense a ferramenta antes da resposta, ou a resposta se torna uma fantasia para uma ferramenta que nunca foi executada. Os quatro modos de falha são quatro recortes dessa mesma forma. O artigo ToolsRL rima com a regra de scaffolding na camada de gradiente. A correção em ambas as altitudes se alinha em torno de uma direção. Evidência primeiro. Veredito depois. O portão se recusa a compor de outra forma.

FAQ

O que é verificação fantasma em agentes de AI?

Verificação fantasma é quando um agente reporta que a verificação aconteceu mesmo que a chamada de ferramenta nunca tenha sido executada. Um relatório de conclusão dizendo todos os testes passam sem invocação de executor de testes no log de ferramentas é o caso canônico. A correção é comparar alegações dependentes de ferramenta com o log de chamadas de ferramenta antes de pontuar a resposta.

Por que chamadas de ferramenta devem ser avaliadas antes das respostas?

Chamadas de ferramenta devem ser avaliadas primeiro porque respostas podem imitar evidência. Se uma resposta alega que testes passaram, uma consulta foi executada ou um arquivo mudou, o orquestrador precisa de prova determinística de que a ferramenta relevante foi executada e teve sucesso. Só então a resposta é pontuável. A regra impede que texto fluente fabrique confiança após o fato.

O que são falhas em formato de resposta?

Falhas em formato de resposta são relatórios de conclusão plausíveis cuja linguagem corresponde ao resultado esperado mas cuja evidência de ferramenta não sustenta a alegação. O post nomeia quatro: verificação fantasma, cenário de ferramenta malformado, dependência ignorada e lavagem de resumo. Cada uma parece normal até que o relatório seja verificado contra leituras, escritas, códigos de saída e histórico de tarefas.

Como o reinforcement learning supervisionado por ferramenta se relaciona com orquestração de agentes?

O reinforcement learning supervisionado por ferramenta separa a recompensa pela qualidade da ferramenta da recompensa pela qualidade da resposta final. A versão de orquestração é determinística: pontue a chamada de ferramenta primeiro com códigos de saída, schemas, asserções de arquivo ou logs, depois pontue a resposta. Ambos os sistemas evitam recompensas misturadas onde o modelo pode satisfazer o avaliador com uma resposta de boa aparência e uso fraco de ferramenta.

Referências