Saltar al contenido principal
DocumentoConstruir flujo de trabajoTipo de paso

8 Tipos de pasos

Uso y referencia de campo de Agente único, chat_grupo, basado en agente, código, clasificador, máquina_estado, flujo de trabajo_sub, aprobación_manual.

Braidrun ofrece actualmente 8 tipos de pasos. Sólo se debe seleccionar un modo principal para cada paso; otros campos son mejoras (reintento, condición, aprobación_manual, etc.).

1. único - único agente

El paso más común: pedirle a un Agente que realice una tarea.

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

Mejoras combinadas permitidas: parallel、repeat_until、iterate_over.

2. group_chat: discusión entre múltiples agentes

Varios agentes se turnan para hablar sobre el mismo tema. Puede especificar el orden de los discursos o dejar que el orquestador decida.

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

repeat_until La expresión condicional será evaluada después de cada ronda; si se cumple, group_chat finalizará.

3. agent_based: delegación dinámica

El agente orquestador selecciona trabajadores y distribuye subtareas en tiempo de ejecución. En comparación con el chat grupal estático, es más adecuado para el escenario de "No sé quién es adecuado, deja que el planificador decida".

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

4. código: guión determinista

Se admiten 7 lenguajes: Python / JavaScript / TypeScript / Bash / Ruby / Lua / CLI. En producción se ejecutan por defecto en un contenedor de sandbox.

yaml
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)}))
Prefijo de código compartido

Cuando varios pasos de código necesitan compartir importaciones o funciones de utilidad, use el nivel superior code_preamble, agrupado por lenguaje de programación; en tiempo de ejecución se antepone automáticamente al script del paso de code del mismo lenguaje.

5. clasificador: variable de enrutamiento

Deje que el Agente tome "A qué categoría pertenece el contexto actual" como resultado y lo escriba en una variable de enrutamiento para usarlo por condición en los pasos siguientes.

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

Recomendado classifier + condition en lugar de complejo on_success.next Matriz de cadenas.

6. state_machine: máquina de estados anidada

Al ejecutarse como un nodo compuesto DAG, puede tener varios estados y transiciones en su interior.

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

No configurar paralelo en los escalones exteriores; solo hay un flujo que ingresa a state_machine.

7. sub_workflow — módulo de subflujo de trabajo

Llame a otro módulo publicado. La entrada/salida se ajusta al contrato declarado por el módulo; La detección de bucle se realiza en tiempo de ejecución.

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

Enumere todos los módulos integrados: Biblioteca de módulos integrada.

8. workflow_output_read — lectura entre workflows

Paso de nivel de sistema: lee un valor de la salida publicada por una ejecución de otro workflow (ver publish_outputs más abajo) y lo escribe en una variable de este workflow. Por defecto lee la última ejecución exitosa del workflow de origen.

yaml
  - 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 — Por defecto latest_successful (la última ejecución exitosa); también se puede indicar una ejecución concreta con execution_id, o tomar el id de ejecución de una variable con input_variable
  • outputs — Obligatorio: el mapeo del nombre de salida publicada al nombre de variable de este workflow
  • missing_policy — Cuando falta la salida: fail (por defecto, el paso da error), skip_step (se salta este paso), use_default (toma el valor por defecto de defaults)
  • require_workflow_status — Por defecto se exige que el estado de la ejecución de origen sea COMPLETED

Mejoras a nivel de paso

Los campos siguientes no son tipos de paso independientes, sino configuraciones de mejora que se añaden a un paso.

manual_approval — Aprobación manual

Añade un control manual delante de cualquier paso: la ejecución se pausa y notifica al aprobador; tras la aprobación continúa, y si se rechaza o expira, se detiene.

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

Vea la lista completa de parámetros y el proceso de aprobación: Aprobación manual.

publish_outputs — Publicar la salida de un paso al exterior

Tras un paso exitoso, publica sus salidas con nombre para que otros workflows las lean con workflow_output_read. Por defecto no publica ningún artefacto interno.

yaml
  - 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 — Obligatorio: una expresión de plantilla que se evalúa al publicar, por ejemplo referenciando la salida de este paso
  • type — Por defecto text; también admite markdown, json, number, boolean, url, file, etc.
  • visibility.scope — private (por defecto, solo el propietario de este workflow), team, workflow_allowlist (junto con la lista blanca allowed_workflows)

structured_output — Salida final estructurada

Solo disponible en pasos de un único Agent: el Agent llama a las herramientas como de costumbre, pero la respuesta final se analiza según un schema ya registrado y se convierte en un resultado estructurado; al configurar write_to, además se serializa el resultado y se escribe en un archivo.

yaml
  - 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 — Obligatorio: el nombre del schema estructurado ya registrado
  • write_to — Opcional: la ruta del archivo a escribir, admite variables de plantilla; el formato de escritura por ahora solo admite json
  • fail_on_empty — Si el paso debe fallar cuando el resultado estructurado esté vacío; por defecto true

Un Vistazo rápido a los límites de combo

  • parallel — Solo se pueden configurar pasos de un solo agente
  • repeat_until — Solo agente único o chat grupal
  • iterate_over — Sólo un único agente o código
  • structured_output — Solo pasos de un único Agent
  • state_machine — Ejecute como un nodo compuesto DAG, no configure el paralelo en la capa exterior