# Wie reproduziert man einen Fehler eines Coding-Agenten über Modellversionen hinweg? > Erfassen Sie den vollständigen Lauf als versioniertes Test-Fixture und spielen Sie denselben Prompt, Commit, Tool-Vertrag, dieselbe Umgebung und dieselben Stoppregeln mit festgelegten Modell-IDs ab. Vergleichen Sie strukturierte Ereignisse und den finalen Repository-Zustand, nicht nur den Text des Assistenten. # Wie reproduziert man einen Fehler eines Coding-Agenten über Modellversionen hinweg? Eine nützliche Reproduktion ist ein ausführbares Experiment und kein kopiertes Transkript. Beginnen Sie mit dem fehlerhaften Repository-Zustand, frieren Sie jede für den Agenten sichtbare Eingabe ein und definieren Sie den Fehler mit einer maschinenprüfbaren Assertion. Spielen Sie das Fixture anschließend mehrfach mit festgelegten Modellversionen ab. Ein Agentenlauf kombiniert Modell, Tools, Dateien, Netzwerk, Orchestrierung und Timing. Ändert sich eine Komponente, beweist ein anderes Ergebnis nicht, dass das Modell den Fehler verursacht oder behoben hat. ## Den Fehler als Assertion definieren Formulieren Sie die kleinste beobachtbare Bedingung, die Fehler und Erfolg trennt: ein weiterhin fehlschlagender Test, eine unerwartete Dateiänderung, ein verbotener Befehl, eine fehlende Migration oder ein kompilierender Patch mit geändertem Verhalten. Vermeiden Sie Kriterien wie „die Antwort wirkt schlechter“. Für eine Reparatur kann gelten: * Der ursprüngliche Regressionstest besteht. * Alle bestehenden Tests bestehen weiterhin. * Keine Datei außerhalb der Erlaubnisliste ändert sich. * Der Agent stoppt innerhalb einer festen Anzahl von Modellaufrufen. * Der finale Diff enthält keine generierten Geheimnisse oder Lockfile-Drift. ## Die vollständige Ausführungshülle erfassen Der Prompt ist nur eine Eingabe. Speichern Sie mit dem Fixture: | Ebene | Was eingefroren wird | Warum es Ergebnisse ändert | |---|---|---| | Repository | Commit, Submodule, Dirty Patch, ungetrackte Dateien | Der Agent arbeitet auf exakt diesem Quellstand | | Anweisungen | Systemprompt, Repository-Regeln, Nutzeraufgabe | Kleine Textänderungen ändern die Planung | | Modell | Provider, unveränderliche ID, Parameter | Aliase und Defaults können wechseln | | Tools | Namen, JSON-Schemas, Rechte, Timeouts | Fähigkeiten bestimmen den Plan | | Umgebung | Image, OS, Architektur, Abhängigkeitslocks | Befehle und Tests können abweichen | | Externe Daten | Simuliertes HTTP, Uhr, Zufall | Live-Dienste erzeugen Drift | | Orchestrator | Schleifenlimit, Wiederholung, Kontextkompression | Dasselbe Modell kann andere Historie erhalten | Entfernen Sie Geheimwerte, bewahren Sie aber Existenz und Umfang der Zugangsdaten. ## Strukturierte Ereignisse statt nur Text protokollieren Speichern Sie Modell-Requests und Antworten, Tool-Aufrufe und Ergebnisse, Wiederholungen und Stoppentscheidungen als geordnete Ereignisse. Große Ausgaben erhalten einen Hash; das Originalartefakt wird separat gespeichert. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` So erkennen Sie, ob das neue Modell ein anderes Tool wählte, denselben Fehler anders deutete oder andere Belege erhielt. ## Versionen fixieren und Live-Varianz entfernen Verwenden Sie datierte oder unveränderliche Modell-IDs. Vergleichen Sie historische Fehler nicht mit `latest`, das bereits auf einen anderen Build zeigen kann. Führen Sie den Test in einem sauberen Container oder einer VM aus. Ersetzen Sie Live-Suche und veränderliche Paketregister durch aufgezeichnete Antworten oder interne Snapshots. Frieren Sie bei Datumslogik die Uhr ein. Wenn Netzwerk nötig ist, protokollieren Sie jede Antwort und kennzeichnen den Test als teilweise kontrolliert. Ein Seed hilft, friert aber verteilte Inferenz, Tool-Timing oder Provider-Änderungen nicht ein. ## Eine Matrix statt nur eines Paars abspielen Ein Lauf pro Version trennt Regression nicht von Varianz. Halten Sie das Fixture konstant: | Modellversion | Wiederholungen | Erfolgsrate | Median der Aufrufe | Fehlersignatur | |---|---:|---:|---:|---| | Fixierte Baseline-ID | 5 | 4/5 | 9 | Randtest übersehen | | Fixierte Kandidaten-ID | 5 | 1/5 | 13 | Generierte Datei bearbeitet | | Kandidat mit altem Prompt | 5 | 1/5 | 12 | Gleiche Signatur | Fünf Wiederholungen sind ein guter Start. Erhöhen Sie sie bei sporadischen oder kritischen Fehlern. Halten Sie temperature und andere Kontrollen gleich, sofern diese nicht selbst getestet werden. ## Entscheidungen und Repository-Zustand getrennt vergleichen Vergleichen Sie getrennt: * normalisierte Modell- und Tool-Ereignisse; * Befehle und Exit-Codes; * finalen Dateibaum und Patch; * Akzeptanztests und Ressourcen. Der natürliche Begründungstext muss nicht identisch sein. Verschiedene Wege können gleichwertige Patches erzeugen, während ähnlicher Text materielle Befehlsunterschiede verbergen kann. ## Das Fixture nach der Reproduktion minimieren Entfernen Sie nach stabiler Reproduktion nacheinander irrelevante Dateien, Tools, Prompt-Absätze und externe Aufrufe. Ein kleines Fixture läuft schneller und zeigt die kausale Grenze besser. Bewahren Sie den vollständigen Incident-Replay für Audits und den minimalen Regressionstest für laufende Evaluation auf. Fügen Sie Letzteren dem Modell-Upgrade-Gate hinzu. ## Einen portablen Modelladapter verwenden Ein Gateway wie Atlas Cloud kann mehrere Modelle hinter einem OpenAI-kompatiblen Client bündeln, doch Kompatibilität bedeutet kein identisches Verhalten. Modell-IDs und Spezialoptionen gehören in Adapter; der gemeinsame Test verwaltet Fixtures, Ereignisse, Wiederholungen und Assertions. Damit läuft dieselbe Reproduktion bei mehreren Providern ohne neue Evaluationslogik. ## Fazit Frieren Sie die Ausführungshülle ein, spielen Sie fixierte Modelle mehrfach ab und bewerten Sie ausführbare Ergebnisse. Sind nicht alle Incident-Bedingungen reproduzierbar, nennen Sie die noch aktiven Eingaben und behandeln das Ergebnis als Vergleich, nicht als Beweis einer Modellregression. ## FAQ ### Was muss für die Reproduktion eines Agentenfehlers erfasst werden? Erfassen Sie Commit und uncommitted Patch, Prompts und Systemanweisungen, Modell-ID und Parameter, Tool-Schemas und Ergebnisse, Umgebungs-Image, Lockfiles, Berechtigungs- und Netzwerkrichtlinien sowie die genaue Erfolgsbedingung. ### Sollte der Fehler mit einem latest-Modellalias abgespielt werden? Nein. Verwenden Sie unveränderliche oder datierte Modell-IDs. Ein latest-Alias kann sich während des Tests ändern und verhindert eine klare Zuordnung von Erfolg oder Fehler. ### Warum reicht ein fester Zufalls-Seed nicht aus? Ein Seed friert Provider-Infrastruktur, Tool-Timing, Suchergebnisse oder Modellrevisionen nicht ein. Er ist nur eine Kontrollgröße und keine Determinismusgarantie. ### Was ist das beste Erfolgssignal für einen Coding-Agenten? Bevorzugen Sie ausführbare Assertions wie Tests, Lint, erwartete Datei-Diffs, Prüfungen verbotener Dateien und Exit-Codes. Textähnlichkeit ist für Coding-Aufgaben meist zu schwach. ### Wie viele Wiederholungen braucht jede Modellversion? Führen Sie genug Läufe aus, um eine deterministische Regression von Varianz zu trennen. Fünf sind ein praktischer Start; kritische Fehler können zwanzig oder mehr erfordern. ### Kann dasselbe Testsystem Modelle verschiedener Provider vergleichen? Ja, wenn Request, Tool-Vertrag, Ereignisprotokoll und Assertions normalisiert werden. Provider-spezifische Optionen gehören in Adapter.