Saltar para o conteúdo principal
DocsCompilar o workflowTipo de passo

8 Tipos de passos

Uso e referência de campo de Agent único, group chat, agent based, código, classificador, state machin, sub workflow, manual aprovation.

Braidrun oferece atualmente 8 tipos de etapas.

1. único — agente único

A etapa mais comum: pedir a um Agente para realizar uma tarefa.

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

Aprimoramentos combinados permitidos: parallel、repeat_until、iterate_over.

2. group_chat — discussão multiagente

Vários agentes se revezam falando sobre o mesmo assunto.

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

repeat_until A expressão condicional será avaliada após cada rodada;

3. agent_based — delegação dinâmica

O agente orquestrador seleciona trabalhadores e despacha subtarefas em tempo de execução.

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

4. código – script determinístico

Suporta 7 idiomas: Python / JavaScript / TipoScript / Bash / Ruby / Lua / CLI. Na produção, eles correm em um recipiente sandboxed por padrão.

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)}))
Prefixo de código compartilhado

Quando várias etapas de código precisarem compartilhar importações ou funções utilitárias, use o nível superior code_preamble, agrupados por linguagem de programação; no tempo de execução é automaticamente predestinado para o script de passos de código na mesma linguagem.

5. classificador – variável de roteamento

Deixe o Agente pegar "A qual categoria o contexto atual pertence" como saída e gravá-lo em uma variável de roteamento para uso por condição nas etapas subsequentes.

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 em vez de complexo on_success.next Matriz de strings.

6. state_machine — máquina de estado aninhada

Executando como um nó composto DAG, ele pode ter vários estados e transições dentro dele.

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

Não configure paralelo nas etapas externas;

7. sub_workflow — módulo de subworkflow

Chame outro Módulo publicado.

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

Liste todos os módulos integrados: Biblioteca de módulos incorporada.

8. workflow output read — cross-workflow reads

Uma etapa de nível do sistema: ele lê valores das saídas publicadas por uma execução de outro workflow (veja publicity outputs abaixo) e escreve-os nas variáveis deste workflow. Por padrão, ele lê a execução bem sucedida mais recente do workflow de origem.

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 — Defaults to latest successful (a execução bem sucedida mais recente); você também pode usar execution id para escolher uma execução específica, ou input variable para tirar o ID de execução de uma variável
  • outputs — Necessário: um mapeamento dos nomes de saída publicados para os nomes das variáveis deste workflow
  • missing_policy — Quando falta uma saída: fail (default, the step errors), skip step (skip this step) ou use default (tomar o valor dos padrões)
  • require_workflow_status — Por padrão, a execução da fonte deve ter o status COMPLETADO

Melhorias no nível dos passos

Os seguintes campos não são tipos de passos autônomos, mas sim configurações de realce adicionadas a um passo.

manual_approval — Aprovação manual

Adicione um portão manual antes de qualquer passo: a execução pausa e notifica o revisor, continua na aprovação, e pára em rejeição ou tempo limite.

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?"

Veja a lista completa de parâmetros e o processo de aprovação: Aprovação manual.

publish_outputs — Publicar saídas de passos externamente

Após um passo ter sucesso, publique saídas nomeadas para outros workflows para ler via workflow output read. Por padrão, nenhum artefato interno é publicado.

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 — Necessário: uma expressão de modelo avaliada no momento da publicação, por exemplo referenciando o resultado desta etapa
  • type — O padrão para texto; também suporta markdown, json, número, booleano, url, arquivo e muito mais
  • visibility.scope — privado (por omissão, apenas o proprietário do workflow), equipe, ou workflow allowlist (emparelhado com a allowlist allow workflows)

structured_output — Resultado final estruturado

Apenas passos de um agente: o Agent chama ferramentas como de costume, mas sua resposta final é analisada em um resultado estruturado contra um esquema registrado; quando write to é definido, o resultado também é serializado para um arquivo.

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 — Obrigatório: o nome de um esquema estruturado registado
  • write_to — Opcional: o caminho do arquivo para o qual escrever, com suporte variável de modelo; o formato de gravação atualmente suporta apenas json
  • fail_on_empty — Falhar no passo quando o resultado estruturado está vazio; o padrão é true

Uma rápida olhada nos limites do combo

  • parallel — Somente etapas de agente único podem ser configuradas
  • repeat_until — Apenas um único agente ou group_chat
  • iterate_over — Apenas um único agente ou código
  • structured_output — Apenas passos de um agente
  • state_machine — Execute como um nó composto DAG, não configure paralelo na camada externa