Vigiar um agente com um modelo de decisão

Os agentes de programação são onde estes modelos são usados de forma mais densa, e os usos agrupam-se em três sítios. Os três partilham uma estrutura: tirar o julgamento ao modelo generativo, dá-lo a algo mais barato e mais rápido, e deixar o código agir sobre uma resposta tipada.

1. Antes de uma chamada de ferramenta: permitir ou não

O sítio mais direto. Um hook PreToolUse do Claude Code faz isto:

Pergunta a um Noul: este comando de shell é estritamente só de leitura? Aprova automaticamente com 0.95, caso contrário recorre ao prompt de permissão normal — e nunca nega.

Três decisões de conceção merecem ser nomeadas:

• 0.95 é alto. A fasquia para aprovar automaticamente fica bem acima da fasquia de «isto parece arriscado». Uma autorização errada custa uma máquina; um bloqueio errado custa uma confirmação extra. Custos assimétricos pertencem a limiares assimétricos.
• Nunca nega. Só alguma vez acrescenta uma aprovação; tudo o resto volta ao sistema original. Uma barreira que só acrescenta capacidade é muito mais fácil de testar — o seu pior caso é não ter ajudado em nada.
• Os comandos perigosos nunca chegam ao modelo. Uma lista local de “não” absoluto e um filtro de injeção apanham-nos primeiro. Isto importa mais do que o limiar — ver O que tem de viver no código.

Resultado medido: 0 de 8 comandos que alteram o estado foram aprovados automaticamente.

2. Quando o agente quer parar: já acabou?

Outro sítio frequente. Um hook Stop pergunta ao modelo de decisão se o agente está a terminar demasiado cedo, apresentando-lhe as suas regras de conclusão em linguagem simples.

A versão mais contida funciona assim:

Gasta uma chamada de quatro perguntas só quando ficheiros mudaram e nenhuma verificação aprovada correu desde então. Fail open em qualquer erro.

«Perguntar só quando vale a pena perguntar» é o cerne desta classe — estes hooks correm a cada turno, e chamar incondicionalmente multiplica o custo pelo número de turnos. A condição acima é «mudanças não verificadas», que é exatamente o momento em que um agente tem mais probabilidade de declarar vitória sem ter verificado.

Um hook relacionado impede um agente de terminar cedo ao julgar regras de conclusão em linguagem simples em vez de confiar na própria afirmação do agente.

3. Quando o contexto enche: o que ainda é preciso?

O terceiro sítio é a compactação de contexto, onde as abordagens divergem mais.

A compactação tradicional resume: entrega-se um trecho de conversa a um modelo e recebe-se prosa de volta. O original desaparece, e o resumo é irreversível.

A abordagem com um modelo de decisão não reescreve — apenas pontua:

A frase comum: a tarefa do modelo de decisão aqui é um julgamento binário de manter/descartar, não uma reescrita. É precisamente aquilo em que é bom e em que os modelos generativos são maus — e «dobrar em vez de eliminar» transforma um julgamento errado de «informação perdida para sempre» em «mais um expand».

O contraponto: barreiras de segurança e barreiras de eficiência falham em direções opostas

O contraste mais instrutivo nesta parte do ecossistema: dada a mesma pergunta «o que acontece em caso de erro», os projetos escolheram respostas opostas, e ambas estão certas.

• Um juiz de permissões: negar em caso de erro ou timeout.
• Um hook Stop: permitir em qualquer erro.

O critério não é «qual é mais segura», mas se esta barreira protege risco ou débito. As barreiras que protegem risco (permissões, segredos, comandos perigosos) devem antes bloquear uma coisa boa do que deixar passar uma má; as barreiras que protegem débito (verificações de conclusão, verificações de formato) devem antes deixar passar algo do que bloquear todo o fluxo.

Numa frase

Os agentes são o lar mais natural destes modelos porque precisam de um grande número de julgamentos baratos cujos resultados são consumidos imediatamente pelo código. Mas em cada um desses pontos, decide primeiro: para que lado deve cair esta barreira quando avaria?