Agente dentro.
Executor fuori.
Un executor intelligente usa un modello per risolvere uno o più passaggi incerti, ma conserva il normale contratto di un executor. Il pianificatore gli affida un compito preciso e riceve il risultato previsto, senza dover conoscere il percorso interno.
Il confine architetturale
Il manifest e il codice dell'executor definiscono lo scopo, gli argomenti, le capacità, il consenso, i limiti e la forma del risultato. Quando una parte del percorso richiede un modello, l'adattatore prepara un'osservazione limitata, controlla la proposta e decide quale operazione concreta eseguire. Il modello non invoca direttamente gli executor e non modifica il proprio contratto.
Nel manifest, intelligence = "agentic" dichiara questa modalità
e permette al registro e all'interfaccia di rappresentarla correttamente. La
dichiarazione viene convalidata, ma da sola non dimostra che
l'implementazione sia sicura: limiti, validazione delle proposte e
postcondizioni devono essere verificati nel codice e nei test.
Che cosa offre oggi il runtime comune
Metnos fornisce un ciclo sincrono e uno asincrono. A ogni tentativo può
aggiornare l'osservazione, chiedere una proposta, convalidarla, eseguirla e
controllare la postcondizione. L'esito interno è uno fra
completed, inconclusive ed exhausted.
Esiste anche la variante «prima il metodo deterministico, poi il modello»:
se il ripiego non produce un risultato valido, resta valido il risultato
deterministico iniziale.
| Responsabilità | Runtime comune | Adattatore dell'executor |
|---|---|---|
| Limiti | Impone massimi a tentativi, tempo, cronologia e osservazioni | Può scegliere limiti più stretti e deve limitare ogni singola operazione |
| Proposta | La richiede e ne gestisce il ciclo | Decide che cosa il modello può vedere e proporre |
| Validazione | Non accetta una proposta respinta | Definisce le regole concrete di ammissione |
| Successo | Restituisce l'esito del ciclo | Definisce e verifica la postcondizione |
| Autorità | Non la amplia | Opera entro manifest, policy, consenso e sandbox |
Dove viene usato
Scelta controllata
Nella navigazione web il modello può scegliere l'identificatore di un controllo fra candidati preparati dal broker. Non produce selettori CSS o XPath.
Nella ricerca di immagini può riordinare identificatori noti quando i metadati non offrono un segnale lessicale sufficiente.
Ripiego controllato
L'OCR prova prima Tesseract. Soltanto se il testo è insufficiente può chiedere al modello visivo una trascrizione; un risultato debole non sostituisce quello iniziale.
L'estrazione strutturata e alcuni percorsi di consultazione usano lo stesso principio con contratti propri.
Il modello è utile quando lo scopo è ristretto, il percorso può variare e la conclusione è verificabile. Non è adatto a nascondere dentro un executor una ricerca aperta, una strategia fra domini o un compito senza un criterio netto di completamento: quelle decisioni appartengono al pianificatore.
Trovare l'ingresso a un sito
Per accedere, Metnos cerca prima un modulo di autenticazione. Se non lo trova, cerca un ingresso all'area personale, un menu o un passaggio intermedio plausibile. Usa prima i segnali della pagina; solo quando non bastano chiede al modello locale di scegliere fra i controlli osservati. Non contiene percorsi speciali per singoli siti.
Una voce come «Privati» o «area privata» può indicare un percorso verso l'accesso, ma non è di per sé un pulsante di login. Metnos segue questo indizio solo se porta a una pagina diversa e non c'è un ingresso esplicito; dopo un clic attende brevemente anche i menu e i moduli che compaiono in ritardo. I termini sono gestiti dal lessico multilingue.
La ricerca scende al massimo di quattro passaggi per percorso. Se incontra un vicolo cieco, torna alla pagina iniziale e ripercorre i passaggi verificati fino alla diramazione utile, dove prova un'alternativa non ancora tentata. Avanzamenti e ritorni condividono un limite di 32 azioni e un tempo di ricerca limitato; una pausa per il consenso non azzera i tentativi. Se nel frattempo il percorso cambia, Metnos si ferma.
La ricerca successiva di una collezione completa distingue gli oggetti cercati, i filtri e i campi richiesti. Il modello locale riconosce il significato del contenuto e sceglie solo fra i controlli osservati. La presenza di oggetti pertinenti, anche fuori filtro, orienta il percorso; non ne certifica la fine. Si esplorano fino a tre livelli, tornando alle diramazioni dalla pagina iniziale. La paginazione resta allo stesso livello. Anche dopo i primi risultati si cercano altre pagine e i dettagli necessari ai campi richiesti. I comandi osservati vengono esaminati a gruppi: una pagina con molti collegamenti non nasconde quelli successivi alla ricerca.
Questa raccolta usa 96 azioni e 300 secondi attivi, condivisi fra avanzamenti, scorrimenti e ritorni; le attese per l’utente non consumano il tempo né azzerano i tentativi. Termina dopo l’esaurimento dei percorsi pertinenti osservati. Limiti di tempo, azioni, profondità o lettura producono un esito parziale, senza inventare il numero totale degli oggetti. I filtri si applicano ai dati raccolti, senza scartare percorsi in base alle date di una pagina intermedia.
I normali confini del sito e i moduli di consenso restano validi anche durante la ricerca. I cookie seguono la procedura separata di rifiuto delle opzioni facoltative, ricontrollata prima dell'invio se compare un nuovo banner. Trovato il modulo, l'inserimento delle credenziali resta deterministico: il modello non riceve i valori dei campi e non esplora altre strade dopo l'inizio della digitazione.
Salvataggio, elenco, login e cancellazione condividono un unico deposito cifrato delle credenziali. L'elenco mostra solo metadati; cambiare la cartella dei dati dell'istanza non seleziona un altro deposito.
Per i CAPTCHA Cloudflare supportati, Metnos prova una sola volta la
libreria locale playwright-captcha, nella stessa sessione e per
non più di 10 secondi. Il tentativo rientra nei limiti del login e il suo
esito viene ricontrollato sulla pagina. Non usa servizi a pagamento.
Se la verifica resta aperta o non è supportata, come reCAPTCHA, chiede
l'intervento dell'utente e conserva la sessione. I codici OTP seguono una
procedura distinta: vengono chiesti all'utente, salvo automatismi
autorizzati esplicitamente. Il risolutore CAPTCHA non accetta cookie
e non legge OTP.
Il pannello CAPTCHA mostra la pagina della sessione già aperta, con i campi sensibili oscurati. L'utente può cliccare e scorrere, aggiornare l'immagine e premere Riprendi. Metnos ricontrolla l'accesso e continua la richiesta originale; un CAPTCHA ancora da completare riapre il pannello. Il controllo associa la risposta al singolo widget anche quando resta visibile dopo il completamento: la risposta di un altro widget non vale. Se il CAPTCHA precedeva il modulo, inserisce ora le credenziali. Se erano già state inviate, verifica quel tentativo senza inviarle nuovamente. Il pannello scade dopo dieci minuti; annullarlo chiude la sua sessione. Le verifiche che richiedono tastiera o audio non sono supportate da questo pannello.
Per i moduli che chiedono prima la mail e poi la password, il broker usa anche il titolo o il nome accessibile del modulo e il lessico multilingue validato. Il riconoscimento funziona quindi anche con URL prive di termini di login. Le scritte esterne al modulo, come un collegamento nella testata, non trasformano una newsletter in un login. Campi ambigui non vengono scelti; le origini autorizzate restano verificate prima dell'inserimento e dell'invio. La compilazione comune svuota il campo, inserisce il valore e ne verifica la corrispondenza prima di proseguire; una discordanza impedisce l'invio. I valori rimangono nel broker e non sono riportati nei risultati o nei log.
L’attesa dopo l’invio usa gli stessi criteri della verifica finale, compresi eventuali cookie di sessione dichiarati. Un cookie generico cambiato durante il caricamento non interrompe l’osservazione. Restano invariati il limite di tempo, il singolo invio e la gestione separata di CAPTCHA, codici e rifiuti.
Le continuazioni dopo un modulo o un consenso usano lo stesso registro dei turni ordinari. Ogni ripresa ha un identificativo nuovo, collegato al turno sospeso, e conserva proprietario, conversazione, esiti e allegati. Il collegamento alle immagini usa questo record persistito. Il ramo ripreso e la coda residua sono osservati senza ripetere i passi precedenti; i valori immessi nel modulo non vengono copiati negli argomenti del registro.
Se non riesce
Se nessuna proposta viene ammessa, il ciclo è inconclusive. Se
sono terminati i tentativi o il tempo disponibile, è exhausted.
L'adattatore traduce poi questo esito nel contratto pubblico del proprio
executor: può mantenere il risultato deterministico, restituire un errore
tipizzato o chiedere l'intervento dell'utente. Il ciclo comune non inventa un
risultato e non promette da solo una ripresa persistente.