単一エージェント・システムでは失敗は単純です。エージェントがエラーを起こしたら、やり直すだけです。
複数エージェント・システムでは、失敗はグラフ問題になります。
カスケード障害の問題
Agent A: ✅ 成功
Agent B: ❌ タイムアウト（Aに依存）
Agent C: ❌ スキップ（Bに依存）
Agent D: ❌ 部分データ（Cに依存）
1回のタイムアウトが、パイプライン全体に伝播します。復旧がなければ、システムは脆弱です。
私たちの復旧戦略
AgentForge は3つの復旧レイヤーを実装しています：
レイヤー1：指数バックオフ付きリトライ
@retry(max_attempts=3, backoff=exponential(base=2, max=60))
def agent_call(params):
return llm.invoke(params)
レイヤー2：サーキットブレーカー
あるエージェントが10分間で5回失敗した場合、その呼び出しを停止し、劣化したレスポンスを返します：
{
"status": "degraded",
"agent": "market_data",
"fallback": "cached_data",
"warning": "Real-time data unavailable, using 15-min delayed feed"
}
レイヤー3：パイプラインの再計画
重要なエージェントが失敗した場合、オーケストレーターは再計画できます：
- 重要でない場合は、失敗したステップをスキップする
- バックアップのエージェントに置き換える
- 停止して、完全なコンテキストのトレースとともにアラートを出す
実際のインシデント
先月、取引時間中に当社のマーケットデータAPIがダウンしました。何が起きたかというと：
- 14:32 — マーケットデータエージェントのタイムアウト（レイヤー1：3回のリトライが失敗）
- 14:33 — マーケットデータエージェントに対してサーキットブレーカーをオープン
- 14:33 — パイプラインが自動的にキャッシュデータへ切り替え、警告フラグを付与
- 14:35 — 「遅延データ」の免責事項付きでレポートを生成
- 15:00 — マーケットデータAPIが復旧し、サーキットブレーカーが自動でクローズ
ゼロの手動介入。ゼロのレポート取りこぼし。
これは最低限の要件です
複数エージェント・システムが、1つのエージェントが失敗するだけで対応できないなら、それは本番投入に適していません。
AgentForge は、これを思いつきの後付けではなく、デフォルトにしています。
https://github.com/agentforge-cyber/agentforge-mvp
2026-04-29 に AgentForge チームが投稿。
