Ratchet Pattern — Como fazer o agente ir até o fim

Ratchet Pattern Image: AI generated

Se o seu agente de IA diz “pronto” mas na verdade não terminou, se o agente pula tarefas difíceis, se você quer que uma máquina — não um humano — determine a conclusão — este artigo explica essa estrutura.

“Terminei”

Pedi a um agente AI que escrevesse testes para 527 funções. O agente concluiu o trabalho e reportou:

“Concluído.”

Funções que realmente receberam testes: 40.

Não mentiu. Fez 40 e julgou que “já era suficiente”. Ao encontrar uma função difícil, pulou. Depois de mais algumas, concluiu que “o restante segue o mesmo padrão, então está feito”.

LLM gera bem. Mas seu julgamento sobre conclusão não é confiável. Huang et al. demonstraram experimentalmente que a autocorreção do LLM sem feedback externo pode na verdade degradar o desempenho[1].

A catraca

Uma chave catraca tem dentes que travam em uma única direção. Gire e ela avança. Solte e ela para, mas não volta.

O Ratchet Pattern aplica esse mecanismo ao controle de agentes. O codigo de verificacao escrito com esse padrao e chamado de ratchet code — codigo que nunca permite regressao abaixo de um nivel de verificacao previamente aprovado.

Item 1: verificação mecânica → PASS → próximo
Item 2: verificação mecânica → FAIL → nova tentativa (com feedback)
Item 2: verificação mecânica → PASS → próximo
...
Item N: PASS → concluído. Parar.

Três regras:

Mostre apenas um item por vez.
Só avança após passar.
Quando todos passarem, pare.

Ao implementar essas regras como CLI, o agente precisa conhecer apenas um comando: next. O resto a máquina decide.

Agente para em 40, catraca completa 527

Mesmo modelo. Mesmo projeto. Mesmas 527 funções.

Agente autônomo:  40 / 527  (7.6%)  — agente declarou "concluído"
Ratchet CLI:     527 / 527 (100%)  — máquina declarou "ainda faltam 487"

A diferença não está no desempenho do modelo. Está em quem decide o “fim”.

No agente autônomo, o LLM julga o encerramento. O LLM é otimista. Faz 40 e “sente” que é suficiente. Na análise de rastreamento de 1.600 execuções de agentes de Cemri et al., a terminação prematura — declarar o objetivo atingido antes de realmente atingi-lo — representou 6,2% de todos os modos de falha[2]. Na catraca, a máquina julga. A máquina não sente. Declara “ainda não” até que o número de itens restantes chegue a zero.

Definição em uma frase

Coloque o agente probabilístico dentro de uma máquina de estados determinística.

Papel	Responsável
Geração	LLM
Veredicto	verifier
Gestão de progresso	ratchet

Muitos sistemas delegam geração, veredicto e decisão de parada inteiramente ao LLM. O Ratchet separa essas responsabilidades.

Cinco princípios

1. A condição de encerramento é mecânica

pass/fail. Não “looks good”. Se go test passa, é PASS. Se coverage chega a 100%, é PASS. Não há espaço para julgamento subjetivo.

2. PASS é imutável

Um item aprovado não se reabre. Sem retrocesso. O número de itens restantes só diminui.

remaining_work(t+1) ≤ remaining_work(t)

O que você construiu hoje não será desmontado amanhã. Só avança. Essa é a diferença fundamental em relação ao “agente de 24 horas”. Um agente sem condição de parada adiciona uma abstração hoje, remove amanhã e readiciona depois de amanhã. A catraca não permite essa oscilação.

3. LLM só gera

Gerar código, escrever testes, propor correções — esse é o papel do LLM. O que corrigir, se passou ou não, qual é o próximo, se terminou — tudo isso a máquina decide. LLM não é um planejador, é um constrained generator.

4. Revogar o direito do agente de declarar conclusão

Se o LLM diz “terminei”, para em 40. Se a máquina diz “terminou”, para em 527. A razão de existir da catraca se resume a essa linha.

5. Verifier deve ser determinístico

Nem tudo pode ser verifier.

Pode ser	Não pode ser
`go test`	“looks cleaner”
medição de coverage	“seems better”
AST validation	“more scalable”
schema diff	“clean architecture”

Condições do Verifier: deterministic, machine-checkable, resumable, localized feedback. Se essas quatro não forem atendidas, os dentes da catraca não engatam.

Feedback é gradient signal

Se a catraca retorna apenas “passou/falhou”, o LLM corrige sem direção. Quanto mais específico o feedback, mais precisa a correção do LLM.

Feedback fraco:   "teste falhou"              → LLM corrige sem direção
Feedback médio:   "coverage 65%"              → LLM reforça aproximadamente
Feedback forte:   "line 41, 44, 70 sem cobertura" → LLM cobre exatamente esses ramos

Números verificados em projeto real:

Sem feedback:  para em 60~70% de coverage
Com feedback:  atinge 100% (para funções alcançáveis)

Mesmo modelo. Uma única linha “line 41 not covered” funciona como gradient signal. A pesquisa Self-Debug de Chen et al. provou que a depuração iterativa, alimentando mensagens de erro do compilador/runtime de volta ao modelo, melhora drasticamente a precisão do código[3].

Quanto maior a resolução do feedback, maior a precisão das correções do LLM, menor o número de iterações do loop e menor o custo.

O agente morre. O progresso sobrevive.

O agente vai cair. Limite de tokens, erro de rede, sessão encerrada. Se a catraca persiste o estado de progresso, o próximo agente continua de onde o anterior parou.

Agente A: processa funções 1~200 → morre
Agente B: next → retoma a partir de 201
Agente C: next → retoma a partir de 401

O agente é descartável. O progresso se acumula.

Troque o Verifier, obtenha outra ferramenta

A catraca não está presa a um verificador específico. Troque o verificador e você tem outra ferramenta.

Catraca + verificador	Uso
Catraca + `go test` + coverage	Geração de testes por função
Catraca + regras estruturais validator	Organização de estrutura de código
Catraca + hurl pass/fail	Verificação de endpoints de API
Catraca + verificação cruzada de especificações	Garantia de coerência SSOT
Catraca + Toulmin verdict	Aplicação de regras definidas pelo usuário

O padrão é um só. O verificador determina o domínio.

Perguntas

Quantos itens seu agente completou antes de dizer “terminei”?

Realmente terminou?

Quem decidiu o “fim” — o agente ou a máquina?

Fontes

[1] Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024. arXiv:2310.01798

[2] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Tanay Chopra, Aditya Tiwari, Kurt Keutzer, Aditya Parameswaran, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track. arXiv:2503.13657

[3] Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128

[4] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366

[5] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023. arXiv:2303.17651

[6] Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022. DOI:10.1126/science.abq1158

[7] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. arXiv:2310.06770