Wo die Schleife mit dem Trae Debugging Tool stagniert
Ein Agent, der aus dem Quellcode heraus debuggt, kann lesen, schlussfolgern und ändern. Beobachten kann er nicht. Die Beobachtung liefern Sie – in Prosa, aus dem Gedächtnis –, und dieser Kanal ist schmal. Er transportiert das, was Ihnen aufgefallen ist, und lässt weg, was Sie für nebensächlich hielten – und genau das ist häufig der entscheidende Teil.
Die Stagnation setzt ein, sobald der Agent alle Hypothesen ausgeschöpft hat, die Ihre Beschreibung hergibt. Weitere Runden helfen nicht, weil sich die Eingabe nicht verbessert hat.
Drei Fehlerarten, bei denen das am stärksten durchschlägt
Timing
Etwas wird gerendert, bevor die Daten da sind, oder eine Anfrage wird fertig, nachdem die Komponente bereits verschwunden ist.
Im Diff nicht zu erkennen, beim Zusehen offensichtlich.
Zurückgebliebener Zustand
Die erste Aktion funktioniert, die zweite nicht, weil etwas nicht zurückgesetzt wurde.
Eine Reproduktion, die von vorn beginnt, bringt das nie zum Vorschein.
Abweichende Umgebung
Der Code stimmt, aber die Umgebung spielt nicht mit: eine fehlende Variable, ein veralteter Cache, andere Daten.
Der Agent repariert immer weiter Code, der nie kaputt war.
Den Beobachtungsschritt ergänzen
Statt zu beschreiben, was Sie gesehen haben, lassen Sie etwas die ausgerollte Anwendung bedienen und melden, was dabei passiert ist. Was der Agent dann bekommt, ist ein Protokoll statt einer Erinnerung: was versucht wurde, was die Anwendung getan hat und wo beides auseinanderging.
Das Setup installiert diese Fähigkeit im Agenten, sodass er seine Belege selbst erzeugen und lesen kann, statt darauf zu warten, dass Sie sie ihm weiterreichen.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Dasselbe Setup steht im TestSprite-Dashboard bereit, falls Sie lokal nichts installieren möchten. Der Rest der CLI-Oberfläche findet sich im CLI-Repository.
Zwei Fragen, die eine Stagnation durchbrechen
Tritt der Fehler auch bei einem sauberen Start auf? Wenn ja, ist es ein Logikproblem. Wenn erst beim zweiten Versuch, liegt es an zurückgebliebenem Zustand – und jede bisherige Hypothese auf Code-Ebene hat am falschen Punkt angesetzt.
Tritt der Fehler auch in einer anderen Umgebung auf? Wenn sich derselbe Build an zwei Stellen unterschiedlich verhält, hören Sie auf, am Code zu ändern. Der Unterschied zwischen den Umgebungen ist der Fehler.
Beide Fragen sind schnell beantwortet, und beide lenken die gesamte Sitzung um, wenn die Antwort überrascht.
Die Reproduktion nach der Behebung behalten
Der Fall, den Sie gebaut haben, um den Fehler zu sehen, ist die Prüfung, die seine Rückkehr verhindert. Führen Sie ihn bei jeder Änderung aus, statt ihn zusammen mit dem Gesprächsverlauf zu löschen.
Der Auslöser ist wichtiger als der Mechanismus. Koppeln Sie ihn an Ihr Deployment-Ereignis, wird jede Änderung geprüft, ohne dass es jemand entscheiden muss; die GitHub App erledigt das aus dem Dashboard heraus, und ein Schritt in GitHub Actions erledigt es aus Ihrem Workflow heraus.
Warum schlägt der Agent immer wieder ähnliche Korrekturen vor?
Weil sich die Eingabe nicht geändert hat. Ohne neue Beobachtungen kann er denselben Hypothesenraum nur erneut durchlaufen, nur anders formuliert.
Sollte ich mehr Logs einfügen?
Mehr Signal hilft, und Logs beschreiben, was der Code entschieden hat – nicht, was auf Nutzerseite tatsächlich passiert ist. Ein Durchlauf gegen die echte Anwendung schließt genau die Lücke, die Logs offenlassen.
Ist das spezifisch für Trae?
Nein. Jeder Agent, der aus dem Quellcode heraus debuggt, hat denselben blinden Fleck. Der Workflow unterscheidet sich, der fehlende Schritt ist derselbe.
Was, wenn ich den Fehler nicht zuverlässig reproduzieren kann?
Dann ist genau diese Sprunghaftigkeit der Befund. Führen Sie denselben Fall mehrfach aus und vergleichen Sie. Ein Ablauf, der in einem von vier Fällen scheitert, ist ein Timing- oder Zustandsproblem – das schränkt die Suche erheblich ein.
Muss die Korrektur separat verifiziert werden?
Ja. Eine Korrektur, die von derselben Argumentation vorgeschlagen und bestätigt wird, liefert keinen unabhängigen Beleg. Irgendetwas muss das korrigierte Verhalten beobachten.
Die Schleife braucht eine Beobachtung, keine weitere Runde.
Eine Sitzung mit dem Trae Debugging Tool stagniert, sobald dem Agenten die Hypothesen ausgehen, die Ihre Beschreibung hergibt. Geben Sie ihm echte Beobachtungen der laufenden Anwendung, prüfen Sie, ob der Fehler einen sauberen Start und eine andere Umgebung übersteht, und behalten Sie die Reproduktion als dauerhafte Prüfung.