Finalmente chegou o que vocês queriam! Ralph TUI, Ralph Loop Visualizado

Eu já escrevi um tutorial sobre ralph-loop, e muitos amigos que o executaram me deram um feedback consistente: É ótimo, o Claude Code finalmente consegue rodar por um longo tempo. Mas às vezes você o observa e parece que não está se movendo, e inevitavelmente se pergunta: "Será que está progredindo ou apenas girando em círculos?"

Essa é a razão pela qual eu estive mexendo com o ralph-tui recentemente.

Ralph TUI

O ralph-tui não força a vinculação ao Claude Code, ele herda e desenvolve a essência do ralph loop, e visualiza a execução das tarefas e o processo, reduzindo significativamente a barreira para que grandes modelos trabalhem por longos períodos. Você pode conectar outros agentes, outros modelos, nacionais, baratos, aqueles que você pode manter rodando por um longo tempo. Com o ralph-tui, para nós, pessoas comuns, o significado não é menor do que mudar de um carro manual para um automático com controle de cruzeiro.

O que é isso exatamente?

Você pode entender o ralph-tui como um "orquestrador de loop de agentes de codificação de IA", só que não se contenta em "poder rodar", ele se preocupa mais com "você pode ver, pode controlar, pode recuperar".

Sua forma básica de trabalho é muito simples:

Você dá a ele um monte de tarefas (pode vir de um PRD, ou de outro sistema de tarefas)
Ele escolhe a de maior prioridade
Monta o prompt
Inicia o agente para executar
Avalia se a tarefa está concluída ou não
Grava o estado
Continua na próxima rodada

O ponto principal é: você pode ver tudo isso no terminal e pode parar e assumir o controle a qualquer momento. Oficialmente, sua posição também é escrita de forma muito direta: um orquestrador de loop de agente com TUI interativo, e suporta TUI / headless / remote.

Por que eu digo que é mais adequado para "rodar por um longo tempo"?

O maior problema de um script rodando em loop não é não conseguir rodar, mas sim você não saber onde ele está rodando.

Você vê os logs sendo atualizados rapidamente, e o ventilador também está girando feliz, mas você não tem certeza:

Será que está repetindo a correção do mesmo bug?
Será que está sempre alterando o mesmo trecho de código e depois alterando de volta?
Será que já terminou, mas não saiu?
Será que está preso em algum teste em um loop infinito?

TUI界面

A solução do ralph-tui é muito "engenharia":

Tem o conceito de sessão, o estado é persistido em disco (.ralph-tui/session.json)
Se quebrar, pode ser recuperado e rodado novamente (crash recovery)
Tem um mecanismo de bloqueio para evitar que você abra várias instâncias e transforme o diretório em uma bagunça
Pode até ser executado headless no CI, e até mesmo abrir um listener remotamente e conectar o TUI local a ele

Em uma frase: É mais como "você está gerenciando um trabalhador que sabe escrever código", em vez de "você está observando um script enlouquecendo".

Como instalar

O ralph-tui é um ecossistema Bun/TypeScript, então a instalação é bem tranquila. O site oficial também fornece uma página de instalação.

Primeiro, verifique se você tem o bun na sua máquina:

bun --version Em seguida, instale o ralph-tui (aqui eu dou um exemplo típico de instalação, consulte a página de instalação oficial para obter detalhes):

bun add -g ralph-tui Após a instalação, verifique:

ralph-tui --help Se você é um fã do Node e não quer usar o bun, também pode:

npm i -g ralph-tui

Não faça nada grandioso ainda, execute um loop mínimo

Eu sugiro que, na primeira vez que usar, não comece com algo como "reestruturar todo o repo". Faça apenas uma coisa: faça com que ele execute uma pequena tarefa aceitável.

Inicialização

Abre um diretório qualquer:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setup Isso entrará no processo de assistente interativo, que basicamente é "instalar o ralph-tui neste seu repositório", ele irá:

Detecta automaticamente quais agents estão instalados na sua máquina (como Claude Code, OpenCode, etc.)
Gera um arquivo de configuração no projeto: .ralph-tui/config.toml
Instala as skills relacionadas à geração de PRD/conversão de tarefas (para que você não precise se preocupar com isso manualmente depois)

Minha sugestão pessoal: não seja preguiçoso na primeira vez, execute o setup completamente.

Gerar o PRD do Projeto

Após executar o setup, o próximo passo é o mais importante do tutorial oficial, e também o mais adequado para escrever um demo em um artigo: create-prd.

O comando ralph-tui create-prd --chat iniciará um fluxo de diálogo, onde ele irá questioná-lo sobre os objetivos, condições de contorno e critérios de aceitação, como um gerente de produto. Após a conclusão, ele irá gerar duas coisas diretamente no projeto (e isso é o mais importante):

Um arquivo markdown de PRD: ./tasks/prd-feature.md
Um arquivo de tarefas executável diretamente: ./prd.json

Neste ponto, você realmente entrou no "ciclo padrão" do ralph-tui:

Requisitos (PRD) → Tarefas (prd.json) → Execução (run)

Executar

Com o prd.json, executar torna-se natural:

ralph-tui run --prd ./prd.json Você verá a TUI iniciar e começar o loop: selecionar tarefa → executar → verificar conclusão → escrever status → finalizar ou próxima rodada.

Na primeira execução, sugiro fortemente adicionar um limite de iteração, para mantê-lo sob controle:

ralph-tui run --prd ./prd.json --iterations 5 Após a execução, verifique as alterações, execute testes e verifique se o PRD e as tarefas estão de acordo com o esperado. Depois de confirmar que o fluxo está funcionando, libere as iterações e avance para headless/remote, este é o ritmo confiável.

Nesse ponto, você basicamente pode confirmar: este loop está realmente funcionando.

Como Escolher Modelos/Agents? A Economia Precisa Ser Falada Honestamente

Eu sei que muitos estão mais preocupados com: "Posso não usar o Claude Code? Posso usar modelos mais baratos?"

A resposta é: Sim.

O próprio ralph-tui permite que você especifique o agent e o model (há exemplos na documentação oficial do run).

Por exemplo, usando Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Mas, honestamente, eu não usaria o Opus para fazer coisas como "completar testes, corrigir lint", é muito caro. Meu hábito é estratificar:

Modelos baratos: executar muitas tarefas repetitivas (completar testes, completar comentários, corrigir formatação, adicionar limites)
Modelos caros: usados apenas em nós críticos (ajustes de arquitetura, bugs difíceis, lógica central)

Se você é um desenvolvedor comum, essa abordagem é ainda mais importante. Porque você não tem o orçamento de uma grande empresa, você precisa manter os custos sob controle para poder executar por mais tempo.

Quer Algo Ainda Melhor? Deixe o Agent "Escrever o PRD"

O ralph-tui tem um design que eu gosto muito: ele suporta skills (basicamente, um conjunto de comandos extras para o agent).

A maneira oficial de instalar é usando add-skill:

bunx add-skill subsy/ralph-tui --all Ou instalar em um agent específico, como claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Após a instalação, você pode usar slash commands na sessão do agent:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads É como se você tivesse instalado um plugin no IDE, só que este plugin é para o agent. O significado disso é reduzir o tempo de "transferência manual de requisitos", tornando os requisitos → tarefas → execução mais como uma linha de produção.

Quando Devo Usá-lo? Quando Não Devo?

Eu não gosto muito da narrativa de "tudo pode ser feito com IA", é fácil induzir ao erro. Uma ferramenta é apenas uma ferramenta, só vale a pena se for adequada ao cenário.

Cenários adequados para usar ralph-tui

Você tem um monte de tarefas como estas:

Complementar testes (especialmente em projetos antigos)
Corrigir lint / formatar
Refatoração em pequenos passos (convergir código repetido)
Adicionar tipos em lote, complementar limites
Desmembrar requisitos e avançar lentamente na fila de tarefas

Essas tarefas têm um ponto em comum: muitas tarefas, alta repetibilidade, podem ser validadas, podem ser iteradas.

Cenários inadequados para forçar o uso de ralph-tui

Você precisa fazer algo como isto:

Uma grande refatoração única, com critérios de aceitação pouco claros
Requisitos vagos, dependendo do seu conhecimento implícito
Requer muita comunicação/confirmação entre equipes
Requer que você faça julgamentos de produto

Nesses casos, o agent loop só vai amplificar a confusão.

Qual a diferença entre ele e ralph-loop (ralph-claude-code)?

ralph-claude-code é mais como um "plug-in de direção autônoma para Claude Code": o script o inicia, executa o loop, e a detecção de saída, limitação de taxa e disjuntor são todos garantidos. Se você quer "rapidez", ele é muito rápido.

ralph-tui é mais como um "console de controle de engenharia para agent loop": ele não fixa um modelo específico, nem um sistema de tarefas específico. Ele quer resolver problemas de engenharia como "execução de longo prazo, observabilidade, controlabilidade, recuperabilidade, capacidade remota".

Então, como escolher?

Você é um usuário do Claude Code e quer executá-lo rapidamente → ralph-claude-code
Você quer conectar diferentes modelos, economizar dinheiro, quer gerenciar o loop como um serviço → ralph-tui

Por fim: não deixe que ele transforme seu repositório em um laboratório

Eu tenho algumas regras de ouro para executar agent loop, escrevo aqui para que você as siga, a probabilidade de dar errado será muito menor:

Execute em branches, não se mate na main.
Na primeira execução, sempre adicione --iterations, primeiro confirme em pequenos passos que ele não vai enlouquecer.
A tarefa deve ser validável: deve ser possível executar testes, executar lint ou comparar arquivos de saída.
Você deve aprender a parar: se você vir que ele está começando a dar voltas, pausar é mais inteligente do que continuar gastando dinheiro.
Modelos baratos para trabalhos pesados, modelos caros para trabalhos críticos: o custo é resultado da operação, não da oração.Endereço do Projeto: https://github.com/subsy/ralph-tui