Blog · Anleitung · 29. Oktober 2026

AEGIS-Workflow-Zustände und -Übergänge, Schritt für Schritt

Auch auf: English, Español, Português, 日本語, Français, 한국어, 简体中文, Italiano, हिन्दी · Alle Anleitungen auf Deutsch

Offenlegung: Wir bei 100monkeys.ai entwickeln AEGIS, lesen Sie diese Anleitung also als Bericht des Herstellers. Einer unserer KI-Agenten hat sie aus der öffentlichen AEGIS-Dokumentation (auf Englisch) entworfen, vor allem der Workflow Manifest Reference und der CLI Reference, und das Unternehmen hat sie geprüft; diese deutsche Fassung ist eine Übersetzung der englischen Originalanleitung. Jede YAML-Zeile und jeder Befehl unten ist von diesen Seiten kopiert; für diese Anleitung wurde nichts davon ausgeführt. Zitate bleiben auf Englisch, mit der Übersetzung daneben. Wo die Dokumentation eine Frage offen lässt, sagt es der letzte Abschnitt.

AEGIS by 100monkeys.ai, in beta, führt einen Workflow als endlichen Automaten aus, geschrieben in einer einzigen YAML-Datei. Die Referenz nennt ihn "a durable, restartable sequence" (eine dauerhafte, neu startbare Abfolge), die Agenten, Container, Systembefehle und menschliche Freigabe-Gates koordiniert. Diese Anleitung schreibt einen Zustand nach dem anderen und zeigt, wie die Engine den nächsten wählt.

Schritt 1. Den Kopf schreiben

apiVersion: 100monkeys.ai/v1
kind: Workflow

metadata:
  name: dev-pipeline
  version: "1.0.0"

apiVersion muss genau 100monkeys.ai/v1 lauten und kind genau Workflow. name folgt ^[a-z0-9][a-z0-9-]{0,62}$, und das Paar aus Name und Version muss eindeutig sein: Eine bestehende Version zu überschreiben braucht den Parameter force. metadata.input_schema ist optional; wenn es vorhanden ist, wird die Eingabe des Aufrufers vor dem Lauf geprüft, und eine ungültige Nutzlast wird "rejected with HTTP 422; no workflow execution is created." (mit HTTP 422 abgelehnt; es wird keine Workflow-Ausführung angelegt.)

Schritt 2. Den ersten Zustand und die Grenzen benennen

Unter spec ist initial_state Pflicht und muss in spec.states existieren. Zwei Grenzen stoppen eine Schleife, die nie endet. spec.max_total_transitions ist standardmäßig 50, höchstens 100, danach "the workflow terminates" (endet der Workflow). max_state_visits jedes Zustands ist standardmäßig 5, höchstens 20. Jeder Zustand hat außerdem ein timeout, standardmäßig 300s. spec.context enthält Konstanten, die jeder Zustand als {{workflow.context.KEY}} liest, etwa eine Iterationsgrenze oder einen Schwellenwert.

Schritt 3. Für jeden Zustand eine Art wählen

Jeder Zustand nennt ein kind. Die Referenz führt acht auf:

Agent führt einen deployten Agenten aus und schreibt dessen status, output, score und iterations unter den Namen des Zustands.
System führt einen Shell-command aus und hält stdout, stderr und exit_code fest.
Action führt eine der eigenen Operationen des Workflows aus, etwa update_blackboard oder repository_commit: "no agent chooses or calls it, and no shell runs." (kein Agent wählt oder ruft sie auf, und keine Shell läuft.)
Human hält den Lauf an, bis ein Mensch antwortet.
ParallelAgents lässt mehrere Prüfer laufen und kombiniert ihre Scores nach einer Konsensstrategie.
ContainerRun und ParallelContainerRun führen Container-Schritte aus, für CI- und CD-Arbeit.
Subworkflow startet einen anderen Workflow, blockierend oder fire-and-forget, bis zu einer Tiefe von höchstens 10.

Schritt 4. Übergänge in der Reihenfolge schreiben, in der sie geprüft werden sollen

Übergänge werden "evaluated top-to-bottom. The first matching transition is taken." (von oben nach unten ausgewertet. Der erste passende Übergang wird genommen.) Jeder nennt einen target-Zustand und optional eine condition. Dieser System-Zustand aus dem Beispiel der Referenz verzweigt nach dem Exit-Code:

    EXECUTE:
      kind: System
      command: python main.py
      env:
        CODE: "{{GENERATE.output}}"
        PYTHONPATH: /workspace
      transitions:
        - condition: exit_code_zero
          target: VALIDATE
        - condition: exit_code_non_zero
          target: REFINE
          feedback: "Execution failed: {{EXECUTE.output.stderr}}"

Die Bedingungen je Art: on_success und on_failure für die meisten Arten; exit_code_zero, exit_code_non_zero und exit_code mit einem value für System und ContainerRun; input_equals, input_equals_yes und input_equals_no für Human; consensus, all_approved und any_rejected für ParallelAgents; custom mit einer Handlebars-expression für jede Art; und always oder gar keine Bedingung als unbedingte Rückfallebene. Der Rat der Referenz: "Always include an unconditional fallback as the last transition." (Setzen Sie immer einen unbedingten Rückfall als letzten Übergang.)

Schritt 5. Nach einem Score verzweigen

    VALIDATE:
      kind: Agent
      agent: judge-v1
      transitions:
        - condition: score_above
          threshold: 0.95
          target: COMPLETE
        - condition: score_below
          threshold: 0.95
          target: REFINE
          feedback: "{{VALIDATE.output.reasoning}}"

Beide Vergleiche sind strikt, ein Score von genau 0.95 nimmt also keinen der beiden Übergänge oben. Der Score wird aus score des Zustands gelesen, sonst aus final_score, sonst aus consensus.score. Ein Zustand ohne Score passt auf keinen, und wenn sonst nichts passt, scheitert der Lauf mit State "<name>" carries no score for its score transitions. score_between nimmt für einen Agent-Zustand inklusive min und max.

Schritt 6. Mitnehmen, was geschehen ist, in den nächsten Zustand

Der feedback-Text eines Übergangs wird im Zielzustand zu {{state.feedback}}; so erreicht eine Fehlermeldung den Agenten, der es erneut versucht. Jeder fertige Zustand wird unter seinem Namen ins Blackboard geschrieben, sodass spätere Zustände {{EXECUTE.output.stdout}} oder {{VALIDATE.score}} lesen. Halten Sie zwei Namensräume auseinander: {{input.KEY}} ist, was der Aufrufer übergeben hat, und "is immutable" (ist unveränderlich), während {{blackboard.KEY}} im Lauf wächst. Eine Vorlage, die einen Schlüssel nennt, den noch kein Zustand geschrieben hat, rendert einen sichtbaren Platzhalter, ERROR: missing key mit dem Namen des Zustands, statt eines leeren Strings.

Schritt 7. Mit Wächter schleifen und den Lauf beenden

    REFINE:
      kind: System
      command: update_context
      env:
        ITERATION: "{{blackboard.iteration_number + 1}}"
        ERRORS: "{{state.feedback}}"
      transitions:
        - condition: custom
          expression: "{{blackboard.iteration_number < workflow.context.max_iterations}}"
          target: GENERATE
        - condition: custom
          expression: "{{blackboard.iteration_number >= workflow.context.max_iterations}}"
          target: FAILED

    COMPLETE:
      kind: System
      command: finalize
      transitions: []

Ein Zustand mit transitions: [] ist ein Endzustand: "When reached, the workflow execution completes with status completed." (Wird er erreicht, endet die Workflow-Ausführung mit dem Status completed.) Geben Sie der Schleife wie oben einen eigenen Wächter auf dem Blackboard, statt sich allein auf max_state_visits zu verlassen.

Schritt 8. Validieren, deployen, ausführen und die Übergänge beobachten

aegis workflow validate ./pipeline.yaml
aegis workflow deploy ./pipeline.yaml
aegis workflow run dev-pipeline --input '{"task": "..."}'
aegis workflow logs <execution_id> --transitions

validate prüft das Manifest lokal; deploy registriert es und scheitert bei bestehendem Namen und bestehender Version, außer Sie fügen --force hinzu; logs --transitions zeigt "state entries/exits only" (nur Ein- und Austritte von Zuständen), der schnellste Weg zu sehen, welchen Zweig jeder Zustand genommen hat.

Was die Dokumentation offen lässt

Gate-Wörter. In der Workflow Manifest Reference akzeptiert input_equals_yes "yes", "approve", "approved" oder "true"; die Seite Human Approvals sagt yes, y oder 1. Testen Sie Ihr Gate, bevor Sie sich auf eine der Listen verlassen.
Eine zweite Syntax. Das Blackboard-Beispiel auf derselben Seite schreibt kind: agent, input_template und Übergänge als on: success mit next:, wo der Rest der Referenz kind: Agent, input, condition und target schreibt. Die Seite sagt nicht, ob die Engine beides akzeptiert.
Arithmetik in Vorlagen. Das Beispiel setzt {{blackboard.iteration_number + 1}}, aber die für Ausdrücke aufgeführten Operatoren sind nur Vergleiche und Logik, ohne +.
Kein Treffer. Außer im Score-Fall sagt die Referenz nicht, was passiert, wenn ein Zustand endet und keiner seiner Übergänge passt.
Wie viele Arten. Der Index der Dokumentation beschreibt "all seven state kinds" (alle sieben Zustandsarten); die Tabelle der Referenz führt acht auf.

Weiter

Für den Human-Zustand im Detail, mit dem, was die prüfende Person sieht und was Schweigen bedeutet, lesen Sie Wie ein Orchestrator einen Freigabeschritt bekommt: ein Muster, mit AEGIS als durchgearbeitetem Beispiel. AEGIS installiert sich mit dem Befehl, der auf 100monkeys.ai steht:

curl -fsSL https://get.100monkeys.ai | bash

AEGIS von 100monkeys.ai installieren