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

Cloud-Betriebsmodus

Status: Aktiv Geltungsbereich: aktueller Stand Zuletzt geprüft: 2026-09-04 Verantwortlich: ax-code runtime

Der Cloud-Betriebsmodus ist eine fertige Haltung für die Verwaltung von Infrastruktur — Cloud-Anbieter (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) und Netzwerkgeräte (VyOS, Juniper Junos) —, bei der ein Fehler laufende Systeme betrifft und ein Git-Rollback den Zustand nicht wiederherstellen kann. Er wird als eingebauter Agent cloudops ausgeliefert: ein System-Prompt plus eine Berechtigungshaltung, die Sie mit einer Auswahl aktivieren, statt Regeln von Hand zu schreiben.

Was der Modus Ihnen bietet

Zuerst nur lesender Agent. Der Agent cloudops beginnt jede Aufgabe mit Inventar und Probeläufen, und sein Prompt verbietet Änderungen, bevor ein Plan, ein Diff und Rollback-Rezepte vorliegen.
Shell mit Rückfrage vor der Ausführung. bash steht auf ask, sodass jeder Shell-Befehl bestätigt wird. Ändernde Verben für Cloud und Netzwerk (Löschfamilie aws/gcloud/az/doctl, kubectl delete/apply --prune, terraform apply ohne Plandatei, entfernter SSH-Commit ohne Commit-Bestätigung, Änderungen per curl gegen APIs der Steuerungsebene) werden als bash_destructive eingestuft und tragen eine eigene interaktive Schranke, die sich nicht umgehen lässt.
Betriebswerkzeuge erster Klasse. ops_plan, ops_diff, ops_verify und ops_journal sind vorab erlaubt; ops_approve und ops_apply bleiben auf ihren interaktiven Wegen (unten).

Der Ablauf: Plan → Diff → Genehmigung → Anwenden → Prüfen → Journal

ops_plan — öffnet einen OperationPlan: Ziel (Anbieter, Konto, Region oder Gerät), Absicht, genauer Apply-Befehl und Befehlskontext sowie Schritte mit Wirkung, Umkehrbarkeit (reversible | hard | irreversible) und Schadensradius (low | med | high). Erzeugt einen kanonischen Plan-Hash.
ops_diff — erzeugt das maschinell prüfbare Artefakt (terraform plan -out, show | compare, Ausgabe des CLI-Probelaufs), lässt es prüfen und hängt es an. Kein Diff, keine Genehmigung.
ops_approve — der Mensch genehmigt den auf den Hash festgelegten Plan. Diese Schranke ist nur interaktiv: Keine Wildcard-Regel und kein autonomer Modus können sie vorab genehmigen, und es wird keine dauerhafte Freigabe „immer erlauben“ angeboten.
ops_apply — führt die Änderung des genehmigten Plans mit dem Genehmigungstoken aus. Das ist der einzige zugelassene Änderungsweg; das Token wird eingelöst, bevor etwas läuft.
ops_verify — führt die deklarativen, nur lesenden Zusicherungen des Plans aus und zeichnet Nachweise für Bestehen oder Fehlschlag auf.
ops_journal — fragt das nur fortgeschriebene, auf das Projekt begrenzte Operationsjournal nach Projekt, Plan oder Status ab.

Den Modus aktivieren

Wählen Sie in der TUI Cloud Ops in der Agentenauswahl (oder erwähnen Sie cloudops mit @ für eine abgegrenzte Aufgabe). Um ihn für ein Projekt zur Voreinstellung zu machen, fügen Sie Folgendes zu ax-code.json hinzu:

{
  "default_agent": "cloudops",
  "isolation": {
    "mode": "workspace-write",
    "network": true
  }
}

workspace-write begrenzt Dateiänderungen auf den Arbeitsbereich; network: true hält webfetch, websearch und die CLIs der Anbieter erreichbar (das Netzwerk ist in Sandbox-Modi sonst aus — siehe Sandbox-Modus). Beides sind Isolationseinstellungen der Sitzung, unabhängig vom Agenten; sie werden daher hier konfiguriert und nicht innerhalb der Agentenvoreinstellung.

Sie können die Haltung je Projekt unter agent.cloudops.permission verschärfen oder erweitern, etwa bestimmte Werkzeuge verweigern. Eine im Repository committete Konfiguration kann nur Regeln zum Verweigern hinzufügen; ein ask zu allow zu lockern, muss aus Ihrer vertrauenswürdigen Benutzerkonfiguration oder der verwalteten Konfiguration kommen, niemals aus dem Repository. Um den Agenten vollständig zu entfernen, setzen Sie "agent": { "cloudops": { "disable": true } }.

Ein durchgespieltes Beispiel

Eine Firewall-Änderung auf einem VyOS-Router anwenden:

Sie fragen: „tcp/8443 von 10.0.0.0/8 an der Edge-Firewall erlauben“.
Der Agent lädt den Skill vyos-firewall, erfasst die aktuelle Konfiguration über SSH (show configuration commands in einer datierten Datei gespeichert) und öffnet mit ops_plan einen Plan: ein Schritt, Wirkung add firewall rule, Umkehrbarkeit reversible (das Löschen der Regel stellt den Zustand wieder her), Schadensradius med.
Er bereitet die Änderung im Konfigurationsmodus vor und hängt den Geräte-Diff mit ops_diff an.
ops_approve zeigt Ihnen den Plan-Hash und die genaue vorbereitete Änderung; Sie genehmigen, und ein Token für 10 Minuten wird ausgestellt.
ops_apply löst das Token ein und führt die Folge commit-confirm aus; der automatische Rollback-Zeitgeber bleibt scharf, bis die Prüfung abgeschlossen ist.
ops_verify prüft die Erreichbarkeit und dass die Regel zum beabsichtigten Verkehr passt; sowohl die Genehmigung als auch das Ergebnis landen im Journal, sodass eine spätere Abfrage ops_journal die gesamte Änderung rekonstruiert.

Wäre das Anwenden in Schritt 5 gescheitert, wäre das Token verbraucht — Schritt 4 liefe vor jedem erneuten Versuch erneut.

Semantik des Genehmigungstokens

Einmalverwendung — wird zu Beginn von ops_apply atomar eingelöst; ein verbrauchtes, unbekanntes oder abgelaufenes Token schlägt fehl, ohne dass etwas ausgeführt wird.
An eine TTL gebunden — Voreinstellung 10 Minuten, höchstens 60. Der Ablauf wird beim Einlösen erst geprüft; es gibt keinen Hintergrundprozess, der abläuft.
An den Plan gebunden — das Token wird gegen den kanonischen sha256-Hash des Plans ausgestellt. Dieser umfasst den genauen Apply-Befehl, den optionalen Snapshot-Befehl und das Arbeitsverzeichnis. Abweichende Argumente und Tokens für einen anderen Plan werden vor dem Verbrauch abgelehnt. Das verhindert eine Wiedergabe, eine Verwechslung zwischen Plänen und das Ersetzen von Befehlen.
Einmal gezeigt — das rohe Token erscheint genau einmal im Ergebnis von ops_approve und wird nie gespeichert (nur sein sha256 wird abgelegt).
Keine Rückgabe — ein fehlgeschlagenes oder zeitlich überschrittenes Anwenden gibt das Token nicht zurück. Ein erneuter Versuch erfordert eine neue Genehmigung über ops_approve.

Sicherheitsmodell

bash_destructive bleibt die Schranke für spontane Änderungen. Der Betriebsablauf deckt geplante Änderungen ab; einzelne zerstörerische Befehle treffen weiterhin den Zerstörungsklassifikator und seine interaktive Schranke, und keine Berechtigungsregel kann sie automatisch genehmigen.
ops_approve ist nur interaktiv, wie isolation_escalation und bash_destructive: Es fragt immer nach, auch unter Regelsätzen mit Wildcard-Erlaubnis und im kopflosen autonomen Modus.
Das Journal wird aus Sicht des Agenten nur fortgeschrieben und ist auf das Projekt begrenzt; es überdauert Sitzungen und wird beim Löschen einer Sitzung nicht mitgelöscht.
Skill-Pakete enthalten die Runbooks der Anbieter. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall und junos-firewall enthalten die zuerst nur lesenden Checklisten, die Schritte zum Planen vor dem Ändern und die Rollback-Muster; der Agent lädt das passende Paket, bevor er eine Fläche bedient. OVHcloud und andere Anbieter werden über konfigurierte MCP-Server und deren Dokumentation abgedeckt, nicht über improvisierte CLI-Ketten.
Zugangsdaten gelangen nie in die Aufzeichnung. Zuweisungen von Zugangsdaten innerhalb gespeicherter Bash-Eingaben werden geschwärzt, bevor sie das Ereignisprotokoll erreichen.

Strikter Modus

Standardmäßig erhält ein als zerstörerisch eingestufter Bash-Befehl (die Familie bash_destructive: ändernde Verben für Cloud und Netzwerk, rm -rf, git push --force und der Rest der Klassifikatorliste) eine interaktive Rückfrage, die sich nicht umgehen lässt — der Benutzer kann den einzelnen Befehl genehmigen, und er wird ausgeführt. Der strikte Modus entfernt diese Möglichkeit.

Ist der strikte Modus aktiv, wird ein als zerstörerisch eingestufter Bash-Befehl sofort verweigert, noch vor jeder Rückfrage. Die Verweigerungsnachricht listet die eingestuften Befehle mit ihren Gründen und verweist das Modell auf den zugelassenen Ablauf: ops_plan → ops_diff → ops_approve (stellt ein einmaliges Genehmigungstoken aus) → ops_apply. Spontane zerstörerische Änderungen in der Shell sind überhaupt nicht mehr möglich; jede Änderung muss geplant, per Diff geprüft, genehmigt und über den journalgestützten Weg angewendet werden.

Aktivieren Sie ihn in vertrauenswürdiger Konfiguration (ax-code.json in Ihrem Verzeichnis für die Benutzerkonfiguration, in verwalteter Konfiguration oder in einer Projektkonfiguration, der der Benutzer ausdrücklich vertraut):

{
  "ops": {
    "strict": true
  }
}

Hinweise:

Zusammenspiel mit der Rückfrage: Der strikte Modus ersetzt die Rückfrage bash_destructive durch eine harte Verweigerung. Ist das Flag aus (die Voreinstellung), entspricht das Verhalten genau der Beschreibung oben — die interaktive Schranke bleibt.
Geltungsbereich: Das Flag ist globale Konfiguration, nicht je Agent — es gilt für jeden Bash-Aufruf in der Sitzung, einschließlich der Unteragenten. Der Agent cloudops kann es nicht selbst aktivieren; Agenten tragen Berechtigungen und Prompts, keine Konfiguration.
Vertrauensgrenze: Nicht vertrauenswürdige, im Repository committete Projektkonfiguration kann den strikten Modus nicht aktivieren; stimmen Sie je Rechner zu (AX_CODE_TRUST_PROJECT_CONFIG=1) oder setzen Sie ihn in vertrauenswürdiger Benutzer- oder verwalteter Konfiguration.
ops_apply bleibt unberührt: Der zugelassene Änderungsweg hat im Werkzeug eine eigene, an den Plan gebundene Token-Schranke und berücksichtigt dieses Flag nie.

Maßgebliche Quelle

packages/ax-code/src/agent/agent.ts — die Agentendefinition cloudops und das Zusammenführen der Berechtigungen
packages/ax-code/src/agent/prompt/cloudops.txt — der System-Prompt des Agenten
packages/ax-code/src/tool/ops_*.ts — die sechs Betriebswerkzeuge und ihre Beschreibungen
packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
Sandbox-Modus — Isolationsmodi, Netzwerksteuerung und Vorrang