DeepSeek-Harness-Laufmodus 2026: Web, Headless oder ACP?

Stand: 18.08.2026. Die Angaben wurden anhand des offiziellen Repositorys sowie der aktuellen Benutzer-, Entwicklungs- und Architekturdokumentation geprüft.

127.0.0.1:3080 als Ausgangspunkt: Die Entscheidung vor dem Einrichten

Die offizielle Web-Variante startet standardmäßig unter http://127.0.0.1:3080. Das zeigt bereits die wichtigste Abgrenzung: Web ist zunächst eine lokale, beobachtbare Arbeitsoberfläche; Headless ist für einen ausdrücklich gestarteten Auftrag gedacht; ACP richtet sich an einen übergeordneten Client, der Sitzungen verwaltet. (offizielles DeepSeek-Harness-Repository)

Für den DeepSeek-Harness-Laufmodus gilt deshalb eine bedingte Entscheidung:

• Web zuerst, wenn ein unabhängiger Entwickler Pläne, Werkzeugaufrufe, Dateiunterschiede und Freigaben während der Arbeit sehen möchte.
• Headless zuerst, wenn ein Automatisierungsauftrag klar begrenzt ist, ein überprüfbares Ergebnis erzeugt und der Erfolg über einen Prozessstatus oder eine nachgelagerte Prüfung bewertet werden kann.
• ACP erst prüfen, wenn ein Editor, ein Agenten-Host oder eine Plattform Sitzungen selbst anlegen und strukturierte Nachrichten verarbeiten soll.
• Mehrere Eingänge parallel zulassen, wenn Modellkonfiguration, Berechtigungen, Plugin-Versionen und Protokollregeln zentral übereinstimmen.

Der Web-Modus ist nicht automatisch leistungsfähiger. Sein Vorteil liegt in der Sichtbarkeit und in der Möglichkeit, an kritischen Stellen einen Menschen einzubeziehen. Das offizielle Projekt befindet sich weiterhin in der Developer Preview und weist ausdrücklich auf mögliche inkompatible Änderungen hin.

Wer mit dieser Entscheidung Zeit spart

Dieser Vergleich richtet sich an unabhängige Entwickler, die den wartungsärmsten täglichen Eingang suchen, an Automatisierungsingenieure, die Aufgaben als wiederholbare Befehle formulieren müssen, sowie an Plattform- und Tool-Entwickler, die ACP, Sitzungsverwaltung und mehrere Arbeitsweisen verantworten.

Wer lediglich eine einzelne lokale Web-Oberfläche einrichten möchte, benötigt zunächst keine komplexe Integrationsarchitektur. Wer dagegen unbeaufsichtigte Aufträge oder Editor-Anbindungen plant, sollte die Betriebs- und Prüfverantwortung vor der Auswahl festlegen.

Erster Schritt: Die Verantwortung statt die Funktionsliste bestimmen

Eine reine Funktionsmatrix führt bei DeepSeek Harness schnell zu einer falschen Schlussfolgerung. Alle drei Eingänge können mit demselben Agenten- und Plugin-Unterbau verbunden sein, aber sie verlagern die Verantwortung an unterschiedliche Stellen.

Für unabhängige Entwickler: Web als sichtbarer Hauptzugang

Die offizielle Web-Anleitung verlangt nach dem Start zunächst die Auswahl eines Arbeitsbereichs. Erst danach steht der Sitzungscomposer für Aufgaben bereit. In der Oberfläche lassen sich Sitzungen starten, Dateien lesen und bearbeiten, Befehle ausführen, Aufgaben delegieren und Pläne verfolgen. Operationen, die nach der aktiven Berechtigungspolitik eine Zustimmung benötigen, werden zur Freigabe vorgelegt. (offizieller Web-Leitfaden)

Das macht Web für tägliche Entwicklungsarbeit sinnvoll, wenn mindestens einer dieser Punkte zutrifft:

• Änderungen müssen vor der Ausführung geprüft werden.
• Der Agent soll seinen Plan erläutern, bevor mehrere Dateien verändert werden.
• Werkzeugaufrufe und erzeugte Unterschiede gehören zur Abnahme.
• Eine Aufgabe ist noch nicht so stabil beschrieben, dass ein Skript sie zuverlässig begrenzen könnte.
• Der Entwickler möchte bei einem unerwarteten Seiteneffekt sofort eingreifen.

Der versteckte Preis dieser Kontrolle ist die geringere Automatisierbarkeit. Ein Browserfenster ist kein belastbarer Ersatz für einen Prozessvertrag. Sitzungszustand, Arbeitsbereich, Freigaben und sichtbare Zwischenstände müssen für eine spätere Rekonstruktion zusätzlich dokumentiert werden. Bei einem gelegentlichen Auftrag ist das trotzdem oft günstiger als die Pflege eines eigenen Headless-Wrappers.

Die Web-Einrichtung sollte außerdem nicht mit einer öffentlichen Fernfreigabe verwechselt werden. Der dokumentierte Standardzugang bindet an eine lokale Loopback-Adresse. Für einen entfernten Zugriff sind Netzwerkfreigabe, Authentifizierung, TLS, Arbeitsbereichstrennung und eine klare DSGVO-Bewertung gesondert zu planen. Die Oberfläche allein liefert diese Governance nicht automatisch.

Für Automatisierungsingenieure: Headless als Prozessvertrag

Die Entwicklungsdokumentation zeigt einen One-Shot-Aufruf mit dem Profil headless:

pnpm dsh --profile headless "summarize this workspace"

Derselbe Abschnitt beschreibt einen API-Schlüssel über DEEPSEEK_API_KEY, während der Entwicklungsleitfaden zusätzlich eine optionale DEEPSEEK_BASE_URL nennt. (offizieller Entwicklungsleitfaden)

Headless passt zu Aufgaben, deren Eingabe- und Ausgabegrenzen bereits feststehen, beispielsweise:

• Zusammenfassungen eines definierten Verzeichnisses;
• Erzeugung eines strukturierten Prüfberichts;
• Analyse eines bekannten Testartefakts;
• Vorschläge für eine klar abgegrenzte, anschließend geprüfte Änderung;
• ein CI/CD-Schritt, dessen Ergebnis durch Tests, Schema-Prüfung oder Diff-Regeln bewertet wird.

Der entscheidende Unterschied zu Web liegt nicht darin, dass Headless „automatischer“ klingt. Der Unterschied besteht darin, dass die Shell und die Pipeline den Auftrag vollständig beschreiben müssen. Die fehlende menschliche Beobachtung wird zur eigenen Engineering-Aufgabe.

Vor dem produktiven Einsatz sollte ein Skript mindestens diese Zuständigkeiten festlegen:

1. Parameterübergabe: Welche Eingabe kommt aus Argumenten, welcher Teil aus einer Datei und welcher aus einer Umgebungsvariablen?
2. Geheimnisse: Wie gelangt der API-Schlüssel in den Prozess, ohne in Shell-Historie, CI-Logs oder Fehlermeldungen zu erscheinen?
3. Arbeitsbereich: Welches Verzeichnis darf gelesen oder verändert werden, und wie wird ein falscher Pfad verhindert?
4. Protokollierung: Werden Eingabe, Startzeit, Prozessstatus, erzeugte Dateien und relevante Fehlermeldungen getrennt gespeichert?
5. Erfolgskriterium: Reicht ein erfolgreicher Prozessabschluss, oder müssen Tests, Diff-Größe, Schema und Freigabe zusätzlich geprüft werden?
6. Wiederholung: Wann darf ein Auftrag erneut laufen, und wie wird verhindert, dass ein nicht idempotenter Schreibvorgang doppelt ausgeführt wird?

Ein erfolgreich beendeter Headless-Prozess ist deshalb nur ein technisches Signal. Für hochriskante Schreibvorgänge bleiben Testumgebung, Review und ein externes Freigabetor erforderlich. Das gilt insbesondere für Datenbankmigrationen, Konfigurationsänderungen, Berechtigungen und automatisch erzeugte Commits.

Für Integrationsentwickler: ACP nur bei einem echten Host-Vertrag

Der Entwicklungsleitfaden nennt einen ACP-Demostart, der frische Agentensitzungen über JSON-RPC und Standard-Ein- und -Ausgabe bereitstellt:

pnpm run demo:acp

Das ist eine andere Verantwortung als der direkte Headless-Aufruf. Ein ACP-Client muss nicht nur Text senden, sondern die Lebensdauer der Sitzung, Nachrichten, Abbrüche und Fehlerzustände korrekt verwalten.

ACP ist daher besonders dann interessant, wenn:

• ein Editor die Sitzung selbst erzeugen und schließen soll;
• ein Agenten-Host mehrere Aufgaben an denselben Laufzeitdienst verteilt;
• Ergebnisse in strukturierter Form an eine Plattform weitergegeben werden;
• Berechtigungen des übergeordneten Clients auf den Arbeitsbereich abgebildet werden müssen;
• Sitzungsstatus, Abbruch und Wiederaufnahme Teil des Produktvertrags sind.

Die Flexibilität ist zugleich die größte Fehlerquelle. Ein ACP-Adapter kann zwar eine saubere Protokollgrenze schaffen, aber er nimmt dem Betreiber nicht die Fragen nach Client-Kompatibilität, Prozessstart, Standardfehlerkanal, Sitzungs-Timeout, parallelen Sitzungen und Rechtevererbung ab.

Ein bereits stabiler Web- oder Kommandozeilenablauf sollte deshalb nicht allein wegen einer flexibleren Schnittstelle ersetzt werden. ACP lohnt sich, wenn der übergeordnete Host einen konkreten Integrationsgewinn erzielt. Ohne diesen Host entsteht lediglich eine zusätzliche Schicht, die getestet, überwacht und bei Änderungen des Preview-Projekts angepasst werden muss.

Zweiter Schritt: Die versteckten Kosten vor dem Wechsel prüfen

Die Auswahl des Modus entscheidet nicht nur über die Bedienoberfläche. Sie bestimmt, wo Fehler sichtbar werden und wer sie beheben muss.

Sichtbarkeit und menschliche Freigabe

Web zeigt den Ablauf unmittelbar. Das erleichtert die Prüfung von Plan, Werkzeugaufruf und Dateidiff, kann aber zu einer falschen Sicherheit führen: Was sichtbar ist, ist nicht automatisch vollständig geprüft. Für sensible Arbeitsbereiche müssen Rechte und Freigabepunkte unabhängig von der Oberfläche dokumentiert werden.

Headless verlagert die Kontrolle in Skripte und Pipeline-Regeln. Ohne gespeicherte Eingabe, Ausgabe und Diff kann später häufig nicht mehr erklärt werden, warum eine Änderung entstanden ist. ACP verlagert diese Nachvollziehbarkeit zusätzlich in die Host-Anwendung. Der Host muss Sitzungsereignisse und Fehler so speichern, dass ein Betreiber nicht nur „fehlgeschlagen“ sieht, sondern den letzten bekannten Zustand rekonstruieren kann.

Stabilität und Preview-Risiko

DeepSeek Harness ist laut README eine Developer Preview mit möglichen inkompatiblen Änderungen. Das betrifft für eine Modusentscheidung nicht nur den Installationsbefehl. Auch Profile, Startparameter, ACP-Verhalten, Plugin-Schnittstellen und Client-Kompatibilität können sich verändern.

Für Web kann eine Änderung sofort beim manuellen Start auffallen. Bei Headless erscheint sie möglicherweise erst im nächsten geplanten Lauf. Bei ACP kann sie als Protokoll- oder Lebenszyklusfehler im Host sichtbar werden. Je weniger menschliche Beobachtung ein Eingang besitzt, desto wichtiger sind Smoke-Tests und ein klarer Rückfallpfad.

Berechtigungen und Datenschutz

Der offizielle Web-Leitfaden beschreibt eine aktive Berechtigungspolitik und Bestätigungen für zustimmungspflichtige Operationen. Daraus folgt jedoch nicht, dass ein Headless- oder ACP-Einsatz dieselbe organisatorische Kontrolle besitzt. Die jeweilige Einbindung muss prüfen, welche Rechte an den Prozess vererbt werden, welche Arbeitsbereiche erreichbar sind und ob sensible Inhalte an die konfigurierte Modellroute gelangen.

Für Teams gehören deshalb mindestens diese Regeln in eine zentrale Konfiguration:

• zulässige Modellroute und optionaler Basis-Endpunkt;
• erlaubte Arbeitsbereiche und Dateigrenzen;
• verwaltete Plugin-Versionen;
• Geheimnisverwaltung ohne Klartext in Protokollen;
• Aufbewahrungsdauer und Zugriff auf Sitzungs- sowie CI-Logs;
• Freigabepflicht für schreibende oder destruktive Aktionen;
• Nachweis, welcher Eingang eine Änderung ausgelöst hat.

Dritter Schritt: Den passenden Einstieg in fünf Prüfungen festlegen

Die folgende Checkliste ist als Entscheidungshilfe gedacht, nicht als allgemeine Produktbewertung:

• [ ] Die Aufgabe benötigt sichtbare Pläne, Werkzeugaufrufe oder manuelle Freigaben. Falls ja, Web als Hauptzugang testen.
• [ ] Die Eingabe ist vollständig formulierbar, das Ergebnis maschinell prüfbar und ein Wiederholungslauf vertretbar. Falls ja, Headless als Kandidat aufnehmen.
• [ ] Ein Editor oder Agenten-Host muss Sitzungen selbst erzeugen, Nachrichten senden und Ergebnisse strukturiert übernehmen. Falls nein, ACP vorerst nicht einführen.
• [ ] Für Headless sind Exit-Status, Logs, Diff-Prüfung und Wiederholungsregeln außerhalb des Agenten definiert.
• [ ] Für ACP sind Client-Version, Sitzungs-Timeout, Abbruch, Fehlerweitergabe und Rechteabbildung als Tests dokumentiert.
• [ ] Modellroute, Arbeitsbereichsrechte, Plugin-Versionen und Protokollaufbewahrung werden unabhängig vom Eingang zentral verwaltet.
• [ ] Es existiert ein risikoarmer Referenzauftrag, der in Web, Headless und ACP mit derselben Eingabe ausgeführt werden kann.
• [ ] Ein Rückfall auf den bisherigen Eingang ist möglich, ohne Arbeitsbereich oder Prüfnachweise zu verlieren.

Wenn die ersten beiden Web-Kriterien erfüllt sind, sollte Web zunächst die Hauptspur bleiben. Wenn die Headless-Kriterien erfüllt sind und der Auftrag regelmäßig wiederkehrt, kann Headless die Automatisierung übernehmen. ACP sollte erst dann die Hauptspur werden, wenn ein Host tatsächlich Sitzungen und strukturierte Ergebnisse benötigt.

FAQ: Die wichtigsten Fragen zur Moduswahl

DeepSeek Harness Web und Headless im Alltag

Web ist für beobachtbare Sitzungen mit sichtbarer Freigabe und Arbeitsbereichsauswahl ausgelegt. Headless wird dagegen als einmaliger Auftrag aus der Entwicklungsumgebung oder einer Pipeline gestartet. Für die Modellqualität sollte daraus kein pauschaler Vorteil abgeleitet werden. Entscheidend sind Kontrolle, Eingabegrenzen und die Frage, ob ein Mensch oder ein Prüfskript den nächsten Schritt verantwortet.

Tägliche Programmierarbeit

Für tägliche Programmierarbeit ist Web meistens der vernünftige Ausgangspunkt, wenn Aufgaben noch unterschiedliche Lösungswege zulassen oder Änderungen vor der Ausführung geprüft werden sollen. Headless wird erst dann attraktiver, wenn Prompt, Arbeitsbereich und Abnahmeregeln stabil sind. Ein gelegentlich genutzter Auftrag rechtfertigt nicht automatisch eine eigene Automatisierungsschicht.

Skriptaufrufe

DeepSeek Harness kann aus einem Skript heraus gestartet werden; die offiziellen Entwicklungsunterlagen nennen dafür das Profil headless. In einer belastbaren Pipeline müssen jedoch Eingabe, Umgebungsvariablen, Arbeitsverzeichnis, Logdatei, Exit-Status und fachliche Nachprüfung zusammenpassen. Ein Prozess, der ohne Fehler beendet wird, kann trotzdem ein unbrauchbares oder unvollständiges Artefakt erzeugen.

Der richtige Zeitpunkt für ACP

ACP wird interessant, wenn ein Editor, ein Agenten-Host oder eine Plattform nicht nur einen Befehl ausführen, sondern Sitzungen verwalten und Ereignisse strukturiert verarbeiten soll. Vor dem produktiven Einsatz sind insbesondere Client-Kompatibilität, Fehlerweitergabe, Abbruch, parallele Sitzungen und Berechtigungszuordnung zu testen. Für einen einzelnen lokalen Auftrag bleibt Headless meist einfacher.

Parallele Eingänge im Team

Ein Team kann Web, Headless und ACP parallel betreiben. Die Trennung sollte jedoch nach Rolle und Risikoprofil erfolgen, nicht nach zufälligen lokalen Einstellungen. Ein Web-Nutzer darf beispielsweise mehr manuelle Kontrolle haben, während ein CI-Auftrag enger begrenzt ist; beide benötigen trotzdem dieselbe Modellfreigabe, Plugin-Version und Dokumentation der erzeugten Änderungen.

Vierter Schritt: Einen risikoarmen Referenzauftrag ausführen

Ein Vergleich ist nur belastbar, wenn jede Variante dieselbe Aufgabe erhält. Geeignet ist ein Auftrag, der keine produktiven Daten verändert, zum Beispiel eine Repository-Zusammenfassung mit einer festgelegten Ausgabedatei oder ein Bericht über vorhandene Pakete.

Der Test sollte in dieser Reihenfolge ablaufen:

1. Arbeitsbereich vorbereiten: Eine Kopie oder ein ausdrücklich freigegebener Testzweig verhindert, dass ein Modusvergleich produktive Dateien verändert.
2. Eingabe einfrieren: Prompt, Dateibestand, Modellroute und relevante Plugin-Versionen werden dokumentiert.
3. Web ausführen: Start, Arbeitsbereichsauswahl, Plan, Werkzeugaufrufe, Freigabepunkte und Ergebnisdatei werden notiert.
4. Headless ausführen: Derselbe Auftrag läuft mit dem dokumentierten Profil. Prozessstatus, Standardausgabe, Fehlerausgabe und erzeugte Artefakte werden getrennt gespeichert.
5. ACP ausführen: Der Host erstellt eine Sitzung, sendet die identische Aufgabe und zeichnet Antworten, Abbruchverhalten und Fehlerweitergabe auf.
6. Ergebnis prüfen: Nicht die schönste Oberfläche entscheidet, sondern Vollständigkeit, Reproduzierbarkeit, Prüfbarkeit und Wiederherstellbarkeit.
7. Betriebsentscheidung formulieren: Das Ergebnis wird als Hauptzugang, Ersatzzugang und verbotener Einsatzbereich festgehalten.

Die verbotenen Einsatzbereiche sind besonders wichtig. Ein Modus kann für Berichte geeignet sein, aber für direkte Produktionsänderungen ausgeschlossen werden. Ebenso kann ACP technisch funktionieren, ohne für einen kleinen Einzelnutzer den zusätzlichen Betriebsaufwand zu rechtfertigen.

Fünfter Schritt: Kleine Teams mit einer Konfiguration statt einem Eingang vereinheitlichen

In einem kleinen Team müssen nicht alle Personen dieselbe Oberfläche verwenden. Ein Entwickler kann Web bevorzugen, während ein Automatisierungsingenieur Headless nutzt und ein internes Werkzeug ACP integriert. Vereinheitlicht werden sollten jedoch die Dinge, die Auswirkungen auf Sicherheit und Nachvollziehbarkeit haben.

Zentral zu verwalten sind:

• Modellname, Modellroute und gegebenenfalls Basis-Endpunkt;
• zulässige Plugin-Versionen und Änderungsprozess;
• Arbeitsbereichs- und Dateiberechtigungen;
• Regeln für Geheimnisse und personenbezogene Daten;
• Protokollformat, Aufbewahrung und Zugriff;
• Testaufträge für Updates;
• Kriterien für Freigabe, Rollback und Incident-Analyse.

Individuell bleiben dürfen Tastaturbelegung, Web-Darstellung, persönliche Sitzungsorganisation und die Wahl zwischen manueller und skriptgestützter Ausführung, sofern die Aufgabe innerhalb derselben Sicherheitsgrenzen bleibt.

Für den Fernbetrieb ist eine kontrollierte Umgebung wichtiger als eine frei erreichbare Oberfläche. Wer DeepSeek Harness auf einem entfernten Mac testen möchte, sollte daher zuerst die RUVCLOUD-Übersicht für entfernte Mac-Arbeitsplätze und anschließend die Bestellung einer passenden Mac-Umgebung prüfen. Die eigentliche Verantwortung für Zugriffsschutz, Benutzerkonten und Arbeitsbereichstrennung bleibt bei der betreibenden Organisation.

Sechster Schritt: Plattformbetrieb mit Rückfallpfad planen

Ein dauerhaft laufender Headless- oder ACP-Eingang benötigt eigene Betriebsgrenzen. Dazu gehören Prozessüberwachung, Ressourcenlimits, Protokollrotation, abgestufte Berechtigungen und ein definierter Umgang mit hängenden Sitzungen. Bei ACP kommt zusätzlich die Frage hinzu, wie lange eine Sitzung offen bleiben darf und wie ein Host nach einem Verbindungsabbruch weiterarbeitet.

Da sich das Projekt in der Developer Preview befindet, sollte eine Plattformmannschaft Updates nicht direkt in den Hauptpfad übernehmen. Ein sicherer Pilot besteht aus zwei Spuren:

• Die bestehende Web- oder Kommandozeilenroutine bleibt für wichtige Aufgaben verfügbar.
• Der neue Headless- oder ACP-Eingang verarbeitet zunächst nur denselben risikoarmen Referenzauftrag und wird anhand gespeicherter Ergebnisse verglichen.

Erst wenn Start, Ergebnis, Abbruch, Rechte, Logs und Wiederherstellung über mehrere Aktualisierungen hinweg nachvollziehbar bleiben, kann der neue Eingang mehr Verantwortung übernehmen. Ein Rollback ist dabei kein Zeichen gegen ACP oder Headless, sondern eine notwendige Eigenschaft eines Preview-Betriebs.

Vergleich vor der Entscheidung

Die technischen Beispiele und Startvoraussetzungen sollten vor jeder Aktualisierung erneut mit dem offiziellen Repository, dem offiziellen Entwicklungsleitfaden und der Architekturdokumentation abgeglichen werden. Der Entwicklungsleitfaden nennt derzeit Node.js ab 22.19 beziehungsweise die 24er-Linie sowie pnpm 11.7.0 als Projektvoraussetzungen; diese Angaben gelten für den dokumentierten Quellcodeaufbau und nicht automatisch für jede vorgefertigte Ausführung.

Für die meisten Einzelentwickler lautet die belastbare Entscheidung daher: Web als Hauptzugang, Headless erst bei wiederkehrenden und prüfbaren Aufgaben, ACP nur bei einem realen übergeordneten Client. Kleine Teams müssen nicht denselben Eingang erzwingen, sollten aber dieselbe Modellroute, dieselben Rechte und dieselben Nachweise verlangen.

Wer derzeit über lokale Shell-Skripte, eine schwer zugängliche Entwicklungsmaschine oder eine gemeinsam genutzte Remote-Umgebung arbeitet, trägt häufig drei Nachteile gleichzeitig: unklare Zugriffstrennung, uneinheitliche Laufzeitbedingungen und erschwerte Wiederherstellung nach einem abgebrochenen Auftrag. Eine gemietete Mac-Umgebung von RUVCLOUD kann für zeitlich begrenzte Web-, Headless- oder ACP-Tests sinnvoller sein, weil der Testarbeitsplatz nicht dauerhaft angeschafft und gewartet werden muss. Für dauerhaft hohe Auslastung, spezielle physische Schnittstellen oder eine streng lokal gebundene Datenverarbeitung bleibt ein eigener Mac die ehrlichere Wahl. Wenn dagegen nur ein isolierter Preview-Test, ein Fernzugriff oder ein kurzfristiger CI-Versuch ansteht, ist eine temporäre Umgebung der naheliegendere nächste Schritt.