NVIDIA Labs hat mit NOOA eine Open-Source-Research-Preview für Agenten veröffentlicht, die einen ungewohnten Schwerpunkt setzt: Der Agent ist ein Python-Objekt. Das ist kein Ersatz für jedes Orchestrierungsframework – aber ein ernstzunehmender Vorschlag, Zustand, Tools und Kontextkosten anders zu behandeln.
Die übliche Agentenfrage lautet derzeit: Welcher Modellanbieter, welcher Graph, welches Tool-Protokoll? NOOA (Object-Oriented Agents) verschiebt die Perspektive auf den Harness. Methoden werden zu aufrufbaren Aktionen, Attribute zu persistentem Zustand, Docstrings zu Instruktionen und Typannotationen zu Verträgen. NVIDIA veröffentlicht dazu Framework, Memory-System, Benchmark-Agenten sowie Evaluierungsartefakte als Research Preview.
Der praktische Punkt: Ergebnisse müssen nicht in den Prompt
Die technisch interessanteste Idee heißt pass-by-reference. Große Tool-Ergebnisse – etwa ein Repo-Checkout, eine Tabelle oder ein Testprotokoll – sollen im Python-Workspace liegen bleiben. Das Modell erhält eine Referenz und kann gezielt damit arbeiten, statt den gesamten Inhalt wiederholt in den Kontext zu kopieren.
klassischer Pfad: Tool-Ausgabe → Prompt → Modellkontext NOOA-Idee: Tool-Ausgabe → Workspace → Referenz im Kontext
Für Teams mit langen Tool-Schleifen ist das mehr als Stilfrage: Weniger Kontextkopien können Prompt-Caches stabiler halten und Tokenverbrauch reduzieren. Ob der Effekt in einer eigenen Umgebung tatsächlich eintritt, hängt jedoch von Modell, Tooling und Aufgabenprofil ab. NVIDIAs Leistungs- und Kostenvergleiche sind Herstellerangaben, nicht unabhängig reproduzierte Benchmarks.
SQLite-Speicher statt automatischer Erinnerungsprosa
NOOA setzt außerdem auf einen inspizierbaren SQLite-basierten Store. Erinnerungen werden bewusst von der Agentenlogik gepflegt; der Ansatz soll automatische Kontextkompaktierung und Zusammenfassungspipelines vermeiden. Das ist attraktiv, weil sich Zustand abfragen, testen und zurücksetzen lässt – verlangt aber auch klarere Datenmodelle und Bereinigungsregeln als ein unsichtbarer Chat-Verlauf.
| Frage | NOOA-Ansatz | Operative Konsequenz |
|---|---|---|
| Wo lebt Zustand? | In Objektfeldern und SQLite | State wird überprüf- und testbar |
| Wie werden große Artefakte genutzt? | Per Referenz im Workspace | Weniger Kontextkopien möglich |
| Wie entstehen Aktionen? | Aus Python-Methoden mit Typen und Docstrings | Schnittstellen liegen näher am Anwendungscode |
Was Teams jetzt tun sollten
- Nicht blind migrieren: NOOA ist ausdrücklich eine Research Preview.
- Ein repräsentatives Tool-Loop messen: Kontextgröße, Cache-Hits, Laufzeit und Fehlerrate vor und nach einer Referenz-Strategie vergleichen.
- State als Produktoberfläche behandeln: Schema, TTL, Löschung und Debug-Zugriff vor dem Persistieren festlegen.
- Benchmarks einordnen: Die veröffentlichten Artefakte sind wertvoll; die behauptete Überlegenheit bleibt dennoch zu reproduzieren.
Ein Architekturvorschlag, kein fertiger Standard
NOOA ist relevant, weil es eine konkrete Gegenposition zu immer umfangreicheren Agenten-Graphen formuliert: Robuste Agents könnten vor allem von einer guten Workspace- und Objektgrenze profitieren. Für produktive Systeme ist das noch keine Entscheidungsvorlage. Für die nächste interne Agenten-Evaluation ist es aber ein nützlicher Test: Muss diese Information wirklich in den Modellkontext – oder sollte sie als überprüfbares Artefakt außerhalb davon bleiben?
Schreibe einen Kommentar