T-Rax — Generazione multi-agente di codice Unity
Una pipeline multi-agente a grafo che trasforma la descrizione di una scena in codice C# Unity funzionante, separando la pianificazione dalla generazione di codice perché ogni agente abbia un solo compito.
In breve
T-Rax genera la logica di scena Unity a partire da una descrizione ad alto livello. Invece di chiedere a un singolo modello di pianificare e scrivere codice in un colpo solo, distribuisce il lavoro su un grafo di agenti — un orchestrator, un planner e un executor — ciascuno con una responsabilità ristretta e un passaggio di consegne definito.
Il problema
Alcune cose si possono provare in sicurezza solo in simulazione: un'evacuazione di emergenza, un intervento su una cabina elettrica, il cambio formato di una macchina, un'esercitazione di protezione civile. Il training in extended reality funziona bene proprio in questi casi — e le organizzazioni che ne avrebbero più bisogno, dai comuni ai vigili del fuoco fino a ospedali, istituti professionali e PMI manifatturiere, sono quelle che meno possono permetterselo.
- Ogni scenario è un progetto software. Realizzarne uno in Unity è lavoro da sviluppatore, quantificato in settimane-uomo, e non ne esiste una versione che un responsabile della formazione possa fare da solo.
- Poiché ogni scenario costa caro, un'organizzazione finisce per averne due o tre invece di una libreria — e poi si addestra soltanto su ciò che ha già costruito.
- Quando una procedura cambia — nuova normativa, nuovo macchinario, protocollo rivisto — lo scenario diventa sbagliato, e correggerlo significa tornare da uno sviluppatore che non è più sotto contratto.
- Chi conosce davvero la procedura — il responsabile della sicurezza, l'infermiere di reparto, il capoturno di stabilimento — non ha modo di descriverla e ottenere in cambio qualcosa di eseguibile.
Come questo progetto aiuta
T-Rax sposta la creazione degli scenari dallo sviluppatore a chi possiede la procedura. L'input è una descrizione strutturata in linguaggio naturale; l'output è codice C# funzionante per la logica di scena. Ciò che sta in mezzo è la parte che conta sul piano organizzativo: il planner mette per iscritto che cosa intende costruire prima che venga generato qualsiasi codice, così il piano è un documento che una persona può leggere, correggere e approvare.
- A scrivere sono gli esperti di dominio, non gli sviluppatori. Lo scenario nasce come specifica scritta — la forma in cui una procedura già esiste.
- Le revisioni diventano economiche. Aggiornare un'esercitazione dopo un cambio di norma significa modificare la specifica e rieseguire la pipeline, non riaprire un progetto Unity.
- Il piano è verificabile prima di essere costruito. Un responsabile della formazione può controllare che la scena prevista corrisponda alla procedura reale mentre è ancora testo — il momento in cui correggerla non costa nulla.
- Gli errori restano attribuibili. Poiché il planner non scrive mai codice e l'executor non ripianifica mai, una scena sbagliata è o un piano sbagliato o una generazione sbagliata. È questo che rende il sistema manutenibile anche da chi non lo ha costruito.
Detto senza giri di parole: questo è lavoro allo stadio di ricerca, non qualcosa che un'organizzazione possa acquistare oggi. Ciò che stabilisce è la forma della risposta — che la generazione di scenari si separa nettamente in un artefatto di pianificazione verificabile e in un passo di codifica meccanico — ed è proprio quella separazione a sopravvivere in qualunque sistema costruito per l'uso reale.
Come è strutturata la pipeline
La separazione è il punto. Il planner non emette mai codice e l'executor non ripianifica mai, il che mantiene i guasti diagnosticabili: una scena sbagliata è o un problema di pianificazione o un problema di generazione, mai un misto ambiguo dei due.
- L'agente orchestrator mantiene l'esecuzione e instrada lo stato tra gli agenti.
- Il planner lavora su tre stadi sovrapposti e produce solo descrizioni di task — mai codice.
- L'agente executor consuma quelle descrizioni ed emette codice C#, incluso il punto di ingresso
SetupStandardScenary(), scritto su file inSceneLogic.cs. - Il workflow planner–executor è documentato come diagrammi Mermaid e SVG accanto al codice.
Perché separare pianificazione e generazione
Un singolo agente a cui si chiede di pianificare e implementare tende a derivare: scrive codice che si discosta silenziosamente da ciò che aveva detto di voler fare, e non c'è alcun artefatto intermedio da verificare. Costringere il planner a emettere prima una descrizione crea quell'artefatto. Il piano si può ispezionare, e il C# generato si può giudicare rispetto a esso.