Trae ist eine Schleife. Ihr Builder-Agent liest Ihr Repository, bearbeitet Dateien, führt Befehle im Terminal aus und liest die Ausgabe, um zu entscheiden, was als Nächstes zu tun ist. Warum sind Ihre API-Tests also nicht in dieser Schleife? Sie sitzen in Apidog hinter einer grafischen Benutzeroberfläche und laufen, wenn jemand daran denkt zu klicken. Ihr Agent berührt sie nie.
Die Lösung ist ein einziger Konfigurationsblock. Die Apidog CLI ist ein npm-Paket, apidog-cli, das die in Apidog erstellten Testszenarien direkt von einem Terminal aus ausführt. Sobald die CLI installiert ist und Trae weiß, dass sie existiert, führt der Builder ein Apidog-Szenario auf dieselbe Weise aus wie Ihre Unit-Tests: Befehl ausführen, Exit-Code lesen, Code reparieren, wenn er rot ist.
Wenn Sie die CLI noch nicht installiert haben, tun Sie das zuerst. Wie Sie die Apidog CLI mit einem KI-Codierungsagenten installieren führt Sie durch die npm-Installation, Authentifizierung und den ersten Lauf, wobei der Agent die Eingaben übernimmt. Dieser Artikel setzt voraus, dass apidog --version eine Zahl ausgibt und Ihr Apidog-Konto authentifiziert ist.
Worum es bei diesem Trae geht
Trae ist die KI-IDE von ByteDance, die auf VS Code basiert und einen Agentenmodus namens Builder besitzt, der eigenständig Dateien bearbeitet und Terminalbefehle ausführt. Die Produktdetails können Sie auf Traes offizieller Website nachlesen. Dieser Artikel handelt von der Desktop-IDE, nicht vom eigenständigen Forschungsprojekt trae-agent auf GitHub. Wenn Sie Trae öffnen, ein Chat-Panel neben Ihrem Editor sehen und den Agenten auf Builder umstellen können, sind Sie hier richtig.
Die Unterscheidung ist wichtig, weil Trae eine eigene Methode hat, Projektregeln zu lernen, und dieser Mechanismus ein einmaliges „Meine Tests ausführen“ in etwas verwandelt, das der Builder eigenständig anwendet. Dieser Mechanismus ist eine Projektregeldatei. Wenn Sie zuerst die werkzeugunabhängige Version dieses Workflows wünschen, behandelt der vollständige Apidog CLI-Leitfaden die CLI an sich.
Schritt 1: Die Projektregeldatei hinzufügen
Trae liest Regeldateien, bevor der Builder seine Arbeit aufnimmt. Die projektweite Datei befindet sich gemäß Traes Regeldokumentation unter .trae/rules/project_rules.md im Stammverzeichnis Ihres Repositorys. Der Agent lädt diese Regeln während der Initialisierung und referenziert sie, während er Code generiert und bearbeitet. Es gibt auch eine benutzereigene user_rules.md, die für alle Ihre Projekte gilt; für diesen Workflow ist eine Projektdatei im Repository-Stammverzeichnis ausreichend.
Erstellen Sie .trae/rules/project_rules.md und fügen Sie einen kurzen Block hinzu, der die CLI, den genauen Szenario-Befehl und die Regeln benennt, die den Builder ehrlich halten:
## API testing with the Apidog CLI
When you change code that touches an API endpoint, verify it by running the
Apidog test scenario, not just the unit tests.
Command:
apidog run -t <scenario_id> -e <env_id> -r cli
Rules:
- `apidog run` exits 0 when every assertion passes and non-zero on any failure.
Treat a non-zero exit code as a failing test, even if the summary looks fine.
- This machine is already authenticated via `apidog login`. Never add an
--access-token flag and never put a token in this file.
- If a flag is unknown, run `apidog run --help` and use the exact flag from there.
Deshalb schreiben Sie die CLI in project_rules.md, anstatt sie im Chat zu erwähnen. Eine Szenario-ID, die in das Chat-Panel eingegeben wird, ist nach Beendigung der Sitzung verschwunden. Eine in .trae/rules/project_rules.md ist von nun an für jeden Teamkollegen und jeden Builder-Lauf vorhanden. Trae liest auch .trae/rules/-Ordner in Unterverzeichnissen, sodass ein Monorepo dienstspezifische Regeln neben jedem Dienst speichern kann.
Schritt 2: Den Befehl von Apidog erhalten
Sie müssen den Befehl nicht erraten. Öffnen Sie das Testszenario in Apidog, gehen Sie zu dessen CI/CD-Tab und kopieren Sie die generierte apidog run-Zeile. Sie enthält bereits die echte Szenario-ID nach -t und die Umgebungs-ID nach -e, sodass Sie einen Befehl einfügen, von dem Apidog weiß, dass er gültig ist, anstatt IDs von Hand zu erfinden.
Fügen Sie diese genauen IDs in den Block in .trae/rules/project_rules.md ein und ersetzen Sie die Platzhalter <scenario_id> und <env_id>. Für die vollständige Liste der Flags und deren Funktionen siehe die apidog run Befehlsreferenz.
Schritt 3: Den Builder den Test ausführen lassen
Nachdem der Block vorhanden ist, wechseln Sie Traes Agenten zum Builder und starten Sie ihn in Ihrem Repository. Der Builder lädt project_rules.md bei der Initialisierung, sodass er bereits weiß, dass die CLI vorhanden ist. Nehmen Sie eine Änderung vor, die Ihre API betrifft, oder bitten Sie ihn einfach, die Überprüfung auszuführen:
Run the Apidog test scenario and tell me the exit code.
Der Builder gibt den apidog run-Befehl aus Ihrer Regeldatei aus. Traes Genehmigungsmodell ist hier wichtig: Wenn der Agent einen Shell-Befehl ausführen möchte, empfiehlt er den Befehl und zeigt einen Ausführen-Button an, und der Befehl wird in Traes Terminal erst ausgeführt, nachdem Sie darauf geklickt haben. Sobald er ausgeführt wurde, liest und analysiert der Builder automatisch die Ausgabe. Sie genehmigen also den apidog run-Befehl einmal, und der Agent übernimmt das Ergebnis von dort.
Der -r cli-Reporter gibt ein Schritt-für-Schritt-Ergebnis und eine Zusammenfassung direkt im Terminal aus, wo der Builder jede Anfrage und Assertion liest, sobald sie erfolgt. Sie möchten sehen, wie der Lauf ausgeführt wird und der Builder sowohl die Zusammenfassung als auch den Exit-Code zurückmeldet.
Schritt 4: Den Bericht in Trae lesen
Wenn ein Lauf rot wird, enthält der Bericht die Antwort. Mit -r cli erhält der Builder eine lesbare Aufschlüsselung in Traes Terminal: jede Anfrage, jede Assertion und welche davon mit erwartetem versus tatsächlichem Wert fehlgeschlagen ist. Die fehlerhafte Assertion benennt das genaue Feld oder den Statuscode, was normalerweise ausreicht, damit der Builder die Lösung findet.
Für einen Bericht, den Sie in einem Browser öffnen oder einem Teamkollegen übergeben können, fügen Sie den HTML-Reporter hinzu:
apidog run -t <scenario_id> -e <env_id> -r cli,html
Der html-Reporter schreibt eine eigenständige Datei nach ./apidog-reports. Behalten Sie cli in der Liste, damit der Builder weiterhin die Inline-Ausgabe erhält, die er liest, um seinen nächsten Schritt zu entscheiden. Für jeden Reporter, einschließlich der JSON- und JUnit-Formate, die CI-Dashboards parsen, siehe den Leitfaden zu Apidog CLI-Testberichten.
Trae-Tests innerhalb seiner eigenen Schleife
Der springende Punkt ist, was passiert, wenn Sie aufhören zu fragen und der Builder das Szenario eigenständig ausführt, weil project_rules.md es ihm befohlen hat.
Stellen Sie sich vor, der Builder bearbeitet einen Handler, der eine Checkout-Antwort erstellt. Seine Schleife ändert sich: Er bearbeitet den Code, dann, anstatt den Sieg zu erklären, führt er Ihr Apidog-Szenario gegen Staging aus, liest den Exit-Code und handelt danach. Grün, es geht weiter. Rot, es öffnet den Bericht, liest, welche Assertion fehlgeschlagen ist (der Statuscode, das fehlende Feld, der falsche Wert), versucht eine Korrektur und führt es erneut aus. Der API-Test wird Teil derselben Bearbeiten-Testen-Beheben-Schleife, durch die der Builder bereits Ihre Unit-Tests laufen lässt. Sie haben eine Anweisung geschrieben und der Builder hat den Befehl in seine bestehende Arbeitsweise integriert.
Dies ist das Delegieren-dann-Verifizieren-Modell, das jeden Agenten-Workflow sicher macht. Der Builder führt den Befehl aus und liest das Ergebnis; Sie erstellen weiterhin Szenarien visuell in Apidog und überprüfen stichprobenartig, ob der Agent die Exit-Codes ehrlich liest. Für das breitere Muster siehe wie man KI-Agenten für API-Tests verwendet und das Apidog AI Test Harness.
Verifizieren, dass Trae die CLI tatsächlich ausführt
Agenten melden Erfolge, die sie nicht verdient haben, und der Builder ist da keine Ausnahme. Drei Prüfungen, in der Reihenfolge ihrer Häufigkeit, Probleme zu erkennen.
Überprüfen Sie zunächst, ob der Befehl überhaupt ausgeführt wurde. Trae zeigt die vom Builder ausgeführten Befehle und deren Ausgabe im Terminal an. Suchen Sie nach der literalischen apidog run-Zeile und einem Ergebnis darunter. Wenn der Builder angibt, die Tests ausgeführt zu haben, Sie aber den Befehl nicht sehen, hat er etwas zusammengefasst, das er nie getan hat. Bitten Sie ihn, es erneut auszuführen und die Rohausgabe anzuzeigen.
Zweitens, den Exit-Code bestätigen:
What was the exit code of that apidog run command?
apidog run beendet mit 0, wenn jede Assertion erfolgreich ist, und mit einem Wert ungleich 0, wenn etwas fehlschlägt. Dieses einzelne Verhalten ermöglicht es dem Builder oder einer Pipeline, den Lauf als sauberes Gate zu behandeln. Wenn der Builder im Text sagt „Tests bestanden“, der Exit-Code aber ungleich 0 ist, hat der Exit-Code Recht.
Drittens, bestätigen Sie, dass es das echte Szenario verwendet hat. Wenn ein Lauf mit „scenario not found“ fehlschlägt, hat der Builder möglicherweise eine ID erfunden oder falsch erinnert. Überprüfen Sie die Werte für -t und -e erneut mit project_rules.md und dem von Apidog im CI/CD-Tab generierten Befehl. Die IDs in Ihrer Regeldatei sind die Wahrheit.
Optional: Den Apidog MCP-Server verbinden
Das Ausführen von apidog run aus project_rules.md deckt die meisten Ihrer Anforderungen ab. Das Verbinden eines MCP-Servers geht noch einen Schritt weiter. Trae-Agenten agieren als MCP-Clients, sodass der Builder Tools aufrufen kann, die ein MCP-Server zur Verfügung stellt.
Um einen hinzuzufügen, öffnen Sie Traes Einstellungen, gehen Sie zum MCP-Tab und wählen Sie entweder einen Server aus dem Marktplatz oder wählen Sie Manuell hinzufügen und fügen Sie einen JSON-Block mit command, args und env des Servers ein, gemäß Traes Leitfaden zum Hinzufügen von MCP-Servern. Der Apidog MCP-Server stellt Ihre API-Spezifikationen über MCP bereit, sodass der Builder Ihr Schema lesen kann, während er Code schreibt, und nicht erst nachträglich. Die Arbeitsteilung ist sauber: Die CLI führt die Tests aus, und MCP liefert dem Agenten die Spezifikation.
Wenn Trae es falsch macht
Einige Fehler treten während der Einrichtung häufig auf.
Er ignoriert die Regeldatei. Wenn der Builder einen generischen Befehl oder gar keinen ausführt, wird die Datei möglicherweise nicht geladen. Bestätigen Sie, dass sie sich unter .trae/rules/project_rules.md im Stammverzeichnis Ihres Repositorys befindet und dass der Ordner rules und nicht rule heißt. Das Neustarten der Sitzung erzwingt ein erneutes Lesen der Regeln.
Er übergibt trotzdem ein Access Token. Wenn der Builder versucht, --access-token hinzuzufügen, rät er aus öffentlichen Beispielen. Der Block weist ihn bereits an, dies nicht zu tun, da die Maschine über apidog login authentifiziert ist. Bekräftigen Sie die Zeile und legen Sie niemals ein echtes Token in project_rules.md ab. Wie die CLI Anmeldeinformationen im interaktiven Gebrauch und in CI handhabt, siehe Apidog CLI-Authentifizierung.
Er erfindet ein Flag. Ein Fehler „unknown option“ bedeutet, dass der Builder ein Flag geraten hat, das Ihre Version nicht besitzt. Sagen Sie ihm, er solle apidog run --help ausführen und das genaue Flag von dort kopieren, was für Ihre installierte Version immer korrekt ist.
Er meldet einen Erfolg bei einem fehlgeschlagenen Lauf. Dies ist der kostspieligste Fehler und der Grund, warum die Exit-Code-Regel in Ihrer project_rules.md und Ihrem Verifizierungsschritt enthalten ist. Wenn die Zusammenfassung und der Exit-Code nicht übereinstimmen, gewinnt der Exit-Code.
Vom täglichen Agenten zu einer getesteten Schleife
Das ist die Einrichtung. Installieren Sie apidog-cli einmal gemäß der Installationsanleitung, fügen Sie einen kurzen Apidog-Block zu .trae/rules/project_rules.md hinzu, und der Builder weiß, wie er Ihre API-Tests ausführt und das Ergebnis innerhalb derselben Schleife liest, die er bereits zum Bearbeiten von Code verwendet. Ein defekter Endpunkt wird erfasst, während der Builder noch an der Änderung arbeitet, nicht erst, nachdem sie ausgeliefert wurde.
Ein Test hinter einer grafischen Benutzeroberfläche wird ausgeführt, wenn ein Mensch klickt; ein einzeiliger Befehl wird ausgeführt, wann immer der Builder dies entscheidet. Sie erstellen Szenarien weiterhin visuell in Apidog, und Ihr Agent führt sie aus, wo Sie nicht zusehen. Laden Sie Apidog herunter, erstellen Sie ein Szenario, fügen Sie den apidog run-Befehl in .trae/rules/project_rules.md ein und beobachten Sie, wie der Builder ihn bei der nächsten Änderung aufgreift. Wenn Sie bereit sind, dasselbe Szenario ohne einen Agenten auszuführen, behandelt Apidog CLI in GitHub Actions die Geheimnisse, Reporter und Exit-Code-Gating für CI.