Esta é a segunda nota de uma série sobre design de agentes de longo horizonte, motivada por uma leitura atenta do BEACON (Universidade de Zhejiang, arXiv:2605.06078).
A primeira nota argumentou que a detecção de loop não captura um agente estagnado, porque repetição é um sinal do lado da entrada enquanto progresso é do lado da saída. Esse argumento só funciona se existir algo contra o qual medir o progresso. Esta nota é sobre esse algo.
Faça a pergunta do jeito certo
A pergunta não é "como o agente sabe que terminou uma etapa". É "como o sistema sabe que ele realmente terminou, em vez de apenas anunciar que terminou".
Uma camada de diferença, e a credibilidade não é comparável.
Já tínhamos duas metades e nunca as conectamos
Ao reler nossa própria implementação, foi essa a parte surpreendente.
A primeira metade. Marcos já existem no produto. Uma ferramenta mantém um plano de tarefas durável: como uma tarefa longa se decompõe e em que estado está cada etapa — pendente, em andamento, concluída, bloqueada. Seu propósito declarado é dar a uma tarefa longa uma âncora de progresso estável. Mas como uma etapa vira "concluída"? O modelo declara.
A segunda metade. Após cada chamada de ferramenta, o host registra um conjunto de fatos determinísticos: se o hash de conteúdo de um arquivo mudou de verdade, qual foi o código de saída de um comando, se houve timeout. Isso é registrado no lado do host e nunca entra no contexto do modelo, e é exatamente por isso que não pode ser fabricado.
É aí que está a lacuna. De um lado, eu terminei. Do outro, o hash de um arquivo passou de A para B. Nada nunca colocou os dois lado a lado.
O que falta não é uma estrutura de dados nem observabilidade. É a ponte entre as duas.
O mais útil do artigo não é a fórmula
O BEACON é conhecido pela vantagem de escala dupla, mas a parte que vale roubar é onde ele posiciona o detector Φ.
Φ não precisa de modelo treinado nem de anotação humana. Lê apenas mudanças de estado observáveis no feedback do ambiente: transições de estado de objetos no ALFWorld (pegou com sucesso, aquecimento concluído), transições de página no WebShop e, no ScienceWorld, simplesmente consome o sinal de subobjetivo que o ambiente já emite.
Zero modelo extra, zero custo extra de amostragem. Compare com as alternativas: um modelo de recompensa de processo exige anotação cara e pode ser burlado, e a estimativa de valor por Monte Carlo exige rollouts adicionais em cada ponto de decisão. É esse custo que Φ evita.
Quem constrói um produto de agente tem uma vantagem que os cenários do artigo não têm: chamadas de ferramenta já são estruturadas, com sucesso e falha explícitos. O artigo precisou garimpar sinais do ambiente. Os nossos já estão lá.
Três camadas, se você fosse construir isso
Camada um: reunir evidência determinística em um único fluxo. Nenhum julgamento semântico, apenas um registro mecânico de mudanças irreversíveis e verificáveis. O hash de conteúdo de um arquivo mudou. Um comando saiu com zero. Uma chamada de API externa retornou sucesso. Uma linha foi gravada. Tudo isso já existe hoje. Está apenas espalhado, nunca reunido em um único registro de fatos estabelecidos até aqui.
Camada dois: conectar as duas metades. A etapa de maior valor. Quando o modelo declara uma etapa concluída, pare de aceitar isso de boa-fé e procure evidência da camada um naquele intervalo. Com evidência, marque como concluída e verificada. Sem evidência, marque como concluída apenas por declaração. Isso não impede o modelo de declarar nada; apenas separa o que tem lastro do que não tem.
Camada três: definir Φ por tipo de capacidade. Os autores admitem que Φ exige conhecimento de domínio e generaliza mal, então não espere um detector universal. Tarefas de código observam códigos de saída de teste. Tarefas de análise de dados observam se o arquivo de saída foi criado. Tarefas de mensageria observam a resposta da API. Essa camada se constrói devagar, uma capacidade por vez.
Um critério que acrescentamos: irreversibilidade, não importância
Esse não está no artigo.
Os marcos do BEACON funcionam porque marcam transições de estado das quais não há volta. Uma vez com a chave, o mundo é outro. Então o critério deveria ser esta ação produziu um efeito colateral externo irreversível, e não esta etapa foi importante.
Irreversível: gravar um arquivo, commitar código, enviar uma mensagem, chamar uma API paga, gravar em banco. Reversível: ler um arquivo, buscar, baixar uma página, pensar.
Duas coisas decorrem disso. É decidível mecanicamente, porque o tipo de ação resolve — nenhum entendimento semântico é necessário, e nenhuma subjetividade do tipo "o modelo achou que esta etapa importava" se infiltra. E coincide com pontos de recuperação: retomar a partir de uma fronteira irreversível é o único tipo de retomada que significa algo, já que ações reversíveis podem simplesmente ser refeitas.
Dois números: um para coragem, outro para cautela
O que dá coragem é o experimento de degradação. Descarte metade dos marcos aleatoriamente e a pontuação ainda é 82.8, contra uma linha de base de 72.8 — dez pontos à frente. A degradação é suave, não um precipício. Para quem vai colocar isso em produção, essa é a parte importante: você não precisa acertar Φ perfeitamente antes de ousar ligá-lo. Cobrir metade já compensa.
O que pede cautela é a comparação de particionamento.
| Particionamento | Pontuação | vs. linha de base (72.8) |
|---|---|---|
| Divisão aleatória em 5 | 74.2 | +1.4 |
| Marcos reais | 91.4 | +17.2 |
A primeira nota também citou esses números, mas aqui a implicação é mais direta. Se seus marcos são definidos por intuição, eles equivalem a uma divisão aleatória e o trabalho é desperdiçado. Marcos têm valor precisamente quando se alinham à estrutura real da tarefa.
Onde isso precisa ser descontado
O próprio apêndice do artigo lista a descoberta automática de marcos como problema em aberto. Os três benchmarks obtêm seus marcos por regras: correspondência de padrões nas respostas do ambiente, transições de página, ou um sinal que o ambiente entrega diretamente. Cenários genuinamente abertos — operação de navegador, refatorações de base de código, pesquisa profunda — não têm essa transição verificável pronta.
Portanto isso é um paradigma validado dentro de ambientes estruturados, não uma solução que se pode transplantar inteira. O que faz aterrissar em um produto de agente é a fronteira estruturada da chamada de ferramenta, não uma resposta que o artigo já tenha fornecido.
A outra armadilha é a granularidade. Esparsa demais e você não fez nada; densa demais e o sinal de segmento vira ruído. Em termos de produto, isso é a granularidade da decomposição da tarefa, e aqui há uma conveniência que os cenários do artigo não têm. As etapas do plano são voltadas ao usuário por definição, então a granularidade pode ser ancorada em se uma pessoa consegue entender a etapa, em vez de ser ajustada puramente por algoritmo.
Se você fizer apenas uma coisa
Faça a camada dois.
É barata, porque os dados da camada um já existem e a camada dois apenas os correlaciona com as declarações do modelo. É verificável de forma independente, porque a razão entre verificadas e declaradas já é uma métrica que vale acompanhar. E é a pré-condição de todo o resto: sem a noção de marco verificado, a detecção de estagnação da primeira nota e a fronteira de compactação da próxima não têm em que se apoiar.
Também tem uma propriedade confortável. Colocar isso em produção não muda comportamento algum — o modelo declara etapas exatamente como antes, só há uma marca a mais. Quando os dados se acumularem, você decide se vale intervir nas declarações que chegaram sem evidência.
A próxima nota trata da compactação de contexto: por que cortar em um limite de tokens tem pouco a ver com o que é seguro esquecer, e uma correção à extensão mais natural desta nota, que é supor que, uma vez verificado um marco, tudo antes dele pode ser dobrado e descartado.