Questo è il secondo approfondimento di una serie sulla progettazione di agenti a lungo orizzonte, nata da una lettura attenta di BEACON (Università di Zhejiang, arXiv:2605.06078).
Il primo approfondimento sosteneva che il rilevamento dei cicli non può individuare un agente in stallo, perché la ripetizione è un segnale sul lato degli input, mentre il progresso è un segnale sul lato degli output. Questo ragionamento funziona solo se esiste qualcosa rispetto a cui misurare il progresso. Questo approfondimento riguarda proprio quel qualcosa.
Porre la domanda nel modo giusto
La domanda non è "come fa l'agente a sapere di aver concluso un passaggio". È "come fa il sistema a sapere che lo ha davvero concluso, invece di limitarsi ad annunciarlo".
Un solo livello di differenza, e la credibilità non è paragonabile.
Avevamo già due metà e non le avevamo mai collegate
Leggendo la nostra implementazione, questa è stata la parte sorprendente.
La prima metà. I traguardi esistono già nel prodotto. Uno strumento mantiene un piano persistente dell'attività: come si scompone un'attività lunga e in quale stato si trova ogni passaggio — in attesa, in corso, completato, bloccato. Il suo scopo dichiarato è dare a un'attività lunga un riferimento stabile per il progresso. Ma come fa un passaggio a diventare "completato"? Lo dichiara il modello.
La seconda metà. Dopo ogni chiamata a uno strumento, l'host registra una serie di fatti deterministici: se l'hash del contenuto di un file è effettivamente cambiato, quale fosse il codice di uscita di un comando, se si sia verificato un timeout. Questi fatti vengono registrati lato host e non entrano mai nel contesto del modello, ed è proprio per questo che non possono essere inventati.
La lacuna è lì. Una riga dice ho finito. L'altra dice l'hash di un file è passato da A a B. Nulla le ha mai affiancate.
Non manca una struttura dati, né l'osservabilità. Manca il ponte tra le due.
La cosa più utile dell'articolo scientifico non è la formula
BEACON è noto soprattutto per il suo vantaggio a doppia scala, ma la parte da prendere in prestito è il modo in cui colloca il rilevatore Φ.
Φ non richiede un modello addestrato né annotazioni umane. Legge solo i cambiamenti di stato osservabili nei riscontri dell'ambiente: transizioni di stato degli oggetti in ALFWorld (raccolta riuscita, riscaldamento concluso), transizioni di pagina in WebShop, e in ScienceWorld utilizza semplicemente il segnale di sotto-obiettivo che l'ambiente emette già.
Nessun modello aggiuntivo, nessun costo aggiuntivo di campionamento. Confrontiamo le alternative: un modello di ricompensa del processo richiede annotazioni costose e può essere aggirato, mentre la stima del valore con Monte Carlo richiede ulteriori simulazioni a ogni punto decisionale. È questo il costo che Φ evita.
Chiunque costruisca un prodotto basato su agenti ha un vantaggio assente negli scenari dell'articolo: le chiamate agli strumenti sono strutturate fin dall'inizio, con esiti espliciti di successo e fallimento. L'articolo doveva estrarre segnali da un ambiente. I nostri ci sono già.
Tre livelli, se dovessi costruirlo
Primo livello: raccogliere le prove deterministiche in un unico flusso. Nessun giudizio semantico, solo una registrazione meccanica di cambiamenti irreversibili e verificabili. L'hash del contenuto di un file è cambiato. Un comando è terminato con codice zero. Una chiamata API esterna ha restituito un esito positivo. Una riga è stata salvata definitivamente. Tutto questo esiste già oggi. È semplicemente sparso, mai riunito in un unico registro dei fatti accertati fino a quel momento.
Secondo livello: collegare le due metà. Il passaggio di maggior valore. Quando il modello dichiara completo un passaggio, smetti di prenderlo sulla fiducia e cerca le prove del primo livello in quell'intervallo. Se ci sono prove, contrassegnalo come completamento verificato. Se non ci sono, contrassegnalo come completamento dichiarato. Questo non impedisce al modello di dichiarare alcunché; separa soltanto ciò che è supportato da ciò che non lo è.
Terzo livello: definire Φ per tipo di capacità. Gli autori ammettono che Φ richiede conoscenze di dominio e si generalizza con difficoltà, quindi non aspettarti un rilevatore universale. Le attività di programmazione osservano i codici di uscita dei test. Le attività di analisi dei dati osservano se il file di output è stato effettivamente creato. Le attività di messaggistica osservano la risposta API. Questo livello si sviluppa lentamente, una capacità alla volta.
Un criterio che abbiamo aggiunto: l'irreversibilità, non l'importanza
Questo non compare nell'articolo scientifico.
I traguardi di BEACON funzionano perché segnano transizioni di stato da cui non si può tornare indietro. Una volta ottenuta la chiave, il mondo è diverso. Quindi il criterio dovrebbe essere questa azione ha prodotto un effetto collaterale esterno irreversibile, anziché questo passaggio era importante.
Irreversibili: scrivere un file, effettuare un commit del codice, inviare un messaggio, chiamare un'API a pagamento, confermare una transazione in un database. Reversibili: leggere un file, cercare, recuperare una pagina, ragionare.
Ne derivano due cose. È determinabile meccanicamente, perché a stabilirlo è il tipo di azione — non serve comprensione semantica e non si insinua la soggettività di "il modello pensava che questo passaggio contasse". Inoltre coincide con i punti di ripristino: riprendere da un confine irreversibile è l'unica ripresa che abbia un significato, dato che le azioni reversibili possono semplicemente essere ripetute.
Due numeri: uno per il coraggio, uno per la prudenza
Quello che rassicura viene dall'esperimento di degradazione. Eliminando casualmente metà dei traguardi, il punteggio resta 82.8, contro un valore di riferimento di 72.8 — dieci punti di vantaggio. La degradazione è graduale, non un crollo. Per chi deve rilasciare questa funzionalità, è questo l'aspetto importante: non occorre rendere perfetto Φ prima di osare attivarlo. Coprirne metà dà già dei benefici.
Quello che invita alla prudenza è il confronto tra le suddivisioni.
| Suddivisione | Punteggio | rispetto al riferimento (72.8) |
|---|---|---|
| Suddivisione casuale in 5 parti | 74.2 | +1.4 |
| Traguardi reali | 91.4 | +17.2 |
Anche il primo approfondimento citava questi numeri, ma qui l'implicazione è più diretta. Se i tuoi traguardi sono stabiliti a intuito, equivalgono all'incirca a una suddivisione casuale e il lavoro è sprecato. I traguardi hanno valore proprio quando corrispondono alla struttura reale dell'attività.
Dove va ridimensionata questa conclusione
L'appendice dell'articolo stesso elenca l'individuazione automatica dei traguardi come problema aperto. Tutti e tre i benchmark ricavano i propri traguardi da regole: riconoscimento di schemi nelle risposte dell'ambiente, transizioni di pagina o un segnale fornito direttamente dall'ambiente. Gli scenari davvero aperti — operazioni nel browser, ristrutturazioni della base di codice, ricerca approfondita — non dispongono di transizioni verificabili già pronte di questo tipo.
Si tratta quindi di un paradigma convalidato in ambienti strutturati, non di una soluzione da trasferire integralmente. A renderlo applicabile in un prodotto basato su agenti è il confine strutturato della chiamata a uno strumento, non una risposta già fornita dall'articolo.
L'altra insidia è la granularità. Traguardi troppo radi e non hai ottenuto nulla; troppo fitti e il segnale a livello di segmento diventa rumore. In termini di prodotto, è la granularità della scomposizione dell'attività, e qui c'è una comodità assente negli scenari dell'articolo. I passaggi del piano sono pensati per essere visibili all'utente, quindi la granularità può basarsi sulla possibilità per una persona di comprendere il passaggio, invece di essere regolata esclusivamente da un algoritmo.
Se fai una sola cosa
Realizza il secondo livello.
Costa poco, perché i dati del primo livello esistono già e il secondo si limita a correlarli con le dichiarazioni del modello. È verificabile in modo indipendente, perché il rapporto tra completamenti verificati e dichiarati è esso stesso una metrica da osservare. Ed è il presupposto di tutto il resto: senza un concetto di traguardo verificato, né il rilevamento dello stallo del primo approfondimento né il confine di compattazione del prossimo hanno una base su cui poggiare.
Ha anche una proprietà rassicurante. Rilasciarlo non cambia alcun comportamento — il modello dichiara i passaggi esattamente come prima, c'è semplicemente un contrassegno in più. Una volta accumulati i dati, puoi decidere se intervenire sulle dichiarazioni arrivate senza prove.
Il prossimo approfondimento riguarda la compattazione del contesto: perché tagliare a una soglia di token ha poco a che vedere con ciò che si può dimenticare in sicurezza, e una correzione al modo più naturale di estendere questo ragionamento, cioè presumere che, una volta verificato un traguardo, tutto ciò che lo precede possa essere condensato e messo da parte.