マルチエージェント AI システムのインタラクティブなデバッグとステアリング: リセットごとにゲート

マルチエージェント AI システムのインタラクティブなデバッグとステアリングは、トランスクリプト編集として扱うべきではありません。安全なリセットにより、独自の系統、復元された状態の証拠、権限レコード、および結果の受信を備えた新しいブランチが作成されます。ブラウザ、ワークスペース、キュー、認証情報、または外部宛先が復元または調整できない場合、正しい状態は不確実であり、「準備完了」ではありません。 それが実際に得られる教訓ですマルチエージェント AI システムの対話型デバッグとステアリング、Microsoft のオープンソースの背後にある CHI 2025 論文AGDebugger。この研究により、巻き戻しと編集をマルチエージェントのデバッグに使用できるようになりました。運用デプロイメントには、もう 1 つの境界線が必要です。リセットでは、仮説をテストするのに十分近い内部状態を再作成できますが、電子メールを自動的に元に戻したり、チケットを元に戻したり、ページを非公開にしたり、新しいブランチがユーザーのタスクを完了したことを証明したりすることはできません。 適切なデフォルトは、6 つのゲートを持つステアリング レシートです。 1. 親とブランチは異なるアイデンティティを持っています。 2. チェックポイントは、必要なすべてのエージェントとツール状態キーをカバーします。 3. チェックポイントが元に戻されるか調整された後の影響。 4. オペレータは介入を行う権限を持っています。 5. エージェント構成は新しいブランチに固定されます。 6. 再開されたブランチは新しい結果の受領書を受け取ります。 最初の 5 つだけがブランチを 再開準備完了 とします。 6 番目は 検証済み になります。 リセットは分岐であり、巻き戻しではありません AGDebugger の論文は具体的な問題から始まります。 5 人のエージェント開発者は、長い会話でエラーを特定するのが難しいこと、インタラクティブなデバッグ制御が欠如していること、エージェント構成の反復が遅いことを説明しました。著者らは、開発者がメッセージを段階的に確認し、以前の時点にリセットし、前のメッセージを編集し、結果として生じる会話分岐を比較できるシステムを構築しました。次に、14 人の参加者を対象とした 2 部構成の研究で、診断とステアリング戦略を検討しました。 これは、ログの検索よりも強力な対話です。開発者は、障害境界で 2 つの反証可能な質問をすることができます。それは、同じ状態が再度実行された場合はどうなるのか、もう 1 つは特定のメッセージが変更された場合はどうなるのかということです。この論文では、研究の中で、詳細の追加、タスクの簡素化、計画の変更という 3 つの一般的なステアリング形式について報告しています。 ただし、実装の詳細は編集アフォーダンスよりも重要です。 AGDebugger は、メッセージが処理される前にエージェントの状態をチェックポイントします。リセット時に、対応するチェックポイントが復元され、新しいセッションが作成されます。フォーク前のメッセージとチェックポイントは共有されたままになります。新しいメッセージとチェックポイントはブランチに属します。たとえインターフェイスが巻き戻っているように見えても、それがリネージです。 操作を分岐として扱うと、演算子に 3 つの有用な不変式が与えられます。 元の失敗した実行は引き続き検査可能です。 正確なフォークポイントは不変です。 編集とその後のすべてのエフェクトは新しいセッションに属します。 これらの不変条件がなければ、編集された記録により、インシデントの診断に使用された証拠が書き換えられる可能性があります。その結果の「成功した実行」は、どの履歴、プロンプト、ツール スキーマ、またはモデル構成によって生成されたのか誰も分からないため、再現することが不可能な場合があります。 ブランチ レコードにはメッセージの内容は必要ありません。 ハッシュ識別子と粗編集クラスは証拠の証跡としては十分です。フォークが存在することを証明するためだけに、プロンプト、ツール引数、シークレット、またはユーザー データをエクスポートしないでください。 プランを変更する前に州のカバレッジを復元する トランスクリプトからメッセージを削除しても、状態は復元されません。この論文では、AGDebugger エージェントが状態の保存および読み込みメソッドを実装していると述べています。 Web エージェントの状態には、URL とビューポートの位置を含めることができます。他のエージェントは異なる状態を必要とする場合があります。また、ブラウザの JavaScript とリモート アプリケーションの状態を完全に復元することは非現実的または不可能な可能性があるため、チェックポイント ポリシーは「十分に優れている」と説明されています。 この制限は、事後検証ではなく、リセット ボタンの横に置く必要があります。 実行を開始する前に、ワークフローに必要な状態キーを定義します。小規模な研究および出版チームの場合、次のようになります。 承認キューが欠落しているため、このチェックポイントは不完全です。トランスクリプトを再生すると、支店が再度質問したり、既存の決定をスキップしたり、権限が引き継がれたかのように動作したりする可能性があります。オペレーターが見る必要があるのは、 restore uncertain 、緑色の再開コントロールではありません。 保障は必要ですが十分ではありません。すべての状態キーについて、リビジョンまたはコンテンツのないフィンガープリントと復元結果を記録します。 状態キー リセット前の証拠 必要な復元テスト エージェントの記憶 リビジョンとチェックポイントのハッシュ ロードされたリビジョンはフォークと一致します ブラウザ 起点、ルート ハッシュ、ローカル セッション クラス 予期されたルートが到達可能であり、セッション クラスが有効です ワークスペース リポジトリのコミットとダーティステート ダイジェスト 正確なリビジョンと意図的なローカル変更 ツールレジストリ スキーマハッシュと機能数 現在のレジストリが一致するか、ドリフトが認識される 承認キュー 決定受領書 ID とステータス 保留中の決定と解決された決定は保存されます 稼働中のリモート システムがチェックポイント以降に移動した可能性があります。それは必ずしも失敗ではありません。それが証拠にラベルを付ける理由になります。ブラウザが記録されたページに戻ることはできるが、ページの基礎となるレコードが変更されている場合、スナップショットの忠実度は部分的です。オペレーターは引き続き診断ブランチを実行できますが、それを正確なリプレイとして提示してはなりません。 構成は状態の一部です。ブランチで使用されるエージェントの役割、モデル識別子、ツール セット、システム プロンプト、およびルーティング ルールを固定します。それ以外の場合、編集が成功したということは、未知の組み合わせが機能したことを証明するだけです。元の構成を不変に保ち、意図的な差分を記録します。 ツール呼び出しを再生する前に効果を調整する チェックポイントは、デバッガの制御下で状態を復元します。外の世界を逆転させるものではありません。 親ブランチがチェックポイント後にチケットを作成したが、約束された公開レポートの作成に失敗したとします。ツール呼び出しの前にリセットして再実行すると、2 番目のチケットが作成される可能性があります。応答がないことは、最初の呼び出しに効果がなかったという証拠にはなりません。再開する前に、外部効果のあるすべてのチェックポイント後の操作を列挙し、分類します。 reverted : 元の効果は安全に取り消されました。 reconciled : 効果は残り、新しいブランチはそれを再利用またはスキップします。 pending : 目的地の証拠がありません。 irreversible : 効果は元に戻すことができないため、人間による新たな決定が必要です。 何でも pending または irreversible その境界で自動再生をブロックします。 接続先がサポートしている安定した操作キーを使用してください。公開操作の場合は、別のドラフト ID を作成する前に、不変のドラフト ID で宛先を照会します。電子メールの場合は、メッセージ本文なしでプロバイダーのメッセージ ID を保持します。リポジトリの変更については、予想されるコミットまたはツリー ハッシュを比較します。チケットの場合は、リクエストの冪等性キーによってチケットを取得します。 オペレーターの介入にも権限境界が必要です。ブランチがローカル フィクスチャに限定されている場合、プランの編集はリスクが低くなります。編集によって受信者、予算、権限、制作ターゲット、または破壊的なアクションが変更される場合、それは大きく異なります。これらの編集を承認された所有者にルーティングし、ブランチを保持します。 needs approval 決定通知書が届くまで。 その決定を待っているだけでは行き詰りません。権限や宛先の状態が不明な状態でリジュームを繰り返すと失敗します。 不都合なケースに対してステアリングレシートを実行する 付随するアーティファクトは、コンテンツフリーのフィクスチャおよび決定論的分類子です。 AGDebugger を実行したり、ユーザー調査を再現すると主張したりするものではありません。リセットに関する動作上の決定をテストします。 ローカルで実行します。 フィクスチャには 8 つの分岐が含まれています。分類子は以下を生成しました。 テストでは 9 番目のアサーションが追加されます。ID が親と等しいブランチは、次のように拒否されます。 invalid lineage . 優先順位は意図的なものです。状態ブロックが欠落していると、演算子が分岐の開始点を確立できないため、解釈に影響します。未調整の効果は、承認が検討される前に再開をブロックします。承認と固定設定はブランチの準備を整えますが、健全な状態にするわけではありません。再開後も、期待される成果物には決定的な検証者が必要です。 1 つのフィールドを変更すると、結果は予想どおりに変化するはずです。不足している承認キュー キーを部分復元に追加すると、復元を進めることができます。保留中のチケット効果が調整されたとマークすると、支店は権限ゲートに到達できるようになります。セット outcomeVerified 流暢な最終回答後に false になり、結果が残る false success . これにより、操作上の重要な違いが生じます。 「再開準備完了」とは、介入境界が制御されていることを意味します。 「検証済み」とは、新しいブランチが意図した作業を完了したことを意味します。 これらの州を 1 つの緑色のバッジに統合しないでください。 実験で証明されないこと アーティファクトは、スナップショットの忠実度ではなく、決定ルールを検証します。ブラウザが正確に復元されたこと、LLM が同じパスをたどること、または文書化されていない副作用がまったく発生しなかったことを証明することはできません。実際の統合には、ランタイム固有の状態アダプターと宛先クエリが必要です。 AGDebugger の調査には、5 人の形成的インタビュー対象者、14 人の調査参加者、2 つの調査タスク、および AutoGen で構築された調査プロトタイプという限定された範囲もあります。その発見は相互作用パターンを正当化します。すべてのマルチエージェント アーキテクチャでインシデント率の削減が確立されるわけではありません。この論文自体は、ステアリングをエージェント実装から切り離すことや、編集が影響したかどうかを判断することなど、未解決の課題を特定しています。 これらの制限により、運用ルールが強化されます。対話型リセットは、確実性を生み出すためではなく、仮説を分離するために使用します。親を保存し、明示的にフォークし、証明できるものを復元し、証明できないものにラベルを付け、外部効果を調整し、権限を要求し、宛先で新しい結果を検証します。 Sidewisp は現在プライベートプレビュー段階です。実稼働監視アダプターとリカバリーエグゼキューターは通常、出荷されません。ここでの手法は検査可能な運用パターンであり、Sidewisp がすでにチェックポイントを作成したり、ライブ エージェント チームを操作したりしているという主張ではありません。 Sidewisp の製品の方向性は、人間の権限、証拠、結果の検証を安全な回復の中心に据えています。 現在マルチエージェント システムを運用している場合は、障害が発生しやすい 1 つのワークフローから始めてください。次のインシデントの前に、その状態キーと外部影響台帳を定義します。最初の有用なチェックポイントは、最も多くの履歴を再生できるチェックポイントではありません。これは、何が復元されたか、何が変更されたままになったか、誰がブランチを承認したか、そして最終結果がどのように検証されたかを正確に説明できるものです。