エージェント ワークフロー ガバナンスの爆発後に学んだ 5 つのエンジニアリングの教訓

#Agent Workflow Governance が爆発した後に私が学んだ 5 つのエンジニアリングの教訓

過去数か月間で、エージェント ワークフロー ガバナンスはニッチな DevOps コンセプトから AI エンジニアリング チームの間でホットな話題になりました。私はチームを率いて 3 つのプロジェクトでガバナンス チェックリストを実装しようとしましたが、その過程で多くの間違いを犯しました。この記事では、独自のエージェント システムで迂回路を避けるのに役立つ、実際の障害シナリオと組み合わせた 5 つの最も重要な教訓を共有したいと思います。

レッスン 1: アクセス許可制御を後処理タスクとして扱わないでください

私が初めてチームを率いてエージェント ワークフロー ガバナンスを実行したとき、最初にオーケストレーション エンジンとタスク キューをセットアップし、アクセス許可の制御に静的 API キーのセットのみを使用しました。オンラインになってから 3 日目、環境変数が正しくなかったため、エージェントが実稼働データベースの書き込みインターフェイスを呼び出し、テスト環境データが混乱しました。

教訓: 権限はワークフロー定義フェーズで明確にする必要があります。各エージェントがアクセスできるリソースと呼び出せる API は、きめ細かいポリシー (OAuth 2.0 スコープや SPIFFE ID など) によって制限する必要があります。ガバナンス チェックリストでは、「アクセス許可を最小限に抑える」はスローガンではなくチェック項目です。各ワークフローの各ステップでは、必要なアクセス許可を宣言し、オーケストレーション層でそれらを検証する必要があります。

レッスン 2: 状態管理は思っているよりも脆弱です

エージェントのワークフローは、多くの場合、複数のサービス間、さらにはクラスター間で実行されます。中間状態を保存するためにメモリ変数を使用するプロジェクトを見たことがあります。ワーカー ノードが再起動されると、進行中のワークフローがすべて失われ、ビジネス側では数時間分の計算結果が失われます。

正しいアプローチ: Redis Streams などの永続状態ストアを使用するか、データベース内のレコードを処理します。各ステップの完了後にチェックポイントが書き込まれ、障害が発生した場合は最新のチェックポイントから回復できます。チェックリストの「状態の永続性」では、各状態 (保留中、実行中、完了、失敗) の保存方法と回復ロジックを説明する必要があります。

レッスン 3: 失敗の処理は再試行だけに頼ることはできません

別のチームは、ガバナンスチェックリストに「失敗時に自動的に 3 回再試行する」と書きました。その結果、サードパーティ API は 3 回連続で 429 の電流制限エラーを返しました。すべての再試行が失敗した後、ワークフローは通知なしで直接配信不能キューに入りました。

教訓: 再試行戦略は、バックオフ アルゴリズム (指数バックオフ + ジッターなど) およびサーキット ブレーカーと組み合わせる必要があります。同時に、「再試行回数が尽きた」場合のアラームと手動介入プロセスを設定する必要があります。チェックリストでは、失敗カテゴリ (再試行可能か再試行不可能か) が定義されているかどうか、最大再試行回数と再試行間隔が構成されているかどうか、再試行が終了した後にアラームがトリガーされるかどうかを確認する必要があります。

レッスン 4: 可観測性はエンドツーエンドをカバーする必要がある

可観測性のないワークフローはブラックボックスのようなものです。私はかつて、運用保守チームが各エージェントのログを表示することによってのみ問題を特定できるプロジェクトに取り組んでいましたが、これは非常に非効率的でした。

改善: 各ステップの最初と最後にトレース (OpenTelemetry など) を挿入して、ワークフロー ID を各ログとメトリックに取り込みます。ガバナンス チェックリストの可観測性チェック項目には、グローバル トレース ID があるかどうか、ステップ レベルの時間のかかる指標が収集されているかどうか、SLA アラームが設定されているかどうかが含まれます。

レッスン 5: セキュリティ コンプライアンスは 1 回限りのタスクではありません

一部の顧客は、すべてのエージェント ワークフローが SOC 2 監査に合格する必要があると考えています。最初は静的スキャンのみを実行していましたが、監査中に特定のワークフロー ステップで機密トークンがログに書き込まれていることが判明しました。

教訓: セキュリティ コンプライアンスをすべてのステップの実行に組み込む必要があります。たとえば、HashiCorp Vault などのシークレット管理サービスを使用して機密情報を挿入し、出力前に機密フィールドをフィルターで除外します。チェックリストには、入力検証、出力フィルタリング、暗号化された送信、監査ログなどのセキュリティ チェックが含まれている必要があります。

実際のシナリオ: クラッシュから再起動まで

具体的な例を挙げてください。当社は、金融顧客の口座開設審査エージェントのワークフローを担当します。これには、本人確認、信用評価、手動審査の 3 つのステップが含まれます。オンラインになってから最初の 1 か月間はすべてがうまくいきました。ある日、信用評価 API が戻り形式をアップグレードするまで、エージェントはスキーマ検証を実行せず、直接例外をスローしていました。 「再試行不可能な例外」カテゴリがチェックリストで定義されていないため、ワークフローは無限ループに入り、繰り返し再試行、失敗、再試行が繰り返されます。最後に、ワーカー スレッド プールが過剰になり、他のワークフローもタイムアウトになります。

見直しの結果、ガバナンス チェックリストに 3 つの項目を追加しました。

• 各ステップでは、予期される入出力スキーマを明示的に宣言する必要があります。
• 例外分類: フォーマット エラーは再試行不可能とみなされ、アラートが直ちに発行され、ワー​​クフローが一時停止されます。
• 同時ワーカーの最大数を設定する必要があります。この数を超えると、新しいリクエストは拒否されます。

この失敗により、ガバナンス チェックリストは見栄えを良くするために書かれたものではなく、変更のたびに見直す必要があることがわかりました。

次のステップ

普通の開発者からエージェント エンジニアに移行する場合、上記の教訓はいくつかの大きな落とし穴を避けるのに役立ちます。しかし、これらは氷山の一角にすぎません。真に体系的なアプローチには、設計パターン、テスト戦略、展開の自動化が含まれます。エージェント ワークフロー ガバナンスのすべての知識を徹底的に習得したい場合は、完全なエンタープライズ レベルのガバナンス ソリューションをカバーする、より体系的な一連のオリジナルの有料記事とコースをまとめました。