Spiegazioni delle funzioni 01: Motore di orchestrazione

Dal primo incarico alla patch verificata

Agent Argo non è costituito da un singolo modello che lavora il più a lungo possibile su un compito. È un sistema che traduce il lavoro software in passaggi comprensibili: pianificare, suddividere, elaborare, verificare, correggere e solo allora sottoporre per l'adozione.

Con questo articolo inizia la serie “Spiegazioni delle funzioni”. Rende comprensibili i meccanismi centrali di Agent Argo – non come promessa di marketing, ma lungo il suo effettivo utilizzo. L'apertura è data dal Motore di orchestrazione: il flusso che trasforma una richiesta in un processo di lavoro controllato.

1. Prima dell'avvio: definire qualità, costi e autonomia

Prima che Argo elabori un compito, due decisioni sono importanti. Sono intenzionalmente separate tra loro:

1. Come deve Argo bilanciare tra costi e qualità del risultato?
2. Quanto può agire in autonomia Argo nel progetto?

Questo evita un tipico conflitto di obiettivi: un'esecuzione accurata non deve ricevere automaticamente più diritti di scrittura. E un'esecuzione autonoma non deve automaticamente scegliere modelli costosi.

I tre livelli per costi e qualità

Il router dei modelli conosce tre modalità comprensibili. Esse modificano quanto incidano prezzo e livello del modello nella selezione; la competenza necessaria resta sempre centrale.

I profili operativi Veloce ed economico, Equilibrato e Approfondito raggruppano questa modalità del router con ulteriori decisioni: ad esempio, se il pensiero condiviso viene solo osservato o eseguito attivamente, se la verifica è vincolante e se Argo può escalare maggiormente in caso di tentativo fallito.

I tre livelli di autonomia

L'autonomia non regola cosa Argo ritenga giusto, ma quando ha bisogno di un essere umano per farlo.

Nel codice queste regole sono implementate in modo più preciso come readonly, confirm_write, auto_write e bypass. I tre livelli le rendono utilizzabili; la policy del progetto resta tuttavia sempre l'ultima istanza. Può ad esempio escludere provider cloud, consentire solo modelli locali, bloccare accessi di rete, limitare i comandi, proteggere i segreti o impostare un limite di costo.

2. Il livello CEO trasforma l'incarico in un piano

L'utente descrive innanzitutto l'obiettivo in linguaggio naturale. Il livello CEO di Argo riceve a tale scopo una panoramica di progetto limitata, il catalogo dei modelli disponibili e le informazioni di progetto rilevanti. Può prima chiarire le domande aperte o generare un piano.

Un piano non contiene solo un elenco di cose da fare. Ogni compito riceve un ruolo, una descrizione, dipendenze e capacità necessarie – ad esempio coding, planning, qa_review o context_comprehension. Per compiti difficili può essere annotata anche una maggiore difficoltà. Il livello CEO non indica rigidamente un modello: descrive il lavoro, il router decide poi per ciascun compito il modello appropriato.

Il piano resta così la convenzione leggibile dall'umano sull'impresa, mentre l'esecuzione può rimanere adattiva.

3. Dal piano nasce un grafo dei task

Dopo l'approvazione del piano, Argo trasforma i compiti in un grafo dei task. Un nodo può essere eseguito solo quando le sue dipendenze sono state completate con successo. Compiti indipendenti possono essere eseguiti in parallelo.

Lo scheduler ordina i nodi pronti secondo un'euristica di utilità comprensibile: qualità attesa meno penalità di costo, tempo e rischio. Se un nodo si trova sul percorso critico, riceve la precedenza in caso di parità, perché determina la durata complessiva dell'esecuzione.

In caso di elevata incertezza o rischio, Argo può selezionare prima dell'elaborazione una modalità di pensiero condiviso: più prospettive sviluppano approcci, si criticano a vicenda e forniscono un approccio di lavoro motivato per il worker. Se questo viene solo protocollato o realmente eseguito lo decide il profilo operativo scelto prima dell'esecuzione.

4. Prima di ogni task: contesto adeguato, capacità adeguate, modello adeguato

Prima che un worker parta, Argo costruisce un contesto adattato a ruolo e compito. Vi appartengono file rilevanti, risultati di dipendenza e – se attivati – un pacchetto di memoria compatto nonché opportune istruzioni di skill. Argo non inserisce ciecamente l'intera conoscenza di progetto nel prompt. Memoria e skill vengono selezionate in base a rilevanza, origine, attualità, costi e stato di sicurezza.

Poi il router dei modelli sceglie un modello. Innanzitutto vengono esclusi i candidati non raggiungibili, senza finestra di contesto sufficiente, con contingente esaurito o che violano la policy attiva. Tra i modelli rimanenti Argo valuta quattro fattori:

• Adeguatezza di capacità: quanto è valutato un modello per le skill necessarie? Con più skill viene considerata la media.
• Costi: quanto è costosa la richiesta – o, con routing attivo dei costi, il risultato probabilmente riuscito?
• Livello del modello: compiti difficili, critici per la sicurezza, di architettura e di revisione possono preferire uno livello flagship.
• Valori esperienziali: dopo un numero sufficiente di risultati reali confluiscono la recente percentuale di successo e di ripetizione di una combinazione modello/skill.

Per il calcolo dei costi Argo può utilizzare l'Expected Cost of Success: prezzo diretto, ripetizioni attese, onere di verifica, possibile rilavorazione e una piccola penalità di latenza. Una singola chiamata economica non è quindi automaticamente la soluzione più conveniente se fallisce più spesso o innesca rilavorazione.

Una raccomandazione di modello esplicita viene accettata solo se disponibile, consentita dalla policy e abbastanza capiente per il contesto. Pianificazione, delega e comprensione del contesto del livello CEO utilizzano a loro volta un modello forte, selezionato appositamente per queste tre capacità.

5. Il worker elabora il task in passi piccoli e verificabili

Un worker non lavora con una singola risposta. Attraversa un ciclo ReAct limitato:

1. Il modello propone azioni strutturate – ad esempio leggere file, cercare, eseguire test o scrivere modifiche.
2. L'executor verifica autorizzazione, percorso, rischio di comando e policy attiva.
3. Argo esegue solo le azioni consentite.
4. Risultati, diff e messaggi di errore tornano come osservazione al modello.
5. Su questa base il worker corregge il passo successivo o conclude il compito.

Così un agente può ad esempio prima leggere il codice interessato, poi apportare una modifica, eseguire un test e includere un risultato di test nella decisione successiva. L'intero flusso resta visibile nel log di esecuzione.

Anche l'output stesso viene verificato. Se un modello fornisce JSON di azione non valido, Argo può richiedere un ciclo di riparazione limitato. In modalità rigorosa un output persistentemente errato viene rifiutato in modo controllato, anziché interpretare testo ambiguo come azione.

6. In caso di errori: correggere miratamente anziché ripetere ciecamente

Non ogni task fallito significa che l'intera esecuzione è fallita. Il motore di orchestrazione distingue le cause di errore e reagisce in modo controllato:

• Un errore temporaneo può essere riprovato entro limiti fissi.
• Un riscontro di verifica rigido fornisce la sua contestazione concreta come incarico per il tentativo successivo.
• Con cascata attivata, il tentativo successivo riprende le conoscenze del precedente, anziché iniziare da zero.
• Dopo un tentativo fallito Argo può preferire un modello più forte.
• Se un budget è esaurito, non parte alcun tentativo costoso alla cieca: il nodo termina con un risultato parziale documentato o viene escalato visibilmente.

La strategia di nodo decide infine se un compito può essere saltato, fallisce in modo controllato o richiede una decisione dell'utente. I compiti dipendenti ricevono esclusivamente risultati parziali confermati. Così da un errore locale non nasce un errore silenzioso che prosegue nel resto del piano.

7. Dopo l'implementazione: revisione, verifica e un possibile ulteriore ciclo

Se i task pianificati sono stati elaborati, Argo verifica lo stato integrato da molteplici punti di vista:

• L'agente QA può leggere file ed eseguire comandi di test.
• L'agente di architettura verifica la struttura in lettura e resta consapevolmente senza diritti di scrittura.
• Verifier deterministici possono eseguire test, controllo dei tipi o linting come oracoli oggettivi.
• Riscontri basati su modello e deterministici vengono fusi in un giudizio complessivo.

Se QA, architettura o un verifier vincolante trovano problemi, Argo assegna i riscontri ai compiti interessati. Solo questi compiti vengono rielaborati con il feedback concreto. Segue poi di nuovo revisione e verifica. Senza modalità consenso questo ciclo è limitato; in una modalità consenso esplicitamente scelta prosegue finché l'utente non interrompe o i revisori non concordano.

Un verifier in modalità osservazione documenta i riscontri, ma non blocca. In modalità vincolante un riscontro rigido può impedire che il risultato valga come riuscito. Così la severità può essere scelta per profilo operativo, senza rinunciare alla tracciabilità.

8. Solo quando lo stato è verificato: documentazione e riepilogo CEO

Dopo un ciclo di lavoro e verifica completato, un agente di documentazione può registrare le modifiche. Successivamente il livello CEO crea il riepilogo per l'utente: cosa è stato svolto? Cosa è rimasto aperto? Quali verifiche sono state eseguite? Quali file o decisioni sono interessati?

Il risultato è più di un testo di chat. L'esecuzione porta un identificativo comune per piano, scelta del modello, costi, azioni, giudizi di verifica, interruzioni utente e successive decisioni di patch. Ciò permette di ricostruire come Argo è giunto a un risultato.

9. Alla fine decide l'umano sul workspace reale

Di default Argo lavora in un worktree isolato. Le modifiche giacciono lì come patch, non silenziosamente nel progetto reale. A seconda del livello di autonomia accade poi uno di tre cose:

• La patch resta pronta per l'accettazione, l'adozione parziale, la modifica o lo scarto.
• Una patch riuscita viene adottata automaticamente.
• In caso di conflitti con file modificati nel frattempo, Argo si ferma visibilmente; non sovrascrive modifiche altrui.

Un'esecuzione fallita non viene applicata automaticamente. Anche una configurazione molto autonoma non abroga la policy: protezione dei segreti, regole dei comandi, limiti dei provider, limiti di budget e necessari gate umani restano efficaci.

Cosa realizza il motore di orchestrazione

Il motore di orchestrazione non decide solo quale modello risponde poi. Collega intenzione dell'utente, impostazioni, pianificazione, parallelizzazione, scelta del modello, uso degli strumenti, correzione errori, garanzia della qualità e adozione sicura in un flusso coerente.

Il criterio non è “più agenti possibile”. Lavoro aggiuntivo nasce solo dove è giustificato: un modello più forte per una difficile decisione di architettura, un secondo approccio di pensiero in caso di incertezza, un retry mirato dopo una contestazione del verifier o un'autorizzazione umana prima di un effetto rischioso.

La rotta è così impostata.