Sintesi Tecnica: TypeGo: Un OS Runtime per Agenti Embodied

Problema

Il documento identifica un disallineamento fondamentale tra l'attuale controllo basato su Large Language Model (LLM) per agenti embodied e i requisiti dell'interazione fisica in tempo reale. Trattare un LLM come un oracolo sincrono di tipo richiesta/risposta sul percorso critico crea tre principali sfide di sistema:

1. Latenza vs. Qualità: L'inferenza degli LLM è troppo lenta per la reazione in tempo reale (causando pause tra le azioni), mentre i modelli piccoli e veloci mancano di capacità di pianificazione.
2. Concorrenza e Arbitrato delle Risorse: Gli agenti nel mondo reale devono gestire molteplici obiettivi concorrenti (ad es. pattugliare mentre comunicano) e condividere attuatori fisici. La letteratura esistente sugli LLM evita ampiamente i classici problemi dei sistemi operativi come la preemption (prelazione) e l'arbitrato delle risorse.
3. Regole Reattive: Le istruzioni in linguaggio naturale "one-shot" definiscono gli obiettivi ma non riescono a catturare le regole reattive rapide (ad es. "indietreggia se un oggetto è entro 0,2 m") che devono eseguire più velocemente di un ciclo di chiamata LLM.

Gli approcci attuali, siano essi pianificatori monolitici (pianificando l'intera sequenza in una volta sola) o pianificatori passo dopo passo (interrogando per ogni azione), soffrono o di un'elevata latenza iniziale o di frequenti arresti durante l'esecuzione.

Metodologia: Il Runtime TypeGo

Gli autori propongono TypeGo, un runtime in stile sistema operativo che tratta il ciclo di controllo di un agente embodied come un sistema in esecuzione continua e asincrona, piuttosto che come un loop di query LLM sequenziale. L'architettura si basa su quattro livelli di pianificazione asincrona (S0–S3) che operano sopra un Skill Kernel, tracciando analogie strutturali con il design dei tradizionali sistemi operativi (Tabella 1).

Componenti Architetturali Core

1. Skill Kernel (Gestore delle Risorse):

   • Agisce come il kernel del sistema operativo, mediando l'accesso a sottosistemi fisici tipizzati (ad es. MOVEMENT, SOUND, DEFAULT).
   • Imporre l'esclusività (ad es. solo un processo può controllare la locomozione alla volta) e la serializzazione per le risorse condivise.
   • Supporta competenze a interruzione limitata (bounded-interruption skills): le competenze possono essere messe in pausa o fermate entro un tempo $t_s$, consentendo una pulizia della preemption e il ripristino dello stato.

2. Astrazione del Processo:

   • Ogni compito (istruzione dell'utente o linea guida comportamentale) è istanziato come un Processo con un Process Control Block (PCB) contenente lo stato di pianificazione, la cronologia e lo stato.
   • Ripresa Dipendente dalla Sorgente: A differenza degli scheduler a priorità numerica, TypeGo distingue tra interrupt-and-return (deviazioni reattive dove il processo originale riprende) e replace-without-return (nuove istruzioni utente che sostituiscono permanentemente il vecchio obiettivo).

3. Ciclo di Pianificazione Asincrona a Quattro Livelli:

   • S3 (Process Scheduler): Il livello più lento. Gestisce il ciclo di vita dei processi, decide quali processi eseguire in base a linee guida semantiche e osservazioni, e gestisce la logica di preemption.
   • S2 (Task Decomposer): Scompone i compiti di alto livello in sottotarelle ordinate e trigger di eventi globali (coppie condizione/risposta). Re-ispetta periodicamente la cronologia per aggiornare il piano.
   • S1 (Action Planner / Streamer): Il livello speculativo. Converte le sottotarelle in un flusso di chiamate alle competenze (skill calls). Fondamentalmente, utilizza una coda limitata (bounded queue) per generare passi futuri in modo speculativo mentre il passo corrente viene eseguito, sovrapponendo la latenza di pianificazione all'esecuzione.
   • S0 (Livello Riflessivo): Il livello più veloce (100 Hz). Esegue coppie condizione/azione in Python compilato derivate da riflessi in linguaggio naturale. Ha la priorità più alta, capace di interrompere qualsiasi processo che detenga sottosistemi contesi.

4. Astrazioni di Programmazione:

   • Prescrizioni: Input in linguaggio naturale. I compiti (tasks) sono instradati verso pianificatori online (S1–S3); i riflessi (reflexes) sono compilati offline in handler S0 ad alta frequenza.
   • Osservazioni: Flussi di dati strutturati e continui (ad es. rilevamenti di oggetti) esposti a tutti i pianificatori.
   • Competenze (Skills): Primitivi chiamabili scritti dagli sviluppatori (non sintetizzati dall'LLM) che implementano operazioni robotiche di basso livello.

Contributi Chiave

1. Runtime in Stile OS per Agenti Embodied: Il documento introduce un design di runtime che decoppia la pianificazione dall'esecuzione, permettendo la gestione di compiti concorrenti e l'arbitrato delle risorse simile a una CPU che gestisce l'hardware.
2. Streaming di Competenze Speculativo: Mantenendo una coda di look-ahead di chiamate alle competenze, TypeGo nasconde la latenza di pianificazione dell'LLM dietro il movimento in corso, consentendo un'esecuzione continua senza attendere il piano successivo.
3. Scheduling Semantico: Lo scheduler (S3) prende decisioni di preemption basate sulla sorgente della richiesta (utente vs. linea guida reattiva) piuttosto che su priorità numeriche fisse, consentendo comportamenti sfumati come il ripristino automatico dei compiti interrotti.
4. Linguaggio Naturale come Medium di Prima Classe: Il sistema consente a non programmatori di scrivere sia obiettivi di alto livello che regole reattive a bassa latenza, con il sistema che li instrada automaticamente al livello di latenza appropriato (S0 vs. S1–S3).

Risultati Preliminari

Gli autori hanno valutato TypeGo su Kalos, un quadrupede Unitree Go2, confrontandolo con ReAct (pianificazione passo dopo passo) e Plan-and-Execute (PAE) (pianificazione monolitica).

• Reattività:
  • Time-to-First-Action (TTFA): TypeGo ha ridotto il TTFA del 73% rispetto a PAE e del 40% rispetto a ReAct. Ciò è ottenuto emettendo un'azione immediata tramite S1 mentre i pianificatori di livello superiore deliberano.
  • Ritardo per Passo: TypeGo ha ridotto il ritardo per passo del 50% rispetto a ReAct eliminando lo "stallo" tra il completamento dell'azione e la successiva query di pianificazione.
• Efficacia:
  • TypeGo ha gestito con successo compiti composti a lungo termine e si è degradato con grazia quando i percorsi erano bloccati (a differenza di PAE, che si bloccava indefinitamente).
  • In un compito specifico che richiedeva un piano globale (andare in un corridoio prima di cercare), PAE ha superato TypeGo, evidenziando un bias noto della pianificazione passo dopo passo verso azioni localmente promettenti.
• Concorrenza:
  • Il sistema ha gestito con successo compiti concorrenti (ad es. pattugliare mentre si risponde a query) e riflessi (evitamento ostacoli).
  • Overhead: L'overhead di scheduling è stato modesto (~200 ms per lo scheduling S3, ~50 ms per l'handling del riflesso S0). Il costo principale è rappresentato dall'uso di token dovuto ai molteplici loop asincroni, che rappresenta un compromesso tra reattività e costo computazionale.

Significato e Rivendicazioni

Il documento posiziona TypeGo non come un sistema operativo finito, ma come un prototipo di prova di concetto che valida l'ipotesi che gli agenti embodied richiedano un runtime in stile OS per gestire concorrenza, latenza e arbitrato delle risorse.

• Spostamento del Focus: Gli autori sostengono che il "problema difficile" si sia spostato dal come un robot si muove (controllo di basso livello) al come un sistema embodied decide (architettura decisionale).
• Ortogonalità: Il design è ortogonale agli sforzi che mirano semplicemente ad accelerare singole chiamate LLM; invece, mira a nascondere la latenza dell'LLM dal percorso critico attraverso la speculazione e la distribuzione a livelli.
• Direzione Futura: Il documento identifica la Memoria come la prossima primitiva critica, immaginando una gerarchia di memoria (M0–M3+) analoga ai file system e alla memoria virtuale per supportare agenti adattivi a lungo termine. Richiede inoltre modelli di isolamento delle risorse più ricchi e policy di runtime attente ai costi per gestire i budget di token e i vincoli di rete.

Il lavoro dimostra che trattare l'agente come un processo multitasking di un OS, piuttosto che come uno script lineare, migliora significativamente la reattività in tempo reale e l'adattabilità in ambienti dinamici.