LangChain マルチエージェントハンドオフ: 監査状態、コンテキスト、および結果

LangChain マルチ エージェント ハンドオフ の場合、転送ツール呼び出しの成功は最初の証拠にすぎません。宣言されたルートが許可され、制御状態が目的のエージェントに移行し、ツール呼び出しサイクルが終了し、必要なコンテキストが到着し、宛先が有用な作業を開始し、要求された結果が個別に検証される場合、ハンドオフは正常であると扱われます。 転送が破損した後もグラフは実行を続ける可能性があるため、その答えは重要です。 goto は 1 つのノードに名前を付けることができますが、 active agent は引き続き別のノードに名前を付けます。転送ツールは、一致するツールの応答なしで戻る場合があります。新しいエージェントは不完全なコンテキストで開始される可能性があります。また、外部タスクが未完了のまま、洗練された最終メッセージを生成することもできます。 このガイドでは、これらの境界を内容のないレシートに変換し、8 つの合成ケースを再生します。この例は、2026 年 7 月 30 日に取得された公式 LangChain および LangGraph ドキュメントを反映しています。そのチェック時に、PyPI が報告しました。LangChain 1.3.14そしてLangGraph 1.2.10。状態とストリーミング コントラクトは変更される可能性があるため、独自の依存関係バージョンを固定して再確認します。 ステートフルな直接会話のためのハンドオフを選択する LangChainさん引き継ぎドキュメント状態を通じてパターンを定義します。ツールは、 current step や active agent などの変数を更新します。後続のモデル コンフィギュレーションまたはグラフ ルーティングでは、その変数が読み取られます。状態はターンを超えて持続するため、現在アクティブなスペシャリストはユーザーと直接会話を続けることができます。 これは次の場合に適しています。 会話は一連の段階を経て進みます。 機能は前提条件の後にのみロックを解除する必要があります。 アクティブなスペシャリストは次のターンでもコントロールを維持する必要があります。 ユーザーはその専門家と直接対話する必要があります。 タスクが複雑だからといって、複数のエージェントで開始しないでください。役人マルチエージェントの概要適切なツールと動的な指示を備えた 1 人のエージェントが多くの場合作業を実行できると述べています。これにより、ハンドオフがサブエージェント、スキル、ルーター、カスタム ワークフローから区別されます。 「エージェント」のアイデンティティが主にプロンプ​​ト、ツール、またはステージの変更である場合、妥当なデフォルトは 1 つのエージェントとミドルウェアです。スペシャリストがまったく異なる状態、ツール、ライフサイクル ロジック、または所有権を必要とする場合は、個別のエージェント サブグラフを選択します。その選択は証拠契約に影響します。 ミドルウェアを備えた単一エージェント: 状態変数が変更され、次のモデル呼び出しが意図した構成を受け取ったことを証明します。 複数のサブグラフ: は、グラフ ルーティングが宛先に到達し、宛先が正しいコンテキストを受信したことも証明します。 ハンドオフはステートフルでマルチホップです。これらは並列ファンアウトの自然な選択ではなく、専門家がユーザーの作業を完了したこと自体を証明するものでもありません。 6 つの境界を順番に監査する 文書化された複数のサブグラフの例では、 goto を含む Command 、 active agent 更新、 ToolMessage 、および graph=Command.PARENT を返します。 LangChain は、ハンドオフ ツールがメッセージ履歴を更新するときに、 ToolMessage が一致する tool call id を使用することを明示的に要求します。その応答がなければ、モデルのツールの要求と応答のサイクルは不正な形式のままになります。 これらのフィールドは重要なチェックを定義しますが、操作全体をカバーするわけではありません。 境界 最低限の証拠 失敗した状態 安全な次の動き ルート to agent が宣言され、 goto === to agent ROUTE REJECTED 転送をブロックします。宣言されたルートを復元する コントロール before state は送信者に名前を付け、after state は受信者に名前を付けます STALE CONTROL 再試行する前に永続化された状態を調整する ツールプロトコル 1 つの ToolMessage は正確な tool call id を閉じます OPEN TOOL PROTOCOL 別のモデルコール前の修復履歴 コンテクスト 必要なすべてのコンテキスト キーが宛先に存在する CONTEXT INCOMPLETE 最低限の譲渡契約を再構築する 行き先 対象のノードは許可された開始を記録します DESTINATION NOT STARTED ルーティングとノード許可を検査する 結果 タスク固有の検証者が期待される結果を記録する FALSE COMPLETE タスクを再度開きます。最後のメッセージを信用しないでください コンテキスト チェックでは、トランスクリプトではなくスキーマを比較する必要があります。たとえば、販売の引き継ぎには、 request type 、 customer tier 、および consent status が必要になる場合があります。レシートには、これらのキー名と、場合によってはコンテンツのダイジェストが記録されます。顧客のメッセージやツールの引数は必要ありません。 この境界は、個別のサブグラフの場合に特に重要です。 LangChain は、メッセージ フローには明示的なコンテキスト エンジニアリングが必要であると警告しています。すべてを渡すと、コンテキストが肥大化したり、無関係なデータが公開されたりする可能性があります。パスが少なすぎると、受信者が自信を持って別のタスクを解決する可能性があります。ルートごとに必要なキーを定義し、キーがない場合はフェールクローズします。 宛先開始の受信は、制御状態の更新とは別のものです。リデューサーは、販売ノードがまったく許可されない場合、すぐにクラッシュする場合、またはキューで待機している場合でも、 active agent: "sales agent" を受け入れることができます。状態の突然変異は活動です。宛先イベントは、受信側が実際に開始したことを確立します。 8 件のレシートを再生する この記事のアーティファクトでは、合成構造フィールドのみを使用します。 その分類子は優先順位ルールを適用します。初期の障害により、後の青信号によって障害が隠されるのを防ぎます。 以下を使用して完全なローカル フィクスチャを実行します。 リプレイでは、8 つのケースから 8 つの予想される分類が生成されました。 これは、LangChain に関する故障率に関する主張ではありません。決定ルールのテストです。有用な観察は、調整されたルーティングと状態がまだ不十分であるということです。ツール メッセージ ID、コンテキスト キー セット、宛先開始時刻、または結果の受信のみを変更すると、判定が変わります。 この固定具は、誘惑的なショートカットも防止します。最終状態が complete であるが、結果の受信が存在しない場合、すべてのハンドオフ固有のフィールドが有効であっても、分類子は FALSE COMPLETE を返します。転送の正確さとタスクの正確さは別の問題です。 正当な待機を維持する 宛先エージェントは、購入を承認したり、許可されたチャネルを通じて秘密を開示したり、取り消し不能なオプションから選択したりする人を必要とする場合があります。これは自動的にハンドオフがスタックするわけではありません。 次のように有効な待機を記録します。 責任ある owner 。 有界の reason 。 将来の deadlineUtc 。 耐久性のある resumeTokenId 。 宛先の状態と必要なコンテキストはすでに永続化されています。 5 つのファクトがすべて存在する場合、実行を WAITING ON APPROVAL にルーティングします。所有者に通知し、期限または決定がされるまでグラフをそのままにしておきます。モデル呼び出しを繰り返しても、権限の欠落は解決されません。彼らは予算を費やすだけで、効果が重複する危険があります。 待機に所有者や期限がない場合は、正常ではなく不確実として分類します。再開トークンが欠落している場合、人間の応答では正しいグラフ状態に再接続できない可能性があります。宛先がまだ待機中に完了を宣言した場合、結果検証者はフレンドリーな最終応答よりも優先されます。 この区別により、オペレーターに実際的な介入境界が与えられます。 待機中: 状態を保存し、その決定を所有者に通知します。 古い制御またはオープンプロトコル: 自動継続を停止し、証拠を調整します。 False complete: タスクを再度開き、結果検証ツールを実行します。 健康: 何もしません。 デフォルトは回復ではなく観察です。再ルーティングによって副作用が繰り返される可能性があり、再構築されたメッセージによって受信者に表示される内容が変わる可能性があります。介入によって外部状態が変更される前に、明示的な権限が必要です。 レシートをグラフの横に置きます 証拠が分かるようになった各境界を収集します。 1. ハンドオフ作成時: 送信者、対象受信者、ルート コントラクト バージョン、ツール呼び出し ID、必要なコンテキスト キー名。 2. 状態削減後: active agent が観察され、結果のグラフ スコープ、一致するツール メッセージ ID。 3. 宛先受付時: ノード ID、開始時刻、試行 ID、コンテキスト コントラクトの結果。 4. 待機チェックポイント時: 所有者、理由、期限、および不透明な再開トークン ID。 5. タスク検証時: 検証者の名前、結果、鮮度、および非機密のレシート ID。 プライベート ステート チャネルがプライベート テレメトリであると想定しないでください。のLangGraph グラフ API ドキュメント値をストリーミングするときにプライベート チャネルが自動的に編集されないことを警告します。ストリームされたキーを明示的に制限するか、最小化されたヘルス イベントを別個に発行します。安全なハンドオフ受信では、プロンプト、メッセージ本文、ツール引数、ツール結果、シークレット、および絶対ローカル パスを除外する必要があります。 ルートとコンテキストのコントラクトをバージョン管理します。バージョンがないと、古い送信者は、新しい宛先が理解できなくなったフィールドを転送しているときに、正常に見える可能性があります。 2 回目の転送が 2 回目の外部アクションにならないように、再試行全体で 1 つの安定した操作 ID を維持します。 最後に、タスクに一致する結果検証ツールを選択します。サポートの引き継ぎには、チケット状態の変更が必要になる場合があります。購入の引き継ぎには、宛先システムからの注文 ID が必要になる場合があります。コーディングの引き継ぎには、テストと予想されるアーティファクトが必要になる場合があります。 LLM の最終メッセージはその受信ではありません。 Sidewisp は現在プライベートプレビュー段階です。 ライブ早期アクセス サイトと記事システムは利用できますが、運用エージェントの正常性収集、LangChain アダプター、および自動リカバリは現在の Web サイト リポジトリには同梱されていません。上のレシートは、今日から実装できる演算子パターンです。これらの境界線に対する冷静な健康状態のビューがチームに役立つのであれば、プライベート プレビューの待機リストが適切な次のステップとなります。