Was hat DeepSeek Harness verändert? Vom AI Agent Framework zur Next-Gen Coding-Agent-Infrastruktur

Kurzüberblick

Schicht	Ein Satz	Was du pflegst
Agent Framework	Orchestriert Prompts, Tools und Schritte im App-Code	Python/TS-Aufrufgraphen
Agent Harness	Runtime, die Tools, FS, Sandbox und Loop als Plugins mountet	Profile / Bundle / SessionEvent
DeepSeek Harness	MIT-Open-Source-dsh auf Cordis: alles ist Plugin	ctx.*-Services + JSON-Tool-Schemas

Die Trennung merken: Framework liefert Chains; Harness liefert einen austauschbaren Host. Modelle wechseln; Seams und JSON-Verträge sollten bleiben.

Was ist DeepSeek Harness?

DeepSeek Harness (dsh) ist eine Open-Source-Agent-Runtime, die ein LLM mit Dateisystem, Terminal, Browser und anderen Coding-Tools verbindet. Nicht die Modellgewichte—sondern der Host, der einen Coding Agent in der Umgebung am Laufen hält.

Drei Punkte zuerst:

• Everything is a Plugin: Tools, FS, Sandbox und Modell-Adapter mounten/unmounten auf Cordis.
• Kein neues DeepSeek-Modell: das Modell ist die Seele, das Harness Körper für Umgebung, Tools und Loop.
• Coding-Agent-fokussiert: Agent Loop, Session Log und Capability Seam werden First-Class-Konzepte.

Wenn du Agents noch als „längeren Prompt“ denkst, lies zuerst Was ist ein AI Agent zu Host und Vertrag—dann zurück. dsh verschiebt genau diese Host-Seite.

Vom Agent Framework zum Agent Harness

Klassische Agent Frameworks vergraben den Agent Loop oft in einer Klasse. Tool-Registrierung, Chatverlauf, Sandbox und Retries verhärten sich im selben Aufrufgraphen—Austausch wird teuer.

Ein Harness macht Loop, Tools und Session zu austauschbaren Runtime-Teilen. Vier Unterschiede:

• Privilegierter Kernel vs Plugins: Fähigkeiten mounten, statt alles in den Core zu schreiben.
• Chatverlauf vs Session Log: modellsichtbare Eingaben als Event-Sequenz rekonstruieren.
• Hardcodierte Sandbox vs Capability Seam: bash und Editor an Service-Grenzen tauschen.
• Prompt als Produkt vs Config-Komposition: Profile / Bundle / Config-Baum formen das Produkt.

Frameworks lehren „wie schreibe ich die Kette“; Harnesses lehren „auf welchen Host setze ich sie“. Die Lebensdauer von Coding Agents hängt am zweiten.

Everything is a Plugin: dsh auf Cordis

dsh sitzt auf einem Cordis-Plugin-Host. Mount und Unmount sind reversibel. Modell-Adapter, Tools, FS und Sandbox kommen über denselben Mechanismus hinzu oder weg.

Typisch deklarierst du Plugins in cordis.yml (oder einem Patch). Modell-Adapter tauschen, ohne Produktcode neu zu schreiben:

# cordis.patch.yml — swap model + add a tool
plugins:
  - name: llm/deepseek
    config:
      model: deepseek-v4-pro
  - name: tools/my-repo-search
    config:
      root: ./src

Das ist der Praxis-Unterschied zum Framework. Ein neues Tool ist ein Plugin, kein Repo-Fork. Die Produktgrenze wandert zu „welche Plugin-Menge bündelt das Bundle?“.

Capability Seam: Definition, Provider, Consumer

Ein Capability Seam ist die Vertragsfläche einer Fähigkeit. Drei Rollen:

1. Service Definition: Name und I/O-Form (meist JSON Schema / inputSchema).
2. Provider: das Plugin, das bash, Editor, Suche usw. wirklich ausführt.
3. Consumer: Agent Loop oder andere Plugins, die über ctx.* aufrufen.

Beispiel: bash ist Provider des Seams „Shell ausführen“. Der Loop sieht nur die definierte Schnittstelle, nicht die Provider-Innenwelt.

Für das Modell erscheinen Tools als Function-Calling-tool_calls; für den Host als prüfbarer JSON-Vertrag. Typisches Tool-Schema:

{
  "name": "str_replace_editor",
  "description": "Edit a file by exact string replacement",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string" },
      "old_str": { "type": "string" },
      "new_str": { "type": "string" }
    },
    "required": ["path", "old_str", "new_str"],
    "additionalProperties": false
  }
}

Dieselbe Grenze lösen MCP-Tool-Lieferung und API-seitiges Function Calling. Schichten in MCP Tool Schema vs Function Calling; warum Schema zum Runtime-Tor wird in Warum braucht KI JSON Schema.

Session Log: rekonstruieren, was das Modell sah

Chat-Bubbles reichen nicht. Das Session Log speichert modellsichtbare Eingaben, tool_calls, Tool-Ergebnisse und Agent-Events chronologisch.

Debug-Maßstab: kannst du aus dem Log rekonstruieren, was das Modell sah? Ein Tool-Result-Event sieht ungefähr so aus:

{
  "type": "tool/result",
  "tool_call_id": "call_7f2a",
  "name": "bash",
  "ok": true,
  "content": {
    "stdout": "passed 12",
    "exit_code": 0
  },
  "ts": "2026-09-11T06:12:04.221Z"
}

Ist das Log-JSON kaputt, lokal Formatieren und Syntax prüfen und gegen die letzte erfolgreiche Session JSON Diff. Geheimnisse und Nutzerdaten nicht auf öffentliche Sites kleben.

Profile, Bundle, Turn und Step

Die Runtime-Assemblierung hat grob vier Schichten:

• Profile: web oder headless—Startform und Default-Fähigkeiten.
• Bundle: gestapelte Plugin-Mengen. Gleicher Core, andere Bundles = Produktunterschied.
• Turn vs Step: Nutzer-/Agent-Turn getrennt von Tool-Steps darin.
• agent/*-Events: Beobachtungsfläche des Loops im Session Log.

Produktdifferenz ist Profile + Bundle, nicht „noch eine Riesenklasse“. Der Loop selbst bleibt austauschbar.

Vier Modes: Standard / Code / Minimal / Creation

dsh wechselt Modes nach Einsatz. Die Namen bleiben Englisch:

Mode ist keine „Modellpersönlichkeit“, sondern Plugin- und Rechtebündel. Produktion: Minimal/Standard zuerst; Creation nur in vertrauenswürdigen Umgebungen.

Was Next-Gen Coding-Agent-Infrastruktur meint

„Infrastruktur“ meint hier vier Dinge:

• Capability Seam: Fähigkeiten als Vertrag austauschbar.
• Fail-closed Security: ungeprüfte Tool-Argumente kommen nicht durch.
• JSON-Verträge: Tool-Definition, Aufruf und Ergebnis teilen Schema.
• Wiederholbare Sessions: Fehler aus dem Session Log reproduzieren.

Weg vom Prompt als Asset hin zu Schema, Seam und Config-Baum. Anschluss an strukturierte Workflows: JSON Schema und Agent-Workflows.

Framework und Harness nebeneinander

Beides „lässt Agents laufen“—aber die Pflegeeinheit unterscheidet sich:

Nicht „Framework wegwerfen“. Über der Kette braucht es eine austauschbare Host-Schicht.

Typische Fehler

• dsh für ein neues Modell halten. Benchmarks drehen ums Modell; Betrieb ums Harness.
• Für ein Tool das ganze Repo forken. Zuerst Plugin und Seam schreiben.
• Schema-Validierung überspringen. tool_calls ohne inputSchema sind Incident-Eingänge.
• Session Log ignorieren. Viel „Modell spinnt“ ist fehlende Kontext-Rekonstruktion.
• Creation Mode in untrusted Envs. Selbstbezügliches Cordis hat weite Rechte.

FAQ

Unterschied zu Produkten wie Claude Code?

Claude Code ist näher an einem fertigen Coding-Agent-Produkt. dsh ist die austauschbare Harness-/Infrastruktur-Schicht—Open Source, um dieselbe Idee auf den eigenen Host zu bringen.

Nur mit DeepSeek-Modellen?

Nein. Modelle kommen über Adapter. Offizielle Demos zielen auf DeepSeek-Modelle, aber das Design setzt Modell-Austausch voraus.

Ist Cordis Pflicht?

Die Upstream-dsh-Implementierung sitzt auf dem Cordis-Plugin-Host. Die Ideen (Seam, Plugin, Session) sind portierbar; dem offiziellen Tree folgst du über das Cordis-Config-Modell.

Welche Rolle spielt JSON?

Es trägt Tool-inputSchema, Aufrufargumente, Tool-Ergebnisse und SessionEvent-Payloads. Im Harness ist der JSON-Vertrag die Produktgrenze—nicht Prosa.

Produktionsreif?

Eher developer preview. Breaking Changes möglich. Intern/Staging starten, Seams und Schemas zuerst festnageln, dann erweitern.

Fazit

DeepSeek Harness hat nicht die Modellkarte verändert, sondern wie man Coding-Agent-Infrastruktur schneidet. Loop, Tools und Session werden Plugins und JSON-Verträge; der Host wird austauschbar.

Schreib heute zuerst Schemas und Capability Seams. Verlängere nicht den Prompt. Modelle wechseln; Harness-Verträge bleiben.

Weiterlesen

• Was ist ein AI Agent? Tool Calling und JSON Host- und Vertragsgrenze zuerst
• Warum braucht KI JSON Schema? Structured Output und Function-Calling-Vertrag
• MCP Tool Schema vs Function Calling Protokollgrenze für Tool-JSON
• Warum AI Agents jetzt JSON Schema brauchen Von Tool Calling zu strukturierten Workflows
• JSONSort lokale Toolbox Formatieren, prüfen, Diff
• Alle Artikel Notizen zu JSON und AI-Entwicklung

Änderungsprotokoll: 2026-09-11 Erstveröffentlichung