Agent Engineering リカバリ ワークフローの例と Responses API のリカバリ順序: AI プログラミング チームはどのように選択すべきですか?

適用可能なオブジェクト

この記事は、AI プログラミング チームのエンジニアおよび技術リーダーを対象としています。エージェント システムを構築または保守していて、「リカバリ ワークフロー」の設計上の問題が発生しました。エージェントの呼び出しが失敗した場合、コンテキストが失われた場合、またはツールの実行がタイムアウトした場合、システムを自動的にリカバリするにはどの方法を使用する必要がありますか? Agent Engineering コミュニティによって推奨されている「リカバリ ワークフローの例」(再試行 + 状態ロールバック テンプレート) について聞いたことがあるかもしれません。また、OpenAI Responses API に付属する「リカバリ順序」メカニズムにも触れたことがあるかもしれません。しかし、どのようなシナリオでどれを選択すればよいでしょうか?これは、チームのテクノロジースタック、システムの複雑さ、回復精度の要求に基づいて判断する必要があります。

寸法を比較する

1. リカバリ機能の範囲: カスタマイズされたプラットフォームと組み込みプラットフォーム

Agent Engineering リカバリ ワークフローの例は、通常、「リカバリ チェーン」を定義できるようにするカスタム実装されたリカバリ テンプレートです。たとえば、3 回再試行し、失敗した場合は前のチェックポイントにロールバックし、失敗した場合は読み取り専用モードに低下します。この柔軟性は、すべてのステップでリカバリ ロジックを正確に制御でき、さまざまな種類のエラーを処理するための条件分岐を作成できることを意味します。

Responses API 回復順序は、OpenAI によって提供される内部回復メカニズムであり、API 呼び出し層で実装されます。リクエストが失敗すると、API は事前に設定された優先順位に従って自動的に代替構成を試行します (より小さいモデルにフォールバックする、温度を下げる、max_tokens を短縮するなど)。ただし、この順序に干渉することはできません。優先度を変更できるのは、API パラメーターの「回復順序」配列を調整することによってのみです。

2. 該当するシナリオ: カスタム リカバリを使用する場合と API レベルのリカバリを使用する場合

シナリオ 1: エージェント内の複数のツール呼び出しの回復

「検索 -> コード生成 -> テスト」を順番に呼び出す必要があるエージェントを想像してください。コード生成が失敗した場合は、検索の副作用 (メモリの解放など) をロールバックして、再試行することができます。現時点では、Responses API 回復命令は単一の API 呼び出しの失敗のみを処理し、複数のツール間の状態の依存関係を感知できないため、無力です。リカバリ ワークフローの例をカスタマイズし、各ステップで補償操作を管理するステート マシンを導入する必要があります。

方法: エージェントのループで、ツール呼び出しごとに「on_failure」コールバックを定義します。コード生成が失敗した場合、まず検索ロールバック機能 (キャッシュのクリアなど) が実行され、エラーの種類に基づいて代替コード モデルに置き換えるかどうかが決定されます。

シナリオ 2: 高負荷時の API 呼び出しの急速な低下

チームが Responses API を使用してチャットボットを構築している場合は、高価な gpt-4o モデルを入手してください。 API が 429 (スロットル) または 500 (サーバー エラー) を返した場合、より小型で安価な gpt-3.5-turbo モデルに自動的に切り替え、応答時間を短縮してコストを節約したいと考えます。現時点では、リクエストで Responses API 回復順序: set "recovery_order": [{"model": "gpt-3.5-turbo", "max_tokens": 512}, {"model": "gpt-3.5-turbo", "max_tokens": 256}] を使用するのが最も直接的です。 API は失敗するたびに自動的に順番に試行し、再試行ロジックを作成する必要はありません。

3. 失敗が最も起こりやすい境界線

障害ポイント 1: カスタム リカバリ ワークフロー ステータスの拡張

多くのチームが初めてリカバリ ワークフローの例を使用し始めるとき、各エラーをリカバリ ステップにマッピングすることを好みます。しかし、すぐに状態図は混乱してしまいました。 Reddit でエンジニアが共有した内容: 彼のエージェントには 12 の状態と 30 の遷移があり、テスト カバレッジは 30% 未満です。最後に、運用上の事故により、リカバリ ワークフローが無限ループに入り、ログはすべて「リカバリ -> ロールバック -> 再試行 -> リカバリ」になりました。

重要なのは、すべてのエラーに対してリカバリを設計しないことです。エラーに優先順位を付け、「回復可能な」エラー (ネットワーク タイムアウトや一時的な電流制限など) に対してのみ回復パスを定義します。 「回復不可能な」もの (無効な入力形式、不十分な権限など) については、処理のために人間に直接スローする必要があります。

障害ポイント 2: Responses API 回復命令ではビジネスレベルのエラーを処理できません

Responses API の回復順序は、HTTP 層のエラーのみを対象としています。ビジネス ロジックで API が 200 を返しても、JSON フィールドが欠落しているか、コンテンツが切り捨てられている場合、リカバリはトリガーされません。あるとき、gpt-4-1106-preview を使用してコードを生成したところ、返されたコード ブロックは半分に切り詰められていましたが、API はリクエストが成功したとみなしました。この場合、回復命令では回復は開始されないため、アプリケーション層で整合性をチェックし、再試行をトリガーする必要があります。

実際のシナリオ (失敗と解決策を含む)

昨年、私はリファクタリングのためのコードレビューを行う AI 製品チームを手伝いました。彼らは Responses API を使用してコード分析エージェントを構築しました。差分を受け取り、API 分析を呼び出し、提案を返します。 API はピーク時にタイムアウトになることが多いため、最初に同じ設定を 2 回再試行し、次に gpt-3.5-turbo に切り替えるという回復順序が設定されています。この解決策は合理的であるように思えましたが、オンラインになってから、gpt-3.5-turbo もタイムアウトすると API がエラーを返し、回復命令は再試行せずに実行されることがわかりました。このエラーはアプリケーション層では捕捉されないため、ユーザーには空白のページが表示されます。

その後、カスタマイズされた回復ワークフローに変更しました。 例: API 実行レイヤーの外側に回復ロジックのレイヤーをラップする - すべての API 回復ステップが失敗した場合、エラーが UI に浸透するのではなく、「分析タイムアウトです。後でもう一度お試しください」という劣化した応答が返されます。同時に、この失敗のコンテキストは、その後のオフラインでの再実行のためにログ (差分の概要を含む) に記録されます。

このケースは次のことを示しています: Responses API 回復命令は防御の第一線として適していますが、すべての問題を解決できるわけではありません。正常なダウングレードとログ追跡が必要な複雑なシナリオの場合、カスタム回復ワークフローが必要な補足です。

実行可能なプラクティス: チームはどのように選択すべきか

1. エージェントのコア コール タイプをリストします: それは単一の API コールですか、それともマルチツール チェーン コールですか?単一の呼び出しの場合は Responses API 回復順序を検討し、複数の呼び出しの場合はカスタム回復ワークフローを検討してください。
2. 採点エラー: どのエラーが「回復可能」ですか (タイムアウト、電流制限など)? 「回復不可能」なものはどれですか (無効なパラメータ、失敗した認証など)?回復可能なエラーに対する回復パスのみを設計してください。
3. 簡単に開始: まず Responses API リカバリ順序を高速レイヤーとして使用し、次にクリティカル パスのカスタム リカバリを追加します。初日から複雑な回復ステート マシンを設計しないでください。
4. 回復効果を監視: 回復の成功または失敗のログを記録します。リカバリの成功率が 80% 未満の場合は、リカバリ戦略を調整する必要があります (再試行間隔を長くする、バックアップ モデルを置き換えるなど)。
5. バックアップ計画を準備する: どちらの回復方法でもエラーを処理できない場合は、エラーをエンド ユーザーに公開するのではなく、システムに「ダウングレード応答」メカニズム (キャッシュされた結果を返す、後で再試行するようユーザーに求めるなど) があることを確認します。

制限事項

• Agent Engineering リカバリ ワークフローの例では、チームにステート マシンの設計能力が必要であり、メンテナンス コストが高くなります。
• Responses API 回復命令は OpenAI API に対してのみ有効です。他のモデルプロバイダー (Anthropic など) に切り替える場合は、それを自分で実装する必要があります。
• どちらの方法も 100% の回復成功を保証するものではありません。根本原因がコードのバグまたはデータ エラーである障害の場合、リカバリは問題を隠すだけであり、最終的には手動介入が必要になります。

概要

AI プログラミング チームにとって、回復ワークフローの選択は「どちらか一方」ではなく、多層防御です。 Responses API リカバリ順序は、API レイヤーでの一時的な障害を迅速に処理するのに適していますが、カスタムのリカバリ ワークフロー サンプルは、複雑なビジネス レベルのリカバリと状態管理を処理するのに適しています。呼び出しチェーンの長さとビジネス許容度に基づいて、どのレイヤーに回復ロジックを展開するかを決定します。

次のステップ

リカバリ ワークフロー、コンテキスト管理、ツール キャリブレーションなどのコア スキルを含むエージェント エンジニアリングの設計パターンを体系的に習得したい場合は、高品質のオリジナルの有料記事と AI の高度なプログラミング コースを徹底的に学習することをお勧めします。