주요 콘텐츠로 건너뛰기
문서워크플로우 구축단계 유형

8단계 유형

단일 에이전트, group_chat, Agent_based, 코드, 분류자, state_machine, sub_workflow, manual_approval의 사용법 및 필드 참조입니다.

Braidrun는 현재 8가지 단계 유형을 제공합니다. 각 단계마다 하나의 기본 모드만 선택해야 합니다. 다른 필드는 향상된 기능입니다(재시도, 조건, manual_approval 등).

1. 단일 — 단일 에이전트

가장 일반적인 단계는 에이전트에게 작업을 수행하도록 요청하는 것입니다.

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

허용되는 결합된 개선 사항: parallel、repeat_until、iterate_over.

2. group_chat — 다중 에이전트 토론

여러 상담원이 동일한 주제에 대해 차례로 연설합니다. 말하기 순서를 지정하거나 오케스트레이터가 결정하도록 할 수 있습니다.

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

repeat_until 조건식은 각 라운드 후에 평가됩니다. 충족되면 group_chat이 종료됩니다.

3. 에이전트 기반 — 동적 위임

오케스트레이터 에이전트는 런타임에 작업자를 선택하고 하위 작업을 디스패치합니다. 정적 group_chat에 비해 "누가 적합한지 모르겠으니 기획자가 결정하도록 하세요"라는 시나리오에 더 적합합니다.

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

4. 코드 — 결정론적 스크립트

7가지 언어를 지원합니다: Python / JavaScript / TypeScript / Bash / Ruby / Lua / CLI. 프로덕션 환경에서는 기본적으로 샌드박스 컨테이너에서 실행됩니다.

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)}))
공유 코드 접두사

여러 코드 단계에서 가져오기 또는 유틸리티 기능을 공유해야 하는 경우 최상위 수준을 사용하세요. code_preamble, 프로그래밍 언어별로 그룹화되며, 실행 시 같은 언어의 code 단계 스크립트 앞에 자동으로 붙습니다.

5. 분류자 - 라우팅 변수

에이전트가 "현재 컨텍스트가 속한 카테고리"를 출력으로 가져와 후속 단계에서 조건별로 사용할 수 있도록 라우팅 변수에 쓰도록 합니다.

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]

추천 classifier + condition 복잡한 대신 on_success.next 문자열 배열.

6. state_machine — 중첩된 상태 머신

DAG 복합 노드로 실행되면 내부에 여러 상태와 전환이 있을 수 있습니다.

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

외부 단계에서는 병렬을 구성하지 마십시오. state_machine으로 들어가는 흐름은 단 하나뿐입니다.

7. sub_workflow — 하위 워크플로 모듈

게시된 다른 모듈을 호출합니다. 입력/출력은 모듈에서 선언한 계약을 준수합니다. 루프 감지는 런타임에 수행됩니다.

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

모든 내장 모듈을 나열합니다. 내장 모듈 라이브러리.

8. workflow_output_read — 워크플로 간 읽기

시스템 수준 단계: 다른 워크플로의 어떤 실행이 발행한 출력(아래 publish_outputs 참고)에서 값을 읽어 본 워크플로의 변수에 씁니다. 기본적으로 출처 워크플로의 가장 최근 성공 실행에서 읽습니다.

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 — 기본은 latest_successful(가장 최근 성공 실행)이며, execution_id로 특정 실행을 지정하거나 input_variable로 변수에서 execution id를 가져올 수도 있습니다
  • outputs — 필수: 발행 출력명에서 본 워크플로 변수명으로의 매핑
  • missing_policy — 출력이 없을 때: fail(기본, 단계 오류), skip_step(본 단계 건너뜀), use_default(defaults의 기본값 사용)
  • require_workflow_status — 기본적으로 출처 실행 상태가 COMPLETED일 것을 요구합니다

단계 수준 강화

다음 필드는 독립적인 단계 유형이 아니라 단계에 붙이는 강화 설정입니다.

manual_approval — 수동 승인

임의의 단계 앞에 인적 게이트를 추가합니다: 실행이 일시 중지되고 승인자에게 알린 뒤, 승인되면 계속되고 거부되거나 타임아웃되면 중단됩니다.

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

전체 매개변수 목록 및 승인 프로세스를 확인하세요. 수동 승인.

publish_outputs — 단계 출력을 외부로 발행

단계 성공 후 명명된 출력을 발행하여 다른 워크플로가 workflow_output_read로 읽을 수 있게 합니다. 기본적으로는 어떤 내부 아티팩트도 발행하지 않습니다.

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 — 필수: 템플릿 표현식으로, 발행 시 평가되며 예를 들어 본 단계의 출력을 참조합니다
  • type — 기본은 text이며, markdown、json、number、boolean、url、file 등도 지원합니다
  • visibility.scope — private(기본, 본 워크플로 소유자만)、team、workflow_allowlist(allowed_workflows 화이트리스트와 함께 사용)

structured_output — 구조화된 최종 출력

단일 Agent 단계에서만 사용 가능: Agent는 평소대로 도구를 호출하지만 최종 응답은 등록된 schema에 따라 구조화된 결과로 파싱됩니다. write_to를 설정하면 결과를 직렬화하여 파일에 씁니다.

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 — 필수: 등록된 구조화 schema 이름
  • write_to — 선택: 기록할 파일 경로로 템플릿 변수를 지원합니다. 기록 형식은 현재 json만 지원합니다
  • fail_on_empty — 구조화 결과가 비었을 때 단계를 실패시킬지 여부이며, 기본은 true입니다

콤보 제한에 대한 간략한 살펴보기

  • parallel — 단일 에이전트 단계만 구성할 수 있습니다.
  • repeat_until — 단일 에이전트 또는 그룹 채팅만 가능
  • iterate_over — 단일 에이전트 또는 코드만
  • structured_output — 단일 Agent 단계만
  • state_machine — DAG 복합 노드로 실행하고 외부 레이어에서 병렬을 구성하지 마세요.