Agentic Orchestration Teil 4: SemVer-Nuancen und Selbstkorrektur

In Teil 3 haben wir beobachtet, wie unser major-upgrader-Agent Dokumentation liest und Anwendungscode umschreibt. Aber KI-Modelle sind nicht unfehlbar. Was passiert, wenn der Migrationsleitfaden unvollständig ist oder die Codebasis zu komplex ist, als dass der Agent einen Testfehler beheben könnte?

Wir müssen Fehlerbehandlung und Selbstkorrektur direkt in den Orchestrator programmieren.

Die “Three Strikes”-Regel

Wenn der major-upgrader das Validierungstor ausführt (test -> format -> lint -> build), bringt ein Fehler die Pipeline nicht zum Absturz. Stattdessen löst er eine Selbstkorrekturschleife aus.

Der Agent liest die Compiler- oder Testausgabe, durchsucht den Migrationsleitfaden erneut und versucht, den Code zu reparieren. Wenn man ihn jedoch ungebremst lässt, könnte ein LLM versuchen, einen komplexen TypeScript-Fehler 50 Mal hintereinander zu beheben, dabei zunehmend absurde Lösungen halluzinieren und API-Tokens verbrennen.

Um dies zu verhindern, erzwingen unsere Agenten-Anweisungen eine strikte “Three Strikes”-Regel:

If any fails:
1. Read the full error output.
2. Cross-reference migration guide for missed breaking changes.
3. Fix and re-run all four commands.
4. Up to **three fix attempts**.
5. After three failures: run `git reset --hard HEAD && pnpm install`, document the blocker, mark group BLOCKED, and move to next group.

Wenn der Agent das Problem nach drei Versuchen nicht lösen kann, erkennt er seine Niederlage an. Er löst das Rollback-Protokoll aus. Durch Zurücksetzen des Branches und Neuinstallation der alten Abhängigkeiten kehrt das Repository in einen sauberen Zustand zurück. Der Agent protokolliert dann den Blocker in seinem zusammenfassenden Bericht und geht elegant zur nächsten Upgrade-Gruppe über.

Dependency Overrides

Eine weitere häufige Fehlerquelle sind Probleme mit transitiven Abhängigkeiten. Angenommen, pnpm install schlägt fehl, weil eine Unterabhängigkeit eine strenge Peer-Anforderung erzwingt, die mit der neuen Major-Version in Konflikt steht.

Anstatt aufzugeben, ist unser major-upgrader autorisiert, die package.json chirurgisch zu bearbeiten, um pnpm.overrides einzufügen:

{
  "pnpm": {
    "overrides": {
      "obscure-utils": "1.2.3"
    }
  }
}

Durch das zwangsweise Anpinnen problematischer transitiver Abhängigkeiten umgeht der Agent Ökosystemkonflikte. Wenn der Agent den Branch an den pr-creator übergibt, hebt die PR-Beschreibung explizit hervor, dass ein manueller Override angewendet wurde, um sicherzustellen, dass ein menschlicher Ingenieur die Entscheidung überprüft.

Der Abschlussbericht

Am Ende der major-upgrade-Pipeline gibt der Orchestrator einen Abschlussbericht (Final Report) aus, der klar umreißt, was erfolgreich war und was blockiert wurde:

## Completed
| Group | Packages | Before | After | PR |
|-------|----------|--------|-------|----|
| @nestjs/* | 8 | v10 | v11 | #44 |

## Blocked / Needs Manual Intervention
| Group | Blocker |
|-------|---------|
| eslint | 200+ rule violations; requires ESLint config rewrite. Agent failed after 3 attempts. |

Dies gewährleistet null stille Fehler. Im letzten Teil unserer Serie, Teil 5, werden wir untersuchen, wie wir diese Workflows sicher in Docker Sandbox MicroVMs ausführen, um echte “YOLO Mode”-Autonomie zu erreichen.

Bleiben Sie dran und genießen Sie jeden Schritt Ihrer Coding-Reise.