利益:
- 最も単純なソリューションからエージェントに段階的に複雑さを適用する
- チェーン、ルーティング、並列ワークフロー パターンの区別
- 複数ステップのタスクを計画、実行、検証のサイクルに分割する
前の単元で 1 台の車両によるシンプルサイクルを確立しました。実際の仕事では、多くの場合、複数の手順、複数のツール、そして場合によっては分岐する意思決定が必要になります。「今月下旬の注文を見つけて、顧客への謝罪メールの草稿を作成し、マネージャーに向けて要約する」。この単元では、実際のエージェントが必要な場合の複数ステップのタスクを整理するパターンと、計画、実行、検証のサイクルについて説明します。主な原則は、必要なだけ複雑にすることです。
最も単純なソリューションからエージェントまで拡張
すべてのタスクが最も複雑なソリューションに値するわけではありません。複雑さのスケールを段階的に登っていき、最も単純で適切な解決策に到達します。
- 単一呼び出し: タスクが単一のモデル呼び出し (要約、分類) によって解決される場合は、ここで終了します。
- RAG による単一呼び出し: 情報が必要な場合は、取得を追加して再度単一呼び出しを行います。
- 固定ワークフロー: 手順が事前にわかっている場合は、手動で順序付けします (コード フロー)。モデルは各ステップでサブジョブを実行しますが、その順序はユーザーが決定します。
- モデル駆動型エージェント: 手順を事前に知ることができない場合、モデルはどのエージェントをいつ呼び出すかを決定します。最も強力ですが、最も高価でリスクの高いオプションです。
ワークフローとエージェントの違いは重要です。ワークフローでは、制御のフロー (予測可能、テスト可能、安価) を作成します。アジェンダの制御をモデルに与えます (柔軟性はありますが、予測できません)。企業の仕事のほとんどは実際にはワークフローです。本物のエージェントは比較的少数です。
ヒント: 「このタスクの手順を事前に書き留めてもいいですか?」聞く。書けるなら、より安く、より安全で、よりテストしやすいワークフローを構築してください。ただし、入力によって手順が異なり予測できない場合は、エージェントが必要です。
3 つの基本的なワークフロー パターン
プロンプトチェーン: 1 つのステップの出力が次のステップの入力になります。 「下書き作成→編集→フォーマット」。すべてのステップはシンプルかつ集中的です。デバッグが簡単です。
ルーティング: まず受信リクエストを分類し、適切な専門家に送信します。 「この質問は技術的なものですか、請求に関するものですか、それとも返金に関するものですか?」 → 正しいサブストリームにリダイレクトします。各パスは、独自のプロンプトとツールを使用して最適化されます。
並列化: 独立したジョブを同時に実行し、結果を結合します。 「5つの書類を別々にまとめてから結合してください。」速いだけでなく、すべての部分に注目が集まります。
パターン
いつ
例
鎖につながれた
ステップは順次的であり、依存しています
下書き→編集→フォーマット
リダイレクト
入力の種類に応じて異なる処理
サポートリクエストの分類
平行
独立したサブワーク
複数の書類を別々に要約する
エージェント（ループ）
歩数を事前に予測することはできない
無制限の研究/修理
# ルーティング パターン (概念的)type = pattern.classify(request) # "return" | 「テクニック」 | "請求書"if ツアー == "返却": 回答 = return_flow(request)elif tur == "技術": 回答 = Technical_flow(request)else: 回答 = invoice_flow(request)
計画・実行・検証サイクル
実際のエージェントの強力なパターン: モデルを計画し、実行し、検証します。モデルは複雑なタスクをサブステップに分割し、ツールを使用して各ステップを実行し、最後に「目標は達成できたか?」と尋ねます。彼はチェックします。検証ステップでは、個別の新鮮な外観 (「この出力はタスクを満たしているか?」) でエラーを検出します。
# 計画-実行-検証 (概念)plan = model.uret("このタスクをステップに分割します: " + task)for step in plan: result = Agent_loop(step) # ツールを使用して実行check = model.uret("この出力はタスクを満たしていますか? 不足しているものがあれば教えてください: " + task + results)if check.missing: # 修正ラウンド ...
長いタスクに関する 2 つの推奨事項: 停止条件を課す (ステップの最大数 - 無限ループを防ぐ) と、進捗状況を追跡する (エージェントが気が散らないように、自分が何をしているかを書き留めてもらいます)。ステップ制限がないエージェントは、行き詰まると永遠に回転し、コストが爆発的に増加します。
弱い/強いデザイン
弱い (すべてを 1 つの巨大なエージェントに任せる):
「複雑なことを終わらせて」と言って、無制限のツールを使用してリリースします。# 結果: 予測できない動作、無限ループのリスク、高コスト、# デバッグ不可能。
強力 (フローファースト、エージェントは必要な場合のみ、限定的):
まず、ジョブを固定ステップ (ルーティング + チェーン) に分割します。ステップが不明なサブタスクでのみエージェントを使用してください。歩数制限、進捗状況の追跡、検証ラウンドを追加します。
ミニケース3個
ケース 1 — エージェントの代わりにワークフロー。あるチームはフリーエージェントを使って「サポートリクエストの処理」タスクを設定しました。場合によっては、エージェントが 15 歩曲がり、間違った道を進むこともありました。手順は基本的に修正されました (分類 → 関連情報の取得 → 草稿の作成 → 承認のために送信)。ルーティング + チェーン ワークフローに切り替えると、一貫性が 58% から 96% に向上し、コストが半分になりました。
ケース 2 — 並列ゲイン。法務チームは 20 件の契約を 1 つずつ要約していました。合計4分かかりました。並列パターン (すべてを同時に、その後結合) に切り替えると、時間が 25 秒に短縮され、各要約に十分な注意が向けられるようになり、品質が向上しました。
ケース 3 — 停止条件がありませんでした。捜査官は同じ 2 つのツールを延々と呼び出し続け、見つからない情報を検索しました。一夜にして多額のコストが蓄積されました。最大8ステップの制限と「3回試して見つからない場合は、分からないと言う」ルールを追加すると、コストは抑えられ、「見つからなかった」という正直な答えが返ってきました。
よくある間違い
- すべてをエージェントに委任する: 手順がわかっていれば、ワークフローはより安価で安全で、テスト可能です。
- ワークフローとエージェントの混合: あなたまたはモデルが主導権を握りますか?これを明確にせずにデザインしないでください。
- 停止条件を設定しない場合: エージェントは無限ループに入り、コストが蓄積されます。
- 進捗状況の追跡がない: 長いミッション中にエージェントは気が散ってしまい、同じ作業を繰り返してしまいます。
- 検証ラウンドをスキップする: 間違っているが、一見もっともらしい出力がチェックされずに配信されます。
注意: エージェントが自由になるほど、爆発範囲は大きくなります。柔軟性は無料ではありません。自由が増えるたびに、予測不可能性とリスクが増大します。最も狭い適切なソリューションを選択します。
要約すると
- 複雑な場合には、「必要に応じて」の原則が適用されます。つまり、本当に必要な場合にのみ、単一通話→ RAG → ワークフロー → エージェントになります。
- ワークフローでは、(予測可能な) 制御の流れを記述します。アジェンダをモデルに任せます (柔軟性はありますが、リスクが伴います)。
- 3 つの基本パターン: チェーン (順次依存)、ルーティング (種類ごとに分散)、並列 (独立したジョブ)。
- 実際のエージェントは、計画、実行、検証のサイクル、停止条件、および進行状況の追跡を使用します。
- 柔軟性が高まるにつれて、予測不可能性とコストが増加します。最も狭い適切なソリューションを選択します。
アプリケーションタスク
自分のビジネスから複数ステップのタスクを選択します (例: 「月次レポートの作成と配布」)。 (1) このタスクの手順を事前に書いていただけますか?作成できる場合は、ワークフローとして設計してください (どのようなパターン: チェーン/ルーティング/並列か)。書けない場合は、エージェントが必要な理由を説明してください。 (2) 選択したデザインをボックスアロー図で描きます。 (3) 代理店の場合: 停止条件、進捗追跡、検証ラウンドをどのように設定するかを記述します。 (4) 「単一の開発エージェント」で同じタスクを実行する場合のリスクを 3 つ挙げてください。
チェックリスト
- [ ] 「必要に応じて複雑さ」のスケールで適切なレベルを選択できます。
- [ ] ワークフローとエージェントの制御の違いがわかります。
- [ ] チェーン、ルーティング、並列パターンを適切なタスクにマッピングできます。
- [ ] エージェントで計画、実行、検証のサイクル、停止条件、進行状況の追跡を設定できます。
- [ ] 柔軟性が高すぎると、予測不可能性とコストが発生することに留意しています。