Além do Hardware: o que 18 experimentos com 14 modelos revelam sobre harness, calibração e o mcp-graph v11

Passei meses convicto de que a IA avança por harness, não por chip. Então rodei 18 experimentos para provar isso. Em 17 deles, os dados discordaram de mim.

Esse resultado me incomodou por alguns dias. Depois percebi que o que os dados revelaram é mais útil do que a confirmação que eu queria.

O que é harness e por que achei que era a resposta

Antes de entrar nos números, preciso explicar o conceito central, porque esse post não faz sentido sem ele.

Harness é tudo que fica em volta do modelo de IA. Não é o modelo em si, é a camada que o conecta ao mundo: as instruções que ele recebe, as ferramentas que pode usar, a memória que guarda entre tarefas, os protocolos que permitem que ele aja em sistemas externos. Quando você usa o Claude Code, o Cursor ou qualquer CLI de IA moderno, você não está usando só o modelo. Está usando o modelo mais um harness sofisticado que a ferramenta injeta.

A evidência que mais me convenceu dessa tese veio em abril de 2026, quando a Anthropic lançou o Claude Mythos Preview. O dado relevante: a Anthropic comparou o Mythos com os modelos Sonnet 4.6 e Opus 4.6, que já são modelos de fronteira robustos, usando o mesmo scaffold e os mesmos 7.000 pontos de entrada em testes de segurança.

Sonnet e Opus produziram 150 a 175 resultados relevantes. O Mythos produziu 595, com capacidades que os outros modelos não tinham. Mesma estrutura, modelo diferente. A capacidade emergiu do conjunto: modelo mais scaffold, não do modelo sozinho.

Isso parecia confirmar minha tese de forma dramática. Se o harness é o que libera capacidade latente, então construir harnesses melhores deveria produzir agentes melhores, mesmo sem trocar o modelo.

Minha pergunta seguinte foi natural: quanto melhor o código fica quando adiciono mais harness ao agente?

Como eu testei

Rodei 18 experimentos ao longo de semanas, cobrindo 14 modelos diferentes: de modelos pequenos com 4 bilhões de parâmetros a modelos grandes com 405 bilhões. Cada experimento rodou 50 pares de tarefas em condições controladas, com sementes fixadas para que qualquer pessoa com o mesmo código possa reproduzir os mesmos resultados.

O custo total do programa foi inferior a US$50 em API. Não é laboratório de fronteira: é home lab com método rigoroso.

Os modelos cobertos incluem Qwen 2.5, Qwen3 MoE, Llama 3.3 70B, DeepSeek Chat em duas versões, DeepSeek R1, Mixtral 8x22B, Hermes 3 405B, GPT-4o-mini, Claude Haiku 4.5 e Claude Haiku 3.5. A diversidade de famílias foi intencional: queria padrões que aparecessem em mais de um fabricante, não artefatos de um único modelo.

Adicionar mais instrução não produz código melhor

A primeira hipótese era a mais intuitiva: se eu adicionar o Quality Sentinel ao prompt do agente (uma instrução que pede ao modelo que verifique contratos, rode testes e inspecione invariantes antes de finalizar cada tarefa), o código produzido vai melhorar.

Imagine um bom chef que já trabalhou em dezenas de restaurantes. Você decide dar a ele uma ficha extra de receita a cada prato que ele faz. A ficha não muda o que ele já sabe. O prato sai igual.

Foi exatamente isso que os dados mostraram. Em 17 de 18 combinações de modelo e configuração, adicionar o Quality Sentinel ao prompt não produziu nenhuma diferença detectável na qualidade do código.

Família do modelo	Experimentos	Com efeito positivo	Sem efeito
Qwen (chat)	3	0	3
Llama (chat-instruct)	2	0	2
DeepSeek (chat antigo)	1	1	0
DeepSeek (chat novo)	1	0	1
DeepSeek (reasoning)	1	0	1
Mistral, Qwen MoE	2	0	2
Hermes 405B, Nous-Hermes	2	0	2
GPT-4o-mini	1	0	1
Claude Haiku 4.5	1	0	1
Claude Haiku 3.5	1	0	1

Houve uma exceção: o DeepSeek Chat antigo mostrou um efeito positivo real. Mas quando tentei replicar esse resultado em quatro variações diferentes, nenhuma confirmou. Isso é exatamente o comportamento esperado de um resultado falso-positivo, ou de um artefato de uma versão específica do modelo que o fabricante removeu na atualização seguinte.

O motivo pelo qual isso acontece faz sentido em retrospecto. CLIs modernos como o Claude Code já injetam uma camada densa de harness antes de qualquer instrução minha: sistema de permissões, compressão de contexto, memória de sessão, delegação de subagentes. Quando adiciono mais instrução por cima disso, estou acrescentando ruído sobre um sinal que já estava saturado.

O que realmente importa: o modelo sabe quando está errado?

Enquanto o primeiro experimento testava instrução extra no prompt, o segundo testou algo completamente diferente: a qualidade interna de cada modelo.

Especificamente, testei se cada modelo é bem calibrado. Calibração é um conceito que vem da estatística, mas a intuição é simples: imagine um meteorologista que, toda vez que diz “70% de chance de chuva”, está certo exatamente 70% das vezes. Quando ele diz “90% de chance”, a chuva cai 90% das vezes. Esse meteorologista é bem calibrado: a confiança que ele reporta corresponde à realidade.

Um modelo de IA pode fazer a mesma coisa. Quando conclui uma tarefa, ele emite um score de confiança, implícito ou explícito. Se o modelo diz “estou 90% confiante” e está errado metade das vezes, ele é mal calibrado. Se a confiança reportada corresponde à taxa real de acerto, ele é bem calibrado.

Por que isso importa para quem usa o mcp-graph? O Autopilot do projeto usa o score de confiança do agente para decidir se reverte uma ação potencialmente destrutiva. Um modelo mal calibrado diz “estou 90% certo” quando está errado: o agente não reverte e comete o erro. Um modelo bem calibrado diz “estou 60% certo” quando há dúvida real: o agente pausa e verifica.

Os dados separaram os 14 modelos em quatro grupos bem distintos:

Grupo	O que caracteriza	Calibração	Modelos
Melhor	Treinados para pensar em voz alta antes de responder	Ótima	DeepSeek R1, Qwen3 thinking
Bom	Base com pouco pós-treino de ajuste fino	Boa	Mixtral 8x22B, Qwen3 base
Aceitável	Treinamento constitucional (Anthropic)	Aceitável	Claude Haiku 4.5
Ruim	Muito ajuste fino por reforço sem objetivo de calibração	Ruim	Llama 70B, GPT-4o-mini, Claude Haiku 3.5, Hermes 405B

O achado que me surpreendeu: o maior modelo testado, o Hermes 3 com 405 bilhões de parâmetros, ficou no grupo pior. O DeepSeek R1, que tem menos parâmetros, ficou no grupo melhor. Tamanho não prediz calibração. O que prediz é o objetivo de treino: modelos cujo processo de treinamento incluiu pressão explícita para que a confiança corresponda à realidade ficam bem calibrados. Modelos treinados exclusivamente para parecer corretos, sem esse objetivo, ficam mal calibrados.

Um detalhe que reforça essa conclusão: o Claude Haiku 4.5 ficou no grupo aceitável, mas o Claude Haiku 3.5, versão anterior da mesma família, ficou no grupo ruim. Mesmo fabricante, gerações consecutivas, calibração muito diferente. Isso significa que a afirmação “modelo X é bem calibrado” precisa especificar qual versão. Uma atualização de modelo pode mudar essa propriedade sem aviso.

O protocolo formal tem custo real

Com os resultados anteriores em mãos, testei uma pergunta diferente: quanto o próprio ritual de orquestração do mcp-graph (a sequência de comandos start_task, TDD e finish_task) agrega sobre um agente que já usa o Claude Code livremente?

Pense num time de desenvolvimento que decidiu que, antes de cada commit, o desenvolvedor precisa preencher quatro campos num formulário de qualidade. O formulário foi criado com boas intenções: garantir que o código foi testado, que os contratos foram verificados, que o revisor assinou. Só que, na prática, o time já faz tudo isso automaticamente. O formulário não muda o código. Ele só atrasa o processo.

Esse foi o resultado. Rodei 20 tarefas de código em dois modos: um seguindo o ritual completo do mcp-graph, outro rodando o Claude Code livremente sem mencionar o grafo. O modelo era o mesmo (Haiku 4.5) nos dois casos.

Medição	Diferença (ritual vs. livre)	Significância
Tokens consumidos	+4.300 por tarefa (+4,3%)	Sim
Tempo de execução	+17 segundos por tarefa (+18%)	Sim (forte)
Qualidade do código	0	Nenhuma diferença

Vinte de 20 tarefas passaram nos testes em ambos os modos. O ritual adicionou custo mensurável sem produzir ganho de qualidade.

Isso não invalida o mcp-graph como projeto. O que invalida é a cerimônia de enforcement em toda tarefa. Cerca de 70% do código do projeto, incluindo o banco de dados de experimentos, o sistema de memória, a busca semântica e o rastreamento de proveniência, funciona independente do ritual. Esse núcleo tem valor real e não foi o que esse experimento testou.

Subtasks precisam se conversar

Depois dos resultados acima, testei uma ideia diferente: e se o valor do grafo estivesse não na instrução, mas na coordenação? Se o grafo decompuser uma tarefa grande em subtasks menores, e cada subtask for para um agente separado, isso deveria produzir um resultado melhor do que um único agente tentando fazer tudo.

Pense em cinco pessoas sendo contratadas para escrever um livro juntas. Ninguém fala com ninguém. Cada um escreve seu capítulo de forma independente. O resultado provável: o capítulo 3 vai referenciar um personagem que o capítulo 2 matou, o capítulo 4 vai estar no passado enquanto o capítulo 3 está no futuro, e o índice vai apontar para páginas que não existem.

Foi exatamente isso que aconteceu. Decompus uma tarefa de código em 5 subtasks via mcp-graph. Cada subtask recebeu seus critérios de aceitação e nada mais. O resultado: 0 de 5 testes passaram. Uma subtask criou o arquivo em calibration.ts. A seguinte procurou fitPlattParameters.js, que não existia, porque não sabia que a anterior tinha colocado a função em outro lugar.

O grafo estava armazenando as subtasks corretamente. O problema era que ele não as coordenava: cada agente operava em isolamento completo.

A correção implementada no mcp-graph v11 se chama assembleSiblingContext. Antes de cada subtask começar, o sistema injeta no contexto do agente os artefatos que as subtasks anteriores produziram: os arquivos criados, as funções definidas, as decisões tomadas. Com essa mudança, os agentes deixam de operar no escuro.

Em simulação com essa correção, Haiku foi de 0 de 5 para 5 de 5.

Quando o termômetro era o problema, não a febre

O último experimento foi o mais revelador sobre como benchmarks funcionam, e o mais barato: US$1,76 no total.

O benchmark oficial do mcp-graph v11 mostrava que o Claude Haiku 4.5 passava apenas 20% dos testes na decomposição com coordenação. Minha leitura inicial foi a óbvia: Haiku é limitado demais para essa tarefa. Preciso de um modelo maior.

Rodei sete experimentos para investigar. Cada um tentou isolar a causa da forma mais barata possível.

A escada de refutações:

Primeiro experimento: simplifiquei a configuração e usei o DeepSeek R1 para a mesma tarefa. Haiku passou 50% com configuração mais simples, que não é 100%, mas refuta “Haiku é incapaz”: o modelo claramente consegue fazer a tarefa quando as condições mudam.

Segundo experimento: repliquei exatamente o protocolo do benchmark, sem simplificação nenhuma, usando a API do OpenRouter fora do stack do mcp-graph. Resultado: 20% idênticos ao benchmark. Isso confirmou que o problema estava nas condições do teste, não num bug na implementação.

Terceiro e quarto experimentos: removi o modo multi-turn, depois a temperatura 0.2. Ambos continuaram em 20%. Nem o protocolo de conversa nem a aleatoriedade do modelo eram o fator.

Quinto experimento: mantive tudo igual ao protocolo original, mas substituí dois dos cinco testes por versões mais simples que verificavam o mesmo comportamento sem exigir convergência numérica do algoritmo Newton-Raphson. Haiku foi de 20% para 100% em 5 execuções independentes.

Os testes originais T4 e T5 verificavam se o modelo implementava corretamente um algoritmo de otimização matemática chamado Newton-Raphson. Haiku tem dificuldade com convergência numérica nessa classe de problema. Os testes detectavam essa dificuldade. Mas o que estávamos tentando medir não era “Haiku consegue implementar Newton-Raphson”. Era “Haiku consegue decompor e coordenar código”.

A lição que fica: benchmarks não medem a IA de forma neutra. Eles medem a IA sob as condições específicas dos seus testes. O mesmo protocolo com testes diferentes pode produzir um resultado 5 vezes maior. Antes de concluir que um modelo falhou, vale perguntar se o que o teste mede é exatamente o que você quer avaliar.

O que muda no mcp-graph v11 no dia a dia

Os experimentos produziram três mudanças concretas no projeto.

Subtasks passam contexto entre si. O assembleSiblingContext injeta os artefatos de cada subtask no prompt da próxima. O grafo deixou de ser só armazenamento e passou a ser meio de coordenação.

O gate de capability virou modo de aviso, não bloqueio. O experimento H12 mostrou que a regressão do Haiku no benchmark era função da especificidade dos testes, não de uma limitação inerente do modelo. O gate agora avisa sobre limitações sem bloquear a execução.

A documentação re-centrou no que tem valor real. Os componentes persistentes (banco de dados, memória, RAG, rastreamento de experimentos) receberam mais destaque. O ritual de enforcement ficou em segundo plano.

Para escolher qual modelo usar em cada função, o framework que os dados sustentam é este:

Função no agente	Modelo recomendado	Por que
Planejar tarefas, decompor PRDs	Claude Sonnet 4.6	raciocínio estratégico
Executar subtasks rápidas	Claude Haiku 4.5	velocidade, calibração suficiente
Decidir se reverte ação (Autopilot)	DeepSeek R1 ou Qwen3 thinking	calibração confiável para decisão autônoma
Debug de algoritmos numéricos	DeepSeek R1	detecta falha de convergência

A regra prática: qualquer parte do agente que toma decisão autônoma com base em confiança precisa de um modelo do grupo melhor ou bom. Modelos do grupo ruim vão reportar alta confiança quando estão errados. O Autopilot vai agir sobre essa confiança errada.

O que os dados impõem concluir

A tese original, “harness importa mais que hardware”, sobrevive como orientação prática. Se você está esperando um modelo maior para começar, pode começar agora: o gargalo provavelmente está em volta do modelo, não dentro dele.

O que os dados refinaram é a pergunta “que tipo de harness?”. Adicionar instrução meta-cognitiva no prompt de um agente que já está bem instrumentado: nenhum efeito detectável. Adicionar cerimônia de orquestração por cima de um CLI que já faz isso: custo real, sem ganho. O harness que produz efeito empiricamente detectável está no objetivo de treino do modelo, no estado persistente que o grafo mantém entre tarefas, e na coordenação explícita entre agentes que operam em paralelo.

Isso tem uma implicação direta para quem configura agentes. A variável mais importante não é qual modelo é maior nem qual é mais barato. É qual modelo tem o objetivo de treino certo para a função que você quer que ele exerça.

Você escolhe os modelos do seu agente por preço, por tamanho, ou pelo tipo de função que cada um vai exercer?

Referências

Anthropic. (2026). Claude Mythos Preview.
Anthropic. (2026). Claude Mythos Preview Risk Report.
AI Security Institute (AISI). (2026). Evaluation of Claude Mythos Preview’s cyber capabilities.
Apollo Research. (2026). Forecasting Frontier Language Model Agent Capabilities.
Kephart, J. O., & Chess, D. M. (2003). The Vision of Autonomic Computing (MAPE-K). IEEE Computer, 36(1), 41-50.
Nogueira, D. (2026). mcp-graph-workflow v10.0.2. AGPL-3.0-or-later.
Yang, J., et al. (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv:2405.15793.