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
Warum AX Code
Status: Aktiv Geltungsbereich: aktueller Stand Zuletzt geprüft: 2026-08-25 Verantwortlich: Betreuende von AX Code
Die meisten Coding-Agenten optimieren den Moment, in dem Code geschrieben wird. AX Code optimiert den Moment danach: die Entscheidung, ob Sie behalten, was der Agent erzeugt hat.
Worauf AX Code optimiert
Agentenausgabe ist billig zu erzeugen und teuer zu prüfen. Wenn ein Agent zwanzig Dateien in drei Modulen berührt, lautet das Problem der prüfenden Person nicht „ist diese Zeile richtig“, sondern „was hat er tatsächlich getan, besteht es, und was geschieht, wenn ich es rückgängig machen muss“.
AX Code ist um dieses Problem herum gebaut:
- Nachweise. Jede Sitzung wird als typisiertes Ereignisprotokoll aufgezeichnet — Routing-Entscheidungen, Modellaktivität, Schritte, Werkzeugaufrufe, Werkzeugergebnisse — plus Datei-Snapshots, die während des Laufs genommen werden.
- Prüfung. Wo eine Schranke durchsetzbar ist, entscheiden die eigenen Prüfungen Ihres Repositorys. Arena-Kandidaten und angewandtes Refactoring hinter einer Schranke führen Typprüfung, Lint und Tests aus, bevor ein Ergebnis angenommen wird.
- Umkehrbarkeit. Snapshot-Punkte lassen sich je Schritt wiederherstellen, nicht nur je Sitzung, einschließlich Änderungen, die an verschachtelte Sitzungen im selben Arbeitsverzeichnis delegiert wurden.
- Ihre Entscheidung. AX Code ordnet ein, bewertet und berichtet. Es führt für Sie nicht zusammen.
Für wen es gedacht ist
Primäre Zielgruppe:
- Senior- und Staff-Entwickelnde, die folgenreiche Änderungen vornehmen
- Betreuende von Open Source und internen Plattformen
- Teams, die mittlere bis große Git-Repositorys betreiben
- Entwickelnde, die Refactorings, Migrationen und modulübergreifende Korrekturen bewerten
- alle, die unbeaufsichtigte oder geplante Agentenarbeit ausführen, die ein Mensch danach prüfen muss
Nicht die primäre Zielgruppe:
- wer eingebettete Autovervollständigung möchte
- wer eine schnelle, wegwerfbare Änderung vornimmt
- ein Team, dessen Vorrang eine vollständig verwaltete Delegation in die Cloud ist
- wer Git nicht nutzen oder Prüfungen des Repositorys nicht ausführen möchte
Für diese Fälle ist ein schlankerer Editor-Assistent wirklich das bessere Werkzeug, und diese Seite sagt das lieber offen, als zu viel zu versprechen.
Worin es sich unterscheidet
Statt einer Feature-Liste, die veraltet, steht hier, worauf jede Kategorie optimiert:
| Kategorie | Optimiert auf | Worin sich AX Code unterscheidet |
|---|---|---|
| Anbietereigene Modellagenten | die Erfahrung eines Modells, von Anfang bis Ende | AX Code ist modellunabhängig und behält die Aufzeichnung lokal |
| Editor-Agenten | interaktiver Ablauf in der IDE | AX Code zielt auf den Schritt der Prüfung und des Audits, nicht auf das Tippen |
| Schlanke Terminal-Agenten | Geschwindigkeit und Einfachheit | AX Code nimmt mehr Begriffe in Kauf, dafür eine einsehbare Aufzeichnung |
| Cloud-Agenten | verwaltete Delegation und Autonomie | AX Code behält Ausführung und Nachweise auf Ihrem Rechner, Apache-2.0 |
Mehrere Fähigkeiten, die AX Code ausliefert, sind Stand 2026 auch anderswo breit verfügbar: Sandboxing, Prüfpunkte und Wiederherstellung, MCP, Hooks, Skills, Unteragenten, Worktree-Isolation, Zeitplanung, Anbieterwahl und das Ausführen eines Prompts über mehrere Modelle. Keine davon allein ist ein Grund, AX Code zu wählen.
Die Kombination, die sich anderswo schwerer zusammensetzen lässt, ist eine isolierte Kandidatenimplementierung, gebunden an die eigenen Prüfungen des Repositorys, mit Rangfolge Prüfung zuerst, mit vollständig lokal behaltener und exportierbarer Ausführungsaufzeichnung — und ohne automatisches Zusammenführen.
Was wir nicht behaupten
Eine Positionierung nützt nur, wenn sie dem Produkt standhält. Ausdrücklich:
replayrekonstruiert; es führt nicht erneut aus. Es baut den aufgezeichneten Ereignisstrom neu auf und prüft ihn. Es führt Modelle, Werkzeuge oder die Außenwelt nicht erneut aus.riskist eine deterministische Heuristik, berechnet aus Änderungshäufigkeit, Prüfzustand, Werkzeugfehlern, berührten Pfaden und Mustern sicherheitsempfindlicher Dateien. Sie ist keine Wahrscheinlichkeit, kein kalibriertes Vertrauen und keine Sicherheitszusage.branchzweigt den Sitzungszustand ab, nicht einen Git-Branch und keinen Worktree. Arena ist der Implementierungsweg über Git-Worktrees.comparevergleicht Läufe, nicht Quellcode. Es berichtet Risiko, Entscheidungspfad und Ereigniszahlen — es ist keine Ansicht für Code-Diffs.- Prüfungsschranken sind nicht allgemein. Sie gelten für Arena-Kandidaten und für angewandtes Refactoring hinter einer Schranke. Gewöhnliche interaktive Bearbeitungen werden nicht automatisch geprüft.
- Prosa von AX Wiki wird vom Modell erzeugt, aus zitierten Quellen. Der Rahmen darum für Planung, Validierung, inkrementelle Aktualisierung und geschützte Abschnitte ist deterministisch.
- Die Sichtbarkeit der CLI-Brücke ist teilweise. AX Code zeichnet die eigene Werkzeugausführung vollständig auf; Arbeit innerhalb eines Hersteller-CLI-Prozesses ist nur über die Ausgabe dieser Brücke sichtbar.
- Manche Fähigkeiten sind optional. Die Laufzeit
workflowerfordertAX_CODE_WORKFLOW_RUNTIME=1.
Herkunft, klar gesagt
AX Code begann auf der unter der MIT-Lizenz stehenden Codebasis von OpenCode. Das bleibt in NOTICE erhalten und wird in der README genannt, statt versteckt zu werden.
Was DEFAI auf dieser Grundlage gebaut hat, ist das Thema dieser Seite: die Schicht der Ausführungsnachweise, die deterministische Debug- und Refactoring-Engine mit Prüfung im Schatten-Worktree, der Graph der Codeanalyse und die Auswirkungsanalyse, die Ausführungsmodi Council und Arena, der Compiler von AX Wiki, Sandboxing auf Betriebssystemebene und AX Code Desktop.
Ein Projekt anzubinden ist keine Ableitung daraus. Der Herkunftsabschnitt der README und NOTICE tragen die Lizenzpflichten nach Apache-2.0 Section 4(d) — sie führen nur Upstream-Projekte auf, deren Code AX Code tatsächlich kopiert und weiterverteilt. Projekte, mit denen AX Code lediglich spricht, stehen dort nicht, auch wenn sie beim Bau der Brücke genau studiert wurden. Die CLI-Anbieter sind der klarste Fall: Claude Code, Codex CLI, Grok Build CLI und Muse Code CLI stehen in den Anbietertabellen, weil AX Code diese lokalen Binärdateien aufruft und ihre Anmeldesitzungen wiederverwendet, nicht weil Code von ihnen hier ausgeliefert wird. Muster von Modellkennungen, Fähigkeitstabellen und anbieterspezifisches Parsen in packages/ax-code/src/provider/ sind die eigene Interoperabilitätslogik von AX Code. Dateien, die wirklich wörtliche Ableitungen sind, tragen eine einzeilige Herkunftszeile, die den Upstream nennt, damit eine Prüfung bewusste Wiederverwendung von einer übersehenen Bereinigung unterscheiden kann.
Weiter
- Ausführungsnachweise — die Befehle, die einen Lauf prüfbar machen
- Geprüfte Änderungen mit mehreren Modellen — Council und Arena
- Hier starten — das mentale Modell des Produkts