次の方法で共有

ワークフロー

ヒント

ワークフローにアクセスする前に、まず、より単純なパターンを試して、ニーズを満たしているかどうかを確認することをお勧めします。 セットアップとデバッグが簡単です。 ワークフローは、1 つのエージェントが単独で確実に提供できない確実な実行順序が必要な場合に最も役立ちます。

これまでの取り組みでは、エージェントを使用して構築する方法がますます強力になりました。 1 つのエージェントで ツールの使用、 スキルの読み込み、 ミドルウェアの実行、 豊富なコンテキストでの描画を行う方法を確認しました。 エージェントを 別のツールとして使用 して構成し、 A2A を使用してサービス境界を越えて接続しました。

これらのパターンはすべて共通の特徴を共有します。 LLM は次に何が起こるかを決定します。 モデルは、呼び出すツール、委任するかどうか、および停止するタイミングを選択します。 これは、適切なパスが会話に依存するオープンエンドタスクには強力ですが、プロセス自体にルールがある場合は責任があります。

次のようなシナリオを検討します。

  • 毎回、下書きを書き、レビューし、改訂し、承認する必要がある ドキュメント レビュー パイプライン 。
  • 情報の収集、コンプライアンス チェックの実行、アカウントのプロビジョニング、ウェルカム メールの送信を行う 顧客オンボード フロー 。一部の手順は並行して行われ、一部は人間の承認によって制御されます。
  • 複数のソースからデータを収集し、結果をマージし、レポートを生成する 分析ワークフロー 。途中でエラーが最初からやり直すのではなく、最後のチェックポイントから再開する必要があります。

いずれの場合も、プロセスの 構造 は事前にわかっています。 手順、順序、決定ポイントは、実行時にモデルを把握する必要はありません。 グラフを明示的に定義し、その中でエージェント (またはその他のロジック) を実行できるようにする必要があります。

ワークフローが提供する 内容 です。

インテリジェンスのスペクトル

エージェント アプリケーションは、完全に自律的または完全なルール ベースである必要はありません。その間にはさまざまな範囲があり、ワークフローを使用して、どこに配置するか選択できます。

Fully intelligent                                              Fully deterministic
(model decides everything)                                     (code decides everything)
◄──────────────────────────────────────────────────────────────►
│                         │                         │
│  Single agent with      │  Workflow with agent    │  Workflow with only
│  tools — the model      │  executors — the graph  │  deterministic executors
│  picks every step       │  controls the process,  │  — no LLM involved,
│                         │  agents handle the      │  pure business logic
│                         │  reasoning-heavy steps  │

左端では、ツールを備えた 1 つのエージェントがすべてを処理します。モデルは、何を行うか、委任するタイミング、停止するタイミングを決定します。 これは最も柔軟なアプローチですが、予測可能な方法も最も少なくなっています。 右端では、純粋に決定論的な実行プログラムを含むワークフローは、基本的に従来のパイプラインであり、完全に予測可能ですが、AI の推論はまったくありません。

ほとんどの実際のアプリケーションは 、中央のどこかに住んでいます。 ワークフローは構造 (どのステップがどの順序で、どのゲートで実行されるのか) を定義します。一方、そのワークフロー内の個々の Executor は、LLM 推論のメリットを得るステップにエージェントを使用します。 重要な場面で AI のインテリジェンスを活用し、明示的なプロセスの予測可能性を手に入れることができます。

重要な分析情報は、 ダイヤルを制御することです。 プロセスの各ステップについて、次の決定を行います。

  • モデルは何をすべきかを理解する必要がありますか? → エージェント実行プログラムを使用します。
  • コードで結果を決定する必要がありますか? → 通常のビジネス ロジックで決定論的実行プログラムを使用します。
  • 人間が電話をかける必要がありますか? → ヒューマンインザループゲートを使用します。

これはワークフローの真の力です。エージェントを置き換えるのではなく、アプリケーションの各部分に入る インテリジェンスの量 を明示的に制御できます。

適切なパターンの選択

この取り組みとワークフローの前半のパターンは、競合するアプローチではなく、さまざまな点で異なります。 重要な質問は、 次に何が起こるかを誰が決める必要があるかです。

質問 答えが "モデル" の場合 答えが "開発者" の場合
次に取り組むサブタスクはどれですか? ツールとしてのエージェント — 外部エージェントが動的にルーティングする ワークフロー - グラフによってパスが定義されます
別のエージェントを関与させるかどうか。 ツールとしてのエージェント — モデル駆動型委任 ワークフロー内のエージェント — エージェントを一緒にワイヤ化するグラフ
いつ人間に尋ねるのですか? ツールの承認 — 事後対応型、ツールごと Human-in-the-loop — 定義されたポイントでの明示的なゲート
部分的な障害を処理する方法 ツール実装での再試行ロジック チェックポイント - 最後に保存された状態から再開します

実際には、ほとんどの運用システムは 両方を組み合わせています。 ワークフローは高度なプロセスを定義し、そのワークフロー内の個々の Executor は LLM 推論のメリットを得るステップにエージェントを使用します。 ワークフロー ページのエージェントには、その方法が正確に示されています。

組み込みのオーケストレーション パターン

一般的なマルチエージェント調整シナリオでは、Agent Framework には 組み込みのオーケストレーション パターン (直接使用したりカスタマイズしたりできる事前構築済みのワークフロー テンプレート) が用意されています。

パターン いつ使用するか
シーケンシャル エージェントは、定義された順序で次々に実行されます。各エージェントは、前のエージェントの出力に基づいて構築されます
並行 エージェントは並列で実行されます。タスクが独立していて待機時間を短縮したい場合に便利です
ハンドオフ エージェントはコンテキストに基づいて相互に制御を転送します。スペシャリストへのルーティングに適しています
グループ チャット エージェントは共有会話で共同作業を行います。議論、レビュー、ブレーンストーミングに役立ちます
マゼンティック マネージャー エージェントは、特殊なエージェントを動的に調整し、構造と柔軟性のバランスを取ります

これらのオーケストレーションは、エージェントの調整に関わる定型処理を行うことで、エージェントそのものに集中できるようにします。

エージェントとしてのワークフロー

最も強力なコンポジション パターンの 1 つは、通常のエージェントのように見えるようにワークフローをラップすることです。 エージェントとしてのワークフロー機能を使用すると、複雑なマルチステップ ワークフローを作成し、標準のエージェント インターフェイスを介して公開できます。 他のエージェントはツールとして呼び出すことができます。A2A クライアントは HTTP 経由でそれを呼び出すことができます。コンシューマーは、ワークフローと通信していることをまったく知る必要はありません。

体験のまとめ

これで、エージェント開発パターンの全範囲を確認できました。

パターン 最適な用途
LLM の基礎 基礎を理解する
LLM からエージェントへ エージェントの抽象化
ツールの追加 外部システムで動作するエージェント
スキルの追加 再利用可能なモジュール式エージェントの動作
ミドルウェアの追加 横断的な懸念事項とガードレール
コンテキスト プロバイダー メモリ、パーソナル化、RAG
ツールとしてのエージェント 単純なエージェントの構成と委任
エージェント間通信(A2A) サービス間エージェント通信
ワークフロー 複雑なマルチステップ オーケストレーションと明示的な制御

各パターンは、機能と複雑さを追加します。 最適なエージェント システムは、要件を満たす最も単純なパターンを使用し、シナリオで要求された場合にのみ、より強力なパターンに到達します。

次のステップ

より深く進む:

  • Last updated on