💻 computer science

TypeGo: An OS Runtime for Embodied Agents

Dit artikel introduceert TypeGo, een runtime in de stijl van een besturingssysteem voor belichaamde agenten, die synchrone LLM-verzoek/antwoordcycli vervangt door asynchrone, multi-timescale planning en gelijktijdige taakbeheer om latentie aanzienlijk te verminderen en realtime controle mogelijk te maken.

Oorspronkelijke auteurs: Guojun Chen, Alex Schott, Lin Zhong

Gepubliceerd 2026-07-08

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Guojun Chen, Alex Schott, Lin Zhong

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een robot hond probeert te leren hoe hij door een drukke wereld moet navigeren. Momenteel werken de meeste robots als een persoon die wacht op een sms-bericht: ze stoppen, wachten tot een "brein" (een Large Language Model of LLM) reageert met de volgende zet, en bewegen dan pas. Als het "brein" 5 seconden nodig heeft om na te denken, staat de robot 5 seconden lang bewegingsloos stil. Dit is te traag voor het echte leven, waar je een vallend object moet ontwijken of met een mens moet praten terwijl je loopt.

TypeGo is een nieuw systeem dat is ontworpen om dit op te lossen. De auteurs van de Yale University stellen voor om de robot niet te behandelen als een simpel machine die wacht op bevelen, maar als een slim besturingssysteem (zoals de software die op je telefoon of laptop draait) dat zowel het lichaam als het brein van de robot tegelijkert wordt beheerd.

Hier is hoe TypeGo werkt, met behulp van eenvoudige analogieën:

1. Het Probleem: De "Stop-en-Denk"-bottleneck

Stel je een robot voor die een kamer door probeert te lopen.

De Oude Manier: De robot zet één stap, stopt, vraagt aan zijn AI-brein: "Wat nu?" De AI denkt 3 seconden na, zegt "Draai naar links," en de robot draait. Daarna stopt hij weer om te vragen: "Wat nu?" Dit creëert een schokkerige, trage robot die niet snel kan reageren op verrassingen.
De Uitdaging: AI-breinen zijn slim maar traag. Robots in de echte wereld moeten snel zijn.

2. De Oplossing: De "Robot OS"

TypeGo fungeert als een besturingssysteem dat meerdere "apps" (taken) tegelijkertijd draait en de fysieke onderdelen van de robot (poten, luidsprekers, camera's) beheert, net zoals jouw computer het scherm, toetsenbord en de luidsprekers beheert.

Het gebruikt vier verschillende "denk-lussen" die op verschillende snelheden draaien en allemaal samenwerken:

De Reflexlaag (S0) – De "Kniepeesreactie":
- Analogie: Stel je voor dat je een hete kookplaat aanraakt. Je trekt je hand weg nog voordat je brein doorheeft dat het heet is.
- Hoe het werkt: Dit is een super-snelle laag die niet wacht op de trage AI. Als er een persoon voor de robot loopt, zegt deze laag direct: "Stop!" of "Stap achteruit!" Deze laag draait 100 keer per seconde, zodat de robot nooit botst.
De Action Streamer (S1) – De "Speculatieve Chef":
- Analogie: Stel je een chef voor die al begint met het snijden van groenten terwijl de soep nog aan het koken is. Hij wacht niet tot de soep klaar is; hij bereidt de volgende stappen alvast voor.
- Hoe het werkt: Terwijl de robot momenteel loopt, denkt deze laag al na over de volgende drie stappen. Het plaatst ze in een "wachtrij" (queue). Tegen de tijd dat de robot de huidige stap heeft voltooid, is de volgende stap al klaar om uitgevoerd te worden. Hierdoor wordt de trage denktijd verborgen achter de snelle bewegingstijd.
De Task Decomposer (S2) – De "Projectmanager":
- Analogie: Als je een mens vertelt: "Maak het huis schoon," breekt diegene dat af in: "Eerst speelgoed opruimen, dan stofzuigen, dan stoffen."
- Hoe het werkt: Deze laag neemt een groot doel (zoals "Zoek een bal") en breekt dit op in kleinere, beheersbare stukjes. Het actualiseert deze plannen elke paar seconden op basis van wat de robot ziet.
De Process Scheduler (S3) – De "Verkeersregelaar":
- Analogie: Stel je een druk kruispunt voor. De verkeersregelaar beslist wie er eerst mag: de ambulance (noodgeval) of de bezorgwagen (routine).
- Hoe het werkt: Als de robot aan het lopen is (Taak A) en een mens vraagt plotseling of hij wil gaan zitten (Taak B), beslist de Scheduler welke taak voorrang krijgt. Het systeem weet dat als een mens een direct bevel geeft, dit prioriteit heeft. Als de robot alleen een muur moet ontwijken, pauzeert het de loop-taak, handelt de muur af, en gaat vervolgens automatisch weer verder met lopen.

3. Praten met de Robot: "Voorschriften"

Je hoeft geen code te schrijven om TypeGo te vertellen wat het moet doen. Je spreekt gewoon natuurlijk.

Taken: "Ga een rode bal zoeken." (Dit gaat naar de Projectmanager).
Reflexen: "Als er iets dichterbij dan 2 voet komt, stap dan achteruit." (Dit wordt omgezet in een snelle, automatische regel voor de Reflexlaag).

4. Hoe het conflicten afhandelt (De "Skill Kernel")

Een robot heeft beperkte fysieke onderdelen. Het kan niet tegelijkertijd lopen en zijn kop laten draaien als die acties met elkaar in conflict komen.

De Kernel: Zie dit als de "Resource Manager". Het werkt als een uitsmijter bij een club. Als de "Loop"-proces de poten wil gebruiken, en de "Praat"-proces de mond, laat de Kernel ze allebei toe omdat ze verschillende onderdelen gebruiken. Maar als twee processen allebei de poten willen gebruiken, zorgt de Kernel ervoor dat het ene proces wordt gepauzeerd totdat het andere klaar is, zodat de robot niet probeert twee conflicterende dingen tegelijk te doen.

5. De Resultaten: Sneller en Slimmer

De onderzoekers hebben TypeGo getest op een echte robot hond (Unitree Go2) genaamd "Kalos".

Snelheid: Vergeleken met oudere methoden verminderde TypeGo de tijd die nodig is voor de eerste beweging met 73%. Ook werd de vertraging tussen stappen met 50% verminderd.
Multitasking: De robot kon lopen terwijl hij naar een mens luisterde, en als de mens een nieuwe opdracht gaf, kon de robot pauzeren, luisteren en daarna weer verdergaan met lopen zonder in de war te raken.
Veiligheid: Als er een obstakel verscheen, reageerde de robot direct (in minder dan een seconde) zonder te wachten tot de trage AI had nagedacht.

Samenvatting

TypeGo is een nieuwe manier om robots aan te sturen. In plaats van een trage AI-hersenen om toestemming te vragen voor elke enkele beweging, geeft het de robot een "besturingssysteem" dat:

Direct reageert op gevaar (Reflexen).
Vooruit plant terwijl het beweegt (Speculative Streaming).
Meerdere taken tegelijk beheert (Scheduling).
Praat met mensen via natuurlijke taal.

Het resultaat is een robot die levendiger, responsiever en beter in staat is om met de chaotische, onvoorspelbare echte wereld om te gaan.

Technische Samenvatting: TypeGo: Een OS-Runtime voor Embodied Agents

Probleemstelling

Het artikel identificeert een fundamentele mismatch tussen de huidige Large Language Model (LLM)-gebaseerde controle voor embodied agents en de vereisten voor real-time fysieke interactie. Het behandelen van een LLM als een synchrone request/response-orakel op het kritieke pad creëert drie primaire systeemuitdagingen:

Latentie versus Kwaliteit: LLM-inferentie is te traag voor real-time reactie (wat zorgt voor pauzes tussen acties), terwijl kleine, snelle modellen een gebrek hebben aan planningsvermogen.
Concurrentie en Resource Arbitrage: Real-world agents moeten meerdere concurrerende doelen afhandelen (bijv. patrouilleren terwijl ze communiceren) en delen fysieke actuatoren. Bestaande LLM-literatuur negeert grotendeels de klassieke OS-problemen van preëmptie en resource arbitrage.
Reactieve Regels: Eénmalige natuurlijke taalinstructies definiëren doelen, maar slagen er niet in om snelle, reactieve regels vast te leggen (bijv. "doe een stap naar achteren als een object binnen 0,2 m is") die sneller moeten worden uitgevoerd dan een LLM-oproepcyclus.

Huidige benaderingen, of het nu gaat om monolithische planners (het plannen van de hele sequentie in één keer) of stapsgewijze planners (per actie query's uitvoeren), lijden aan ofwel een hoge initiële latentie of frequente stagnatie tijdens de uitvoering.

Methodologie: De TypeGo Runtime

De auteurs stellen TypeGo voor, een runtime in de stijl van een besturingssysteem (OS), die de control loop van de embodied agent behandelt als een continu uitvoerend, asynchroon systeem in plaats van een sequentiële LLM-query loop. De architectuur is gebouwd op vier asynchrone planningslagen (S0–S3) die draaien over een Skill Kernel, waarbij structurele analogieën worden getrokken naar traditioneel OS-ontwerp (Tabel 1).

Kerncomponenten van de Architectuur

Skill Kernel (Resource Manager):
- Dient als de OS-kernel en bemiddelt de toegang tot getypeerde fysieke subsystemen (bijv. MOVEMENT, SOUND, DEFAULT).
- Dwingt exclusiviteit af (bijv. slechts één proces kan op één moment de voortbeweging controleren) en serialisatie voor gedeelde resources.
- Ondersteunt bounded-interruption skills: Skills kunnen worden gepauzeerd of gestopt binnen een begrensde tijd $t_s$ , wat zorgt voor een schone preëmptie en state recovery.
Process Abstraction:
- Elke taak (gebruikersinstructie of gedragsrichtlijn) wordt geïnstantieerd als een Process met een Process Control Block (PCB) dat de planningsstatus, historie en status bevat.
- Source-Dependent Resumption: In tegenstelling tot numerieke prioriteits-schedulers, maakt TypeGo onderscheid tussen interrupt-and-return (reactieve omwegen waarbij het oorspronkelijke proces hervat wordt) en replace-without-return (nieuwe gebruikersinstructies die het oude doel permanent vervangen).
Vierlaagse Asynchrone Planningsloop:
- S3 (Process Scheduler): De langzaamste laag. Beheert de levenscyclus van processen, beslist welke processen draaien op basis van semantische richtlijnen en observaties, en handelt de preëmptielogica af.
- S2 (Task Decomposer): Decomponeert hoogwaardige taken in geordende subtaken en globale event triggers (conditie/respons paren). Het inspecteert periodiek de historie om het plan bij te werken.
- S1 (Action Planner / Streamer): De speculatieve laag. Het zet subtaken om in een stroom van skill calls. Cruciaal is dat het een bounded queue gebruikt om toekomstige stappen speculatief te genereren terwijl de huidige stap wordt uitgevoerd, waardoor de planningslatentie wordt overlapt met de uitvoering.
- S0 (Reflexive Layer): De snelste laag (100 Hz). Voert gecompileerde Python conditie/actie paren uit die zijn afgeleid van natuurlijke taalreflexen. Het heeft de hoogste prioriteit en is in staat om elk proces te onderbreken dat gecontendeerde subsystemen bezit.
Programmeerabstracties:
- Prescriptions: Natuurlijke taalinputs. Tasks worden gerouteerd naar online planners (S1–S3); Reflexes worden offline gecompileerd naar hoogfrequente S0 handlers.
- Observations: Gestructureerde, continue datastromen (bijv. objectdetecties) die aan alle planners worden blootgesteld.
- Skills: Aanroepbare primitieven die door ontwikkelaars zijn geschreven (niet gesynthetiseerd door de LLM) die lage-niveau robotoperaties implementeren.

Belangrijkste Bijdragen

OS-stijl Runtime voor Embodied Agents: Het artikel introduceert een runtime-ontwerp dat de planning ontkoppelt van de uitvoering, wat gelijktijdige taakbeheer en resource arbitrage mogelijk maakt, vergelijkbaar met hoe een CPU hardware beheert.
Speculative Skill Streaming: Door een look-ahead queue van skill calls te onderhouden, verbergt TypeGo de LLM-planningslatentie achter lopende bewegingen, wat zorgt voor continue uitvoering zonder te wachten op de volgende planning.
Semantic Scheduling: De scheduler (S3) neemt preëmptiebeslissingen op basis van de bron van de aanvraag (gebruiker vs. reactieve richtlijn) in plaats van vaste numerieke prioriteiten, wat genuanceerde gedragingen mogelijk maakt zoals het automatisch hervatten van onderbroken taken.
Natuurlijke Taal als Eersteklas Medium: Het systeem stelt niet-programmeurs in staat om zowel hoogwaardige doelen als laag-latente reactieve regels te schrijven, waarbij het systeem ze automatisch routeert naar de juiste latentie-tier (S0 vs. S1–S3).

Voorlopige Resultaten

De auteurs hebben TypeGo geëvalueerd op Kalos, een Unitree Go2 quadruped, waarbij ze het hebben vergeleken met ReAct (stapsgewijze planning) en Plan-and-Execute (PAE) (monolithische planning).

Responsiviteit:
- Time-to-First-Action (TTFA): TypeGo verminderde de TTFA met 73% vergeleken met PAE en met 40% vergeleken met ReAct. Dit wordt bereikt door een onmiddellijke actie via S1 uit te sturen terwijl hogere planners delibereren.
- Per-Step Delay: TypeGo verminderde de delay per stap met 50% vergeleken met ReAct door de "stall" tussen de voltooiing van een actie en de volgende planning-query te elimineren.
Effectiviteit:
- TypeGo handelde complexe, langdurige taken succesvol af en degradeerde gracieus wanneer paden geblokkeerd waren (in tegen tegenstelling tot PAE, dat onbepaald bleef stagneren).
- In een specifieke taak die een globaal plan vereiste (naar een gang gaan voordat men gaat zoeken), presteerde PAE beter dan TypeGo, wat wijst op een bekende bias in stapsgewijze planning richting lokaal veelbelovende acties.
Concurrentie:
- Het systeem beheerde succesvol gelijktijdige taken (bijv. patrouilleren terwijl vragen worden beantwoord) en reflexen (obstakelvermijding).
- Overhead: De scheduling overhead was bescheiden (~200 ms voor S3 scheduling, ~50 ms voor S0 reflex handling). De primaire kosten kwamen voort uit tokenverbruik vanwege de meerdere asynchrone loops, wat een afweging vertegenwoordigt tussen responsiviteit en computationele kosten.

Betekenis en Claims

Het artikel positioneert TypeGo niet als een afgerond besturingssysteem, maar als een proof-of-concept prototype dat de hypothese valideert dat embodied agents een OS-stijl runtime nodig hebben om concurrentie, latentie en resource arbitrage te beheren.

Verschuiving van Focus: De auteurs stellen dat de "harde problem" is verschoven van hoe een robot beweegt (low-level controle) naar hoe een embodied systeem beslist (besluitvormingsarchitectuur).
Orthogonaliteit: Het ontwerp is orthogonaal aan inspanningen die simpelweg een enkele LLM-call versnellen; in plaats daarvan beoogt het de LLM-latentie te verbergen van het kritieke pad door middel van speculatie en gelaagde dispatch.
Toekomstige Richting: Het artikel identificeert Memory als de volgende cruciale primitief, waarbij een geheugenhiërarchie (M0–M3+) wordt voorgesteld die analoog is aan bestandssystemen en virtueel geheugen om langdurige, adaptieve agents te ondersteunen. Er wordt ook gepleit voor rijkere resource isolatiemodellen en kostenbewuste runtime-policies om tokenbudgetten en netwerkbeperkingen te beheren.

Het werk demonstreert dat het behandelen van de agent als een multitasking OS-proces, in plaats van een lineair script, de real-time responsiviteit en adaptiviteit in dynamische omgevingen aanzienlijk verbetert.