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 deteção de ciclos não identifica um agente estagnado, porque a repetição é um sinal do lado da entrada, enquanto o progresso é do lado da saída. Esse argumento só funciona se existir algo que sirva de referência para medir o progresso. Esta nota é sobre esse algo.
Faça a pergunta da forma certa
A pergunta não é "como o agente sabe que terminou uma etapa". É "como o sistema sabe que ele realmente terminou, em vez de ter apenas anunciado que terminou".
Uma camada de diferença, e a credibilidade não é comparável.
Já tínhamos duas metades e nunca as ligámos
Ao reler a nossa própria implementação, foi essa a parte surpreendente.
A primeira metade. Já existem marcos no produto. Uma ferramenta mantém um plano de tarefas persistente: como uma tarefa longa se decompõe e em que estado está cada etapa — pendente, em curso, concluída, bloqueada. O seu propósito declarado é dar a uma tarefa longa uma âncora de progresso estável. Mas como é que uma etapa passa a "concluída"? O modelo declara-a.
A segunda metade. Após cada chamada de ferramenta, o anfitrião regista um conjunto de factos determinísticos: se o hash do conteúdo de um ficheiro mudou de facto, qual foi o código de saída de um comando, se o tempo limite foi excedido. Isto é registado do lado do anfitrião 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 ficheiro passou de A para B. Nunca nada 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 a pena aproveitar é onde posiciona o detetor Φ.
Φ não precisa de um 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 (apanhou 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 modelos adicionais, zero custos adicionais de amostragem. Compare com as alternativas: um modelo de recompensa de processo exige anotação dispendiosa e pode ser contornado, e a estimativa de valor por Monte Carlo exige simulações adicionais em cada ponto de decisão. É esse custo que Φ evita.
Quem constrói um produto com agentes tem uma vantagem que os cenários do artigo não têm: as chamadas de ferramenta já são estruturadas, com sucesso e falha explícitos. O artigo precisou de extrair sinais do ambiente. Os nossos já lá estão.
Três camadas, se fosse construir isto
Camada um: reunir evidência determinística num único fluxo. Nenhum juízo semântico, apenas um registo mecânico de mudanças irreversíveis e verificáveis. O hash do conteúdo de um ficheiro mudou. Um comando terminou com o código zero. Uma chamada de API externa devolveu uma indicação de sucesso. Uma linha foi gravada. Tudo isto já existe hoje. Está apenas disperso, nunca reunido num único registo de factos estabelecidos até aqui.
Camada dois: ligar as duas metades. A etapa de maior valor. Quando o modelo declara uma etapa concluída, deixe de aceitar isso de boa-fé e procure evidência da camada um nesse intervalo. Com evidência, marque como concluída e verificada. Sem evidência, marque como concluída apenas por declaração. Isto não impede o modelo de declarar seja o que for; apenas separa o que tem fundamento do que não tem.
Camada três: definir Φ por tipo de capacidade. Os autores admitem que Φ exige conhecimento do domínio e generaliza mal, por isso não espere um detetor universal. As tarefas de código observam os códigos de saída dos testes. As tarefas de análise de dados observam se o ficheiro de saída foi criado. As tarefas de mensagens observam a resposta da API. Esta camada constrói-se devagar, uma capacidade de cada vez.
Um critério que acrescentamos: irreversibilidade, não importância
Esse não está no artigo.
Os marcos do BEACON funcionam porque assinalam transições de estado sem retorno. Depois de obter a chave, o mundo é outro. Por isso, 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 ficheiro, fazer um commit de código, enviar uma mensagem, chamar uma API paga, gravar numa base de dados. Reversível: ler um ficheiro, pesquisar, descarregar uma página, pensar.
Duas coisas decorrem disso. É decidível mecanicamente, porque o tipo de ação basta — não é necessária qualquer compreensão semântica, e não se infiltra qualquer subjetividade do tipo "o modelo achou que esta etapa era importante". E coincide com pontos de recuperação: retomar a partir de uma fronteira irreversível é o único tipo de retoma que significa algo, já que as ações reversíveis podem simplesmente ser repetidas.
Dois números: um para coragem, outro para cautela
O que dá coragem é a experiência de degradação. Elimine metade dos marcos aleatoriamente e a pontuação continua a ser 82.8, contra uma referência de 72.8 — dez pontos à frente. A degradação é gradual, não uma queda abrupta. Para quem vai colocar isto em produção, essa é a parte importante: não precisa de acertar perfeitamente em Φ antes de ousar ativá-lo. Cobrir metade já compensa.
O que pede cautela é a comparação de particionamento.
| Particionamento | Pontuação | vs. referência (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 os seus marcos forem definidos por intuição, equivalem a uma divisão aleatória e o trabalho é desperdiçado. Os marcos têm valor precisamente quando se alinham com a estrutura real da tarefa.
As ressalvas necessárias
O próprio apêndice do artigo lista a descoberta automática de marcos como um problema em aberto. Os três testes de referência obtêm os seus marcos através de regras: correspondência de padrões nas respostas do ambiente, transições de página ou um sinal que o ambiente fornece diretamente. Cenários verdadeiramente abertos — utilização de um navegador, refatorações de bases de código, investigação aprofundada — não têm essa transição verificável pronta.
Portanto, isto é um paradigma validado em ambientes estruturados, não uma solução que se possa transplantar por inteiro. O que permite aplicá-lo a um produto com agentes é a fronteira estruturada da chamada de ferramenta, não uma resposta que o artigo já tenha fornecido.
A outra armadilha é a granularidade. Demasiado esparsa e não fez nada; demasiado densa e o sinal de segmento transforma-se em ruído. Em termos de produto, isto é 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 orientadas para o utilizador por definição, por isso a granularidade pode basear-se na capacidade de uma pessoa compreender a etapa, em vez de ser ajustada apenas por um algoritmo.
Se 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 proporção entre verificadas e declaradas já é uma métrica que vale a pena acompanhar. E é a condição prévia para tudo o resto: sem a noção de marco verificado, a deteçã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 tranquilizadora. Colocar isto em produção não altera qualquer comportamento — o modelo declara etapas exatamente como antes, apenas há uma marca adicional. Quando os dados se acumularem, decide se vale a pena intervir nas declarações que chegaram sem evidência.
A próxima nota trata da compactação de contexto: por que razão cortar num 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, depois de verificado um marco, tudo o que o precede pode ser condensado e descartado.