Skip to main content
次の要件を満たすサポートワークフローを作る場合は、このレシピを使います。
  • ダッシュボードのプリセットからルーティングとプロンプトの既定値を引き継ぐ
  • 厳密に構造化された出力を返す
  • リスクの高いケースを人による確認のために保留する
  • ゲートウェイの失敗をエージェントコード内に隠さず、ログで確認できるようにする

1. プリセットから始める

support-triage のようなプリセットを作成し、次の項目を管理します。
  • 既定のルーティングモデルまたはルーターの対象
  • プロバイダーの優先設定
  • サポート用システムプロンプト
  • 安定したデコードパラメーター
これにより、リクエストポリシーを重複させず、エージェントコードをワークフロー制御に集中できます。

2. 明確なトリアージ契約を定義する

運用担当者がすぐ確認できるよう、最初の出力形式は小さく保ちます。

3. プリセット駆動のエージェントを作成する

SDK は preset: "support-triage" をゲートウェイのエイリアス形式 @support-triage に解決します。

4. ゲートウェイ接続アダプターを設定する

トリアージ実行ごとに固定する項目には、アダプターの既定値を使います。

5. 再試行回数を制限してワークフローを実行する

レビューのために実行が一時停止したら、明示的に再開します:

6. ゲートウェイの失敗を運用イベントとして扱う

エージェントのコールバックチェーン内で失敗を握りつぶして隠さないでください。 代わりに、AgentGatewayError を明示的にキャッチします。
次に、以下を行います。
  1. ランタイムに failed の実行状態とステップ状態を保存させます。
  2. 元の例外がメモリ上にない後続の復旧処理では、loaded.run.errorDetails または loaded.steps[n].errorDetails を確認します。
  3. リクエストの詳細で次を確認します。
    • ガードレールの適用
    • ルーティングの詳細
    • プラグインの実行
    • リクエスト ID とプロバイダーデータ
特に次の場合は重要です。
  • ガードレールがリクエストをブロックする
  • プリセットの許可リストが要求されたモデルを拒否する
  • プロバイダーの認証情報や有効化フィルターによって、ルーティング候補が除外される
  • response healing でスキーマに適合する JSON を復元できない

7. 確認すること

成功した実行と、意図的にリスクのある実行をそれぞれ 1 回行い、次を確認します。
  • リクエスト詳細画面にプリセットで指定されたリクエスト対象が表示される
  • 高リスクのケースが waiting_for_human で保留される
  • モデルステップの再試行で modelAttempts が保存される
  • ガードレールまたはプリセットによる失敗がエージェントの例外内に隠されず、リクエスト詳細に表示される

関連ガイド

最終更新日 2026年10月2日