2026-07-31T06:15:06.207Z

マルチエージェントの可観測性: 調整トポロジの監査

観察されたエージェント間のルートをバージョン管理されたトポロジ コントラクトと比較して、ドリフト、安全でないエッジ、曖昧な所有権、誤った完了を検出します。

マルチエージェントの可観測性は、「記録されたすべてのスパンが終了したか?」よりも厳密な質問に答える必要があります。実際に参加したエージェントと、彼らが実際に使用したルートが、この実行で承認された調整設計と一致するかどうかがわかります。 実際のデフォルトは、 バージョン管理されたトポロジ契約 : 許可されたエージェント、許可された有向エッジ、および現在の実行フェーズで予期されるエッジの小さなマニフェスト。そのマニフェストをコンテンツのないインタラクション レシートに結合します。成功したトレースは、デフォルトで緑色になるのではなく、動作中、待機中、不完全、安全でない、あいまい、または誤完了として分類できます。 トレースには何が起こったかが記録されるため、これは重要です。発生したことのない必須の委任のスパンを含めることはできません。また、目的のグラフが提供されない限り、観察された直接ルートが禁止されていたかどうかを判断することもできません。同じ区別が現在のアーキテクチャ ガイダンスにも現れています: Microsoft マルチエージェントリファレンスアーキテクチャ エージェント間のメッセージ フローと調整パターンを特別な可観測性シグナルとして呼び出します。 Azure Architecture Center マルチエージェント オーケストレーションにより調整オーバーヘッドが追加され、新しい障害モードが追加されることを警告します。タスクを確実に満たす最も複雑性の低いものを使用します。複数のエージェントが正当化される場合、それらのトポロジをテスト可能にします。 トレースは意図したトポロジを証明できません OpenTelemetry のトレース API トレースとスパンの ID、親子関係、リンク、イベント、タイムスタンプ、属性、ステータスなどの適切な相関プリミティブを提供します。これらのプリミティブは、観察されたコール ツリーまたは非同期関係を記述することができます。どのエージェントが許可されたのか、どのルート バージョンがアクティブであったのか、どのエッジが表示されるべきだったのに表示されなかったのかは宣言されません。 オーケストレーターが調査を委任し、研究者が証拠を検証者に渡し、検証者が評決を返すとします。観察されたすべてのイベントには次のような特徴があります。 status: "ok" 少なくとも 5 つの悪い状況では、 実行では昨日のルーティング ポリシーが使用されました。 研究者は審査を通さずに出版社に直接電話した。 未登録のエージェントがグラフに侵入しました。 オーケストレーターは同じ所有ルートを 2 回委任しました。 検証者が戻る前に、親が完了を宣言しました。 「すべてのイベント OK」クエリでは、これらのレコードにエラーは表示されません。トポロジ監査では、代わりに 2 つのセットを比較します。 このレイヤーにはコンテンツを含まないままにしておきます。受信には、安定した実行 ID、エージェント ID、ルートの種類、トポロジ バージョン、イベント ID、観測時間、およびローカル ステータスが必要です。プロンプト、応答、シークレット、ツール引数、または絶対ファイル パスは必要ありません。 この契約は、ファンアウト完了クォーラムから意図的に分離されています。クォーラムは、必要なブランチが返されたかどうかを尋ねます。待機グラフは、どの依存関係が進行を妨げているかを尋ねます。永続的なハンドオフの受信では、責任がキューまたは再起動境界を超えたかどうかが尋ねられます。トポロジー適合性では、事前に次の質問が行われます。 これは私たちが実行しようとしていた調整グラフでしょうか? バージョン管理された調整契約を構築する 明示的なアイデンティティと有向エッジから始めます。最新のトレースに現れたものから許可されたグラフを推測しないでください。それは単に事後の漂流を祝福するだけです。 許可されたセットが予期されたセットと同じではありません。リサーチのみのフェーズでは、2 つの代表者が予想され、パブリッシャーの優位性は期待されない可能性があります。完全な出版フェーズでは、調査の引き継ぎ、検証者の返却、発行者の委任、発行者の返却が期待される場合があります。実行の開始時に、そのフェーズ固有のセットを固定します。そうしないと、オプションのエッジが障害の途中でひそかに必須になったり、必要なエッジがいつの間にか定義から消えてしまったりする可能性があります。 コンパクト分類子は次の優先順位を使用できます。 1. 古い契約 — イベントのバージョンは固定されたバージョンとは異なります。 2. 不明なエージェント — いずれかのエンドポイントが承認された ID セットの外にあります。 3. 禁断の縁 — 指示されたルートとインタラクションの種類は許可されません。 4. 曖昧なルート — 同じ所有エッジが、明示的な多重性ルールなしで複数回出現します。 5. 偽完了 — 最終的な親には、期待されるエッジまたは検証された結果の受け取りがありません。 6. 待っている — 予期されたエッジが存在せず、名前付き依存関係が明示的で、期限が過ぎていない。 7. 不完全 — 期待されたエッジが期限を過ぎてもまだ存在しない。 8. 健康または働いている — 観察されたセットは現在の計画と一致しますが、「健全」は検証された最終結果のために予約されています。 注文は重要です。シャドウ エージェントが禁止されたルートを使用し、親も遅れている場合、「不完全」では弱すぎます。オペレータはまず未承認のトポロジを含める必要があります。逆に、期限前に宣言された待機はストールではありません。これは健全な依存関係の状態であり、破壊的なリセットを引き起こすことなく正しい所有者に到達する必要があります。 動的ルーティングが主な制限です。システムは、実行時に専門エージェントの中から正当に選択することができます。その選択を境界付きエッジ クラスとして表すか、ディスパッチ前に正確な実行計画を生成します。次のようなワイルドカード orchestrator 保守は簡単ですが、診断値のほとんどが失われます。バージョンの変更は監査可能である必要があり、実行中に途中で黙って新しいバージョンが採用されるべきではありません。 サンプリングももう 1 つの境界です。大量のトレースはサンプリングされる可能性がありますが、健全性の決定に使用されるコンパクトなトポロジの受信は、同じポリシーの下では消えることはできません。必要な領収書が入手できない場合は、報告してください uncertain または incomplete ;部分的なトレースから緑色を再構築しないでください。 完了を信頼する前にドリフトを再生してください 私は上記の契約に反する内容のない 9 件の訴訟を再審理しました。フィクスチャには、正常な完了、現在の作業、正当な待機、期限後のエッジの欠落、古いトポロジ、禁止された直接ルート、不明なエージェント、重複したルート所有権、およびリターン レシートのない端末親が含まれていました。 決定論的監査では、予想される 9 つの状態すべてが一致しました。単純なルール 少なくとも 1 つのイベントが存在し、すべてのローカル イベントのステータスが ok 、親は失敗していない マーク付き 9ケースすべてグリーン 。健康だったのは1人だけでした。これら 9 つのナイーブ グリーンのうち 6 つは、安全ではない、不完全、古い、曖昧、または偽完全でした。残りの2人は働いて待っている状態であり、完全な健康状態に崩壊すべきではありません。 場合 記録されたイベントはすべてOKですか? トポロジーの判定 演算子の意味 : 完全なグラフと結果のレシート はい healthy 計画したグラフと最終結果を確認します 現在計画されているエッジ はい working 有用な作業は継続する可能性があります。介入しないでください 期限内に返却しなかった場合 はい waiting 指定された依存関係を通知または監視します 期限を過ぎても同じ返品が見つからない はい incomplete 最初に存在しない予期されるエッジを調査します 古いトポロジ バージョン はい stale contract 実行結果を間違ったデザインと比較するのはやめてください 未承認の直接ルート はい forbidden edge 作業を再試行する前にルートを封じ込める 不明な参加者 はい unknown agent 身元と権限を確認する 所有ルートが重複しています はい ambiguous route 所有権と重複する可能性のある効果を調整する 親端末、不在を返します はい false complete 実行を再開します。完成には必要な証拠が欠けている 正規化されたエッジ キーに対する小さな関数を使用して決定を再現できます。 進行状況、品質、結果のスコアリングを行う前に、トポロジ チェックを実行します。次に、判定の境界を明示的に保ちます。 トポロジー適合性は、承認された調整形状が観察されたことのみを証明します。 working 単にイベントが増えるだけでなく、有用な動きの新たな証拠が必要です。 waiting 名前付きの依存関係と期限が必要です。 healthy 完了には、確定的な宛先または成果物の受領書が利用可能な場合は必要です。 不確実な証拠は不確実なままでなければなりません。 アクティブなリカバリには、制限された権限、可視性、およびアクション後の検証が必要です。 これにより、オペレータには次のような狭い採用ルールが与えられます。 実行の固定トポロジ、現在のフェーズ、および最終結果の受信が一致するまで、マルチエージェントの完了を信頼しないでください。 一致するグラフは必要な証拠であり、答えが正しいという証拠ではありません。 Sidewisp は現在プライベートプレビュー段階です。 公開早期アクセス サイトと対話型デモンストレーションは公開されていますが、実稼働マルチエージェント モニタリング アダプター、ライブ ヘルス コレクター、および自動リカバリ エグゼキューターは同梱されていません。 Sidewisp の意図された役割は、既存のランタイムの周囲に健全性レイヤーを追加し、証拠、重大度、不確実性、最も安全な次のアクションを検査しやすくすることであり、ランタイムを置き換えたり、人間の権限なしに動作したりすることではありません。