Substituindo pipelines de recuperação complexos por comandos simples do git para agentes de IA

De pipeline complexo a comandos git simples

Um desenvolvedor construindo o DiffMem, um sistema de memória baseado em git para agentes de IA, descobriu que sua camada de recuperação era desnecessariamente complexa. Ele tinha sentence-transformers fazendo pontuação de similaridade de cosseno, rank-bm25 para busca por palavras-chave, um pipeline de LLM de duas passagens para destilar consultas e sintetizar resultados, e scikit-learn e numpy como dependências. Isso resultou em uma imagem Docker de 3GB (sentence-transformers arrastando todo o PyTorch), timeouts em usuários pesados cerca de 10% das vezes, e uma inicialização a frio que reconstruía um índice BM25 na memória toda vez.

A percepção: LLMs já conhecem git

A percepção crucial veio de reconhecer que comandos Unix são o padrão de uso de ferramentas mais denso nos dados de treinamento de qualquer LLM. Bilhões de arquivos README, scripts de CI e respostas do Stack Overflow estão cheios de comandos grep, git log e cat. O LLM não precisa de um pipeline de recuperação personalizado construído ao seu redor—ele já fala a linguagem dos comandos shell.

A solução de ferramenta única

Eles substituíram todo o sistema complexo por uma ferramenta:

{
  "name": "run",
  "description": "Execute um comando somente leitura no repositório de memória",
  "parameters": {
    "command": "Comando shell (suporta encadeamento com |, &&, ||, ;)"
  }
}

É isso. Uma função. O agente escreve comandos shell, já conhecendo grep, git diff, head e outros utilitários Unix sem precisar ser ensinado.

Como o agente funciona

O agente segue um protocolo fixo em seus turnos:

• Lê o manifesto da entidade
• Executa uma sonda temporal contra o log de commits
• Agrupa sua investigação em uma única chamada de ferramenta
• Gera um plano de recuperação
• Para

O agente retorna ponteiros, não conteúdo. Ele lê sinais leves durante seus turnos (head -30 para estrutura, grep -n para palavras-chave, git diff HEAD~3.. para mudanças recentes), então diz ao código o que buscar. O código resolve os ponteiros, mantendo o contexto do agente enxuto.

Exemplo do mundo real

Quando um usuário enviou uma mensagem de aniversário sobre se sentir isolado com a pressão do trabalho, o agente executou:

git log --format='%h %ad' --date=relative --name-only -15

Isso revelou que wife.md e company.md mudaram na mesma sessão, e um colega-chave apareceu em 2 das últimas 3 sessões. A mensagem do usuário não dizia nada sobre trabalho—o BM25 nunca teria encontrado company.md, e a similaridade semântica em "me sentindo isolado no meu aniversário" também não chegaria lá. Mas a co-ocorrência no histórico de commits revelou a conexão que realmente importava.

No turno 3, o agente compôs uma chamada de ferramenta com nove comandos encadeados com ponto e vírgula:

git diff HEAD~2.. -- memories/people/wife.md; git log --stat -5 -- memories/people/wife.md; head -30 memories/people/wife.md; grep -n "birthday|surgery|stress" memories/people/wife.md; tail -50 timeline/2026-03.md; git diff HEAD~3.. -- timeline/2026-03.md; grep -n "project|deliverable" memories/contexts/company.md; git diff HEAD~2.. -- memories/contexts/company.md; git diff HEAD~1.. -- memories/people/colleague.md

A saída final foi um plano de recuperação JSON com diffs git específicos, níveis de prioridade e estimativas de tokens—não conteúdo, mas ponteiros. O código então executou os comandos e montou o contexto dentro do orçamento de tokens.

Resultados

Essa abordagem permitiu que eles excluíssem rank-bm25, sentence-transformers, scikit-learn e numpy. A imagem Docker caiu aproximadamente 3GB. O servidor inicia mais rápido, usa uma fração da memória e não tem mais índice BM25 na inicialização a frio. A taxa de timeout de 10% desapareceu. No Cloud Run com carga real de usuários, isso não foi uma melhoria marginal, mas uma classe diferente de implantação.

O que restou: requests, openai, gitpython.