Wenn die Änderung eines Coding-Agenten lokal besteht und in der CI scheitert

Drei Stellen, an denen der Unterschied entsteht

Die lokale Umgebung eines Agenten kann eine gehostete Sandbox, ein CI-ähnlicher Runner oder ein Container auf irgendeinem Rechner sein, jeweils mit eigenem Setup aufgebaut. Daraus ergeben sich drei unterschiedliche Quellen dafür, dass aus einem Bestehen ein Fehlschlag wird.

• Die Umgebung unterscheidet sich: Laufzeit- oder Tool-Versionen, eine ohne Lockfile installierte Abhängigkeit, eine Datenbank oder Queue, die nur an einem Ort läuft, Netzwerkregeln oder Zugangsdaten, die in einer Umgebung verfügbar sind und in der anderen nicht.
• Die Befehle unterscheiden sich: Der Agent hat nur eine Testdatei ausgeführt, Lint oder Typprüfung ausgelassen oder ist einer Anweisungsdatei gefolgt, die einen anderen Befehl nennt als der CI-Workflow.
• Der Test ist nicht deterministisch: Er hängt von Reihenfolge, Zeit, paralleler Ausführung oder geteiltem Zustand ab und besteht oder scheitert auf demselben Commit. Die Instabilität kann schon vor der Änderung bestanden haben oder durch sie entstanden sein.

Ein Ablauf, der die Ursache eingrenzt

1. 1

   Lesen, was der Agent tatsächlich ausgeführt hat

   Öffnen Sie das Sitzungsprotokoll, nicht die Zusammenfassung des Agenten. Notieren Sie die genauen Befehle, ihre Exit-Codes und ob die komplette Suite lief. Anthropics Leitfaden zur Evaluierung unterscheidet zwischen dem, was ein Agent über seine Arbeit sagt, und dem tatsächlichen Ergebnis in der Umgebung, und diese Unterscheidung gilt auch hier.

2. 2

   Den gescheiterten Job mit Debug-Logging wiederholen

   In GitHub Actions wiederholen Sie nur die gescheiterten Jobs mit Runner-Diagnose- und Step-Debug-Logging. Ein Rerun nutzt denselben Commit und dieselbe Ref wie der ursprüngliche Lauf. Ein anderes Ergebnis deutet daher auf die Umgebung oder auf Nichtdeterminismus hin, nicht auf neuen Code.

3. 3

   Basis-Commit und Commit des Agenten vergleichen

   Ein Bestehen beim Rerun entlastet die Änderung nicht, denn auch eine vom Agenten eingeführte Race Condition scheitert nur manchmal. Führen Sie den fehlschlagenden Test wiederholt auf dem Basis-Commit und auf dem Commit des Agenten aus, mit denselben Abhängigkeiten und Diensten, und vergleichen Sie Fehlerraten und Fehlerbilder. Fehlschläge nur mit der Änderung deuten auf die Änderung hin. Fehlschläge auf beiden entlasten sie ebenfalls nicht, denn die Änderung kann einen bestehenden instabilen Test häufiger oder anders scheitern lassen. Ordnen Sie den Test ein, geben Sie ihm einen Owner und ein Ticket und lassen Sie den Agenten ihn nicht durch gelockerte Assertions grün machen.

4. 4

   Den CI-Befehl in einem sauberen Container nachstellen

   Nutzen Sie das CI-Image und dessen Versionen, führen Sie den exakten CI-Befehl aus und vergleichen Sie Laufzeitversionen, installierte Pakete, Umgebungsvariablen und laufende Dienste mit der Umgebung des Agenten.

5. 5

   Das Setup-Protokoll des Agenten prüfen

   Suchen Sie nach gescheiterten Setup-Schritten und blockierten Anfragen. Manche gehosteten Agenten arbeiten nach einem gescheiterten Setup-Schritt einfach weiter, wie unten beschrieben.

gh run rerun RUN_ID --failed --debug

Symptome und wo Sie zuerst nachsehen

• Modul nicht gefunden oder andere Version nur in der CI: Der Agent hat ohne Lockfile installiert oder eine andere Laufzeitversion verwendet.
• Integrationstests scheitern nur an einem Ort: Eine Datenbank, eine Queue oder Seed-Daten gibt es in der einen Umgebung und in der anderen nicht.
• Lint- oder Typfehler nur in der CI: Der Agent hat Tests ausgeführt, aber nicht den vollständigen Check, oder seine Anweisungen nennen einen anderen Befehl.
• Netzwerk- oder Authentifizierungsfehler: Ein Host, der in einer Umgebung erlaubt ist, wird in der anderen blockiert, oder Zugangsdaten kommen nicht so an, wie das Programm sie erwartet.
• Ergebnisse ändern sich zwischen Reruns desselben Commits: Etwas ist nicht deterministisch, im Test, in der Änderung oder in beidem. Vergleichen Sie wiederholte Läufe auf Basis und Änderung, bevor Sie es einordnen.

Fallen, die nur bei gehosteten Agenten auftreten

GitHubs Copilot Cloud Agent führt vor dem Start einen Job copilot-setup-steps aus. Scheitert ein Schritt, überspringt der Agent die übrigen Schritte und arbeitet mit der Umgebung, wie sie ist, sodass eine fehlende Abhängigkeit erst später als merkwürdiges Testergebnis auftaucht. Von seiner Firewall blockierte Anfragen erscheinen als Warnung im Pull Request, mit Adresse und Befehl. Und bei einem Copilot-Pull-Request laufen Workflows erst, wenn jemand mit Schreibrecht Approve and run workflows wählt. Ein fehlendes CI-Ergebnis ist also kein Bestehen.

In OpenAIs Codex Cloud erreichen Network Secrets Programme als Platzhalter, die ein Proxy für erlaubte HTTPS-Ziele ersetzt. Ein Tool, das den Rohwert liest, bekommt den Platzhalter und scheitert auf eine Weise, die es in der CI nicht gibt. Bestehende Codex-Aufgaben behalten außerdem ihre eigenen gespeicherten Dateien und installierten Tools, sodass eine lang laufende Aufgabe nicht zu einer neu veröffentlichten Umgebung passen muss.

Das Harness korrigieren, nicht nur die Änderung

Ein hypothetischer Fall: Die CI führt Tests parallel in Shards aus, der Agent dagegen in einem Prozess. Ein Test, der sich auf den Zustand verlässt, den ein anderer hinterlassen hat, besteht beim Agenten und scheitert in Shard drei. Diesen einen Pull Request zu reparieren hilft einmal. Die dauerhaften Korrekturen liegen im Harness:

• Ein einziger Check-Befehl, den die Anweisungsdatei nennt und die CI ausführt, mit derselben Testreihenfolge und Parallelität
• Laufzeit- und Tool-Versionen, an einer Stelle fixiert, die beide Umgebungen lesen
• Dienste, die für Agent und CI aus derselben Container-Definition starten
• Eine Regel, dass die Beschreibung des Pull Requests die ausgeführten Befehle und ihre Ergebnisse nennt
• Tests, die nach dem Vergleich von Basis und Änderung als instabil eingestuft sind, gekennzeichnet, mit Owner und nachverfolgt und bis zur Reparatur außerhalb des schnellen Testsatzes des Agenten

Scheitert die CI bei einem Aufgabentyp immer wieder aus Umgebungsgründen, holen Sie diesen Typ in die interaktive Arbeit zurück, bis das Harness korrigiert ist. Diese Diagnose und Reparatur gehört zu unserer Arbeit im Harness Engineering mit Plattform-Teams.

Ein Repository für Coding-Agenten vorbereitenHarness Engineering