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

Autonomer Modus

Status: Aktiv Umfang: aktueller Stand Zuletzt geprüft: 2026-08-25 Verantwortlich: ax-code-Laufzeit

Der autonome Modus lässt ax-code Aufgaben abschließen, ohne bei jedem risikoarmen Schritt auf eine menschliche Bestätigung zu warten. Ist er aktiv, werden Genehmigungsabfragen automatisch zugelassen, sofern sie nicht ausdrücklich gesperrt sind, und Dialogfragen werden mit einer Best-Practice-Heuristik automatisch beantwortet, die empfohlene, standardmäßige, übliche, einfache und minimale Wahl bevorzugt und riskante oder überkonstruierte Optionen meidet.

Standardmäßig ist der autonome Modus an. Haben Sie ihn zuvor ausgeschaltet, wird diese Einstellung gespeichert und beim nächsten Start wiederhergestellt.

Schnellstart

Umschalten aus der TUI:

• Geben Sie /autonomous in den Prompt ein, oder
• Drücken Sie Ctrl+P und suchen Sie nach „autonomous“, oder
• Klicken Sie auf die Anzeige autonom an/aus in der Statusleiste

Die Statusleiste zeigt den aktuellen Zustand:

• autonom an (gelber Hintergrund, fetter roter Text) — der Agent läuft ohne Pause
• autonom aus (grüner Text) — der Agent hält bei Genehmigungs- und Frageabfragen an

Die Einstellung bleibt über Sitzungen hinweg in ax-code.json erhalten.

Was sich ändert

Funktionsweise

Der autonome Modus wirkt auf drei Ebenen:

Quelle der Wahrheit

Diese Seite fasst das für Sie sichtbare Verhalten zusammen. Ändert sich das Verhalten, prüfen Sie die Dokumentation gegen:

• packages/ax-code/src/session/processor.ts für automatische Genehmigung, Schleifenverhalten, Ablehnungsbehandlung und autonome Obergrenzen.
• packages/ax-code/src/session/system.ts und Anbieter-Prompt-Dateien unter packages/ax-code/src/session/prompt/ für Anweisungen zum autonomen Arbeitsablauf.
• packages/ax-code/src/question/ und packages/ax-code/test/question/question.test.ts für Heuristiken der automatischen Antwort und das Eskalationsverhalten.
• packages/ax-code/src/session/blast-radius.ts für Obergrenzen autonomer Schritte und Dateiänderungen.
• packages/ax-code/test/session/system.test.ts, packages/ax-code/test/session/prompt.test.ts und zugehörige Sitzungstests für das Verhalten von Prompt und Entscheidungsbuch.

Halten Sie die Sicherheitsgarantien hier mit der Sandbox-Dokumentation deckungsgleich; der autonome Modus ändert das Genehmigungsverhalten, nicht die Durchsetzung der Isolation.

1. Automatische Genehmigung (serverseitig)

Der autonome Modus nutzt eine hybride Richtlinie, die Ablehnung zuerst prüft (ADR-004 / PRD v4.2.0). Ruft ein Tool ctx.ask() für eine Genehmigung auf, stuft das Permission-Modul die Genehmigung ein:

• SICHERE Genehmigungen (read, glob, grep, list, lsp, code_intelligence, skill, todoread) werden ohne blockierende Abfrage automatisch zugelassen.
• RISIKO-Genehmigungen (edit, bash, external_directory, task, webfetch, websearch, codesearch, …) fallen in den Regelsatz — die konfigurierten Zulassungs- und Ablehnungsregeln des Agenten gelten weiter, und von Ihnen definierte Ablehnungsregeln werden immer durchgesetzt. Im Sandbox-Modus full-access werden RISIKO-Genehmigungen automatisch zugelassen, nachdem die Ablehnungsregeln ausgewertet wurden.
• Unbekannte Genehmigungen fragen standardmäßig (experimental.autonomous_strict_permission: false behält das frühere Zulassungsverhalten).

Genehmigungen, die immer eine Entscheidung pro Aufruf erreichen, statt sofort regelbasiert zugelassen zu werden: isolation_escalation (Anfragen zur Sandbox-Aufhebung), Genehmigungen INTERACTIVE_ONLY und die Menge NEVER_AUTONOMOUS_AUTOAPPROVE. Eine Einengung (ADR-098): Im Sandbox-Modus full-access werden Anfragen external_directory, die nur als interaktiv markiert sind — Bash-Befehle, deren Pfade sich statisch nicht prüfen lassen, weil sie Glob, Variable oder Brace-Expansion nutzen — ebenfalls automatisch zugelassen, weil eine Sandbox mit vollem Zugriff keine Dateisystemgrenze mehr zu schützen hat. Ausdrückliche Ablehnungsregeln gelten weiter, und Modi mit aktiver Sandbox (workspace-write, read-only) behalten die Abfrage pro Aufruf.

Untätiges „Einmal zulassen“ (standardmäßig an): Auto an plus Sandbox aus (full-access) bedeutet minimale Interaktion: Jede ausstehende Genehmigung kann nach 15 Sekunden einmal automatisch antworten, einschließlich requireInteractive sowie Hook- und Sandbox-Eskalationsabfragen. Auto aus oder Sandbox an verlangt eine menschliche Antwort auf ausstehende Abfragen. WebMCP verlangt zusätzlich, dass die zugehörige Brücke verbunden ist; eine andere verbundene Brücke genügt nicht. Ausdrückliche Ablehnungsregeln gelten weiter. experimental.permission_idle_once.enabled: false schaltet Countdowns ab, und permissions kann ihren Umfang einschränken. Die ältere Einstellung timeout_ms wird aus Kompatibilitätsgründen akzeptiert, ändert die feste Dauer von 15 Sekunden aber nicht mehr.

Der Server besitzt den Countdown. Die älteste Anfrage jeder Sitzung erhält eine Frist; eingereihte Anfragen erhalten frische 15 Sekunden, sobald sie an die Spitze gelangen. Menschliche Antworten brechen den Timer ab. Wird Auto ausgeschaltet, die Sandbox eingeschaltet oder die zugehörige WebMCP-Brücke getrennt, brechen ausstehende Countdowns ab. Stellt sich die Berechtigung wieder her, startet ein neuer Countdown. Kurze Lücken beim Neuladen der Konfiguration setzen den Countdown aus. Automatische Antworten prüfen den aktuellen Modus, die Brücke und die Ablehnungsregeln erneut und speichern nie eine dauerhafte Zulassung. Die interne Debug- und Test-Überschreibung AX_CODE_PERMISSION_IDLE_ONCE_MS bleibt verfügbar und ist auf das Maximum des Node-Timers begrenzt.

Modi gelten für das aktive Verzeichnis. Ein verschachteltes ax-code.json kann die Einstellungen der Repository-Wurzel überschreiben; nutzen Sie den Sandbox-Schalter der aktiven Sitzung, um ihren wirksamen Modus zu ändern.

Nicht überschreibbare geschützte Pfade: Der autonome Modus verweigert außerdem das Schreiben einer festen Menge von Pfaden der Richtlinie und der Steuerungsebene — ax-code.json/ax-code.jsonc, .ax-code/**, .git/config und .git/refs/** —, damit der Agent seine eigene Konfiguration nicht bearbeiten, seine eigenen Autonomiegrenzen nicht anheben und keine Git-Hooks platzieren kann. Anders als die konfigurierbare Liste gesperrter Pfade lassen sich diese weder durch Projekt- noch durch Benutzerkonfiguration entfernen.

2. Automatische Antwort auf Fragen (serverseitig)

Stellt ein Tool Ihnen eine Frage, wählt das Question-Modul sofort eine Antwort. Es bevorzugt Optionen, die als empfohlen, Standard, sicher, üblich, konventionell, Best Practice, einfach oder minimal markiert sind. Es meidet Optionen, die als experimentell, riskant, gefährlich, zerstörerisch, fortgeschritten, komplex, Umschreiben oder überkonstruiert markiert sind. Hat keine Option ein Signal, wählt es die erste Option, weil das Frage-Tool Agenten anweist, die empfohlene Option an die erste Stelle zu setzen.

3. Prozessorschleife (Sitzungsebene)

Wird eine Genehmigung dennoch abgelehnt (zum Beispiel durch eine ausdrückliche Ablehnungsregel), hält die Prozessorschleife nicht an — sie geht zum nächsten Schritt, statt die Sitzung zu beenden.

4. Entscheidungsrahmen im Stil von PRD und ADR

Der autonome Modus fügt dem System-Prompt eine leichte Erinnerung an den Arbeitsablauf hinzu. Vor der Umsetzung sollte der Agent die Arbeit mit Problem, Einschränkungen, Entscheidung, Abwägungen, Plan und Prüfung rahmen. Bei umfangreichen Änderungen über mehrere Dateien, an der Architektur oder sichtbar im Produkt darf er ein Repository-Dokument anlegen oder aktualisieren, wenn das zum Dokumentationsmuster des Repositorys passt. Bei trivialen Änderungen sollte er diesen Rahmen im Plan leicht halten, um Überkonstruktion zu vermeiden.

Autonom und Sandbox

Autonomer Modus und Sandbox-Modus sind unabhängig. Sie können beide gleichzeitig nutzen:

Die Standardhaltung der Laufzeit ist autonom an plus Sandbox aus: full-access mit aktiviertem Netzwerk. Das bietet das reibungsärmste CLI-Verhalten, aber keine Isolationsgrenze. Nutzen Sie /sandbox, --sandbox workspace-write, AX_CODE_ISOLATION_MODE oder die Projektkonfiguration, um Einschränkungen für nicht vertrauenswürdige oder unbeaufsichtigte Arbeit zu aktivieren.

Konfiguration

Konfigurationsdatei

In ax-code.json:

{
  "autonomous": true
}

Setzen Sie den Wert auf false, um ihn zu deaktivieren:

{
  "autonomous": false
}

Umgebungsvariable

AX_CODE_AUTONOMOUS=true ax-code    # force autonomous on
AX_CODE_AUTONOMOUS=false ax-code   # force autonomous off

Vorrang

Umgebungsvariable > Konfigurationsdatei > Standard (an)

Arbeitslastbudgets (Modellrunden und Tool-Aufrufe)

Der autonome Modus bedeutet kein unbegrenztes Ausführen. Es gelten mehrere unabhängige Obergrenzen. Die folgenden Standardwerte sind die ausgelieferten Konstanten; heben oder senken Sie sie in ax-code.json, wenn eine Arbeitslast mehr Spielraum braucht.

Eine Modellrunde ist eine Modellanfrage der äußeren Schleife. Ein Tool-Aufruf ist eine Tool-Ausführung innerhalb einer Modellrunde. Das sind getrennte Budgets: Eine einzelne Modellrunde kann mehrere Tool-Aufrufe auslösen. Ältere Konfigurationsnamen, die steps enthalten, bleiben unterstützt, machen die beiden Einheiten aber nicht austauschbar.

Bevorzugen Sie das erstklassige Objekt autonomy. Die älteren Schlüssel session.* und experimental.autonomous_caps.* funktionieren weiter als Aliase (niedrigerer Vorrang).

Binärdateien (cp einer ausführbaren Datei, curl -o eines Zip-Archivs und andere Schreibvorgänge ohne Text) zählen weiter zur Datei-Grenze, belasten aber null Zeilen. Die Zeilengrenze misst textuelle Änderung. Textschreibvorgänge der Shell behalten die Schätzung ceil(size / 80), damit eine dichte Nutzlast das Budget nicht durch wenige Zeilenumbrüche umgehen kann.

Nicht verfolgte Pfade, die git check-ignore als ignoriert meldet, belasten ebenfalls null Zeilen und zählen weiter als eine Datei. Das deckt erzeugte Bäume wie target/ ab, wenn ein Prüfer seine Ausgabe dorthin umleitet (cargo clippy > target/review/clippy.log). Die Ausnahme gilt nur, wenn Git mit Exit 0 endet. Ein fehlendes Repository, ein Git-Fehler und eine verfolgte Datei behalten die normale Zeilenbelastung, einschließlich einer verfolgten Datei, deren Name einem Ignore-Muster entspricht.

Profile

Setzen Sie autonomy.profile, um mehrere Felder auf einmal zu belegen (ausdrückliche Felder gewinnen weiterhin):

Prüfen mit /limits

Führen Sie in einer Sitzung /limits aus, um den aufgelösten Budgetstapel, den wirksamen TUI-Nenner für den aktiven Agenten, Konfigurationsquellen und Doctor-Warnungen auszugeben (zum Beispiel, wenn agent.steps enger ist als das Sitzungssegment). Nutzen Sie /limits help für Schlüsselnamen.

Was die TUI zeigt: Während eines autonomen Laufs meldet die Kopfzeile turn current/max · total current/max · cont current/max. turn ist das aktuelle Fortsetzungssegment und nutzt die wirksame Taktgrenze für den aktiven Agenten — min(agent.steps, session.max_steps), wenn der Agent begrenzt ist, sonst die Grenze je Segment. total überdauert automatische Fortsetzungen. cont zeigt ∞, wenn ein aktives Ziel oder der Super-Long-Modus die gewöhnliche Fortsetzungsgrenze anhebt.

Automatisches Routing: Schlüsselwort-Routing kann die Sitzung auf einen Spezialagenten umschalten (Debug, Security, DevOps, …). Spezialisten teilen dieselbe standardmäßig unbegrenzte Richtlinie für Modellrunden je Agent wie Dev, sofern Sie nicht agent.<name>.steps setzen. Schalten Sie das Routing mit "routing": { "disable": true } ab, wenn Sie nur den Dev-Agenten möchten.

Lange Läufe: Nutzen Sie /goal oder Super-Long für mehrstündige Arbeit — sie heben gewöhnliche Fortsetzungsgrenzen auf und nutzen die höhere kumulierte Decke (Standard 20,000), mit Semantik für Prüfung und Pause, dokumentiert im Schleifenmodus. /goal schreibt zuerst einen prüfbaren Vertrag (Akzeptanzkriterien und Prüfplan) und fällt auf pausiert zurück, wenn dieser Plan nicht erzeugt werden kann.

Wenn eine Grenze einen Lauf stoppt

Bevor ein gewöhnlicher Lauf seine kumulierte Modellrunden-Decke erreicht, fügt AX Code eine begrenzte Konvergenzanweisung ein (höchstens die letzten 50 Runden, bei kleinen eigenen Budgets herunterskaliert). Die Anweisung sagt dem Modell, breite Erkundung zu beenden, laufende Arbeit abzuschließen oder sicher zu parken, gezielte Prüfungen auszuführen und unfertige Arbeit wahrheitsgemäß zu melden, und fügt kein Budget hinzu und umgeht keine Grenze.

Ist ein endgültiges Budget erreicht, enthält session.error ein optionales maschinenlesbares code, und das Wiedergabeereignis session.end zeichnet denselben Wert als stopCode auf. Bestehende grobe Endgründe bleiben aus Kompatibilitätsgründen unverändert. Die aktuellen Grenzcodes sind:

• MODEL_TURN_SEGMENT_LIMIT
• MODEL_TURN_TOTAL_LIMIT
• AGENT_MODEL_TURN_LIMIT
• AGGREGATE_TOOL_CALL_LIMIT
• FILE_CHANGE_LIMIT
• LINE_CHANGE_LIMIT

An einer Segmentdecke setzt AX Code automatisch fort, solange das konfigurierte Fortsetzungsbudget bleibt. Ist dieses Budget erschöpft, stoppt der Lauf, und die Meldung sagt, was geschehen ist. Ein neuer Prompt wie continue startet einen neuen, von Ihnen gelenkten Lauf mit neuer Laufbuchhaltung; er verlängert den gestoppten Lauf nicht rückwirkend. Nutzen Sie /goal, wenn das Ziel ausdrücklich und fortsetzbar bleiben soll, bis Abschluss, Blockierung oder eine Grenze des Ziel- oder Laufzeitbudgets erreicht ist. /goal schaltet weder Genehmigung, Isolation, Wirkungsradius, Stillstand, Token, Zeit noch die Schutzmaßnahmen der kumulierten Modellrunden ab.

Beispiel: Budgets für einen großen autonomen Stapel anheben

{
  "autonomous": true,
  "autonomy": {
    "profile": "long",
    "budget": {
      "model_turns": { "per_segment": 500, "total": 20000 },
      "tool_calls": {
        "per_segment": 1000,
        "rate": { "count": 40, "window_seconds": 10 },
        "per_tool": { "bash": 80, "edit": 150 }
      },
      "changes": { "files_total": 100, "lines_total": 10000 }
    },
    "stall": {
      "tool_only_turns": 50,
      "tool_only_nudge": 20,
      "failed_mutation_attempts": 30,
      "max_consecutive_errors": 3
    }
  },
  "agent": {
    "debug": { "steps": 200 }
  }
}

Wann Sie den autonomen Modus ausschalten

• ax-code kennenlernen — sehen Sie, was der Agent bei jedem Schritt tut
• Heikle Vorgänge — prüfen Sie jede Dateiänderung, bevor sie angewendet wird
• Agentenverhalten untersuchen — verstehen Sie, warum der Agent bestimmte Entscheidungen trifft
• Nicht vertrauenswürdiger Code — prüfen Sie Tool-Aufrufe bei der Arbeit mit unbekannten Repositorys

Wann der autonome Modus an bleiben soll

• Routineaufgaben — Refactoring, Fehlerkorrekturen und Migrationen, bei denen Sie dem Agenten vertrauen
• CI/CD-Pipelines — Headless-Ausführung, bei der die Aufgabe bereits durch Richtlinie begrenzt ist
• SDK-Nutzung — programmatische Agentenausführung über createAgent()
• Große Aufgaben — Änderungen über mehrere Dateien, bei denen ein Halt bei jeder Genehmigung Stunden dauern würde

Headless- und CI-Nutzung

Im Headless-Modus (ax-code run, ax-code serve, SDK) ist der autonome Modus wesentlich — es gibt keine TUI, die Abfragen anzeigen könnte. Die serverseitige automatische Zulassung sorgt dafür, dass der Agent bis zum Abschluss läuft, ohne an unbeantworteten Abfragen hängen zu bleiben.

# Headless one-shot with autonomous on (default)
ax-code run "Fix all TypeScript errors in src/"

# Explicit override
AX_CODE_AUTONOMOUS=true ax-code run "Migrate API routes"

ax-code run gibt standardmäßig knappe Tool-Ausgabe aus: Befehlsausgabe wird auf ihren Schwanz reduziert, Bearbeitungen zeigen eine Diff-Zusammenfassung, und Todo-Schreibvorgänge zeigen eine Fortschrittszahl in einer Zeile. Fehler werden nie verborgen — sie erscheinen mit derselben Schwanzgrenze wie andere Ausgabe. Übergeben Sie --full, um für die Prüfung die vollständige Tool-Ausgabe wiederherzustellen (volle Diffs, ungekürzte Befehlsausgabe, volle Todo-Listen).

Sicherheitsgarantien

Auch bei aktivem autonomem Modus gilt:

1. Die Sandbox setzt Grenzen weiter durch — Schreibvorgänge außerhalb des Arbeitsbereichs werden unabhängig vom autonomen Modus blockiert
2. Eine Isolationseskalation fragt immer — der Agent kann Sandbox-Einschränkungen nicht still überschreiben
3. Ablehnungsregeln werden durchgesetzt — ausdrückliche Genehmigungsregeln "deny" blockieren Tool-Aufrufe weiter
4. Autonome Entscheidungen werden aufgezeichnet — Metadaten des Frage-Tools enthalten ein strukturiertes Buch autonomousDecisions, und die Tool-Ausgabe enthält die gewählten Antworten, damit der Agent sie später melden kann
5. Überkonstruktion vermeiden — die autonome Fortsetzung erinnert den Agenten, die einfachste übliche Änderung zu bevorzugen und Abstraktionen ohne mindestens drei konkrete Anwendungsfälle zu meiden
6. Sitzungs-Snapshots werden aufgezeichnet — jeder Tool-Aufruf wird für Prüfung und Wiedergabe protokolliert
7. Abbruch funktioniert immer — Esc (Unterbrechung) stoppt den Agenten sofort