KI-Agenten-Harnesses: drei Repositories mit unterschiedlichen Aufgaben

Wer KI-Agenten-Harnesses für das eigene Unternehmen oder für MSP-Kunden prüft, sollte diese drei Repositories getrennt betrachten. DeepSeek Harness beschreibt eine Plugin-basierte Architektur. Anatomy stellt eine Skill zum Erstellen interaktiver technischer Grafiken vor. OpenClaw dokumentiert einen Assistenten, der auf den Geräten der Nutzer läuft und mit Messaging-Kanälen verbunden ist. Die Projekte sind Ausgangspunkte für unterschiedliche Fragen – keine gemeinsame Funktionsliste.

KI-Agenten-Harnesses: die Grenzen der drei Repositories

deepseek-ai/deepseek-harness. Das README stellt DeepSeek Harness als Open-Source-Agent-Harness vor. Es beschreibt eine auf Cordis basierende everything-is-a-plugin-Architektur. Das ist die Architekturbeschreibung des Repositorys. Für sich genommen sagt sie weder, welche Komponenten sich austauschen lassen, noch, wie jede einzelne Integration funktioniert.

Das README weist außerdem darauf hin, dass DeepSeek Harness in der Developer Preview ist und Änderungen die Kompatibilität beeinträchtigen können. Für den lokalen Start dokumentiert es den Befehl npx @deepseek-ai/dsh web, der eine Web-UI startet. Vor der Ausführung fordert es dazu auf, einen Sicherheitshinweis zu lesen. Dessen Inhalt gehört nicht zu den hier ausgewerteten Quellen.

Empfehlung: Wer DeepSeek Harness für ein Projekt bewertet, sollte die getestete Version festhalten und prüfen, wie sich Updates auf den eigenen Prototyp auswirken. Prüffrage: Welche Erweiterungspunkte braucht der konkrete Anwendungsfall, und wo sind sie dokumentiert? Die Architekturformel im README hilft bei der Orientierung, ersetzt diese Prüfung aber nicht.

Anatomy: eine Skill für eine konkrete Aufgabe

wheresryan22/anatomy. Das README stellt Anatomy als Skill für Claude vor, die eine Idee anhand eines funktionsfähigen Objekts erklärt. Es nennt auch OpenCode und Codex als Einsatzmöglichkeiten. Das Repository beschreibt interaktive isometrische Grafiken und unterscheidet zwischen SVG-Ausgaben, SVG-Grafiken mit WebGL und einem als Beta bezeichneten 3D-Modus. Für den SVG-Modus nennt es als Ausgabeformate eine eigenständige HTML-Seite, eine SVG-Datei sowie React- oder Next.js-Komponenten.

Entscheidend ist hier die dokumentierte Aufgabe: eine interaktive Darstellung eines Konzepts zu erstellen. Daraus lässt sich keine Aussage über den gesamten Arbeitsablauf eines Agenten ableiten. Das README enthält Beispiele für Grafiken und eine Anleitung zum Starten der Skill. Beides lässt sich konkret prüfen, wenn Erklärmaterial für ein technisches Team benötigt wird.

Empfehlung: Ein Konzept wählen, das sich im Team schwer erklären lässt, und das Ergebnis als Lehrmaterial beurteilen. Prüffragen: Macht die Grafik das gewünschte Verhalten verständlich? Sind die dargestellten Details korrekt? Falls sie veröffentlicht werden soll: Wer prüft Text, Interaktionen und Barrierefreiheit?

OpenClaw: beim Gateway und der Sicherheit anfangen

openclaw/openclaw. Das README stellt OpenClaw als Open-Source-Assistenten vor, der auf dem Computer des Nutzers läuft und sich mit Messaging-Kanälen verbindet. Es beschreibt das Gateway als lokale Steuerungsebene für Sitzungen, Werkzeuge, Ereignisse und Kanalverbindungen. Außerdem gibt es an, dass Modelle und Agent-Harnesses als Plugins ausgetauscht werden können, ohne den Rest zu ändern. Diese Aussage bezieht sich auf genau diese Komponenten. Dass das README weitere Werkzeuge, Skills und Plugins auflistet, belegt diese Eigenschaft nicht für jeden aufgeführten Eintrag.

Zur Sicherheit fordert das README dazu auf, eingehende Nachrichten als nicht vertrauenswürdige Eingaben zu behandeln. Es stellt klar, dass Werkzeuge in der Hauptsitzung auf dem Host ausgeführt werden, sofern kein Sandboxing konfiguriert ist. Bevor weitere Nutzer angebunden oder das Gateway aus der Ferne erreichbar gemacht wird, empfiehlt es die Lektüre der Sicherheitsleitfäden. Diese Leitfäden werden im README erwähnt, gehören aber nicht zu den für diesen Artikel ausgewerteten Seiten.

Empfehlung: Vor einem gemeinsamen Test festlegen, wer Nachrichten senden darf und welche Aktionen erlaubt sein sollen. Prüffragen: Wo werden die Werkzeuge in der gewählten Konfiguration ausgeführt? Auf welche Zugangsdaten können sie zugreifen? Welche Kontrollen sind nötig, bevor ein vom Team genutzter Kanal angebunden wird? Das muss an der konkreten Installation geprüft werden; eine allgemeine Beschreibung liefert dafür keine Garantien.

Was sich aus dieser Einordnung ableiten lässt

Für ein KMU oder einen MSP empfiehlt es sich, jeden Test an eine eng gefasste Frage zu knüpfen: Erfüllt die beschriebene Architektur von DeepSeek Harness die eigenen Entwicklungsanforderungen? Liefert die Anatomy-Skill eine nützliche und überprüfbare Erklärung? Hält die OpenClaw-Konfiguration die festgelegten betrieblichen Grenzen ein? Die Antworten sollten getrennt bleiben: Eine im Repository beschriebene Fähigkeit gilt nicht automatisch für die anderen Projekte.

Für eine breiter angelegte Bewertung bietet die Altovar-Seite zu künstlicher Intelligenz für Unternehmen einen Einstieg in das Thema. Für die Eigenschaften der einzelnen Projekte sind dagegen die jeweiligen Repositories maßgeblich.

Quellen: README von deepseek-ai/deepseek-harness; README von wheresryan22/anatomy; README von openclaw/openclaw.