DeepSeek Harness: Eigene Modelle anbinden

Zuletzt aktualisiert am 18.08.2026; die Angaben wurden anhand des offiziellen DeepSeek-Harness-Repositories, des offiziellen Provider-Leitfadens und des offiziellen Web-UI-Leitfadens geprüft. DeepSeek Harness befindet sich weiterhin in der Developer Preview; laut offizieller README sind daher kompatibilitätsbrechende Änderungen möglich.

Ein konkreter Prüfpunkt ist bereits dokumentiert: Die Web-Oberfläche läuft standardmäßig unter http://127.0.0.1:3080. Daraus folgt die wichtigste Entscheidung für die DeepSeek Harness eigene Modellanbindung: Für den direkten DeepSeek API-Zugriff sollte zunächst die integrierte Route verwendet werden. Ein benutzerdefinierter Provider ist erst dann sinnvoll, wenn ein Unternehmensgateway, ein selbst gehosteter Dienst oder ein nicht im Katalog vorhandener Endpunkt angebunden werden soll.

Diese Anleitung ist für drei Gruppen gedacht: Plattformingenieure, die ein internes Modellgateway anbinden, Teams mit selbst gehosteten Modellen, die eine OpenAI-kompatible API prüfen müssen, und Agent-Entwickler, die eine zusätzliche Modellroute einführen möchten, ohne bestehende Sitzungen zu verändern.

Ein eigener Provider ist keine allgemeine Umschaltfunktion für jedes beliebige Modell. Er bildet eine konkrete Verbindung aus Provider ID, Endpunkt, Protokoll, Zugangsdaten und Modellkatalog ab. Wer lediglich zwischen zwei bereits im installierten Katalog vorhandenen Modellen wechseln möchte, sollte deshalb zuerst die vorhandene Provider-Konfiguration verwenden. Der Katalog bringt seine Endpunkte, Protokolle und Modelllisten bereits mit.

Die Entscheidung lässt sich so treffen:

Vor dem Anlegen sollte das Team mindestens diese Punkte dokumentieren:

• Liefert der Dienst Chat-Anfragen über das erwartete API-Protokoll?
• Welche exakte Base URL soll DeepSeek Harness aufrufen?
• Gibt es einen abrufbaren Modellkatalog oder nur eine manuell bekannte Modell-ID?
• Wird der Schlüssel direkt gespeichert oder über eine Umgebungsvariable referenziert?
• Welche Route bleibt für den Rückfall aktiv, falls das Gateway ausfällt?
• Dürfen Sitzungsdaten, Prompts und Tool-Ergebnisse das interne Netzwerk verlassen?

Gerade der letzte Punkt ist bei einem Unternehmensgateway entscheidend. Ein Gateway kann zwar die Modellroute zentralisieren, aber gleichzeitig zusätzliche Protokollierung, Zugriffskontrolle und Aufbewahrungsregeln einführen. Für DSGVO-relevante Projekte sollte vor dem ersten echten Repository-Test geklärt sein, welche Inhalte im Gateway- oder Anbieterprotokoll landen.

Achtung: Die offizielle Dokumentation bestätigt die Unterstützung von Katalog-Providern und benutzerdefinierten Providern. Daraus folgt jedoch nicht automatisch, dass jeder Dienst mit ähnlicher API-Bezeichnung kompatibel ist. Die konkrete Route muss mit einer isolierten Sitzung geprüft werden.

Öffnen Sie in der Web-Oberfläche Settings → Models und wählen Sie die Funktion zum Hinzufügen eines benutzerdefinierten Providers. Der offizielle Leitfaden verlangt eine kleingeschriebene Provider ID, eine Base URL, ein API-Protokoll, Zugangsdaten und mindestens ein Modell.

Die Provider ID sollte vor dem ersten Speichern endgültig gewählt werden. Sie ist nicht nur ein Anzeigename. Nach der Dokumentation wird sie in Requests, gespeicherten Sitzungen, Standardmodellen und Zugangsdatenreferenzen verwendet. Eine Umbenennung ist deshalb kein einfaches Editieren: Der empfohlene Weg besteht darin, einen neuen Provider anzulegen und den alten erst nach erfolgreicher Prüfung zu löschen.

Für die interne Namensgebung eignen sich funktionale IDs wie:

• gateway-intern
• selfhosted-coding
• staging-models

Die ID sollte weder den aktuellen Modellnamen noch eine kurzlebige Versionsnummer enthalten. Wenn das Gateway später das dahinterliegende Modell austauscht, bleibt die Route dadurch stabiler. Eine ID wie model-v1-test erzeugt dagegen unnötige Sitzungs- und Dokumentationsarbeit, sobald die Modellversion ersetzt wird.

Die übrigen Felder lösen unterschiedliche Probleme:

1. Base URL: Sie bestimmt, an welchem Dienst DeepSeek Harness die Anfrage absetzt. Eine falsche Pfadtiefe kann dazu führen, dass die Oberfläche speichert, der Dienst aber keine gültige API-Anfrage erhält.
2. API-Protokoll: Es beschreibt, wie Requests und Antworten strukturiert sind. „OpenAI-kompatibel“ genügt als Werbeaussage nicht; entscheidend ist, ob die konkrete Operation, etwa Chat-Aufruf und Modellabfrage, tatsächlich bereitgestellt wird.
3. Zugangsdaten: Sie erlauben die Authentifizierung am Gateway. Die offizielle Dokumentation beschreibt, dass Schlüssel nicht im Klartext zurück an die Oberfläche geliefert werden, sondern über eine Credentials-Referenz verwaltet werden.
4. Modell-ID: Sie muss exakt der Kennung entsprechen, die der Dienst akzeptiert. Anzeigenamen, Aliasnamen und interne Bezeichnungen sind nicht automatisch austauschbar.

Die offiziellen Felder und ihre Standardwerte können sich während der Developer Preview ändern. Deshalb sollten Teams keine Konfigurationsschlüssel aus älteren Blogbeiträgen übernehmen, sondern vor jeder Änderung den aktuellen Provider-Leitfaden und den Konfigurationskatalog prüfen.

Nach dem Eintragen der Basisdaten sollte nicht sofort ein wichtiger Agent-Workflow gestartet werden. Öffnen Sie im Bereich Model catalog zunächst die Funktion zum Abruf verfügbarer Modelle. DeepSeek Harness fragt dabei den angegebenen Endpunkt mit den aktuell im Formular sichtbaren Zugangsdaten ab. Die ausgewählten Modelle gehören zunächst zum Entwurf und werden erst beim Speichern dauerhaft übernommen.

Das Ergebnis lässt sich in drei typische Fälle einteilen:

Fall A: Die Modellliste wird erfolgreich geladen

Wählen Sie zunächst nur ein Modell aus, das für den ersten Test vorgesehen ist. Mehr Modelle erhöhen nicht automatisch die Sicherheit. Je kleiner der erste Konfigurationsumfang bleibt, desto leichter lässt sich feststellen, ob ein Fehler aus der Authentifizierung, der Modell-ID oder dem Agentenverhalten stammt.

Fall B: Der Abruf endet mit 401

Der offizielle Leitfaden nennt als Ursache zuerst den Zugangsschlüssel. Die Modell-Erkennung verwendet bei einer OpenAI-kompatiblen API den Aufruf GET /models. Ein 401 bedeutet daher typischerweise, dass der Schlüssel fehlt, abgelaufen ist, am Gateway nicht akzeptiert wird oder nicht an den erwarteten Pfad weitergereicht wird.

Die Rückfallaktion lautet:

• Schlüssel im Gateway unabhängig von DeepSeek Harness testen.
• Prüfen, ob das Gateway für GET /models dieselbe Authentifizierung erwartet wie für Chat-Anfragen.
• Zugangsdaten in DeepSeek Harness erneut speichern.
• Falls der Endpunkt absichtlich keine Modellliste anbietet, die Modell-ID manuell eintragen und den Modellabruf nicht als Pflichtprüfung behandeln.

Fall C: Der Endpunkt liefert keine Modellliste

Das ist nicht automatisch ein Fehler. Einige selbst gehostete Dienste bieten nur den eigentlichen Chat-Endpunkt und keinen Modellkatalog an. In diesem Fall muss das Team die Modell-ID manuell eintragen. Wichtig ist dann, dass die Schreibweise exakt aus der Serverkonfiguration übernommen wird.

Wenn das Modell zwar in der Liste erscheint, später aber als unbekannt zurückgewiesen wird, liegt häufig eine Abweichung zwischen Katalog-ID und Request-ID vor. Prüfen Sie dann, welche Modellkennung das Gateway tatsächlich an die Backend-Route weitergibt. Ein erfolgreich gespeicherter Provider ist kein Beweis dafür, dass die Modell-ID auf dem Server gültig ist.

Die erste funktionale Prüfung sollte in einem neuen, isolierten Arbeitsbereich stattfinden. Der offizielle Web-UI-Leitfaden weist darauf hin, dass zunächst ein Workspace ausgewählt werden muss, bevor eine Sitzung für Aufgaben verwendet werden kann.

Gehen Sie in dieser Reihenfolge vor:

1. Isolierten Workspace anlegen: Verwenden Sie ein Testverzeichnis ohne vertrauliche Repository-Daten und ohne Schreibrechte auf produktive Systeme.
2. Neue Sitzung starten: Wählen Sie den benutzerdefinierten Provider und die geprüfte Modell-ID ausdrücklich aus.
3. Minimale Textanfrage senden: Fordern Sie beispielsweise eine kurze Zusammenfassung einer lokalen Testdatei an.
4. Verbindungsdaten protokollieren: Notieren Sie Provider ID, Modell-ID, Zeitpunkt, Antwortstatus und die sichtbare Fehlermeldung.
5. Einen harmlosen Tool-Aufruf ausführen: Lassen Sie nur eine ungefährliche Operation wie das Auflisten eines Testverzeichnisses zu.
6. Tool-Verhalten prüfen: Achten Sie darauf, ob der Agent den Aufruf korrekt anfordert, ob die Genehmigung sichtbar ist und ob das Ergebnis wieder in der Sitzung ankommt.
7. Fehler absichtlich dokumentieren: Testen Sie nicht mit einem produktiven Auftrag, sondern halten Sie fest, wie ein ungültiger Modellname oder ein gesperrter Endpunkt angezeigt wird.

Der Texttest prüft hauptsächlich Netzwerk, Authentifizierung, Modell-ID und Antwortformat. Der kontrollierte Tool-Aufruf prüft zusätzlich, ob das gewählte Modell und das Gateway die für den Agenten erforderliche Nachrichtenstruktur korrekt verarbeiten. Ein erfolgreicher kurzer Chat reicht deshalb nicht aus, um eine Route für produktive Agenten freizugeben.

Erfahrung aus der Betriebsprüfung: Wird der erste Test direkt in einem wichtigen Repository durchgeführt, vermischt das Team Konfigurationsfehler mit Berechtigungs-, Workspace- und Tool-Problemen. Ein isolierter Arbeitsbereich spart später vor allem Diagnosezeit.

Die Auswahl eines Modells macht dieses Modell zum Standard für neue Sitzungen. Eine bereits verwendete Sitzung behält dagegen das Modell, das in ihrem eigenen Protokoll gespeichert wurde. Der offizielle Provider-Leitfaden beschreibt dieses Verhalten ausdrücklich.

Das hat drei praktische Folgen:

• Eine bestehende Sitzung wechselt nicht automatisch auf den neuen Provider.
• Ein neuer Standardwert ist kein Beweis, dass alte Sitzungen repariert wurden.
• Nach einer Änderung sollte die erste Vergleichsanfrage in einer neuen Sitzung erfolgen.

Wenn ein Provider gelöscht wird, obwohl er noch als Standardmodell gespeichert ist, kann die Oberfläche die Eingabe blockieren und eine neue Modellauswahl verlangen. In diesem Zustand sollte nicht wiederholt an der alten Sitzung gearbeitet werden. Legen Sie eine neue Sitzung mit der geprüften Rückfallroute an und dokumentieren Sie, welche Sitzung welchem Provider zugeordnet ist.

Für Teams mit mehreren Agenten ist eine kleine Sitzungsregel sinnvoll: Jede Änderung an Provider ID, Modell-ID oder Gateway-Route erhält eine eigene Test-Sitzung. Dadurch bleibt später nachvollziehbar, ob ein Fehler bereits vor oder erst nach der Änderung auftrat.

Die folgenden Signale sollten nicht gleich behandelt werden:

• Fehlende Zugangsdaten: Zugangsschlüssel oder referenzierte Umgebungsvariable fehlen. Zugangsdaten erneut speichern oder die Referenz prüfen.
• Unbekanntes Modell: Die Modell-ID ist nicht konfiguriert oder wird vom Endpunkt anders geschrieben. Modell manuell ergänzen oder die exakte Server-ID übernehmen.
• 401 beim Modellabruf: Schlüssel und Authentifizierung des GET /models-Aufrufs prüfen. Wenn kein Katalog existiert, manuelle Modellpflege verwenden.
• Leere Modellauswahl nach dem Speichern: Speichern und Erkennung nicht gleichsetzen; Modellkatalog oder manuelle Modell-ID kontrollieren.
• Fehler nur in alter Sitzung: Neue Sitzung mit derselben Route starten. Das alte Sitzungsprotokoll kann weiterhin auf den vorherigen Provider zeigen.
• Antwort funktioniert, Tool-Aufruf scheitert: Das Gateway unterstützt möglicherweise nur einen Teil des erwarteten Protokolls. Die Route bleibt für reine Texttests geeignet, ist aber noch nicht für Agentenbetrieb freigegeben.

Nicht dokumentierte Fehlercodes sollten nicht mit erfundenen Bedeutungen versehen werden. Entscheidend sind die Stelle des Fehlers, die verwendete Provider ID, die Modell-ID, der konkrete Request-Typ und die Frage, ob der Fehler beim Abruf, beim Textrequest oder beim Tool-Aufruf auftritt.

Nach erfolgreicher Prüfung sollte das Team eine kurze Änderungsakte führen. Sie muss mindestens enthalten:

• Provider ID und Anzeigename
• Base URL und API-Protokoll
• Modell-ID und Datum der letzten Prüfung
• Art der Zugangsdatenreferenz
• Ergebnis des Modellabrufs
• Ergebnis der minimalen Textanfrage
• Ergebnis des kontrollierten Tool-Aufrufs
• bekannte Einschränkungen des Gateways
• definierte Rückfallroute
• verantwortliche Person für die nächste Prüfung

Der Rückfall sollte nicht erst dann eingerichtet werden, wenn die primäre Route bereits ausgefallen ist. Lassen Sie die getestete integrierte DeepSeek-Route oder einen zweiten geprüften Provider bestehen, sofern Datenschutz- und Betriebsregeln das erlauben. Bei vertraulichen Daten darf eine öffentliche Rückfallroute natürlich nicht einfach als technische Notlösung aktiviert werden.

Nach einem Update von DeepSeek Harness oder des internen Modellgateways werden mindestens die folgenden Prüfungen erneut ausgeführt: Modellabruf, kurze Textanfrage, kontrollierter Tool-Aufruf und Start einer neuen Sitzung. Das ist besonders wichtig, weil sich DeepSeek Harness laut offizieller README noch in einer Developer Preview befindet und Änderungen an Schnittstellen oder Standardverhalten möglich sind.

• [ ] Direkte DeepSeek API zuerst über die integrierte Route geprüft
• [ ] Notwendigkeit eines eigenen Providers schriftlich begründet
• [ ] Provider ID vor dem ersten Speichern endgültig gewählt
• [ ] Base URL und API-Protokoll aus der aktuellen Dokumentation übernommen
• [ ] Zugangsdaten nicht in Tickets oder Klartextkonfiguration abgelegt
• [ ] Modellabruf erfolgreich getestet oder fehlender Katalog dokumentiert
• [ ] Modell-ID exakt aus dem Dienst übernommen
• [ ] Neue isolierte Sitzung verwendet
• [ ] Minimale Textanfrage erfolgreich
• [ ] Kontrollierter Tool-Aufruf erfolgreich
• [ ] Provider und Modell im Testprotokoll festgehalten
• [ ] Neue Sitzung nach dem Modellwechsel geprüft
• [ ] Rückfallroute vorhanden und separat getestet
• [ ] DSGVO-, Protokollierungs- und Berechtigungsfolgen des Gateways bewertet

Ein eigener Provider lohnt sich damit vor allem dort, wo ein internes Gateway, ein selbst gehosteter Dienst oder ein katalogfremdes Modell tatsächlich benötigt wird. Für den direkten offiziellen DeepSeek-Zugriff erzeugt er dagegen zusätzliche Pflegepunkte: eine eigene Provider ID, manuelle Modellpflege, eine weitere Zugangsdatenreferenz und mehr Prüfaufwand bei Updates.

Wenn die Route in einer isolierten, dauerhaft verfügbaren macOS-Umgebung getestet werden soll, ist ein eigener Rechner oft unnötig unflexibel: Hardwarebeschaffung, lokale Wartung und fehlende Reproduzierbarkeit erschweren kurzfristige Gateway- oder Agententests. NUKCLOUD kann dafür eine gemietete Mac-Umgebung bereitstellen, in der das Team eine getrennte Testinstanz aufsetzt, Änderungen kontrolliert prüft und die Umgebung nach der Abnahme wieder verwirft oder für einen definierten Zeitraum weiterbetreibt. Für einen ersten Überblick über verfügbare Mac-Optionen eignet sich die deutsche NUKCLOUD-Übersicht; bei einer geografisch passenden Teststrecke können auch US-Ost oder US-West relevant sein. Langfristig stabile Dauerlast, physische Spezialhardware oder lokale Netzwerkabhängigkeiten sprechen weiterhin eher für eine eigene Infrastruktur als für Miete.