8 Schrittarten

Braidrun bietet derzeit 8 Schrittarten an. Für jeden Schritt muss nur ein Hauptmodus ausgewählt werden; Andere Felder sind Erweiterungen (Wiederholung, Bedingung, manuelle_Genehmigung usw.).

1. Single – einzelner Agent

Der häufigste Schritt: Einen Agenten bitten, eine Aufgabe auszuführen.

  - step: plan
    agent: planner
    input: "Plan a daily report pipeline"
    depends_on: [intro]
    retry:
      maxAttempts: 3
      backoff: exponential

Zulässige kombinierte Erweiterungen: parallel、repeat_until、iterate_over.

2. group_chat – Diskussion mit mehreren Agenten

Mehrere Agenten sprechen abwechselnd zum gleichen Thema. Sie können die Sprechreihenfolge festlegen oder den Orchestrator entscheiden lassen.

  - step: peer_review
    group_chat:
      agents: [coder, reviewer]
      topic: "Review the change"
      max_rounds: 6
      repeat_until: "score >= 8"

repeat_until Der bedingte Ausdruck wird nach jeder Runde ausgewertet; Wenn es erfüllt ist, wird group_chat beendet.

3. agent_based – dynamische Delegation

Der Orchestrator-Agent wählt Arbeiter aus und verteilt Unteraufgaben zur Laufzeit. Im Vergleich zum statischen Gruppenchat ist es besser für das Szenario „Ich weiß nicht, wer geeignet ist, lassen Sie den Planer entscheiden“ geeignet.

  - step: delegate
    agent_based:
      orchestrator: planner
      workers: [coder, analyst, writer]
      input: "{{steps.plan.output}}"

4. Code – deterministisches Skript

Unterstützt 7 Sprachen: Python / JavaScript / TypeScript / Bash / Ruby / Lua / CLI. In der Produktionsumgebung läuft es standardmäßig in einem Sandbox-Container.

code_preamble:
  python:
    inline: |
      import json, os

workflow:
  - step: transform
    code:
      language: python
      timeout: 30
      script: |
        data = json.loads(os.environ.get("STEP_INPUTS", "{}"))
        print(json.dumps({"rows": len(data)}))

5. Klassifikator – Routing-Variable

Lassen Sie den Agent „Zu welcher Kategorie gehört der aktuelle Kontext“ als Ausgabe übernehmen und diese in eine Routing-Variable schreiben, damit sie in den nachfolgenden Schritten von der Bedingung verwendet werden kann.

  - step: classify_request
    classifier:
      agent: router
      input: "Classify the user intent"
      categories:
        - name: coding
          description: Needs code changes
        - name: analysis
          description: Needs investigation only
      output_variable: route

  - step: coding_path
    agent: coder
    condition: route == coding
    depends_on: [classify_request]

Empfohlen classifier + condition statt komplex on_success.next String-Array.

6. state_machine – verschachtelte Zustandsmaschine

Als DAG-Verbundknoten ausgeführt, kann er mehrere Zustände und Übergänge enthalten.

  - step: triage
    state_machine:
      initial: ingest
      states:
        - name: ingest
          agent: planner
          transitions:
            - condition: route == analysis
              next: analyze
            - condition: route == coding
              next: code
        - name: analyze
          agent: analyst
          transitions:
            - next: DONE
        - name: code
          agent: coder
          transitions:
            - next: DONE

Konfigurieren Sie in den äußeren Schritten nicht parallel; Es gibt nur einen Fluss, der in state_machine eintritt.

7. sub_workflow – Sub-Workflow-Modul

Rufen Sie ein anderes veröffentlichtes Modul auf. Eingabe/Ausgabe hält sich an den vom Modul deklarierten Vertrag; Die Schleifenerkennung erfolgt zur Laufzeit.

  - step: fetch_report
    sub_workflow:
      workflow_id: 0d2c…ab12        # UUID of the published module
      version_strategy: pinned
      pinned_version: "2.0.1"
      inputs:
        app_id: "{{var:app_id}}"
        window: last_7d
      outputs:
        report_path: report_path    # parent variable <- module output

Listen Sie alle integrierten Module auf: Integrierte Modulbibliothek.

8. workflow_output_read — workflowübergreifendes Lesen

Schritt auf Systemebene: liest Werte aus der von einer bestimmten Ausführung eines anderen Workflows veröffentlichten Ausgabe (siehe unten publish_outputs) und schreibt sie in die Variablen des eigenen Workflows. Standardmäßig wird die zuletzt erfolgreiche Ausführung des Quell-Workflows gelesen.

  - step: read_spend_report
    workflow_output_read:
      workflow_id: 7f3a…9c21           # source workflow UUID
      selector:
        mode: latest_successful
      outputs:
        report_url: spend_report_url   # published name -> local variable
      missing_policy: use_default
      defaults:
        report_url: ""

• selector.mode — Standard ist latest_successful (die zuletzt erfolgreiche Ausführung); alternativ per execution_id eine bestimmte Ausführung angeben oder per input_variable die execution id aus einer Variablen beziehen
• outputs — Pflichtfeld: Zuordnung von veröffentlichtem Ausgabenamen zu Variablennamen im eigenen Workflow
• missing_policy — Bei fehlender Ausgabe: fail (Standard, Schritt meldet Fehler), skip_step (diesen Schritt überspringen), use_default (den Standardwert aus defaults nehmen)
• require_workflow_status — Standardmäßig wird verlangt, dass der Status der Quellausführung COMPLETED ist

Erweiterungen auf Schrittebene

Die folgenden Felder sind keine eigenständigen Schritttypen, sondern Erweiterungskonfigurationen, die einem Schritt hinzugefügt werden.

manual_approval — Manuelle Genehmigung

Fügt vor einem beliebigen Schritt ein manuelles Gate hinzu: Die Ausführung pausiert und benachrichtigt den Genehmiger, wird nach der Genehmigung fortgesetzt und bei Ablehnung oder Zeitüberschreitung gestoppt.

  - step: deploy
    agent: deployer
    input: "Deploy to production"
    manual_approval:
      enabled: true
      approvers:
        - team-lead@company.com
      timeout: 3600
      approval_message: "Ready to ship?"

Sehen Sie sich die vollständige Parameterliste und den Genehmigungsprozess an: Manuelle Genehmigung.

publish_outputs — Schrittausgabe nach außen veröffentlichen

Veröffentlicht nach erfolgreichem Schritt die benannten Ausgaben, damit andere Workflows sie per workflow_output_read lesen können. Standardmäßig werden keine internen Artefakte veröffentlicht.

  - step: build_report
    agent: analyst
    input: "Summarize yesterday's spend"
    publish_outputs:
      - name: report_url
        type: url
        source: "{{steps.build_report.output}}"
        description: Latest spend report link
        visibility:
          scope: team

• source — Pflichtfeld: Template-Ausdruck, der bei der Veröffentlichung ausgewertet wird, etwa als Referenz auf die Ausgabe dieses Schritts
• type — Standard text; unterstützt werden außerdem markdown, json, number, boolean, url, file usw.
• visibility.scope — private (Standard, nur der Eigentümer dieses Workflows), team, workflow_allowlist (zusammen mit der allowed_workflows-Whitelist)

structured_output — Strukturierte Endausgabe

Nur für Einzel-Agent-Schritte verfügbar: Der Agent ruft Tools wie gewohnt auf, aber die endgültige Antwort wird gemäß dem registrierten schema in ein strukturiertes Ergebnis geparst; ist write_to konfiguriert, wird das Ergebnis zusätzlich serialisiert in eine Datei geschrieben.

  - step: final_commentary
    agent: analyst
    input: "Write the commentary"
    structured_output:
      schema: ai_commentary_parts
      write_to: "{{var:output_dir}}/commentary.json"
      fail_on_empty: true

• schema — Pflichtfeld: Name des registrierten strukturierten schema
• write_to — Optional: Pfad der Zieldatei, unterstützt Template-Variablen; als Schreibformat wird derzeit nur json unterstützt
• fail_on_empty — Ob der Schritt fehlschlagen soll, wenn das strukturierte Ergebnis leer ist; Standard true

Ein kurzer Blick auf die Combo-Limits

• parallel — Es können nur einzelne Agentenschritte konfiguriert werden
• repeat_until — Nur einzelner Agent oder Gruppenchat
• iterate_over — Nur ein einzelner Agent oder Code
• structured_output — Nur Einzel-Agent-Schritte
• state_machine — Als DAG-Verbundknoten ausführen, nicht parallel in der äußeren Ebene konfigurieren