LLM ベースのマルチエージェント シナジーによる統合デバッグ アプローチ: 修復の検証

LLM ベースのマルチ エージェントの相乗効果による統合デバッグ アプローチは、エージェントが自身の会話を生き残る証拠を残す場合にのみ役立ちます。元の障害が再現されなかったり、決定的な境界ケースがテストされなかったりしても、ローカライザーは確かな音を出し、修復者はパッチを発行し、レビュー担当者はそれを承認することができます。したがって、合理的なデフォルトは、専門のエージェントに修復を提案して申し立てさせるが、リンクされたレシートによって複製、系統、テスト範囲、オラクルの品質、およびレビューが証明された場合にのみパッチを推奨するというものです。 この運用ルールは、研究結果と製造保証を混同することなく、FixAgent 論文 のアーキテクチャに従っています。この文書では、専門エージェント全体での障害の特定、パッチの生成、およびエラー後の分析が分離されています。また、利用可能なテストに合格する「もっともらしい」パッチと、手動検証によって確立された「正しい」パッチとを区別します。その区別が健康の境界です。 FixAgent の結果で何が証明されるのか、そして何が証明されないのか FixAgent が公開した設計は、「複数のモデルにデバッグを依頼する」よりも具体的です。その 方法論 では、ローカライザー、修復者、再訪問者に加えて、追加のテスト用の入力作成エージェントが使用されます。エージェントは推論を説明し、重要な変数を追跡し、前段階の結果を下流に渡します。生成されたパッチが失敗した場合は、テスト フィードバックを使用して修復段階を再度サンプリングできます。 この論文では、QuixBugs、Codeflaws、および ConDefects に関する良好な結果が報告されています。これらは、論文のデータセット、モデル、プロンプト、検証手順に基づいた研究結果です。これらは、任意のリポジトリ パッチを安全にマージできるかどうかを確立するものではありません。一次情報源からの 2 つの詳細により、運用上の決定が変わります。 1. この論文では、妥当なパッチとは人間が書いたテストに合格するパッチであると定義していますが、正確さには別途手動による検証が必要です。 2. その 制限セクション には、追加のテスト入力エージェントが単独で期待される出力を計算できないと記載されています。信頼できるオラクルなしで生成された入力は完全なテストではありません。 リリースされた Rudra 実装 により、境界が検査可能になります。そのマルチラウンド ランナーは、観察された失敗ケースがゼロであると修復が成功したものとして扱い、そのフラグをランチャーに返します。これは実験のテスト ループに適しています。オペレーターは、どのスイートが実行されたか、そのオラクルが信頼できるかどうか、結果がこのパッチに属するかどうか、レビュー担当者が実際の差分を受け入れたかどうかを尋ねる必要があります。 この教訓は、エージェントによるレビューが役に立たないということではありません。専門家の意見が一致しないと、ローカリゼーションが悪いか、パッチが弱いことが露呈する可能性があります。教訓は、あるエージェントのテキストだけが次のエージェントによって消費される唯一の証拠ではないということです。 すべてのデバッグ段階を修理レシートにリンクする 最小限の修理レシートには内容が含まれていない場合があります。プロンプト、ソース コード、テスト出力、モデル推論は必要ありません。人間または決定論的なゲートが境界を再構築できるようにするには、安定したアイデンティティと判定が必要です。 境界 最小領収書フィールド 失敗をキャッチ --- --- --- 複製 実行 ID、コマンド ハッシュ、観察された元のエラー 再現されなかったバグのパッチ ローカリゼーション 実行 ID、ソース リビジョン、証拠のタイムスタンプ 別のリビジョンから再利用されたローカライザーの結果 パッチ パッチのハッシュ、親リビジョン、変更された行数 空の、古い、または無関係な修復 検証 必要なスイート ID、監視されたスイート ID、失敗した数 必要なスイートが実行されなかった場合に「すべてのテストに合格」 オラクル 検証済み、不明、または論争中 信頼できる期待される結果が得られないケースが生成されました。 レビュー 承認、拒否、または所有待ち モデル契約をマージ権限と間違えた 結果 完了請求と宛先受領書 パッチが検証または配信されていない、完了した実行 実行 ID は特に重要です。 run-old からのローカリゼーションの回答は、 run-42 からのパッチを黙って正当化するものであってはなりません。パッチ ハッシュも同様に重要です。1 つの差分に対する緑色のテスト レコードを、後のリサンプルに添付することはできません。これは通常の系統ですが、会話のコンテキストによって近くのメッセージが関連しているように見えるため、エージェントのワークフローでは系統が失われることがよくあります。 付属の治具で使用される形状は次のとおりです。 文字列は識別子であり、格納されたコンテンツではありません。実際のシステムでは、正規の入力とアーティファクトに対してハッシュを計算する必要があり、テスト記録にはツールのバージョン、構成リビジョン、開始時刻、終了時刻、終了の出所を含める必要があります。シークレット、プロンプト、ファイルの内容、および生のツール引数は、ヘルス レシートの外に置く必要があります。 緑を信頼する前に、9 つの不都合な状態をリプレイしてください 記事アーティファクトには、9 つ​​の合成ケースと優先順位付き Node.js 分類子が含まれています。記事レポート ディレクトリから実行します。 観察された結果は次のとおりです。 意図的に不便なケースがあります: - UNREPRODUCED は、不足しているベースラインを確実なパッチで隠す前にワークフローを停止します。 - LOCALIZATION DRIFT は、別の実行からのローカライザー受信をキャッチします。 - NO EFFECTIVE PATCH は、欠落しているハッシュまたはゼロ行の変更を拒否します。 - TEST GAP は、監視されたスイートが緑色であっても、実行されなかった必要な統合スイートを報告します。 - ORACLE UNCERTAIN は、生成された入力に検証済みの期待される出力がない場合に不確実性を保持します。 - REVIEW REJECTED は、技術的にグリーン パッチが承認されるのを防ぎます。 - WAITING は、領収書に所有者と期限が記載されている場合にのみ、正当な依存関係を表します。 - FALSE COMPLETE は、観察されたテストがまだ失敗している場合、完了要求よりも上位にランクされます。 - VERIFIED REPAIR では、以前のすべての境界が一致する必要があります。 順序が重要です。完了の要求は、失敗したテストを無効にすることはできません。ゼロ障害カウンターは、欠落しているスイートを上書きできません。生成された境界ケースは、オラクルがなければ正当性を確立できません。レビュー待機は、所有者と期限がある場合、ストールとして分類されるべきではありません。 この実験は、単一のヘルス スコアが不十分なデバッグ アーティファクトである理由も示しています。 suite-gap と verified-repair の両方のケースでは、失敗したテストはゼロであると報告されていますが、必要な統合スイートを実行したことがないため、動作状態が異なります。欠けている証拠は緑のカウンターよりも重要です。 実際のコーディング エージェント ワークフローにゲートを追加する エージェント フレームワークを再構築するのではなく、小さなプロモーション境界から始めます。 1. 入力リビジョンをフリーズします。 ローカリゼーションの前に、リポジトリのコミットまたはワークスペースのスナップショットを記録します。 2. 失敗を再現します。 コマンド/構成ハッシュと構造化された結果を保存します。再現性が不安定な場合は、不確実であるとラベルを付け、最終的なグリーンランを修復の証拠として扱わないでください。 3. 各ハンドオフをリンクします。 ローカライザー、修復者、およびレビュー担当者のレシートが同じ実行および親リビジョンを参照することを要求します。 4. バインドされたリサンプリング FixAgent 論文のフィードバック ループは便利ですが、再試行すると予算が消費され、パッチが変更される可能性があります。すべての新しいパッチに独自のハッシュを与え、試行を制限し、差分が変更されたときに以前のテスト証拠を無効にします。 5. 実行前に必要なスイートを宣言します。 それ以外の場合、エージェントは結果を確認した後で「すべてのテスト」を再定義できます。 6. Oracle 権限からテストの実行を分離します。 生成された入力によりカバレッジが向上しますが、人、仕様、参照実装、または独立した決定論的ルールが期待される結果を提供する必要があります。 7. マージまたはデプロイメントの権限は人間が管理するようにしてください。 承認された受領書によって決定を準備できます。エージェントの許可を拡大するものであってはなりません。 8. 宛先を確認します。 タスクがプル リクエストを開く、問題を更新する、またはリリース アーティファクトを生成するものである場合は、その宛先を個別に確認します。ローカル パッチはアクティビティであり、必ずしも要求された結果になるわけではありません。 承認一時停止の場合は、明示的なレコードを使用します。 そのレコードが最新である間、エージェントが沈黙しているという理由だけでページングを行わないでください。期限が切れた場合、所有者が行方不明である場合、または再開された実行で新しい証拠が得られない場合は、エスカレーションします。待っているだけでは行き詰りません。結果デルタのない反復アクティビティは進歩とは言えません。 Sidewisp の境界 支持できる理論は狭いです。マルチエージェントのデバッグは、専門家の出力が決定論的な修復証拠に結合されている場合に運用上信頼できるものになりますが、リネ​​ージ、カバレッジ、オラクルの品質、レビュー、または結果の証拠が欠落している場合には緑は保留されます。 9 つのケースのフィクスチャは、2 つの故障ゼロのケースが異なる評決に達するため、「観察された故障がゼロであることは修理が確認されたことを意味する」という近道を偽っています。 これは動作パターンであり、Sidewisp が現在 FixAgent を実行している、またはコーディング エージェントの修復を監視しているという主張ではありません。 Sidewisp は現在プライベートプレビュー段階です。 これは AI エージェントの健全性プラットフォームですが、運用監視エンジン、ランタイム アダプター、および回復エグゼキューターは通常出荷されません。意図されたヘルス層は、マージ権限を人間に残しておきながら、有益な進行状況、正当な待機、誤った完了、および不確実な証拠を区別するため、ここで関連します。 繰り返されるデバッグ ワークフローでは、最初にレシートを使用します。記録を読まないと、紛失したスイートと検証済みの修理を区別できない場合、証拠契約は依然として不十分です。