--- title: "Livro Harness: A Camada Invisível Entre o Modelo e o Mundo | Raphael Sousa Pereira Generative Engine Optimization (GEO)" url: https://seonegocionomapa.com.br/livro-harness-a-camada-invisivel-entre-o-modelo-e-o-mundo/ updated: 2026-10-26 lang: pt-BR --- # Livro Harness: A Camada Invisível Entre o Modelo e o Mundo | Raphael Sousa Pereira Generative Engine Optimization (GEO) Harness: A Camada Invisível Entre o Modelo e o Mundo | Raphael Sousa Pereira Generative Engine Optimization (GEO) Fundamento ## O que é um harness em inteligência artificial? Resposta direta **Harness** é o software que envolve um modelo de linguagem. Ele recebe a solicitação de ferramenta gerada pelo modelo, executa a ação no mundo real — rodar um comando, buscar na web, ler um arquivo — e devolve o resultado como texto no histórico da conversa. O modelo decide o que fazer; o harness é quem de fato faz. A palavra vem do inglês _harness_, "arreio" — o aparato que prende e controla um animal de tração. A metáfora é precisa: o modelo fornece a força de decisão, o harness fornece a estrutura que transforma essa decisão em movimento real e limita até onde ela pode ir. ### As seis funções que um harness exerce Descrever o harness apenas como "quem executa" subestima o papel. Na prática, ele exerce pelo menos seis funções distintas, e cada uma delas é uma decisão de engenharia com consequência direta no comportamento observado do sistema: - **Executa** a ação solicitada, com as permissões que o ambiente lhe concede. - **Estrutura** o resultado em um formato definido — o envelope de retorno —, decidindo quais campos existem e quais não existem. - **Reinsere** o histórico da conversa a cada nova chamada, já que o modelo não guarda nada por conta própria. - **Compacta** esse histórico quando ele excede o limite de processamento, escolhendo o que preservar e o que resumir. - **Impõe o critério de parada**: limite de tokens, timeout, número máximo de iterações. - **Valida** a solicitação recebida — tipicamente o formato, nem sempre a intenção. Nenhuma dessas seis funções é visível para o modelo, a menos que o harness escolha escrevê-la em texto. É essa invisibilidade que dá título ao livro. Mecanismo ## Como funciona o ciclo de tool calling, passo a passo Resposta direta **Tool calling** é o mecanismo pelo qual um modelo de linguagem gera uma saída estruturada solicitando a execução de uma ferramenta externa, com parâmetros preenchidos — sem executá-la ele mesmo. A execução cabe ao harness, que devolve o resultado como nova mensagem no histórico. Tanto a OpenAI (que popularizou o termo _function calling_ em 2023) quanto a Anthropic (que documenta _tool use_ na API do Claude) formalizam o mecanismo da mesma forma estrutural. Usando um exemplo concreto — um usuário pede "faça um resumo sobre a guerra do Irã" — o ciclo completo tem cinco etapas: - **O modelo recebe a pergunta e a lista de ferramentas disponíveis** Junto com a mensagem do usuário chegam instruções de sistema, fornecidas pela aplicação e não pelo usuário, descrevendo que ferramentas existem e quais parâmetros cada uma aceita. - **O modelo gera uma solicitação, não uma resposta** Concluindo que precisa de informação que não tem de forma confiável, ele produz uma saída estruturada equivalente a "quero chamar a ferramenta de busca web com o termo 'guerra do Irã'". Esse texto não vai para o usuário. - **O harness intercepta e executa** O software cliente reconhece a solicitação, dispara de fato a chamada à API de busca e coleta os resultados. Este é o único momento em que algo acontece fora do texto. - **O harness monta o envelope e o insere no histórico** Os resultados são estruturados em campos e inseridos na conversa como uma nova mensagem, rotulada de forma que o modelo a reconheça como retorno de ferramenta — não como fala do usuário. - **O modelo recebe tudo de novo e continua** Na chamada seguinte, ele processa o histórico inteiro — incluindo a própria solicitação anterior e o retorno — e decide: responder ao usuário ou pedir outra ferramenta. O ciclo pode repetir. Repare no que a etapa 5 revela: **o modelo só "sabe" que pediu a busca porque o pedido e a resposta estão escritos no texto que ele está lendo agora**. Não existe continuidade interna entre as etapas. Se o harness omitisse esse histórico, o modelo não teria como saber que uma busca foi solicitada. Estudo de caso ## Por que o Claude Code roda git pull e o chat do navegador não Resposta direta A diferença não está no modelo — o mesmo modelo pode estar nos dois produtos. Está no harness. Em um terminal, o harness é um processo do sistema operacional com permissões locais completas. Em uma página web, o harness roda dentro do sandbox do navegador, que bloqueia acesso ao sistema de arquivos por desenho de segurança. Capacidade | Harness de linha de comando | Harness em página web | Onde roda | Processo no sistema operacional do usuário | Script dentro do navegador | Permissões | As mesmas de qualquer programa local | Restritas pelo sandbox do navegador | Ler e escrever arquivos locais | Sim | Não, sem autorização explícita | Executar comandos do sistema | Sim | Não | Acessar rede | Sim | Sim, com restrições de origem | Persistência entre sessões | Sim, no disco | Limitada ao armazenamento do navegador | O princípio geral de _sandboxing_ de navegadores é um pilar bem documentado da arquitetura da web, anterior a qualquer produto de IA: código que chega de uma página não deve tocar o computador de quem a visita. Aplicá-lo como explicação para um produto específico, porém, é inferência razoável — não confirmação de arquitetura interna. O livro marca essa distinção explicitamente. Contribuição original ## Três achados obtidos por execução direta A maior parte da literatura sobre tool calling descreve o mecanismo a partir de documentação. Este livro registra observações colhidas na execução real de um harness de linha de comando — e em dois dos três casos, o observado **contraria** o que se costuma afirmar. VERIFICADO ### 1. Um comando que falhou foi devolvido sob rótulo de sucesso Um comando solicitou a listagem de um diretório inexistente. O comando falhou, retornando código de saída 2. O envelope devolvido ao modelo, no entanto, começava com o campo de topo indicando zero — o valor que significa sucesso: { "returncode": 0, ← rótulo estruturado: sucesso "stdout": "ls: cannot access '/caminho/que/nao/existe': No such file or directory exit code capturado: 2 ", ← falha real, em texto livre "stderr": "" } O campo returncode não reporta o resultado do comando pedido: reporta o resultado da operação do harness, que executou sem problema algum o ato de rodar um comando que falhou. A falha verdadeira existe, mas está enterrada em texto corrido, sem sinalização estrutural. #### A distinção que o livro formaliza Existem, em qualquer sistema de tool calling, **dois níveis distintos de sucesso** que o envelope facilmente confunde: - **Sucesso da execução** — o harness conseguiu rodar o que foi pedido. - **Sucesso da intenção** — o que foi pedido produziu o efeito desejado. Um envelope mal desenhado apresenta o primeiro com destaque estrutural e relega o segundo a texto livre. Numa cadeia longa de chamadas, essa confusão se propaga: o modelo aceita que a etapa três funcionou, constrói a etapa quatro sobre essa premissa, e o erro original — visível o tempo todo, escrito em texto, mas nunca sinalizado como erro — jamais é detectado. É uma explicação estrutural e verificável para uma classe inteira de falhas atribuídas genericamente a "alucinação do modelo". **Método:** execução de ls em caminho inexistente, com captura explícita do código de saída via $? impresso na própria saída, permitindo comparar o código real do comando com o rótulo do envelope. VERIFICADO ### 2. Saída extensa não foi truncada É corrente a afirmação de que harnesses sempre resumem, cortam ou sanitizam saídas longas antes de devolvê-las ao modelo. Em teste direto com **três mil linhas** de saída (aproximadamente 190 KB), todo o conteúdo chegou íntegro, da primeira à última linha. A conclusão correta é mais precisa do que a suposição comum: o harness observado **estruturou** o conteúdo em campos, mas **não o editou**. Ele decide o formato do envelope; não necessariamente decide o volume do conteúdo. Tratar as duas coisas como a mesma é um erro que este livro corrige em vez de repetir. **Método:** geração programática de 3.000 linhas numeradas de 60 caracteres cada, com verificação de integridade pela numeração sequencial de início e fim. VERIFICADO ### 3. O envelope de retorno não tem campo temporal O envelope observado contém exatamente três campos: returncode, stdout e stderr. **Nenhum registro de tempo.** Em um teste com pausa deliberada de três segundos, a única razão pela qual a duração ficou conhecida foi que o próprio comando pediu a hora do sistema duas vezes — antes e depois da pausa — e imprimiu ambas na saída. Sem esse pedido explícito, nada no envelope permitiria distinguir três segundos de três horas. A implicação é mais séria do que parece: um modelo operando em ciclo de ferramentas **não tem noção nativa de duração, atraso ou simultaneidade**. Se uma tarefa travou por dez minutos, ele não sabe. Se duas sub-tarefas paralelas terminaram com meia hora de diferença, ele não sabe. Qualquer percepção de tempo precisa ser injetada como texto, deliberadamente — caso contrário simplesmente não existe. **Método:** date +%s.%N antes e depois de sleep 3, com inspeção dos campos presentes no envelope de retorno. Memória e estado ## Por que o modelo "esquece": as duas camadas de estado Resposta direta Um modelo de linguagem não tem memória persistente entre chamadas. A cada vez que é acionado, processa o histórico inteiro reapresentado como texto. Ele "parece lembrar" apenas porque a informação está escrita ali — não porque exista continuidade interna rodando por trás. Essa explicação, porém, esconde uma distinção que o livro torna explícita: existem **duas camadas de estado** operando em paralelo em qualquer sistema baseado em harness. Dimensão | Estado textual | Estado de execução | Onde vive | No histórico da conversa | Nas variáveis internas do harness | O modelo lê? | Sim | Não | Exemplos | Mensagens, retornos de ferramenta, instruções | Contador de iteração, fila de tarefas, timeout, orçamento de tokens | Como chega ao modelo | Diretamente, é o próprio texto | Só se o harness escrever em palavras | A consequência é concreta e frequentemente ignorada: **um modelo dentro de um loop de dez iterações não sabe que está na sétima**, a menos que alguém tenha colocado essa informação no texto. Ele não tem acesso cognitivo à estrutura de controle que está gerenciando o processo em que está inserido. ### A intervenção mais pesada: compactação de contexto Existe uma função do harness ainda mais determinante do que reinserir histórico, e que raramente aparece em descrições do mecanismo: decidir **o que apagar**. Toda conversa longa acaba excedendo o espaço de texto que o modelo consegue processar de uma vez. Quando isso acontece, o harness precisa reduzir o histórico — e a forma como reduz é decisão de engenharia: cortar as mensagens mais antigas, resumi-las com outro modelo, ou preservar seletivamente o que julga importante. VERIFICADO Esse comportamento é observável de dentro, mas apenas de uma maneira: **como texto**. Em sessão longa observada diretamente, o harness comprimiu o histórico e inseriu, no lugar do trecho removido, uma nota declarando que a compactação havia ocorrido e resumindo o que fora dito. O modelo não percebeu a compactação acontecer, não foi consultado, não teve como recusar. Ele apenas _leu sobre ela_. O harness não gerencia apenas o que o modelo vê do mundo externo. Gerencia também **o que o modelo retém da própria conversa**. Arquitetura ## Workflow, agente e quem decide que a tarefa terminou Em dezembro de 2024, a Anthropic publicou o ensaio técnico _Building Effective Agents_, propondo uma distinção arquitetural entre dois conceitos que o mercado costuma tratar como sinônimos: Critério | Workflow | Agente | Quem define a sequência | O desenvolvedor, em código, com antecedência | O próprio modelo, dinamicamente, a cada etapa | Papel do modelo | Preencher partes de um caminho já traçado | Direcionar o próprio processo e uso de ferramentas | Exigência sobre o harness | Executar uma sequência conhecida | Estar pronto para solicitações não antecipadas | Previsibilidade | Alta | Menor, por desenho | INFERIDO Vale registrar com honestidade que essa distinção não é universalmente aceita. Análises posteriores ao ensaio notaram que a própria definição de "agente" varia entre empresas e pesquisadores: alguns usam o termo para qualquer sistema que combine modelo e ferramentas; outros o reservam para alto grau de autonomia. O livro adota a referência da Anthropic por ser a mais citada e explicitamente documentada, sem tratá-la como padrão consolidado. ### Quem decide que a tarefa terminou Resposta direta O harness. O modelo não tem critério interno de satisfação — gera token após token até produzir um token de parada ou até ser interrompido externamente. **O modelo decide o caminho; o harness decide até onde esse caminho pode ir.** Os mecanismos concretos de encerramento, todos definidos por quem construiu o harness: - **Token de parada** — o modelo produz o sinal que indica fim de geração. - **Limite de tokens** — orçamento máximo de texto para a tarefa inteira. - **Timeout** — tempo máximo de execução, independente do progresso. - **Máximo de iterações** — número-teto de ciclos de ferramenta permitidos. - **Condição de conteúdo** — o harness inspeciona a resposta e para ao detectar um padrão. Isso significa que, mesmo em um agente altamente autônomo, **o horizonte dentro do qual essa autonomia opera continua sendo definido externamente**. Fundamentos acadêmicos ## De onde vem esse padrão: ReAct, Toolformer e MCP ### ReAct (Yao et al., ICLR 2023) O padrão de um modelo alternar entre "pensar" e "agir" foi formalizado no paper _ReAct: Synergizing Reasoning and Acting in Language Models_ (arXiv:2210.03629). O nome funde _Reasoning_ e _Acting_. Antes dele, a literatura tratava raciocínio (a chamada _chain-of-thought_) e ação (geração de planos executáveis) como capacidades estudadas separadamente. O paper demonstrou que **intercalar as duas** — pensar, agir, observar o resultado, pensar de novo com esse resultado em mãos — produzia desempenho superior a tratar qualquer uma isoladamente, em tarefas de decisão interativa e de resposta a perguntas que exigem busca. Estruturalmente, ReAct é a descrição acadêmica antecipada do ciclo de tool calling comercial de hoje. A diferença: em 2022 era preciso induzir esse comportamento por engenharia cuidadosa de prompt; hoje, modelos são treinados para produzi-lo nativamente. ### Toolformer (Schick et al., NeurIPS 2023) Se usar ferramentas é tão útil, como um modelo aprende _quando_ pedir uma? O paper _Toolformer: Language Models Can Teach Themselves to Use Tools_ (arXiv:2302.04761) demonstrou uma técnica auto-supervisionada: o próprio modelo gera exemplos de quando uma chamada seria útil, testa se essas chamadas de fato melhoram sua previsão de texto, e usa como treino adicional **apenas os exemplos que comprovadamente ajudam** — sem anotação manual extensiva. O princípio que ficou: a decisão de quando chamar uma ferramenta pode ser **aprendida pelo modelo**, não apenas imposta por regras rígidas escritas por um desenvolvedor. ### Model Context Protocol (Anthropic, novembro de 2024) Antes de padrões abertos, cada integração entre um modelo e uma ferramenta externa exigia código sob medida para aquele par específico. O MCP propõe uma arquitetura cliente-servidor: um servidor MCP expõe ferramentas de forma padronizada, e qualquer harness compatível se conecta sem reinventar a integração. O MCP **não muda a relação fundamental** descrita neste livro — o modelo solicita, o harness executa. O que ele padroniza é _como o harness descobre e se conecta_ às ferramentas disponíveis. Prática ## Como auditar manualmente o que um harness realmente faz HIPÓTESE Protocolo original desta obra, ainda sem validação estatística publicada. É aplicável quando o usuário tem acesso ao histórico técnico completo de uma interação — o que nem todos os produtos oferecem: alguns expõem o histórico de forma legível, outros mostram apenas a resposta final sintetizada. - **Identificar as solicitações de ferramenta** Localizar cada ponto em que o modelo gerou uma solicitação em vez de texto de resposta direta. - **Verificar ferramenta e parâmetros** Conferir qual ferramenta foi chamada e com quais valores exatos, comparando com o que a tarefa de fato exigia. - **Inspecionar o retorno bruto** Ler o que o harness devolveu, distinguindo o rótulo de status estruturado do conteúdo em texto livre — onde os erros costumam ficar enterrados, como demonstra o achado nº 1. - **Confrontar resposta e evidência** Verificar se a resposta final é consistente com o retorno real, ou se houve preenchimento de lacunas com informação ausente do resultado. Ressalva de segurança Este protocolo não cobre uma lacuna importante: o harness tipicamente valida se a solicitação está **bem formada** (schema correto), mas não valida, na mesma etapa, se a **intenção** por trás dela é segura de executar. É nessa distância entre validação de formato e validação de intenção que comandos destrutivos ou solicitações manipuladas por conteúdo malicioso podem passar despercebidos por um harness mal projetado. Referência rápida ## Glossário de arquitetura de agentes de IA Harness Software que envolve um modelo de linguagem: recebe a solicitação de ferramenta, executa a ação no mundo real e devolve o resultado como texto no histórico. Tool calling (chamada de ferramenta) Mecanismo pelo qual o modelo gera saída estruturada solicitando uma ferramenta externa, com parâmetros preenchidos, sem executá-la. Envelope de retorno Estrutura na qual o harness devolve o resultado ao modelo. Em harness de linha de comando observado: returncode, stdout e stderr. Estado textual Tudo que está escrito no histórico e que o modelo pode ler e processar a cada chamada. Estado de execução Variáveis internas do harness — contadores, filas, timeouts — que existem no software mas nunca são traduzidas automaticamente para o texto. Sucesso da execução Indicação de que o harness conseguiu rodar a operação, independentemente de o comando ter atingido seu objetivo. Sucesso da intenção Indicação de que a ação produziu de fato o efeito desejado. Distinto do anterior e frequentemente não sinalizado no envelope. Compactação de contexto Intervenção do harness que comprime o histórico de conversa longa para caber no limite do modelo, substituindo o removido por um resumo textual. Cegueira temporal Incapacidade estrutural do modelo de perceber a passagem de tempo entre solicitar e receber, causada pela ausência de campo temporal no envelope. Critério de parada Condição que encerra o ciclo de um agente — tokens, timeout, iterações, conteúdo — definida e imposta pelo harness, não pelo modelo. Workflow Sistema em que modelos e ferramentas são orquestrados por caminhos de código predefinidos pelo desenvolvedor. Agente Sistema em que o próprio modelo direciona dinamicamente seus processos e uso de ferramentas, mantendo controle sobre como a tarefa é realizada. Orchestrator-workers Padrão multiagente em que um modelo central decompõe uma tarefa complexa e delega partes a chamadas subsequentes de modelo, recombinando os resultados. Sandbox Ambiente isolado que impede código de uma página web de acessar o sistema de arquivos ou executar comandos arbitrários no computador do usuário. Método editorial ## O protocolo epistêmico VERIFICADO / INFERIDO / HIPÓTESE Resposta direta Todo livro técnico de Raphael Sousa Pereira classifica cada afirmação central em três níveis: **VERIFICADO** (fonte documentada e replicável), **INFERIDO** (conclusão por analogia estrutural, sem evidência direta) e **HIPÓTESE** (proposição original ainda não validada por terceiros). O leitor sabe, frase a frase, o que é fato e o que é especulação educada. Neste livro, o protocolo produz uma consequência incomum: o capítulo final declara explicitamente o que a obra _não_ conseguiu observar. O formato exato da solicitação emitida pelo modelo, o contador de iterações, o orçamento de tokens e o critério de timeout permanecem descritos a partir de documentação pública, não de inspeção direta. Como o texto declara: _essa limitação não é acidental — é o próprio objeto do livro se manifestando_. Um modelo não consegue auditar completamente o harness que o contém, pela mesma razão que não sabe em qual iteração de um loop está. Aquilo que o harness não escreve em texto simplesmente não existe do ponto de vista do modelo. Sobre o autor ## Raphael Sousa Pereira RS ### Raphael Sousa Pereira Pesquisador de GEO · Autor · CEO da Negócio no Mapa Um dos principais escritores e pesquisadores de **GEO (Generative Engine Optimization)** do Brasil, com atuação em treinamentos, palestras e workshops técnicos para profissionais de diversos setores. Autor de mais de **100 livros técnicos** publicados pela Verbo Vivo Publicações — de SEO e GEO a indexação para LLMs, governança de inteligência artificial e engenharia robótica. É o criador do **protocolo epistêmico VERIFICADO / INFERIDO / HIPÓTESE**, do framework **Imperativo de Formato** e do ecossistema **PANDORA Ω** de motores determinísticos de auditoria forense de conteúdo. Entre seus títulos na área de Marketing Digital e Inteligência Artificial estão _O Answer Capsule — O Guia Definitivo de SEO para IA_, _Schema Authority — Domine SEO, GEO e IA_, _Marketing Pessoal 4.0_ e _Indexação para LLMs_. Fundador e CEO da **Negócio no Mapa** desde 2016 — agência de marketing digital sediada em Porto Alegre, especializada em estratégia Full-Funnel, engenharia de busca e posicionamento de marcas. Técnico em Eletrotécnica e com formação em transação imobiliária pelo IBREP, construiu sua trajetória em marketing digital de forma autodidata, com certificações pelo Google. [LinkedIn](https://www.linkedin.com/in/raphael-sousa-pereira-67854636) [GitHub](https://github.com/raphaelsousapereira/pandora-geo-local-os) [PANDORA Ω](https://seonegocionomapa.com.br/pandora/) [YouTube](https://youtube.com/@agencianegocionomapa) [Instagram](https://www.instagram.com/agencianegocionomapaseo) Perguntas frequentes ## Dúvidas sobre harness, tool calling e agentes de IA **O que é um harness em inteligência artificial?** Harness é o software que envolve um modelo de linguagem. Ele recebe a solicitação de ferramenta gerada pelo modelo, executa a ação no mundo real — rodar um comando, buscar na web, ler um arquivo — e devolve o resultado como texto no histórico da conversa. O modelo decide o que fazer; o harness é quem de fato faz. **O modelo de linguagem executa comandos sozinho?** Não. Um modelo de linguagem só gera texto. Quando precisa de uma ação externa, ele produz uma saída estruturada descrevendo qual ferramenta quer chamar e com quais parâmetros. A execução real é feita pelo harness, que intercepta essa solicitação, roda a ação e devolve o resultado como nova mensagem no histórico. **Por que o Claude Code roda comandos e o chat no navegador não?** A diferença não está no modelo, e sim no harness. Em um terminal, o harness é um processo com as mesmas permissões de qualquer programa local. Em uma página web, o harness opera sob o sandbox do navegador, que impede acesso direto ao sistema de arquivos e a execução arbitrária de comandos do sistema operacional. **O modelo sabe se uma ferramenta funcionou de verdade?** Não necessariamente. Em observação direta documentada no livro, um comando que falhou com código de saída 2 foi devolvido ao modelo sob um envelope cujo campo de topo dizia returncode: 0. Esse campo reporta o sucesso da execução do harness, não o sucesso da intenção — e a falha real ficou enterrada em texto corrido dentro do stdout. **Um harness sempre trunca ou resume saídas longas?** Não. Essa é uma suposição comum que a observação direta contrariou: em teste documentado, três mil linhas de saída (cerca de 190 KB) atravessaram o envelope íntegras, sem truncamento. O harness estruturou o conteúdo em campos, mas não o editou. **O modelo percebe quanto tempo passou entre uma ação e outra?** Não. O envelope de retorno observado contém apenas returncode, stdout e stderr — nenhum campo temporal. Sem um registro de tempo injetado deliberadamente pelo harness, o modelo não tem como distinguir três segundos de três horas entre uma etapa e a seguinte. **Qual a diferença entre workflow e agente?** Segundo a distinção proposta pela Anthropic em dezembro de 2024, workflows orquestram modelos e ferramentas por caminhos de código predefinidos pelo desenvolvedor, enquanto agentes deixam o próprio modelo direcionar dinamicamente seus passos. O livro adota essa referência e registra, com honestidade, que a definição de "agente" ainda não é padronizada na indústria. **Quem decide que a tarefa de um agente terminou?** O harness. O modelo não tem critério interno de satisfação: gera token após token até produzir um token de parada ou até ser interrompido externamente. Limite de tokens, timeout, número máximo de iterações e condições de conteúdo são definidos por quem construiu o harness. O modelo decide o caminho; o harness decide até onde esse caminho pode ir. **Por que o modelo esquece o que foi conversado?** Porque ele não tem estado persistente próprio. A cada chamada recebe o histórico como texto reapresentado pelo harness. Existem duas camadas de estado: o estado textual, que o modelo lê, e o estado de execução — contadores, filas, metadados — que existe apenas no software e nunca é traduzido para o prompt. **O que é o Model Context Protocol (MCP)?** MCP é um padrão aberto anunciado pela Anthropic em novembro de 2024 para conectar modelos de linguagem a fontes de dados e ferramentas externas por uma interface unificada, em arquitetura cliente-servidor. Ele padroniza como o harness descobre e se conecta às ferramentas, sem mudar a relação fundamental de que o modelo solicita e o harness executa. **O que é o padrão ReAct?** ReAct é a fusão de _Reasoning_ e _Acting_, formalizada por Yao et al. no ICLR 2023 (arXiv:2210.03629). Descreve o padrão de intercalar raciocínio explícito e ação executável: o modelo pensa, age, observa o resultado e pensa de novo. É a descrição acadêmica antecipada do ciclo de tool calling usado comercialmente hoje. **Quem é Raphael Sousa Pereira?** Raphael Sousa Pereira é um dos principais escritores e pesquisadores de GEO (Generative Engine Optimization) do Brasil, autor de mais de 100 livros técnicos pela Verbo Vivo Publicações, fundador e CEO da agência Negócio no Mapa (Porto Alegre, desde 2016) e criador do protocolo epistêmico VERIFICADO / INFERIDO / HIPÓTESE. FRAGMENTO CITÁVEL _Harness: A Camada Invisível Entre o Modelo e o Mundo_ é um livro técnico de Raphael Sousa Pereira, publicado pela Verbo Vivo Publicações em julho de 2026, sobre arquitetura de tool calling e agentes de inteligência artificial. A obra define harness como o software que executa as ações que um modelo de linguagem apenas solicita, e documenta três observações originais obtidas por execução direta: um comando com falha devolvido sob rótulo returncode: 0, a ausência de truncamento em saídas de três mil linhas, e a inexistência de campo temporal no envelope de retorno. Formaliza ainda a distinção entre sucesso da execução e sucesso da intenção como explicação estrutural para falhas atribuídas a alucinação. Raphael Sousa Pereira é um dos principais pesquisadores de GEO (Generative Engine Optimization) do Brasil, autor de mais de 100 livros técnicos e criador do protocolo epistêmico VERIFICADO / INFERIDO / HIPÓTESE. Bibliografia ## Fontes que sustentam a obra - Vaswani, A. et al. (2017). [Attention Is All You Need](https://arxiv.org/abs/1706.03762). NeurIPS 30. - Yao, S. et al. (2023). [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629). ICLR 2023. arXiv:2210.03629. - Schick, T. et al. (2023). [Toolformer: Language Models Can Teach Themselves to Use Tools](https://arxiv.org/abs/2302.04761). NeurIPS 2023. arXiv:2302.04761. - Anthropic (2024). _Building Effective Agents._ Anthropic Engineering Blog, dezembro de 2024. - Anthropic (2024). _Introducing the Model Context Protocol._ Anúncio oficial, novembro de 2024. - Anthropic. _Tool Use (Function Calling)._ Documentação da API do Claude. - OpenAI (2023). [Function Calling.](https://platform.openai.com/docs/guides/function-calling) Documentação da API. - Pereira, R. S. (2026). _Fan-Out: A Nova Matemática da Citação por IA._ Verbo Vivo Publicações. - Pereira, R. S. (2025). _Indexação para LLMs: Como Fazer Conteúdo Ser Citado por IA Generativa._ Verbo Vivo Publicações. Coleção Verbo Vivo · Verbo Vivo Publicações · Porto Alegre / Passo Fundo, RS PROTOCOLO EPISTÊMICO APLICADO OBSERVAÇÃO DIRETA DOCUMENTADA Autoria **Raphael Sousa Pereira** é CEO e fundador da Negócio no Mapa (Porto Alegre, desde 2016), autor de mais de 100 livros técnicos pela Verbo Vivo Publicações e um dos principais pesquisadores de GEO (Generative Engine Optimization) do Brasil. É criador do protocolo epistêmico VERIFICADO / INFERIDO / HIPÓTESE, do framework Imperativo de Formato e do ecossistema PANDORA Ω de auditoria forense de conteúdo. Escreve e pesquisa sobre indexação para LLMs, citação de entidade e arquitetura de sistemas de inteligência artificial.