メインコンテンツへ移動
ドキュメントワークフローの構築ステップタイプ

8ステップタイプ

単一エージェント、グループチャット、エージェントベース、コード、分類子、状態マシン、サブワークフロー、マニュアル承認の使用法とフィールド参照。

Braidrun では現在 8 つのステップ タイプを提供しています。 Only one main mode must be selected for each step;他のフィールドは拡張機能 (再試行、条件、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.agent_based — 動的委任

オーケストレーター エージェントはワーカーを選択し、実行時にサブタスクをディスパッチします。静的なグループチャットと比べて、「誰が適任かわからない、プランナーに任せる」というシナリオに適しています。

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 に入るフローは 1 つだけです。

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 — 構成できるエージェント ステップは 1 つだけです
  • repeat_until — 単一のエージェントまたはグループチャットのみ
  • iterate_over — 単一のエージェントまたはコードのみ
  • structured_output — 単一 Agent ステップのみ
  • state_machine — Run as a DAG composite node, do not configure parallel in the outer layer