Hintergrund und Problemdefinition
„A Programming Paradigm for Spatiotemporal Composability" ist von Yifan Shi, Wei Zhang (Peking-Universität) und Tianyi Cui (DeepSeek-AI, d. h. der Koishi-Framework-Autor Shigma) mitverfasst. Es handelt sich um ein Papier aus der Programmsprachentheorie und Laufzeitsysteme, nicht um ein Papier über Modelltraining oder Modellfähigkeiten.
Agent = Model + Harness
[Originale Schlussfolgerung des Papiers §1.2.2] Das Papier nimmt den Agent Runtime als eines seiner motivierenden Beispiele: moderne KI-Agenten hängen von Laufzeit-Agent-Harnesses ab, Systeme, die Werkzeugkasten, Ausführungsumgebungen, Berechtigungssandboxes, Sitzungszustand, Kontextgedächtnis, Sub-Agenten-Workflows und UI zusammenfügen; „zukünftige Harnesses könnten Modifikationen an ihren eigenen Komponenten generieren und ausrollen, während sie weiterhin Anfragen bedienen".
Diese Definition passt exakt zu DeepSeeks offizieller Beschreibung des Harness: Agent = Model + Harness. Das Model ist für Reasoning und Entscheidungen zuständig; der Harness stellt Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI über Plugins bereit. DeepSeek Harness macht all diese Fähigkeitsdomänen zu Cordis-Plugins.
Warum benötigt ein langlebiger, sich selbst verändernder Agent dynamisches Laden, Entladen und Ersetzen von Komponenten? Weil das kennzeichnende Merkmal eines selbst-evolvierenden Agenten darin besteht, „sich während des Laufs zu verändern" — ein Werkzeug upzugraden, ein Skill zu ersetzen, die Umgebung eines Sub-Agenten anzupassen. Wenn jede Modifikation einen Neustart der gesamten Session erzwingt, gehen Kontext und Zwischenzustände verloren; wenn nicht neu gestartet wird, werden die Seiteneffekte der alten Komponente (offene Verbindungen, registrierte Callbacks, gehaltener Zustand) zu dangling Garbage, die die weitere Ausführung verschmutzt. Traditionelle Mechanismen geben keine Antwort auf „wie man eine noch verwendete Komponente sauber austauscht".
Warum traditionelle Plugin-Systeme, DI und HMR nicht ausreichen
Das Papier §1.2.1 nimmt VSCode als kanonisches Beispiel:
- Temporal limitation: VSCodes Extension Host bietet keinen Mechanismus, den Code einer einzelnen Erweiterung zur Laufzeit zu entladen; das Deaktivieren oder Deinstallieren einer Erweiterung erfordert einen Neustart des gesamten Hosts. 87 der Top-100-Erweiterungen enthalten ausführbaren Code, alle benötigen einen Neustart. Der
deactivate-Hook wird lediglich als Graceful-Exit-Callback beim Herunterfahren des Prozesses verwendet und trennt das Effect Disposal vom Effect Creation (inactivate), was die Locality of Concern verletzt. - Spatial limitation:
extensionDependencieswird fast nicht verwendet (nur 7 der Top 100 deklarieren es); es gibt keinen strukturellen Vertrag zwischen Erweiterungen, undgetExtension(...).exportsgibt einen Wert vom Typanyzurück.
[Aus dem Papier abgeleitete Inferenz] Traditionelle DI (z. B. Spring, Angular) injiziert Abhängigkeiten nur bei der Initialisierung; wenn ein Provider zur Laufzeit ersetzt oder entfernt wird, werden bestehende Dependents weder deaktiviert noch reinitialisiert. Reacts useEffect paart Effect mit Cleanup, aber Hooks dürfen nicht innerhalb von Conditions/Loops/verschachtelten Funktionen aufgerufen werden, der Effect-Körper akzeptiert keine Async-Funktion und keinen Iterator, und ein zusammengesetzter Inverse lässt sich aus bestehenden Effects nicht komponieren. HMR (webpack, Vite) migriert Zustand über import.meta.hot nach vorne und verlässt sich auf handgeschriebene Migrationsfunktionen der Entwickler. Software Transactional Memory (STM) und RAII beschränken Reversal auf einen festen, statischen Scope. OSGi Declarative Services reagieren auf Service-Verfügbarkeit, aber der Deactivation-Callback ist handgeschrieben und synchron.
[Originale Schlussfolgerung des Papiers §1.2.3] Betriebssysteme bieten Temporal Composability auf Prozessgranularität; Container-Orchestratoren bieten Spatial Composability auf Servicegranularität, aber das sind grobkörnige Substitute: jeder Neustart verwirft den gesamten prozesslokalen Zustand (Caches, Verbindungen, Teilberechnungen), und der Wiederaufbau dauert Sekunden bis Minuten; Orchestrierung auf Containerebene kann Abhängigkeiten zwischen Komponenten, die sich einen Adressraum teilen, nicht ausdrücken. Das Papier fordert eine Kompositionsabstraktion in derselben Granularität wie die Komponenten selbst.
Zwei orthogonale Dimensionen
[Originale Schlussfolgerung des Papiers §1.1] Das Papier identifiziert zwei orthogonale Dimensionen dynamischer Komposition:
- Temporal composability (Zeitdimension): Wenn eine Komponente entfernt wird, muss jede Änderung, die sie an der gemeinsamen Umgebung vorgenommen hat, vollständig und sicher rückgängig gemacht werden. Das erfordert das Verfolgen jeder Ressourcenzuweisung, jeder Ereignisregistrierung und jeder Zustandsänderung, die die Komponente ausgeführt hat, und garantiert deren geordnete Wiederherstellung.
- Spatial composability (Raumdimension): Komponenten müssen strukturell und überprüfbar Abhängigkeiten untereinander deklarieren, entdecken und auflösen können. Das erfordert die Verwaltung der Abhängigkeitstopologie und die Koordination der Komponentenlebenszyklen bei Änderung der Abhängigkeiten.
[Originale Schlussfolgerung des Papiers §2.3] Effect beschreibt „wie eine Berechnung die Umgebung verändert", und Coeffect beschreibt „wie eine Berechnung von der Umgebung abhängt" — die beiden Richtungen sind komplementär, nicht vermengen. In der statischen Einstellung reduziert sich Temporal auf lexikalischen Scope (RAII, Bracket-Pattern) und Spatial auf Modul-Import-Auflösung; in der dynamischen Einstellung werden beide deutlich schwieriger.
Die Lösung des Papiers: den klassischen Effect/Coeffect aus der statischen Analyse zur Kompilierungszeit auf Laufzeitmechanismen anheben — Revertible Effects (jede Kontexttransformation trägt einen Inverse, zur Laufzeit verfolgt) löst Temporal; Reactive Coeffects (Komponenten deklarieren Coeffect-Spezifikationen; der Kontext benachrichtigt sie bei Änderung gemäß Spezifikation) löst Spatial. Beide werden in einem einzigen Kontext-Typ vereinigt, bilden den Komponentenbegriff und liefern einen dynamischen Kompositionskalkül mit bewiesenen metatheoretischen Eigenschaften.
Karte der zentralen Konzepte
| Konzept | Bedeutung | Quelle |
|---|---|---|
| Revertible Effect | Jede Kontexttransformation trägt einen Inverse, zur Laufzeit verfolgt | §3.1, Def 8 |
| Reactive Coeffect | Komponenten deklarieren Coeffect-Spezifikationen; der Kontext benachrichtigt bei Änderung gemäß Spezifikation | §3.2.2, Def 26 |
| Unified Context Γ∞ | Ein einzelner Kontext-Typ, der rekursiv (Zustand, Akkumulator, Coeffect-Tabelle) trägt | §3.3.1, Def 32 |
| Component ℭΓ | Tripel (Abhängigkeitsspezifikation d, Provision p, Effect-Witness-Funktion e) | §4.1, Def 43 |
| Fiber | Eine Instanziierung einer Komponente, die den Lebenszyklusstatus trägt | §4.1, Def 44 |
| Committed View ω | Die aktuell committete Abhängigkeitsauflösung (Fiber-Namen-Mapping) | §4.1, Def 44 |
| Target View | Der Abhängigkeitsauflösungszustand, in dem sich das Fiber befinden sollte | §4.2, Def 46 |
| Isolation Realm | Derselbe Key löst sich in verschiedenen Kontexten zu unterschiedlichen Instanzen auf | §3.2.3, Def 28 |
| Interception | Die Abhängigkeit nicht ersetzen, nur ihre Verwendungsweise verändern | §3.2.3, Def 30 |
Die nachfolgenden Kapitel folgen dieser Haupotlinie: Effects behandelt die Rückgängigmachung des Temporal; Coeffects behandelt die Reaktion des Spatial; Lebenszyklus behandelt die Koordination beider auf einer Komponenteninstanz; Theoreme behandelt, was dieser Mechanismus garantiert; DeepSeek Harness behandelt, wie er auf einer realen Agent Runtime landet; Grenzen behandelt, was nicht garantiert wird.