Como aplicar controle de versão para agentes hoje

Controle de versão para agentes de IA funciona assim: cada requisito vira um commit que guarda o pedido e o checkpoint do trabalho. Quando um novo pedido contradiz o antigo, um agente escolhe a versão compatível e cria um branch. No teste dos autores, isso cortou 73,6% dos tokens em código.

O que é o GitHarness e de onde vem a ideia

O GitHarness é um método de controle de versão para agentes de IA, descrito em preprint de 29 de setembro de 2026 no arXiv 2609.36789. Em vez de manter uma conversa linear, ele guarda cada requisito e o trabalho correspondente como um commit em um grafo que aceita branches.

O harness é o software ao redor do modelo: ele executa as ferramentas e guarda o estado do trabalho. No GitHarness, um commit não carrega só código. Ele pareia o requisito vigente com um checkpoint persistente do que foi feito para atendê-lo.

Um modelo treinado, chamado Git Agent no paper, escolhe qual versão histórica serve de base. Os autores ajustaram apenas esse seletor, um Qwen3 de 8 bilhões de parâmetros, com aprendizado por reforço. Os modelos que executam o trabalho ficam congelados.

Atenção ao status: os autores afirmam no paper que vão liberar a implementação, mas até outubro de 2026 o código e os prompts completos não foram publicados. Não existe, portanto, ferramenta oficial para instalar hoje.

Por que continuar a conversa ou recomeçar do zero custa caro

Os dois comportamentos padrão desperdiçam recursos porque ignoram quais partes do trabalho continuam válidas. O paper ilustra com dois casos: um feedback muda a cor de um guarda-chuva e outro remove uma seção de um relatório.

Na continuação simples, o agente empilha o pedido novo sobre a versão desatualizada. A cor antiga do guarda-chuva permanece no resultado, e o contexto acumula trabalho obsoleto em todas as turnos seguintes.

No reinício completo, o agente joga fora progresso que o novo pedido não afetou. Ele reescreve seções do relatório que estavam corretas, gastando tokens e tempo de execução.

Nenhum dos dois caminhos é uma escolha deliberada: é o que o harness faz quando falta estrutura. O problema central é decidir qual versão anterior ainda é segura como base, e é exatamente essa decisão que o GitHarness automatiza.

Como funciona o grafo de versões e o Git Agent

Cada mudança de requisito cria uma versão no grafo. A versão guarda duas coisas: o requisito efetivo e um checkpoint do trabalho feito para ele. Nada é sobrescrito, então versões antigas continuam disponíveis para consultas futuras.

O Git Agent roda um loop de raciocínio e ação, no estilo ReAct: ele raciocina, chama uma ação, lê o resultado e repete. Ao final, devolve três saídas: o requisito resolvido, a versão base escolhida e uma dica de atualização que o paper marca como não autoritativa.

Ele dispõe de três ações, cada uma com um papel claro:

• Inspect: lê o requisito de uma versão passada. Não decide nada sozinho.
• Commit: declara o requisito completo atual e escolhe a versão base. Se a base é o head atual, o commit estende o caminho principal; se é outra versão, cria um branch.
• Reuse: aponta uma versão que já satisfaz o requisito, e nada mais é executado.

Com a base escolhida, o harness executa um dos três modos de execução:

Modo	O que faz	Custo extra
Reutilização exata	Devolve o checkpoint antigo sem executar nada	Zero
Reutilização e patch	Bifurca o checkpoint e altera só os arquivos afetados	Baixo
Resolução do zero	Começa com workspace vazio	Alto

No exemplo do guarda-chuva, o modo adequado é reutilização e patch: o harness bifurca a versão com a cor original e muda apenas o trabalho afetado. A versão desatualizada permanece no grafo.

Há uma lacuna de documentação: sem o código publicado, ninguém sabe se um checkpoint guarda arquivos, estado de chat ou ambos. O formato exato dos prompts do Git Agent também não foi divulgado.

O que o benchmark MT-Agent-Bench mediu

Os autores criaram um benchmark próprio, o MT-Agent-Bench, com cinco domínios de 100 tarefas cada: matemática, SQL, busca, código e pesquisa. Nove tipos de mudança de requisito, agrupados em três categorias, testam o agente ao longo da tarefa.

O teste cobriu 30 configurações: dois modelos (Qwen3 32B e DeepSeek-V4-Flash) vezes três harnesses (TCRag, Stack Planner e OpenHands) vezes cinco tipos de tarefa. Nenhum teste usou Claude Code, Codex ou Cursor. Como o benchmark é dos próprios autores, trate os números como evidência de primeira parte.

O GitHarness superou a linha de base nativa nas 30 configurações e igualou ou superou o melhor baseline concorrente em 28 delas. Ele não venceu todos os concorrentes em todos os cenários.

Em código com DeepSeek-V4-Flash, a taxa de tarefas resolvidas subiu assim:

Harness	Nativo	GitHarness
Stack Planner	67	74
OpenHands	64	72
TCRag	56	62

No Qwen3 32B, os ganhos em código foram maiores em pontos percentuais, mas partiram de bases fracas: 3 para 19, 8 para 17 e 7 para 16 nos três harnesses.

Tokens: onde o método economiza e onde gasta mais

A economia de tokens depende da tarefa. No melhor caso medido, Stack Planner com DeepSeek-V4-Flash em código, o baseline nativo consumiu cerca de 4,90 milhões de tokens a US$ 2,28, e o GitHarness cerca de 1,29 milhão a US$ 0,63, uma queda de 73,6%.

Nas outras modalidades do mesmo setup, a economia foi menor: SQL poupou 35,8%, busca 54,5% e pesquisa 36,7%. Ou seja, fora do melhor caso, a faixa fica entre 36% e 55%, sempre segundo a tabela 10 do paper.

Matemática andou na direção oposta. Os tokens subiram de 43,13 mil para 59,98 mil, cerca de 39% a mais, mesmo com a acurácia em alta. O paper não explica o motivo. Economia, portanto, não é garantia.

Vale lembrar que reutilizar ou remendar executa menos trabalho, o que é consistente com os números menores de tokens. Mas o único número que você deve citar como 73,6% é aquele setup específico, reportado pelos autores.

A ablação que mostra o custo de escolher mal a base

A prova mais útil do paper é a ablação em que os autores removem a escolha de versão histórica e fixam o head atual como base. Isso reproduz o comportamento de sempre continuar da última versão, usando Stack Planner com DeepSeek-V4-Flash.

O efeito foi forte em todos os domínios:

Domínio	GitHarness	Sem seleção de versão
Código	74,0	44,0
Matemática	94	84
Busca	58	42

Em código, os tokens saltaram de 1,29 milhão para 4,51 milhões, cerca de 3,5 vezes mais. O agente rendeu pior e custou mais caro ao mesmo tempo.

Duas outras ablações em código completam o quadro. Sem a ação inspect, a taxa caiu para 42,0 com 4,22 milhões de tokens, quase tão grave quanto remover a seleção inteira. Sem a resolução do zero, a taxa ficou em 72,0, mas poupou cerca de 260 mil tokens. Ou seja: ler requisitos antigos antes de escolher importa, e o modo do zero compra acurácia com tokens.

Os autores registram seus próprios limites no texto. Eles admitem que o método depende de interpretar requisitos com precisão, o que fica difícil com feedback ambíguo ou conflitante, e que restaurar um estado compatível não garante que o agente preserve todo o trabalho não afetado.

O que você pode usar hoje: pi-optchat e o hábito de Git

Já que o código do GitHarness não saiu, existem dois caminhos práticos em outubro de 2026. Um é uma extensão comunitária; o outro é um hábito manual que copia as duas ideias centrais do paper.

pi-optchat: memória em árvore, não branches

O pi-optchat é uma extensão comunitária para o agente Pi, com 237 estrelas em 11 de outubro de 2026. Implementa a receita OptChat descrita por Victor Taelin, do seu perfil no GitHub, mas não é a implementação oficial dele.

Cada mensagem entra em um log de apenas append. Um modelo barato comprime esse log numa árvore binária de resumos de uma linha. O modelo principal enxerga uma visão limitada: mensagens recentes em detalhe fino, antigas em detalhe grosso. Uma ferramenta de zoom com um identificador e um número N expande uma linha; com N igual a 1, devolve a mensagem completa.

Os números do readme: a visão cresce uma linha por mensagem até 128.000 bytes, quando comprime em lote para 64.000. A receita original estima uma média de 96 kilobytes, o que dá perto de 30 mil tokens. As mensagens originais ficam no log, então o agente vê uma visão comprimida de todo o histórico, não só 30 mil tokens de história crua.

O pi-optchat é um design de memória: ele não cria branches, não faz rollback de trabalho e não tem benchmark contra trabalho obsoleto. Ele importa histórico do Claude Code, Codex, Pi e ChatGPT, mantendo datas e rótulos de origem, e o próprio armazenamento de perfil é versionado em Git, sem backup remoto. Instale com pi install npm:pi-optchat; exige Pi 1.0.2 ou compatível, Node 22.19 ou mais novo e Git. A licença é MIT e a versão mais recente no npm é a 0.8.3, de 10 de outubro de 2026.

O hábito de Git que você adota sem ferramenta nova

Este hábito é conselho prático, não algo medido no paper. Ele copia o pareamento de requisito com checkpoint e a escolha de base:

1. Quando um requisito mudar, commit o trabalho atual e escreva o requisito completo na mensagem do commit, não só a mudança.
2. Se um pedido novo contradiz trabalho anterior, encontre o último commit que ainda atende. Inspecione cada candidato com cuidado, porque trabalho obsoleto volta se você errar.
3. Crie um branch a partir desse commit e mantenha o branch antigo, como o paper mantém commits antigos no grafo.
4. Abra uma sessão nova de agente nesse branch e cole o requisito completo na primeira mensagem.
5. Não continue o chat antigo e bagunçado. Com isso, você faz à mão o trabalho do Git Agent.

Perguntas frequentes

• O GitHarness está disponível para instalar? Não. O preprint de setembro de 2026 afirma que os autores vão liberar a implementação, mas até outubro de 2026 nem o código nem os prompts completos foram publicados. Se você quer algo hoje, restam o hábito manual de Git e o pi-optchat, que ataca memória, não branches de trabalho.

• O ganho de 73,6% menos tokens vale para qualquer tarefa? Não. O número vem de uma única configuração, Stack Planner com DeepSeek-V4-Flash em código, no benchmark dos próprios autores. Nas outras modalidades do mesmo setup a economia ficou entre 36% e 55%, e em matemática o consumo subiu cerca de 39%.

• O pi-optchat faz a mesma coisa que o GitHarness? Não. O pi-optchat estrutura a memória do modelo numa árvore de resumos com zoom e funciona como alternativa à compactação de contexto. Ele não cria branches, não faz rollback e não resolve trabalho obsoleto. O GitHarness estrutura o trabalho em si, não a memória.

• Posso aplicar a ideia sem trocar de ferramenta? Sim. Commit o trabalho com o requisito completo na mensagem, escolha o commit compatível quando um pedido contradiz o anterior, crie um branch e inicie uma sessão nova do agente nele. A ablação do paper indica que escolher mal a base custa caro, então inspecione os candidatos antes de decidir.

Source video