# Como aplicar controle de versão para agentes hoje

> Published 2026-10-18T12:44:03.453Z on https://www.crazystack.com.br/pt/p/como-aplicar-controle-de-versao-para-agentes-hoje/
> Source video: https://www.youtube.com/watch?v=tN6SXwfXSm8

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](https://arxiv.org/abs/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](https://qwenlm.github.io/) 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](https://qwenlm.github.io/) 32B e [DeepSeek-V4-Flash](https://www.deepseek.com/)) vezes três harnesses (TCRag, Stack Planner e [OpenHands](https://github.com/All-Hands-AI/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](https://www.npmjs.com/package/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](https://github.com/VictorTaelin), 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](https://git-scm.com/). 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](https://www.youtube.com/watch?v=tN6SXwfXSm8)