8 Types d'étapes

Braidrun propose actuellement 8 types d'étapes. Un seul mode principal doit être sélectionné pour chaque étape ; d'autres champs sont des améliorations (nouvelle tentative, condition, manual_approval, etc.).

1. unique – agent unique

L'étape la plus courante : demander à un agent d'effectuer une tâche.

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

Améliorations combinées autorisées : parallel、repeat_until、iterate_over.

2. group_chat — discussion multi-agents

Plusieurs agents parlent à tour de rôle sur le même sujet. Vous pouvez spécifier l'ordre de parole ou laisser l'orchestrateur décider.

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

repeat_until L'expression conditionnelle sera évaluée après chaque tour ; si tel est le cas, group_chat prendra fin.

3. agent_based — dynamic delegation

L'agent orchestrateur sélectionne les travailleurs et répartit les sous-tâches au moment de l'exécution. Par rapport au group_chat statique, il est plus adapté au scénario « Je ne sais pas qui convient, laissez le planificateur décider ».

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

4. code - script déterministe

Prend en charge 7 langages : Python / JavaScript / TypeScript / Bash / Ruby / Lua / CLI. En production, l'exécution se fait par défaut dans un conteneur en bac à sable.

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. classificateur - variable de routage

Laissez l'agent prendre « À quelle catégorie appartient le contexte actuel » comme sortie et écrivez-le dans une variable de routage pour une utilisation par condition dans les étapes suivantes.

  - 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]

Recommandé classifier + condition au lieu de complexe on_success.next Tableau de chaînes.

6. state_machine — machine à états imbriquée

Fonctionnant en tant que nœud composite DAG, il peut contenir plusieurs états et transitions.

  - 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

Ne configurez pas le parallèle dans les étapes externes ; il n'y a qu'un seul flux entrant dans state_machine.

7. sub_workflow — module de sous-workflow

Appelez un autre module publié. Les entrées/sorties respectent le contrat déclaré par le module ; la détection de boucle est effectuée au moment de l'exécution.

  - 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

Répertoriez tous les modules intégrés : Bibliothèque de modules intégrée.

8. workflow_output_read — lecture inter-workflows

Étape de niveau système : lit une valeur depuis la sortie publiée par une exécution d'un autre workflow (voir publish_outputs ci-dessous) et l'écrit dans une variable du workflow courant. Par défaut, elle lit la dernière exécution réussie du workflow source.

  - 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 — Par défaut latest_successful (la dernière exécution réussie) ; vous pouvez aussi spécifier une exécution précise via execution_id, ou récupérer l'execution id depuis une variable via input_variable
• outputs — Obligatoire : mappage du nom de la sortie publiée vers le nom de la variable du workflow courant
• missing_policy — En cas de sortie manquante : fail (par défaut, l'étape signale une erreur), skip_step (ignore cette étape), use_default (reprend la valeur par défaut définie dans defaults)
• require_workflow_status — Exige par défaut que l'exécution source soit à l'état COMPLETED

Enrichissements au niveau de l'étape

Les champs suivants ne constituent pas des types d'étape à part entière, mais des configurations d'enrichissement ajoutées à une étape.

manual_approval — Approbation manuelle

Ajoute un contrôle humain avant n'importe quelle étape : l'exécution se met en pause et notifie l'approbateur, se poursuit après approbation, et s'arrête en cas de rejet ou de dépassement du délai.

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

Consultez la liste complète des paramètres et le processus d’approbation : Approbation manuelle.

publish_outputs — Publier la sortie d'une étape vers l'extérieur

Après la réussite de l'étape, publie une sortie nommée que d'autres workflows peuvent lire via workflow_output_read. Par défaut, aucun artefact interne n'est publié.

  - 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 — Obligatoire : expression de modèle, évaluée au moment de la publication, par exemple pour référencer la sortie de cette étape
• type — Par défaut text ; prend également en charge markdown, json, number, boolean, url, file, etc.
• visibility.scope — private (par défaut, uniquement le propriétaire du workflow), team, workflow_allowlist (associé à la liste blanche allowed_workflows)

structured_output — Sortie finale structurée

Disponible uniquement pour les étapes à Agent unique : l'Agent appelle les outils normalement, mais sa réponse finale est analysée en un résultat structuré selon le schema enregistré ; si write_to est configuré, le résultat est en outre sérialisé et écrit dans un fichier.

  - 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 — Obligatoire : nom du schema structuré enregistré
• write_to — Facultatif : chemin du fichier d'écriture, prenant en charge les variables de modèle ; le format d'écriture ne prend actuellement en charge que json
• fail_on_empty — Indique si l'étape doit échouer lorsque le résultat structuré est vide ; true par défaut

Un Aperçu rapide des limites des combos

• parallel — Seules les étapes d'un seul agent peuvent être configurées
• repeat_until — Un seul agent ou group_chat
• iterate_over — Un seul agent ou code
• structured_output — Uniquement pour les étapes à Agent unique
• state_machine — Exécuté en tant que nœud composite DAG, ne configurez pas le parallèle dans la couche externe