KI-Agent zur Fehlerbehebung: So baut man einen Agenten, der Bugs zuerst reproduziert

Ein KI-Agent, der Bugs selbstständig behebt, funktioniert nur, wenn er eine Regel befolgt: keine Reproduktion, keine Lösung. Der Agent verwandelt den Bug-Report in einen Test, der aktuell fehlschlägt, patcht den Code auf einem isolierten Branch, führt diesen Test erneut aus – zusammen mit der gesamten Testsuite – und meldet sich erst zurück, wenn alles grün ist. Das Merging übernimmt weiterhin ein Mensch. Kann er den Bug nicht reproduzieren, bleibt er still.

Testen Sie Apidog noch heute

Das DeepSeek-Harness-Team stellte diese Idee am 1. November 2026 einem breiten Publikum vor – in einem Essay zum Design von Super-Agenten. Diese Anleitung macht daraus eine Pipeline, die Sie noch diese Woche bauen können: mit einer Reproduktion, die als API-Test vom Agenten selbst erstellt und im Terminal ausgeführt wird.

Warum „Agent, behebe das“ ohne Repro scheitert

Bittet man einen Coding-Agenten, einen Bug-Report zu beheben, erhält man meist einen souveränen Diff. Ob damit Ihr Bug behoben wird, ein eingebildeter Bug oder gar nichts – das lässt sich nicht erkennen.

Ohne Reproduktionsschritt gehen drei Dinge schief:

• Der Agent rät die Ursache. Er wählt die plausibelste Zeile anhand der Fehlermeldung und bearbeitet sie.
• „Behoben“ hat keine Definition. Der einzige Beweis ist die eigene Zusammenfassung des Agenten.
• Regressionen schleichen sich ein. Ein Patch an einem gemeinsamen Validator kann einen Endpunkt reparieren und vier andere beschädigen.

Ein fehlschlagender Test löst alle drei Probleme: Er verankert den Bug, definiert „fertig“ und bleibt als Regressionstest in Ihrer Suite.

Woher „stillschweigend reproduzieren und beheben“ stammt

In „Exploring Super-agent Design“ beschreibt das DeepSeek-Harness-Team eine Richtlinie aus seiner eigenen Nutzergruppe: Meldet jemand einen Bug, versucht ein Agent, ihn im Hintergrund zu reproduzieren. Er äußert sich erst, wenn es eine bestätigte, einfache Lösung gibt. Andernfalls schweigt er.

Das Essay nennt das spekulative Ausführung und kombiniert es mit zwei Bausteinen, die Sie hier wiederverwenden. Worker erhalten je Aufgabe eine isolierte Session, sämtliche Tools und das stärkste Modell – und berichten an einen Router, statt mit Menschen zu sprechen. Ein Watchdog ist eine separate Session, die prüft, ob jeder Worker Fortschritte macht oder abdriftet.

Ein Vorbehalt: Das Essay beschreibt eine Architektur, keine ausgelieferten DeepSeek-Harness-Features. Teile davon stecken in einem Prototyp-Plugin, dsh-superagent-prototype, das laut den Autoren kein offizielles DeepSeek-Produkt ist. Zum Router-und-Worker-Bild siehe wie man einen Super-Agenten baut.

Die fünfstufige Agent-Pipeline zur Bugbehebung

Ein sich selbst reparierender Agent durchläuft jedes Mal dieselbe Schleife – mit zwei Schranken:

1. Aufnahme: Bericht, die fehlschlagende Anfrage und die erhaltene Antwort einsammeln.
2. Reproduzieren: Einen Test schreiben, der aus dem gemeldeten Grund fehlschlägt. Kein fehlgeschlagener Test, keine Lösung.
3. Beheben: Den Code auf einem isolierten Branch oder Worktree patchen.
4. Erneut ausführen: Der neue Test muss bestehen, ebenso die bestehende Suite.
5. Übergeben: Einen Pull Request mit den Nachweisen öffnen – oder schweigen.

Schritt 1: Den Bug-Report aufnehmen

Ihr Agent kann „der Checkout ist wieder kaputt“ nicht reproduzieren. Geben Sie der Aufnahme eine feste Struktur:

Fehlen Felder, fragt der Agent einmal nach oder zieht die Anfrage aus den Logs. Error-Bodies, die den RFC-9457-Problem-Details folgen, helfen, weil der Fehlertyp in einer vorhersagbaren Form ankommt.

Schritt 2: Den Bug als fehlschlagenden API-Test reproduzieren

Das ist die Schranke. Der Agent wandelt den Aufnahme-Datensatz in einen Testfall mit zwei Assertions um – den erwarteten Statuscode und ein Feld, das die Antwort enthalten soll – und führt ihn gegen die echte Umgebung aus. Drei Ausgänge sind möglich:

• Er schlägt aus dem gemeldeten Grund fehl. Sie haben eine Repro. Weiter geht’s.
• Er besteht. Der Bug ist wie beschrieben nicht reproduzierbar. Loggen und stoppen.
• Er schlägt aus einem anderen Grund fehl (Auth-Fehler, fehlende Daten, Timeout). Das ist eine defekte Repro, kein bestätigter Bug. Stoppen.

Nur der erste Fall schaltet eine Lösung frei. Das bedeutet „stillschweigend“ in der Praxis: Die anderen beiden erzeugen einen Log-Eintrag für diejenigen, die die Warteschlange prüfen – nicht eine Nachricht im Chat des Nutzers.

Schreiben Sie die Repro als API-Test, nicht als Unit-Test: Der Agent trifft dieselbe Schnittstelle wie der Nutzer, sodass er nicht versehentlich einen anderen Bug reproduziert.

Schritt 3: Den Code in einem isolierten Branch beheben

Sobald die Repro rot ist, erhält der Worker eine eigene Kopie des Codes. Ein git worktree ist die leichtgewichtigste Option: ein zweites Arbeitsverzeichnis auf einem neuen Branch, sodass die Änderungen des Agenten Ihr Checkout nie berühren. Führen Sie den Service daraus aus und verweisen Sie die Testumgebung dorthin.

Halten Sie zwei Einschränkungen streng ein. Die Lösung muss klein sein: Legen Sie ein Limit fest, etwa 3 Dateien oder 50 geänderte Zeilen, und behandeln Sie alles Größere als Meldung für einen Menschen. Und sie muss die Repro zielen: keine Refactorings, Umbenennungen oder Aufräumarbeiten – jede zusätzliche Änderung ist etwas, das Ihr Reviewer prüfen muss.

Schritt 4: Repro und gesamte Suite erneut ausführen

Die zweite Schranke hat zwei Teile. Zuerst führt der Agent denselben Testfall aus Schritt 2 unverändert erneut aus – und er muss bestehen. Hat der Agent die Assertions bearbeitet, um dorthin zu gelangen, scheitert die Lösung; Ihre Pipeline findet das heraus, indem sie die Testdatei vor und nachher vergleicht.

Zweitens muss die bestehende Suite grün bleiben. Eine Lösung, die einen Test grün und drei rot macht, geht zurück zu Schritt 3. Begrenzen Sie die Schleife zeitlich, etwa auf 3 Versuche oder 20 Minuten, dann stoppen und protokollieren, was versucht wurde. Hier beweist der Watchdog seinen Wert: Er kann einen Worker abwürgen, der immer wieder dieselbe Zeile bearbeitet oder in Dateien abdriftet, die die Repro nie berührt hat.

Schritt 5: Nur eine bestätigte, einfache Lösung übergeben

Sind beide Schranken grün, öffnet der Agent einen Pull Request mit Nachweisen, nicht mit einer Erzählung: der Bericht, der fehlgeschlagene Lauf, der Diff und der erfolgreiche Lauf samt Suite-Ergebnissen. Ein Mensch prüft und merged. Geschützte Branches stellen sicher, dass das Token des Agenten zwar Branches pushen, aber nie in main mergen kann. Scheitert eine Schranke, hört der Melder nichts; der Agent schreibt eine Log-Zeile und macht weiter.

Schutzmaßnahmen für einen sich selbst reparierenden KI-Agenten

Errichten Sie diese Zäune, bevor der erste unbeaufsichtigte Lauf startet:

Zugangsdaten sind am wichtigsten: Eine Repro trifft die API tatsächlich – nutzen Sie also Staging oder lokale Testdaten.

Ihren Coding-Agenten die Repro mit Apidog CLI erstellen lassen

Schritt 2 ist das Herz der Pipeline – und genau dafür wurde die Apidog CLI gebaut. Ihr Coding-Agent (Claude Code, Codex, Cursor oder OpenCode) schreibt den Testfall als JSON, legt ihn in Ihrem Apidog-Projekt an und führt ihn im Terminal aus. Sie schreiben nur einen Prompt.

Einmalig einrichten:

npm install -g apidog-cli@latest apidog auth login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted 

Dann geben Sie Ihrem Agenten den Bug-Report und diesen [REDACTED PROMPT]
Here is a bug report for POST /orders in Apidog project .
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.

 Der Agent baut das Payload nicht aus dem Gedächtnis. Er liest das Schema, findet eine Kategorie, validiert seine Datei und legt den Testfall erst dann an: 

bash
apidog cli-schema get test-case-create
apidog test-case category --project
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project --file repro-orders.json

 Die Datei, die er schreibt, sieht so aus (die IDs stammen aus Ihrem Projekt): 

json
{
"name": "Repro: POST /orders with null coupon returns 500",
"apiDetailId": 123456,
"categoryId": 1,
"method": "post",
"path": "/orders",
"parameters": {},
"commonParameters": {},
"requestBody": {
"type": "application/json",
"data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
},
"postProcessors": [
{ "type": "assertion", "defaultEnable": true, "enable": true,
"data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
{ "type": "assertion", "defaultEnable": true, "enable": true,
"data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
]
}

 Jetzt der rote Lauf, der den Bug beweist: 

bash
apidog run --test-case --project -e -r cli,json --out-file repro-before

 Der CLI-Reporter zeigt die fehlschlagende Status-Assertion bei einem 500, und `repro-before.json` landet in `apidog-reports/`. Nach der Lösung führt der Agent denselben Befehl mit `--out-file repro-after` aus, und beide Assertions bestehen. Diese beiden Dateien sind die Nachweise im Pull Request. Für Schritt 4 führt er jeden Testfall des Endpunkts aus, damit die Lösung keinen Nachbarn still beschädigen kann: 

bash
apidog test-case run --project --endpoint -e -r cli,json

 Fügen Sie `--upload-report` hinzu, um den Lauf in der Apidog-App anzuzeigen. Nach dem Merge bleibt der Repro-Testfall als Regressionstest in Ihrem Projekt, und derselbe `apidog run` mit `-r junit` lässt sich in CI einbinden, wie in [Apidog CLI in einer CI/CD-Pipeline ausführen](https://apidog.com/de/blog/apidog-cli-ci-cd-pipeline?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) gezeigt. Weitere Setups finden Sie im [Apidog-CLI-Agenten-Workflow](https://apidog.com/de/blog/apidog-cli-agent-workflow?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) und unter [Apidog CLI in Claude Code](https://apidog.com/de/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Apidog Free deckt bis zu 4 Nutzer ab – Sie können also die gesamte Schleife ohne Bezahlplan ausprobieren. ## FAQ ### Kann ein KI-Agent Bugs wirklich ohne Menschen beheben? Er kann viele einfache Bugs selbstständig reproduzieren, patchen und beweisen – aber er sollte sie nicht mergen. Behalten Sie einen Menschen beim Merging, und lassen Sie den Branch-Schutz das durchsetzen. ### Was, wenn der Agent den Bug nicht reproduzieren kann? Er stoppt und protokolliert, was er versucht hat. Ein Bug, den er nicht reproduzieren kann, ist eine Lösung, die er nicht bestätigen kann – jeder Patch wäre ein Ratespiel. Ein Mensch ergänzt dann Details im Bericht oder schließt ihn. ### Wie verhindere ich, dass der Agent den Test so bearbeitet, dass er besteht? Speichern Sie eine Kopie oder einen Hash des Testfalls, sobald er erstmals fehlschlägt, und vergleichen Sie, bevor Sie die Lösung akzeptieren. Halten Sie die Testdatei außerhalb der Pfade, die der Worker bearbeiten darf. ### Brauche ich DeepSeek Harness, um das zu bauen? Nein. Das Essay beschreibt ein Design, und sein Prototyp-Plugin ist kein offizielles DeepSeek-Produkt. Jeder Coding-Agent, der Shell-Befehle ausführt, funktioniert – auch Claude Code in [GitHub Actions](https://apidog.com/de/blog/claude-code-github-actions?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Sehen Sie sich [an, was DeepSeek Harness ist](https://apidog.com/de/blog/what-is-deepseek-harness?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation), wenn Sie es dort ausprobieren möchten.