Gerade eben hat DeepSeek Harness mit seiner bahnbrechenden Open-Source-Freigabe für Aufsehen gesorgt: Alles ist ein Plugin

Heute in den frühen Morgenstunden wurde die offizielle Version von DeepSeek V4 Pro veröffentlicht und löste eine Welle der Begeisterung aus. Jetzt, nach einem halben Tag, ist auch DeepSeek Harness (Entwicklervorschau) da!

Natürlich ist das keine Überraschung, schließlich hat das Projekt schon lange im Vorfeld geworben. Zum Beispiel hat Cui Tianyi vom DeepSeek Harness-Team in sozialen Netzwerken ständig Vorankündigungen veröffentlicht und Mitarbeiter für das Team rekrutiert.

Anfang August haben wir auch die Zugangsberechtigung für die interne Testphase von DeepSeek Harness erhalten und konnten schon früh von diesem Agent-Framework profitieren, das zweifellos neue Veränderungen in die KI-Gemeinschaft bringen wird.

Open-Source-Adresse: https://github.com/deepseek-ai/deepseek-harness

Zum Beispiel haben wir hier mit DeepSeek Harness, das mit dem offiziellen DeepSeek-V4-Flash ausgestattet ist, ein Ego-Zombie-Shooter-Spiel erstellt. Ohne dass wir zwischendurch eingegriffen haben, entstand in etwas mehr als 30 Minuten ein fertiges Produkt, das zwar nicht perfekt, aber schon recht spielbar ist.

Angesichts der Tatsache, dass Andrej Karpathys Ansatz zur Generierung von 3D-Welten mit KI in letzter Zeit sehr beliebt ist, haben wir DeepSeek Harness (V4-Flash) auch der Herausforderung des Benchmarks »Huaqiang kauft eine Wassermelone« gestellt: Die klassische Szene »Huaqiang kauft eine Wassermelone« soll anhand einer Textbeschreibung als 3D-Animation nachgebildet werden (ebenfalls das Ergebnis eines One-Shot-Prompts):

Insgesamt ist die Handlung dieser Animation zwar noch weit von Perfektion entfernt, aber weitgehend nachgebildet, und die Beziehungen zwischen den Figuren lassen sich auch grob erkennen. Im Vergleich dazu ist die Animation, die wir mit demselben Prompt und Codex, der mit GPT-5.6 sol-xhigh ausgestattet ist, erstellt haben, weitaus schlechter:

Man muss bedenken, dass die Parametergröße von DeepSeek-V4-Flash weit unter der von GPT-5.6 sol liegt. Es ist offensichtlich, dass DeepSeek Harness einen großen Beitrag dazu geleistet hat.

Heute, mit der Veröffentlichung der offiziellen Version von DeepSeek V4 Pro, haben wir dieses Modell auch an DeepSeek Harness angeschlossen und es noch einmal ausgeführt:

Das Ergebnis ist tatsächlich etwas besser.

Als Nächstes werfen wir einen Blick auf die Projektstruktur, die beeindruckend ist: Das Repository enthält bereits über 230 Workspace-Mitglieder, der Code verteilt sich auf Bereiche wie packages/, apps/, examples/, python/, native/, vendor/, website/ und mehr. Für fast jede Funktion – Dateisystem, Terminal, Subprozesse, PTY, Sprachenserver, Webzugriff, Fähigkeiten, Subagenten, Workflows, Planmodus, Sitzungspersistenz, Einstellungen, Anmeldeinformationen und Telemetrie – gibt es ein eigenes Paket.

Wenn man ein normales Agent-Projekt mit einem fertig installierten Computer vergleicht, ähnelt DeepSeek Harness eher einer Lochplatte mit beeindruckender Größe: Modelle, Tools, Schnittstellen, Speicher, Sicherheitsrichtlinien und Kontextverwaltung können alle aufgesteckt und auch wieder abgezogen werden.

Es bietet eine Standard-Baugruppenlösung, aber es ist offensichtlich, dass DeepSeek nicht einen fest geformten »DeepSeek-Programmierassistenten« schaffen möchte, sondern eine Methode zum Zusammenbauen von Agenten.

Was ist DeepSeek Harness?

Zuerst klären wir ein leicht zu verwechslendes Problem: DeepSeek Harness ist kein neues DeepSeek-Modell und auch kein reiner API-Client. Es ist ein Satz von SDKs und Anwendungsframeworks zum Erstellen, Ausführen und Erweitern von Agenten, standardmäßig kann es eine Verbindung zu DeepSeek-Modellen herstellen (andere Modelle lassen sich auch einfach individuell verbinden), sodass das Modell Projekte lesen, Dateien ändern, Befehle ausführen, Aufgaben verwalten, Unteraufgaben zuweisen und über Web-UI, Vollbild-Terminal, Headless-Befehle oder Automatisierungsprotokolle mit Benutzern interagieren kann.

Die Web-Oberfläche von DeepSeek Harness bietet einen praktischen Eingang zur direkten Konfiguration anderer Modelldienste, ohne dass Benutzer Konfigurationsdateien manuell bearbeiten müssen

In der heutigen KI-Gemeinschaft ist der Begriff »Harness« nicht mehr unbekannt. Seine ursprüngliche Bedeutung bezieht sich auf Pferdegeschirre, Kabelbäume und Rückhaltevorrichtungen. Abstrahiert betrachtet hat er die Funktion, Kraft mit einer funktionierenden Einheit zu verbinden und gleichzeitig zu verhindern, dass diese Kraft außer Kontrolle gerät. Im Bereich der KI ist Harness dafür verantwortlich, das Modell mit Dateisystemen, Shells, Code-Editoren, Webseiten und anderen Agenten zu verbinden, gleichzeitig aufzuzeichnen, was es tut, seine Handlungsmöglichkeiten einzuschränken und bei Fehlern zu entscheiden, ob der Vorgang wiederholt, abgebrochen, der Kontext komprimiert oder das Problem an den Benutzer zurückgegeben wird.

Das erklärt möglicherweise auch, warum die Code-Menge und die Anzahl der Pakete in diesem Projekt so groß sind: Schließlich gibt es sehr viele zugehörige Aufgaben und Tool-Optionen, darunter ob Tool-Aufrufe parallel ausgeführt werden können, ob Abbruchbefehle Subprozesse wirklich stoppen können, ob Tool-Ergebnisse den Kontext beeinträchtigen, wohin neue Nachrichten eingefügt werden sollen, die der Benutzer während der Ausführung des Modells sendet, wie die Modelleingabe zum Zeitpunkt der Wiederherstellung der Sitzung neu erstellt wird, welche Tools Subagenten zur Verfügung stehen und ob Schreibvorgänge in Dateien den Arbeitsbereich verlassen oder ob der Inhalt, der bei der Wiedergabe der Oberfläche angezeigt wird, mit dem Echtzeitablauf übereinstimmt.

DeepSeek Harness versucht, all diese Probleme zu offiziellen Systemfähigkeiten zu machen.

Alles ist ein Plugin

Das auffälligste Designprinzip von DeepSeek Harness ist »Alles ist ein Plugin«, selbst die Agent-Loop selbst wird als Plugin betrachtet.

Das Projekt baut auf dem Mikrokern von Cordis auf. Ein laufendes Harness ist im Wesentlichen ein Cordis-Context. Verschiedene Pakete registrieren Dienste, Ereignisse und Fähigkeiten beim Context, und schließlich werden sie durch Konfigurationsdateien zu einem lauffähigen Agenten zusammengesetzt.

packages/core/ ist der Kern des gesamten Systems und enthält Session, System Prompt, Tools, Agent und Agent Loop. Sie lösen die grundlegendsten Probleme: Was eine Sitzung ist, wie Systemprompts zusammengesetzt werden, wie Tools registriert und aufgerufen werden, wie Agenten erstellt werden und wie eine Gesprächsrunde von der Benutzereingabe über die Modellanfrage, die Tool-Ausführung bis zur endgültigen Antwort gelangt.

Außerhalb des Kerns gibt es eine große Anzahl von Funktionspaketen:

• packages/llm/ ist für Modelladapter und Stream-Ausgabe zuständig;
• packages/shell/, packages/subprocess/ und packages/terminal/ sind für einmalige Befehle, Prozessbäume und dauerhafte Terminals zuständig;
• packages/fs/ ist für das Lesen, Schreiben, Bearbeiten und Suchen von Dateien sowie für Richtlinienbeschränkungen zuständig;
• packages/lsp/ verbindet den Sprachenserver, sodass der Agent nicht nur Textsuchen durchführen, sondern auch semantische Code-Navigation erhalten kann;
• packages/web/ ist für die Suche und das Web-Scraping zuständig;
• packages/skill/ verwaltet wiederverwendbare Fähigkeiten;
• packages/subagent/ und packages/workflow/ erweitern den einzelnen Agenten zu einem multiagenten System, das delegiert und orchestriert werden kann.

Wenn man weiter nach außen blickt, sind Planung, Ziele, Aufgabenlisten, Hintergrundaufgaben, Kontextkompression, Sitzungsabfragen, Sitzungstitel, Anmeldeinformationen, Benutzereinstellungen, Genehmigungsmechanismen und Telemetrie ebenfalls in unabhängige Funktionen unterteilt. Das Interessanteste an dieser Struktur ist, dass sie eine fast hartnäckige Grenzbewusstsein widerspiegelt: Wer die Schnittstelle besitzt, wer die Implementierung verantwortet und wer die Fähigkeit dem Modell präsentiert, sollte möglichst nicht vermischt werden.

In der Projektdokumentation werden typische Funktionen in drei Ebenen unterteilt: Schnittstelle, Implementierung und Verbraucher.

Am Beispiel von Bash: Die Schnittstelle definiert, was »Befehl ausführen« bedeutet, die lokale Implementierung ist für die tatsächliche Erstellung des Prozesses zuständig, und das Toolkit für das Modell wandelt diese Fähigkeit in ein vom Modell verständliches Schema und Ergebnis um. Wenn die lokale Shell in Zukunft durch einen Remote-Container, eine Cloud-Sandbox oder eine Unternehmensausführungsplattform ersetzt werden soll, muss theoretisch nur die Implementierungsebene ausgetauscht werden, ohne dass Modell-Tools und Agent-Loop neu geschrieben werden müssen.

Das ist ein typisches Framework-Denken. Es lässt das Repository in der frühen Phase groß erscheinen, zeigt aber auch, dass das Ziel von DeepSeek Harness nicht ein fertiges Produkt ist, das nur vom offiziellen Team gewartet werden kann. Stattdessen sollen verschiedene Bereitsteller Modelle austauschen, Speicher austauschen, Sicherheitsrichtlinien ändern, Tools hinzufügen und sogar die Agent-Loop ersetzen können.

Hier sehen wir auch das echte Open-Source-Prinzip, an dem DeepSeek seit jeher festhält!

cordis.yml

Eine Konfiguration zum Zusammenbau verschiedener Agenten

Das pluginbasierte Architektur erreicht Entwickler schließlich über cordis.yml. Die Konfigurationsdatei listet Plugin-Namen, stabile IDs und Parameter auf und bestimmt, welche Gruppe von Fähigkeiten der aktuelle Agent besitzt.

Derselbe Code kann zu völlig unterschiedlichen Produktformen zusammengesetzt werden. Mit dem DeepSeek-LLM-Adapter, Dateisystem, Bash und TUI erhält man einen programmierten Agenten im Terminal; wenn die Benutzeroberfläche durch ein Web-Plugin ersetzt wird, erhält man eine Browser-Anwendung; mit dem Headless-Eingang akzeptiert er eine Aufgabe, führt die Runden von Modell und Tools aus und beendet den Vorgang nach der Ausgabe der Antwort; wenn er durch einen ACP- oder JSON-RPC-Vordereingang ersetzt wird, kann er zu einem Automatisierungsdienst werden, der von anderen Programmen gesteuert werden kann.

Die Konfiguration unterstützt auch Überlagerungsebenen. TUI und Web UI können eine gemeinsame Basiskonfiguration nutzen und dann ihre jeweiligen Oberflächen-Plugins und Parameter überlagern; die persönliche Konfiguration befindet sich auf der letzten Ebene. Auf diese Weise müssen Bereitsteller nicht den gesamten Konfigurationsbaum kopieren, sondern nur die angegebenen Plugins ersetzen. Es gibt jedoch ein Detail zu beachten: Konfigurations-Patches ersetzen die gesamte Konfiguration des Ziel-Plugins, nicht eine tiefe Zusammenführung. Wenn nur ein neues Feld geschrieben wird, können die ursprünglichen API-Schlüssel, Basisadressen oder andere