Die Blaupause für die "Selbstevolution" von DeepSeek wurde offengelegt.

Die neueste gemeinsame Arbeit von DeepSeek und der Peking-Universität enthüllt die Harness-Version des Schwarzen Wals.

Sie trägt den Titel „A Programming Paradigm for Spatiotemporal Composability“, die ursprüngliche chinesische Übersetzung lautet „Ein Programmierparadigma zur Behandlung von räumlich-zeitlicher Zusammensetzbarkeit“.

Das klingt etwas kompliziert, Sie brauchen sich nur einen Satz zu merken —

Der gesamte Text dreht sich um Cordis, das Kernstück des Schwarzen Wals, eine beliebig ein- und aussteckbare „Lego-Bodenplatte“.

Hier gilt: Alles ist Plugin, alles kann neu zusammengesetzt werden.

Das erklärt auch, warum der Öffnungsgrad des „Schwarzen Wals“ so hoch ist und die Behörden die Nutzer so sehr dazu ermutigen, Plugins zu erstellen und Harness umfassend anzupassen.

Dies ist eine Arbeit mit riesigem Informationsgehalt und zugleich das Meisterwerk des DeepSeek Harness-Teams nach langer Vorbereitung, das in Form des großen Schwarzen Wals einen vollen Erfolg erzielte.

Bemerkenswert ist, dass dies die siebte Arbeit von DeepSeek in diesem Jahr und die n-te gemeinsame Arbeit mit der Peking-Universität ist.

Die Arbeit umfasst insgesamt über 80 Seiten. Ich habe sie von Anfang bis Ende durchgearbeitet und einige Kernaussagen zusammengefasst —

1. Cordis bietet eine allgemeine dynamische Kompositionssemantik. Die über Context verwalteten Komponenten können dynamisch geladen und entladen werden, und ihre verwalteten Nebeneffekte werden automatisch zurückgesetzt.

2. Die mathematische Grundlage stammt aus zwei klassischen Konzepten der Typentheorie: Effekt und Koeffekt.

3. Es handelt sich nicht um ein Laboratoriumsspielzeug. Dieses Design wird seit vier Jahren im Koishi-Chatbot-Framework eingesetzt, und über 4000 Community-Plugins wurden in der Produktivumgebung validiert.

Und all dies dient dem gleichen ehrgeizigen Ziel —

Selbstevolution.

Zeit und Raum: Die zwei Hürden für die Selbstevolution von Harness

In der Softwarewelt gibt es eine kontraintuitive Realität: Bei den meisten Systemen mit Plugin-Unterstützung muss nach dem Entfernen eines Plugins der gesamte Host-Prozess neu gestartet werden.

Das bedeutet, dass man möglicherweise nur ein einzelnes Plugin löscht, aber alle bereits geladenen Plugins zusammen mit ihm neu gestartet werden müssen.

Ja, „Einsteck“-Plugins lassen sich nach dem Einfügen praktisch nicht mehr herausziehen.

VSCode ist ein typisches Beispiel.

Die Arbeit zeigt, dass unter den Top-100-Erweiterungen im VSCode Marketplace bis zum 9. Juni 2026 87 ausführbaren Code enthalten. Sobald sie aktiviert sind, können sie zur Laufzeit nicht einzeln entladen werden, und nach dem Deaktivieren oder Löschen muss der gesamte Erweiterungshost neu gestartet werden.

Das ist kein Problem, das nur VSCode betrifft. Die Arbeit weist darauf hin, dass fast alle Plugin-Architekturen solche Mängel aufweisen, lediglich in unterschiedlichem Ausmaß.

In einem gewöhnlichen Plugin-System ist dies bereits lästig, aber wenn die einzigen Kosten ein Neustart sind, ist es noch akzeptabel.

Im Kontext von Agenten ist dies jedoch ein ganz anderes Problem.

Ein regulärer Agent ist normalerweise vollgestopft mit vielen Dingen: Werkzeugsammlungen, Ausführungsumgebungen, Zugriffssteuerungen, Sandboxen, Sitzungsstatus, Gedächtnissystemen … er ist an sich schon ein extrem komplexes Ingenieursystem.

Und jetzt trifft er auf das „selbstevolvierende KI“-Wesen, das wie Sun Wukong ist — ein kleiner Fehler kann dazu führen, dass es sich selbst versehentlich vollständig verändert.

Genau hier setzt DeepSeeks Arbeit bei der Selbstevolution an:

Zukünftige Agenten können je nach Aufgabe selbst ein Werkzeug generieren, es in die Laufzeitumgebung einfügen und es bei Problemen selbst wieder ersetzen.

Wenn man bei jeder Änderung einer Codezeile den gesamten Prozess neu starten muss, können der zuvor angesammelte Kontext und alle Caches vollständig abstürzen.

Dies wird als zeitliche Zusammensetzbarkeit bezeichnet.

Wenn die Abhängigkeiten zwischen Modulen dadurch verwaltet werden, dass jedes Modul selbst Patches anwendet, heute nach der Existenz von A prüft und morgen nach B sucht … kann man leicht zyklische Abhängigkeiten einfügen, die beim Neuladen zu schwerwiegenden Fehlern führen.

Dies wird als räumliche Zusammensetzbarkeit bezeichnet.

Und diese zwei Schwierigkeiten sind genau die zwei Probleme, die Cordis lösen soll.

Der Lösungsansatz von DeepSeek

Zuerst müssen zwei mathematische Grundlagen ergänzt werden, die auch die zwei theoretischen Säulen dieser Arbeit sind —

Effekt und Koeffekt.

Einfach ausgedrückt beschreibt Effekt „den Einfluss des Programms auf die Welt“; Koeffekt beschreibt „die Einschränkungen der Welt auf das Programm“. Die beiden stehen in einer dualen Beziehung: Effektsysteme bereichern die Typen, Koeffektsysteme bereichern den Kontext.

Aber es gibt ein Problem: Im Kontext von selbstevolvierender KI wird das Framework dynamisch geladen.

Klassische Effekte/Koeffekte sind Werkzeuge statischer Typsysteme.

Um beide Hürden im Bereich Zeit und Raum zu überwinden, hat das Team diese beiden Konzepte für die Agenten-Laufzeit angepasst und aufgerüstet — zu „umkehrbaren Effekten“ und „reaktiven Koeffekten“.

Umkehrbare Effekte (revertible effects) zielen auf die Zeitdimension ab.

Die Kernaussage lautet nur: Jede Änderung des Kontexts muss mit einer expliziten Umkehrfunktion versehen sein, sodass die Nebeneffekte umkehrbar sind.

Beim Laden eines Plugins wird bei jeder Statusänderung die entsprechende Umkehrfunktion aufgezeichnet und nacheinander zu einer „Widerrufungskette“ zusammengesetzt.

Beim Entladen des Plugins wird diese Kette rückwärts ausgeführt, sodass der Systemstatus exakt auf den Zustand vor dem Laden des Plugins zurückgesetzt wird.

Man kann es sich wie einen Stapel Teller vorstellen: Der zuletzt aufgelegte Teller wird zuerst herausgenommen.

Auf diese Weise wird die zeitliche Reihenfolge nicht durcheinandergebracht.

Die reaktiven Koeffekte (reactive coeffects) sind für die Raumdimension zuständig.

In Cordis können Komponenten deklarieren, welche Abhängigkeiten sie benötigen, sodass die Abhängigkeiten auflösbar sind.

Beispielsweise kann ein Chat-Plugin angeben, dass es einen Nachrichtenadapter und eine Datenbank benötigt. Erst wenn beide Abhängigkeiten erfüllt sind, wechselt es in den ACTIVE-Zustand. Fehlt eine Bedingung, bleibt es im INACTIVE-Zustand, startet nicht vorzeitig und läuft auch nicht erst los, um dann wegen eines Null-Verweises einen Fehler zu werfen.

Wenn ein Anbieter verfügbar wird, wird der Abhängige automatisch aktiviert. Wenn der Anbieter entfernt wird, hält der Abhängige zuerst an, und nachdem er seine eigenen Effekte zurückgezogen hat, schließt der Anbieter den Entladevorgang ab.

Wenn die Abhängigkeitsanbieter entladen werden, werden die Abhängigen automatisch deaktiviert; wenn die Abhängigkeiten wieder online gehen, werden die Abhängigen automatisch wiederhergestellt. Diese Topologie-Orchestrierung wird nicht manuell von Entwicklern geschrieben, sondern automatisch aus den Deklarationen abgeleitet.

Die Kombination der beiden bildet das Kernstück von Cordis.

Die anschauliche Bedeutung des Begriffs „räumlich-zeitliche Zusammensetzbarkeit“ im Titel der Arbeit liegt genau hier.

Koishi

Also, wurden all diese oben genannten Punkte bereits in der Praxis validiert?

Ja.

Und der Umfang ist nicht gering.

Für die experimentelle Validierung in der Arbeit wird ein Chatbot-Framework namens Koishi verwendet.

Koishi wird auf Basis von Cordis erstellt und hat in vier Jahren über 4000 Community-Plugins angesammelt, die Instant-Messaging-Adapter, Datenbanktreiber, Verwaltungskonsolen und verschiedene Benutzerfunktionen abdecken.

Laut GitHub ist Koishi ein plattformübergreifendes, erweiterbares und leistungsstarkes Chatbot-Framework.

Sein Name und sein Ikonendesign stammen von der Figur Komeiji Koishi aus dem Werk Touhou Project.

Komeiji Koishi ist eine Figur, die unbewusste Handlungen ausführt. Dieser Name symbolisiert sowohl das Thema des Chatbots, als auch die Leidenschaft, die die Entwickler hineingesteckt haben.

Das ist eine sehr interessante README-Datei.

Also was ist Cordis genau?

Laut dem Autor von Koishi stammt der Name Cordis aus dem lateinischen Wort für „Herz“, und alles in Koishi beginnt mit Cordis.

Als Metaframework ist Cordis nicht an irgendeinen spezifischen Bereich oder Anwendungsfall gekoppelt.

Die Funktionen, die es bietet, sind für die meisten Frameworks nichts Besonderes — ein Plugin-System, aber hinter diesem System steht ein Ziel, das die meisten Frameworks nicht erreicht haben: Umkehrbarkeit.

Er hat auch diesen Satz hinterlassen:

Ich hoffe, dass es das Kernstück zukünftiger Software wird (zumindest der Software, die ich entwickle).

Vier Jahre später liefert diese Arbeit von DeepSeek den entsprechenden Nachweis.

Zuerst die Validierung in der Zeitdimension.

In Koishi kann ein Administrator ein Plugin über die Konsole deaktivieren, der Einfluss des Plugins auf das System wird sofort zurückgesetzt, und andere Plugins arbeiten weiter.

Während der Entwicklung wird das geänderte Plugin nach der Modifikation und Speicherung neu angewendet, während Caches und Verbindungen unverändert bleiben.

Anschließend die Validierung in der Raumdimension.

In der Koishi-Ökologie bieten IM-Adapter den Zugang zu Nachrichtenplattformen, Datenbanktreiber bieten persistente Speicherung, und Funktionsplugins deklarieren diese als Abhängigkeiten, um direkt darauf zuzugreifen.

Während des tatsächlichen Betriebs wird beim Wechsel des Speicher-Backends oder beim Wiederverbinden des Adapters nur das Plugin neu aktiviert, bei dem sich die Abhängigkeit tatsächlich geändert hat, während Plugins mit unveränderten Abhängigkeiten völlig unbeeinflusst bleiben.

Man muss wissen, dass diese Plugins normalerweise von verschiedenen Autoren unabhängig voneinander entwickelt werden, und die einzige Koordination zwischen ihnen sind die reaktiven Koeffekte, auf die Cordis Wert legt.

Das zeigt, dass ein Satz dynamischer Kompositionsregeln tatsächlich in einer offenen Plugin-Ökologie funktioniert, die von verschiedenen Autoren beigetragen wird.

Die Arbeit stellt diesen Fall aber nicht als perfektes Demo dar.

Das Team gibt zu, dass derzeit nur Validierungsdaten aus der einzigen Ökologie von Koishi und der einzigen Sprache TypeScript vorliegen, und kontrollierte Vergleiche mit alternativen Architekturen fehlen …

Aber das Wichtigste ist, dass sie eine neue Richtung aufzeigt: Eine grundlegende Einrichtung für Agent-Harness, die der Selbstevolution dient.

Das heute veröffentlichte DeepSeek Harness ist genau die aktualisierte Version von Koishi Cordis.

Vorstellung der Autoren der Arbeit

Zum Schluss sprechen wir wie üblich über die Autoren der Arbeit.

Es gibt insgesamt drei Autoren, die sowohl zur Peking-Universität als auch zu DeepSeek gehören.

Der Erstautor heißt Yifan Shi, er kommt von der Peking-Universität und ist zugleich Mitglied von DeepSeek.

Bei gründlicher Recherche stellt sich heraus, dass sein Name bereits im technischen Bericht von DeepSeek V3 erschienen ist.