AX Code holen · KostenlosDokumentation
AX Code.
de
English繁體中文简体中文日本語한국어FrançaisDeutschBahasa IndonesiaItalianoPortuguês (Brasil)РусскийEspañolTürkçeTiếng Việt
Loslegen

Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

Geprüfte Änderungen mit mehreren Modellen

Status: Aktiv Umfang: aktueller Stand Zuletzt geprüft: 2026-08-21 Verantwortlich: AX-Code-Laufzeit

Eine Ablaufseite für die Aufgabe: „Ich habe eine folgenreiche Änderung, ich möchte mehr als einen Versuch dafür, und die eigenen Prüfungen des Repositorys sollen entscheiden, welcher Versuch es wert ist, behalten zu werden.“

Für die Modusreferenz — Flags, Konfigurationsschlüssel, Eingaben der Rangfolge — siehe Ausführungsmodi. Diese Seite ist die Aufgabe von Anfang bis Ende.

Wann sich das lohnt

Mehrere Modelle auszuführen kostet ein Mehrfaches eines einzelnen Laufs. Es lohnt sich, wenn die Änderung folgenschwer ist und ein Fehlschlag später teuer zu entdecken wäre: eine Umstrukturierung über Modulgrenzen, eine Migration, eine Korrektur in sicherheitsempfindlichem Code oder eine Änderung, bei der Sie wirklich nicht wissen, welcher Ansatz richtig ist.

Es lohnt sich nicht für eine einzeilige Bearbeitung, eine Umbenennung oder etwas, das Sie durch Lesen prüfen könnten.

Zwei verschiedene Werkzeuge

Werkzeug Was es erzeugt Schreibt Dateien?
council unabhängige Prüfmeinungen, zusammengefasst Nein
arena Kandidatenumsetzungen, gereiht Nur in isolierten Worktrees

Verwenden Sie council, um zu entscheiden, was zu tun ist — es fächert eine Entwurfs- oder Prüffrage an mehrere verbundene Anbieter auf und fasst die Antworten zu Befunden von Konsens, strenger Mehrheit, Minderheit und Einzelmeinung zusammen, mit optionalen anonymen Diskussionsrunden. Es ist beratend. Einigkeit unter Modellen ist kein Beweis der Korrektheit, sondern ein Signal dafür, wie umstritten die Frage ist.

Verwenden Sie arena, um zu entscheiden, welche Umsetzung behalten wird.

Der Ablauf implement in der Arena

1. Vorbereiten

Der Modus Implement verlangt ein Git-Projekt mit mindestens einem Commit und einem sauberen primären Worktree. Worktrees der Teilnehmenden werden von einem exakten Basis-Commit erzeugt und können uncommittete Änderungen nicht erben. Committen oder verstauen Sie daher zuerst.

Sie brauchen außerdem mindestens zwei verschiedene wählbare Modelle auf verbundenen Anbietern (ein gemeinsames Gateway wird unterstützt) und modes.arena.enabled: true.

2. Ausführen

/arena <task description>

Jeder Teilnehmende erhält einen eigenen Git-Worktree, erzeugt aus dem aufgezeichneten Basis-Commit, und ein Implement-Agent läuft darin. Teilnehmende ändern Ihren primären Arbeitsbaum nicht.

3. Was AX Code mit jedem Kandidaten tut

  • Schnappt die verfolgten und nicht verfolgten Änderungen des Teilnehmenden in einen dauerhaften Branch-Commit, einschließlich aller Commits, die der Agent selbst gemacht hat.
  • Führt erkannte Projektprüfbefehle aus — Typprüfung, Test, Lint —, aber erst nachdem ein nicht leerer Patch erfasst wurde. Ein leerer Patch kann nicht gewinnen.
  • Reiht standardmäßig Prüfung zuerst: Nur abgeschlossene, nicht leere Patches, die die Prüfung bestehen, können gewinnen. Unter bestandenen Kandidaten bevorzugt es geringeres Risiko und vielfältigere Patches.

4. Entscheiden

Der Bericht gibt Ihnen Worktree-Pfade, Branch-Namen und Commit-Bereiche.

AX Code führt den Gewinner nicht zusammen. Prüfen, zusammenführen oder Cherry-pick machen Sie selbst. Das ist absichtlich: Prüfung bedeutet „Ihre konfigurierten Prüfungen sind auf diesem Patch bestanden“, was ein echtes Signal ist, aber kein Ersatz für eine Durchsicht.

5. Prüfen und bei Bedarf zurücknehmen

Sobald ein Kandidat in Ihrem Baum ist, gelten die Nachweisbefehle wie gewöhnlich:

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

Siehe Ausführungsnachweise.

Was „geprüft“ hier genau bedeutet

Es bedeutet: Die erkannten Befehle des Projekts für Typprüfung, Lint und Test liefen gegen den Patch dieses Kandidaten und bestanden.

Es bedeutet nicht, dass die Änderung korrekt, vollständig, sicher oder gut entworfen ist. Wenn Ihre Testsuite das geänderte Verhalten nicht abdeckt, beweist ein bestandener Kandidat nur, dass nichts bereits Abgedecktes zerbrochen ist. Die Prüfung hebt den Boden an und zertifiziert die Decke nicht.

Das erstreckt sich auch nicht auf gewöhnliches interaktives Bearbeiten. Arena-Kandidaten und die gesteuerte Anwendung einer Umstrukturierung führen Prüfungen aus. Ein normales edit oder write in einer gewöhnlichen Sitzung tut das nicht automatisch. Führen Sie verify_project aus, wenn Sie diesen Nachweis für einen gewöhnlichen Lauf aufgezeichnet haben wollen.

Kosten und Fehlermodi

  • Die Kosten skalieren mit den Teilnehmenden. Jeder führt einen vollen Implement-Agenten aus.
  • Ein unsauberer Worktree stoppt den Lauf, bevor etwas anderes geschieht, und zwar absichtlich.
  • Weniger als zwei verschiedene Modelle macht den Vergleich bedeutungslos, und das Werkzeug meldet das, statt eine Rangfolge zu erfinden.
  • Alle Kandidaten können die Prüfung verfehlen. Das ist ein nützliches Ergebnis: Meist war die Aufgabe unzureichend beschrieben, oder die Prüfungen des Repositorys sind strenger, als die Agenten annahmen.