DeepSeek Harness: Wenn wirklich alles ein Plugin ist

Bei KI-Agenten sprechen wir fast immer zuerst über das Modell. Welches Modell schreibt den besseren Code? Welches versteht längere Kontexte? Welches löst mehr Aufgaben in einem Benchmark? Das ist verständlich, greift aber inzwischen zu kurz. Ein Agent besteht nicht nur aus einem Sprachmodell. Er braucht Werkzeuge, Speicher, Sitzungen, Berechtigungen, eine Laufzeitumgebung, Planung, Protokollierung und irgendeine Oberfläche, über die Menschen eingreifen können.

Genau deshalb finde ich die Developer Preview von DeepSeek Harness so spannend. DeepSeek fasst die Idee in einen bemerkenswert klaren Satz: Everything is a plugin. Nicht nur zusätzliche Tools sollen austauschbar sein. Auch Modelle, Skills, Sessions, Sandboxes, Storage, Agentenschleifen, Scheduling und selbst die Benutzeroberfläche werden als Plugins behandelt.

Das klingt zunächst wie eine technische Designentscheidung für Entwickler. Tatsächlich steckt darin aber eine grössere Aussage über die nächste Phase der KI. Wenn die Intelligenz aus dem Modell kommt, die praktische Arbeitsfähigkeit aber aus dem Harness, dann darf diese zweite Hälfte nicht zu einem undurchsichtigen Block eines einzelnen Anbieters werden.

Der Agent ist mehr als sein Modell

DeepSeek beschreibt die Formel selbst sehr knapp: Agent gleich Modell plus Harness. Das Modell verarbeitet Sprache und erzeugt Entscheidungen. Das Harness verbindet es mit der realen Umgebung. Es stellt Dateien bereit, registriert Tools, verwaltet Zustände, startet Unteragenten, führt Befehle aus und entscheidet, welche Informationen beim nächsten Modellaufruf wieder im Kontext landen.

Ein Harness ist damit nicht einfach die Verpackung um ein Modell. Es bestimmt, was aus einer Modellantwort überhaupt werden kann. Darf der Agent nur Text ausgeben, oder darf er eine Datei verändern? Sieht er das ganze Repository oder nur einen Arbeitsordner? Läuft ein Befehl direkt auf dem Host, in einem Container oder auf einer entfernten Sandbox? Muss ein Mensch eine Aktion freigeben? Bleibt der Zustand über mehrere Sitzungen erhalten? All das sind keine Eigenschaften des Modells, sondern Entscheidungen der Laufzeit darum herum.

Vom Antworten zum Handeln

In einem einfachen Chat fällt diese Trennung kaum auf. Eine Frage geht hinein, eine Antwort kommt zurück. Sobald ein Agent aber an einem Repository arbeitet, Tickets bearbeitet, auf interne Systeme zugreift oder länger laufende Aufgaben übernimmt, wird das Harness mindestens so wichtig wie das Modell. Es übersetzt eine sprachliche Absicht in eine Folge realer Schritte und führt deren Ergebnisse wieder als neuen Kontext zum Modell zurück.

Genau dort entscheidet sich, ob aus beeindruckender Demo-Technik ein verlässliches Werkzeug wird. Ein sehr gutes Modell mit schlechtem Kontext, zu breiten Rechten und unzuverlässiger Sitzungsverwaltung bleibt ein schlechter Agent. Es kann brillant argumentieren und trotzdem die falsche Datei bearbeiten, einen veralteten Zustand verwenden oder bei einem Fehler nicht sauber weiterarbeiten. Umgekehrt kann ein etwas schwächeres Modell in einer gut gebauten Laufzeit erstaunlich nützlich sein, weil es die richtigen Werkzeuge sieht, klare Grenzen hat und seine Arbeit nachvollziehbar bleibt.

Die Architektur wird Teil des Ergebnisses

DeepSeek Harness macht diese Schicht sichtbar. Der Cordis-Kernel montiert Plugins, löst Abhängigkeiten auf und kann Komponenten wieder entfernen. Fähigkeiten werden als Services bereitgestellt. Ein Plugin kann beispielsweise eine Shell implementieren, ein anderes macht diese Shell als Modell-Tool verfügbar, und ein drittes konsumiert das Tool in einem Workflow. Die konkrete Implementierung kann über die Konfiguration gewechselt werden, ohne den ganzen Harness umzubauen.

DeepSeek geht dabei weiter als viele Plattformen, die lediglich ein paar zusätzliche Tools als Erweiterung zulassen. Auch die Modellanbindung, die Tool-Registry, das Session-Log und die Agentenschleife selbst sind Plugins. Laut Architektur gibt es keinen privilegierten Kern, der für jede Erweiterung gepatcht werden müsste. Neues Verhalten wird neben den vorhandenen Komponenten montiert und kann beim Entfernen seine Registrierungen wieder sauber abbauen.

Das ist keine völlig neue Idee. Betriebssysteme, Browser, Editoren und Plattformen leben seit Jahrzehnten von modularen Komponenten. Neu ist, wie konsequent DeepSeek dieses Prinzip auf einen vollständigen KI-Agenten überträgt. Die Architektur des Agenten wird dadurch nicht mehr als festes Produkt akzeptiert, sondern als Zusammenstellung von Entscheidungen, die ein Betreiber verändern kann.

Warum „alles ist ein Plugin“ so reizvoll ist

Die Plugin-Idee verschiebt die Macht von einem fertigen Produkt hin zu einer zusammensetzbaren Laufzeit. Ich kann einen Modellanbieter ersetzen, ohne meine komplette Arbeitsweise neu zu bauen. Ich kann eine lokale Shell gegen eine stärker isolierte Variante tauschen. Ich kann einen anderen Speicher, eine andere Sitzungslogik oder eine eigene Oberfläche einsetzen. DeepSeek dokumentiert neben dem eigenen Modellzugang auch weitere Anbieter und benutzerdefinierte OpenAI-kompatible Endpunkte.

Modellwechsel ohne kompletten Neuanfang

Damit wird ein Agent eher zu einer Infrastruktur, die ich passend zu meinem Umfeld zusammenstelle. Ein kleines Entwicklerteam braucht vielleicht nur Dateizugriff, Git und Tests. Ein Security-Team will zusätzlich Netzwerkabfragen, isolierte Sandboxes, strengere Freigaben und unveränderbare Protokolle. Ein Unternehmen kann einen eigenen Modell-Gateway verwenden, während ein privates Lab ein lokales Open-Weight-Modell anspricht.

Das ist strategisch wichtig, weil Modelle derzeit sehr schnell wechseln. Heute überzeugt ein Anbieter beim Coding, morgen ein anderer bei langen Kontexten oder Werkzeugnutzung. In einem geschlossenen Produkt ist der Modellwechsel oft gleichzeitig ein Plattformwechsel. Sitzungen, Regeln, Berechtigungen, Integrationen und Arbeitsweisen müssen neu aufgebaut werden. In einer modularen Laufzeit kann das Modell dagegen eine Komponente bleiben, die gegen einen anderen Provider oder einen selbst betriebenen Endpunkt getauscht wird.

Völlig reibungslos ist das nicht. Modelle unterscheiden sich bei Rollenformaten, Reasoning, Tool-Aufrufen, Bildunterstützung und Fehlerverhalten. Diese Unterschiede müssen deshalb in den jeweiligen Adaptern sauber behandelt werden. Aber genau hier zeigt sich der Wert einer klaren Naht: Besonderheiten eines Anbieters ziehen sich nicht unkontrolliert durch das ganze Produkt.

Austauschbare Infrastruktur statt austauschbarer Knöpfe

Besonders interessant ist die Trennung von Definition, Anbieter und Nutzer einer Fähigkeit. Eine Bash-Schnittstelle beschreibt, was die Fähigkeit kann. Ein Provider entscheidet, wo und wie Befehle tatsächlich laufen. Erst ein weiteres Plugin macht daraus ein Tool, das das Modell aufrufen darf. Solche Nähte sind wichtig, weil sie Kontrolle an einer klaren Stelle ermöglichen. Dort lassen sich Zeitlimits, Isolation, Freigaben und Protokollierung einbauen, ohne jede Agentenschleife neu zu programmieren.

Das Potenzial wird deutlich, wenn mehrere Fähigkeiten dieselbe Ausführungswelt teilen. Werden Dateisystem und Prozesse von einer lokalen Umgebung in eine entfernte Sandbox verschoben, können Shell, Terminal und Code-Navigation gemeinsam dorthin folgen. Für den Nutzer bleibt die Fähigkeit ähnlich, während sich darunter der Sicherheits- und Betriebsrahmen grundlegend ändert. Genau diese Art Austauschbarkeit ist wertvoller als ein zusätzlicher Schalter in einer Oberfläche.

Auch die verschiedenen Laufzeitmodi zeigen, was DeepSeek vorhat. Der Standardmodus bringt den vollständigen Coding-Agenten mit. Im Code-Modus kann das Modell mehrere Tool-Aufrufe über generierten TypeScript-Code orchestrieren. Der Minimalmodus reduziert die Umgebung für Benchmarks auf Shell und Editor. Im Creator-Modus lassen sich Plugins und eigene Presets untersuchen. Nicht jeder Anwendungsfall muss dadurch dieselbe riesige Werkzeugkiste laden.

Profile und Bundles machen daraus mehr als eine lose Sammlung von Erweiterungen. Ein Profil kann eine definierte Agentenlaufzeit für einen bestimmten Zweck bilden. Denkbar ist ein schlankes Profil für lokale Entwicklung, ein stärker eingeschränktes Profil für Produktionssysteme und ein forensisches Profil, das besonders viel protokolliert. Die Fähigkeiten bleiben aus denselben Bausteinen zusammengesetzt, aber ihre Kombination und ihre Grenzen passen zum jeweiligen Risiko.

Wo das Potenzial praktisch entsteht

Die Architektur ist spannend, aber ihr Wert zeigt sich erst in konkreten Situationen. Ein Plugin-System ist kein Selbstzweck. Es muss erlauben, einen Agenten schneller an reale Anforderungen anzupassen, ohne für jeden Anwendungsfall eine neue Plattform zu bauen.

Vom persönlichen Werkzeug zur Firmenplattform

Ein einzelner Entwickler kann mit einer lokalen Shell, einem Dateieditor und einem Modell beginnen. Sobald daraus ein Teamwerkzeug wird, kommen andere Anforderungen hinzu: zentrale Identitäten, getrennte Workspaces, Freigaben für kritische Aktionen, ein Modell-Gateway, Kostenkontrolle, persistente Sitzungen und ein exportierbarer Audit-Trail. In einer monolithischen Anwendung entscheidet der Hersteller, ob und wann diese Funktionen kommen.

In einer modularen Laufzeit können Unternehmen fehlende Teile selbst ergänzen oder vorhandene Provider ersetzen. Der Agent muss dadurch nicht neu erfunden werden. Die gleiche Oberfläche und dieselbe Agentenlogik können hinter einem Unternehmens-Gateway andere Modelle nutzen, Befehle in einer internen Sandbox ausführen und Sitzungen in einem eigenen Storage ablegen. Das ist der Unterschied zwischen einem praktischen Tool und einer kontrollierbaren Plattform.

Unterschiedliche Vertrauenszonen aus denselben Bausteinen

Nicht jede Aufgabe verdient dieselben Rechte. Ein Agent, der Dokumentation zusammenfasst, braucht keine Produktionszugänge. Ein Agent für Incident Response benötigt vielleicht Logdaten und Netzwerkabfragen, darf aber keine Konfiguration verändern. Ein Agent für Deployment kann Änderungen ausführen, sollte dafür jedoch engere Freigaben, kürzere Tokens und eine besonders klare Protokollierung erhalten.

Mit sauber getrennten Services und Profilen lässt sich diese Differenzierung in der Laufzeit ausdrücken. Das Modell muss nicht jedes Sicherheitsdetail verstehen und freiwillig einhalten. Die Umgebung entscheidet technisch, welche Fähigkeiten überhaupt vorhanden sind. Für Security ist das ein zentraler Punkt: Eine nicht montierte Fähigkeit steht dem Modell gar nicht erst als direktes Werkzeug zur Verfügung.

Ein Ökosystem für Spezialisten

Kein einzelner Anbieter wird die beste Sandbox, den besten Session-Store, jedes Unternehmenssystem und alle Modelladapter gleichzeitig bauen. Ein offenes Plugin-Modell erlaubt Spezialisten, genau eine Schicht gut zu lösen. Ein Security-Anbieter könnte eine gehärtete Ausführungsumgebung bereitstellen. Ein Storage-Projekt könnte revisionssichere Sitzungen liefern. Ein internes Plattformteam könnte Freigaben und Identitäten an die eigene Organisation anbinden.

Wenn diese Komponenten über stabile Schnittstellen zusammenpassen, entsteht ein Ökosystem statt einer immer grösseren Einzelanwendung. Das ist vermutlich das grösste Potenzial von DeepSeek Harness. DeepSeek muss nicht alle Anwendungsfälle gewinnen. Es genügt, wenn die Architektur zum Ort wird, an dem andere ihre Fähigkeiten anbieten und kombinieren.

Nachvollziehbarkeit ist kein Nebendetail

Der zweite starke Gedanke neben den Plugins ist das append-only Session Log. Laut DeepSeek wird alles, was das Modell sieht, als Ereignis festgehalten. Dazu gehören Systemanweisungen, Tool-Aufrufe und Ergebnisse, Kontextinjektionen sowie die Planung von Unteragenten. Fortsetzen, Abzweigen, Suchen und Wiederholen basieren auf demselben Ereignisstrom.

Für Entwickler ist das praktisch, weil sich ein fehlerhafter Lauf rekonstruieren lässt. Für Security und Betrieb ist es noch wichtiger. Wenn ein Agent eine Datei verändert, einen Befehl startet oder Daten an einen Dienst sendet, brauche ich mehr als die letzte Chatnachricht. Ich muss nachvollziehen können, welcher Kontext vorlag, welches Tool beteiligt war und an welcher Stelle eine Entscheidung in eine Aktion überging.

Bei klassischen Anwendungen lässt sich ein Fehler häufig auf eine Eingabe und einen deterministischen Codepfad zurückführen. Bei Agenten ist das schwieriger. Ein Modell kann aus demselben groben Auftrag unterschiedliche Zwischenschritte ableiten, Werkzeuge in anderer Reihenfolge verwenden und auf unerwartete Ergebnisse reagieren. Ohne vollständige Historie bleibt am Ende nur die Behauptung, der Agent habe etwas entschieden. Das reicht weder für Debugging noch für einen Sicherheitsvorfall.

Die Entscheidung, den Ereignisstrom zur Quelle der Wahrheit zu machen, schafft noch eine zweite Möglichkeit: besser vergleichbare Experimente. Eine Sitzung kann an einem bestimmten Punkt abgezweigt und mit einem anderen Modell, einem veränderten Prompt oder anderen Fähigkeiten fortgesetzt werden. Damit lässt sich nicht nur vergleichen, welches Modell die schönere Antwort schreibt. Man kann untersuchen, wie sich eine konkrete Änderung auf denselben realen Arbeitsstand auswirkt.

Für Unternehmen könnte daraus langfristig eine Art Change- und Incident-Protokoll für Agenten entstehen. Wer hat den Auftrag erteilt? Welche Richtlinie war aktiv? Welche Daten bekam das Modell? Welche Aktion wurde freigegeben? Welches Ergebnis kam zurück? Diese Fragen werden wichtig, sobald Agenten nicht mehr nur beraten, sondern Änderungen an echten Systemen auslösen.

Ein Log ist allerdings noch kein fertiger Audit-Trail. Aufbewahrung, Zugriffsschutz, Integrität, sensible Inhalte und Export müssen weiterhin sauber gelöst werden. Ein vollständiges Protokoll kann selbst zum Risiko werden, wenn es Prompts, Quellcode, Tool-Ergebnisse oder Zugangsdaten enthält. Trotzdem gefällt mir die Grundentscheidung: Modell sichtbare Informationen sollen nicht aus irgendeinem versteckten Seiteneingang kommen, sondern aus einem rekonstruierbaren Ereignisstrom.

Open Source wird zur strategischen Waffe

Dass dieses Projekt aus China kommt, macht die Sache noch interessanter. DeepSeek veröffentlicht nicht nur Modellgewichte, sondern baut inzwischen sichtbar an mehreren Schichten des Stacks. DeepSeek V4 steht mit Gewichten und Code unter der MIT-Lizenz bereit. Nun kommt mit dem ebenfalls MIT-lizenzierten Harness eine offene Laufzeit für agentische Arbeit dazu. Darunter liegt mit Cordis sogar ein eigenes Plugin- und Kompositionsmodell.

Das passt zu einer Entwicklung, die ich bereits in meinem Artikel über KI, Sicherheit und den Kampf um den vollständigen Stack beschrieben habe. China will bei KI nicht nur Anwendungen konsumieren. Chinesische Unternehmen bauen Modelle, Inferenzsoftware, Hardwarepfade und nun auch die Agenteninfrastruktur darüber. DeepSeek zeigt dabei ein Tempo, das man im Westen nicht mehr mit dem alten Bild einer blossen Kopierindustrie erklären kann.

Open Source ist in diesem Rennen nicht nur Idealismus. Es ist Distribution, Vertrauen durch Prüfbarkeit und ein Beschleuniger für ein Ökosystem. Wer Gewichte, Code und Schnittstellen freigibt, lädt Entwickler weltweit dazu ein, Fehler zu finden, Integrationen zu bauen und das eigene Design zum De-facto-Standard zu machen. Ein offener Harness kann für DeepSeek strategisch wertvoller sein als eine weitere geschlossene Chat-Oberfläche, weil er auch dann relevant bleibt, wenn darin Modelle anderer Anbieter laufen.

Das ist ein bemerkenswerter Punkt. DeepSeek baut eine Plattform, in der DeepSeek selbst austauschbar bleibt. Kurzfristig wirkt das fast widersprüchlich. Warum sollte ein Modellanbieter den Wechsel zu einem Konkurrenten erleichtern? Langfristig kann genau das die stärkere Position sein. Wenn Entwickler ihre Agenten, Plugins, Sicherheitsregeln und Sitzungen auf dieser Laufzeit aufbauen, wird das Harness zur gemeinsamen Infrastruktur. DeepSeek verliert vielleicht einzelne Modellaufrufe, gewinnt aber Einfluss auf die Architektur des gesamten Ökosystems.

Offenheit beschleunigt zudem Lernen. Bei einem geschlossenen Produkt bleibt die Weiterentwicklung der Kernarchitektur weitgehend beim Hersteller. Ein offenes Projekt wird von Nutzern in Umgebungen eingesetzt, die das ursprüngliche Team nie vollständig vorhersehen konnte. Daraus entstehen Fehlerberichte, neue Adapter, alternative Backends und Betriebswissen. Gerade in einem jungen Feld wie agentischer Software kann diese Rückkopplung wichtiger sein als ein perfekter erster Release.

Gerade darin liegt die clevere Seite des Plugin-Ansatzes. DeepSeek muss nicht jeden Speicher, jede Sandbox und jedes Unternehmenssystem selbst bauen. Es liefert eine Architektur, in die andere diese Fähigkeiten einsetzen können. Wenn das Ökosystem wächst, profitiert der Kern von jeder neuen Integration.

China baut nicht nur ein Modell, sondern einen Weg darum herum

Die geopolitische Bedeutung liegt deshalb nicht allein in Benchmarkwerten. Ein Land oder ein Wirtschaftsraum wird technologisch nicht souverän, nur weil irgendwo ein starkes Modell trainiert wurde. Es braucht Hardware, Inferenzsoftware, Entwicklungswerkzeuge, Schnittstellen, Betriebserfahrung und Entwickler, die darauf Produkte bauen. DeepSeek Harness ist ein weiterer Baustein in genau dieser Kette.

Das westliche Narrativ über chinesische Technologie hinkt dieser Entwicklung oft hinterher. Wer China weiterhin vor allem als günstigen Nachbauer betrachtet, übersieht die Geschwindigkeit, mit der dort eigene Architekturen veröffentlicht und globale Entwickler angesprochen werden. DeepSeek muss dafür nicht in jeder Kategorie dauerhaft führen. Es reicht, wenn das Unternehmen den Abstand klein hält, schnell iteriert und seine Arbeit so öffnet, dass andere darauf weiterbauen.

Der Abstand zu geschlossenen Spitzenmodellen schrumpft

Open-Weight-Modelle galten lange als interessante Alternative für Labs und Spezialfälle, während die wirklich starken Fähigkeiten bei wenigen geschlossenen Anbietern lagen. Dieses Bild hält immer schlechter. Die Lücke ist nicht in jeder Disziplin verschwunden, aber sie wird schneller geschlossen als viele erwartet haben.

DeepSeek stellt seine V4-Modelle in den eigenen Auswertungen direkt neben aktuelle geschlossene Spitzenmodelle. Je nach Benchmark liegt V4 Pro nahe an ihnen, erreicht vergleichbare Werte oder bleibt sichtbar zurück. Bei Software Engineering, Tool-Nutzung, Faktenwissen und sehr schwierigen Reasoning-Aufgaben gibt es kein einheitliches Resultat. Genau deshalb sollte man nicht aus einer einzelnen Tabelle den „Sieger“ bestimmen.

Der wichtigere Punkt ist die zeitliche Distanz. Fähigkeiten, die vor kurzer Zeit noch als exklusiver Vorsprung der grössten US-Labs galten, tauchen heute wenige Monate später in Modellen auf, deren Gewichte heruntergeladen, selbst betrieben und untersucht werden können. „Nur wenige Monate hinter den Topmodellen“ ist keine naturwissenschaftlich messbare Konstante. Es beschreibt aber ziemlich gut, wie kurz der Vorsprung geschlossener Systeme inzwischen wirken kann.

Damit verändert sich auch die wirtschaftliche Bedeutung eines Vorsprungs. Wenn ein geschlossenes Modell für eine bestimmte Aufgabe zehn Prozent besser ist, kann das entscheidend sein. Wenn ein offenes Modell aber gut genug ist, auf eigener Infrastruktur läuft und sich in die eigene Sicherheitszone integrieren lässt, kann die Gesamtrechnung trotzdem für das offene Modell sprechen. Kontrolle, Datenstandort, planbare Kosten und die Möglichkeit zur eigenen Anpassung sind Teil der Leistung, auch wenn sie in einem Benchmark nicht auftauchen.

Dabei darf man die Hardware nicht vergessen. Offen verfügbare Gewichte bedeuten nicht automatisch, dass ein 1,6-Billionen-Parameter-Modell bequem im Serverschrank läuft. DeepSeek V4 Pro ist ein enormes Mixture-of-Experts-Modell. Selbst wenn pro Token nur ein Teil der Parameter aktiv ist, bleiben Speicher, Inferenzkosten und Betrieb anspruchsvoll. Offenheit beseitigt also die Zugangsbarriere zum Code und zu den Gewichten, nicht die physische Realität grosser Modelle.

Trotzdem verändert schon die Existenz dieser Gewichte den Markt. Forschende können das Modell untersuchen. Anbieter können es auf eigener Infrastruktur bereitstellen. Communities können Quantisierungen und Laufzeitoptimierungen entwickeln. Unternehmen gewinnen zumindest eine Alternative zur vollständigen Abhängigkeit von einer einzelnen API.

Der Wettbewerb verschiebt sich dadurch. Rohes Modellwissen bleibt wichtig, aber der dauerhafte Wert liegt zunehmend auch in Datenpipelines, Evaluierungen, Laufzeit, Sicherheit, Distribution und der Einbindung in echte Prozesse. Ein offener Harness passt genau in diese Verschiebung. Wenn Modelle schneller austauschbar werden, gewinnt die Plattform, die ihnen zuverlässig Kontext, Werkzeuge und Grenzen gibt.

Offen bedeutet nicht automatisch vertrauenswürdig

Bei aller Begeisterung wäre es naiv, „Open Source aus China“ automatisch mit Souveränität gleichzusetzen. Wer den gehosteten DeepSeek-Dienst nutzt, sendet Daten weiterhin an einen externen Anbieter. Erst ein selbst betriebener Modellendpunkt und ein kontrollierter Harness verändern die Datenhoheit wirklich. Auch dann bleiben Herkunft, Build-Prozess, Abhängigkeiten und Updates Teil der Lieferkette.

Plugins verschärfen diese Verantwortung. Ein Plugin ist kein harmloses Theme. Es kann Tools registrieren, auf Services zugreifen und Code auf dem System ausführen. Die DeepSeek-Dokumentation warnt bei Installationen aus Git-Repositories ausdrücklich davor, dass freigegebene Build-Skripte ausserhalb der Agenten-Sandbox auf dem Host laufen können. Sie empfiehlt, nur vertrauenswürdige Quellen zuzulassen und Abhängigkeiten auf einen konkreten Commit festzulegen.

Das ist genau die richtige Warnung. Eine offene Plugin-Plattform schafft Austauschbarkeit, aber auch eine neue Supply Chain. Jeder zusätzliche Anbieter kann Zugriff auf Prompts, Dateien, Zugangsdaten oder ausführbare Werkzeuge erhalten. Ein kompromittiertes Plugin braucht keinen spektakulären Modell-Jailbreak, wenn es bereits legitimer Teil der Laufzeit ist.

Quellcode einsehen zu können ist ein Vorteil, aber noch keine Sicherheitsprüfung. Jemand muss den Code tatsächlich prüfen, Builds nachvollziehen, Versionen fixieren und Updates kontrollieren. Bei einem wachsenden Plugin-Ökosystem wird Herkunft deshalb fast so wichtig wie Funktion. Ein nützliches Plugin aus unbekannter Quelle kann ein grösseres Risiko sein als eine fehlende Funktion.

Für einen ernsthaften Betrieb würde ich deshalb nur wenige, geprüfte Plugins einsetzen. Versionen gehören fixiert, Berechtigungen getrennt, Secrets ausserhalb der Konfiguration verwaltet und ausgehende Verbindungen kontrolliert. Sandboxes müssen tatsächlich isolieren und nicht nur so heissen. Das Session Log sollte geschützt und auf sensible Daten geprüft werden. Vor allem darf die Aussage „alles ist ein Plugin“ nicht in „jedes Plugin darf alles“ enden.

Das langfristige Potenzial hängt daher auch an Governance. Eine gute Plattform braucht verständliche Herkunftsnachweise, signierte Artefakte, reproduzierbare Builds, klare Abhängigkeiten und eine Möglichkeit, Fähigkeiten pro Profil einzuschränken. Wenn DeepSeek und die Community diese langweiligen Grundlagen ernst nehmen, kann Offenheit zu echter Kontrolle führen. Wenn nicht, wird aus dem Plugin-Versprechen lediglich eine sehr grosse Angriffsfläche.

Was ich von DeepSeek Harness sehen möchte

DeepSeek nennt das Projekt bewusst eine Developer Preview und kündigt inkompatible Änderungen an. Das ist ein guter Zeitpunkt zum Lesen, Experimentieren und für Tests mit unkritischen Daten. Es ist noch kein Grund, zentrale Produktionsabläufe davon abhängig zu machen.

Spannend wird, ob aus der sauberen Architektur ein belastbares Ökosystem entsteht. Dazu gehören signierte Releases, nachvollziehbare Herkunft von Plugins, klare Berechtigungsmodelle, reproduzierbare Builds und ein Update-Prozess, der nicht bei jedem Wechsel Vertrauen verlangt. Ebenso wichtig ist die Frage, wie gut sich Plugins unterschiedlicher Anbieter wirklich kombinieren lassen, wenn das Projekt schnell weiterentwickelt wird.

Ich möchte auch sehen, ob die versprochene Austauschbarkeit im Alltag hält. Ein Modelladapter lässt sich auf dem Papier leicht wechseln. In der Praxis unterscheiden sich Modelle bei Tool-Aufrufen, Reasoning, Kontextformaten, Bildunterstützung und Fehlermodi. Eine offene Schnittstelle reduziert diese Unterschiede, sie lässt sie nicht verschwinden.

Trotz dieser Vorbehalte ist DeepSeek Harness für mich eines der interessanteren KI-Projekte dieses Jahres. Nicht weil es bereits der beste Coding-Agent sein muss. Spannend ist, dass ein chinesisches KI-Unternehmen die Schicht oberhalb des Modells offenlegt und daraus ein Baukastensystem macht. Während andere Anbieter ihre Agenten immer tiefer in geschlossene Plattformen integrieren, setzt DeepSeek auf eine Architektur, in der sogar das eigene Modell nur ein austauschbares Plugin ist.

Mein Eindruck und das unglaubliche Tempo

Schon die Developer Preview zeigt mir viel Potenzial. Die Oberfläche macht das Plugin-Prinzip greifbar, und die Trajectory-Ansicht zeigt, dass Nachvollziehbarkeit nicht erst nachträglich eingebaut werden soll. Noch ist das Projekt jung und vieles bewegt sich, aber gerade diese offene Architektur wirkt wie eine Grundlage, auf der sehr schnell etwas Grosses entstehen kann.

Im Moment passiert in der KI-Welt so viel, dass selbst ein paar Wochen Abstand alt aussehen können. Wen wundert es, wenn allein Alphabet für 2026 Kapitalausgaben von 175 bis 185 Milliarden Dollar erwartet und Meta weitere 115 bis 135 Milliarden, in beiden Fällen stark geprägt von KI-Infrastruktur? Hunderte Milliarden fliessen plötzlich in dieselbe Idee, denselben Wettbewerb und dieselbe Zukunft.

Dieses Kapital garantiert keine guten Produkte. Es erklärt aber, weshalb Modelle, Rechenzentren und Agentenplattformen in einem Tempo vorankommen, das vor wenigen Jahren unmöglich wirkte. Modelle werden austauschbarer, offene Gewichte holen schnell auf, und die entscheidende Differenzierung wandert in den Harness. DeepSeek gibt bei allen drei Themen sichtbar Gas. Wer KI-Infrastruktur baut, sollte das nicht nur als chinesische Konkurrenzgeschichte lesen, sondern als Einladung, die eigene Abhängigkeit von geschlossenen Stacks neu zu bewerten.

Bis zum nächsten Mal,
Euer Joe