論文の概要: Phoenix: Safe GitHub Issue Resolution via Multi-Agent LLMs
- arxiv url: http://arxiv.org/abs/2606.20243v2
- Date: Mon, 22 Jun 2026 11:00:39 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-06-24 22:16:48.242357
- Title: Phoenix: Safe GitHub Issue Resolution via Multi-Agent LLMs
- Title（参考訳）: Phoenix: マルチエージェントLLMによるGitHubの安全な課題解決
- Authors: Kipngeno Koech, Muhammad Adam, Baimam Boukar Jean Jacques, Joao Barros,
- Abstract要約: PhoenixはGitHubの問題をトリアージからプルリクエスト生成を通じて解決するマルチエージェントLLMシステムである。
フェニックスは6つの専門エージェントで仕事を分解する。
14リポジトリにわたる42の実際の問題に関する補完的なパイロットは、100%の正確性を保存する。
- 参考スコア（独自算出の注目度）: 0.0
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: We present Phoenix, a multi-agent LLM system that resolves GitHub issues from triage through pull-request creation, combining seven layered safety controls with a baseline-aware test evaluation strategy. Phoenix decomposes the work across six specialized agents. Planner, reproducer, coder, tester, failure analyst and Pull Request (PR) agent, all coordinated by a label-based GitHub webhook state machine. Every change is checked against a baseline test run before a pull request is opened. On a 24-instance slice of SWE-bench Lite. run on the production webhook path, Phoenix oracle-resolves 75% of instances with no pass-to-pass regressions on successful runs; this curated slice is not directly comparable to full-split leaderboard results, and we discuss the limits of the comparison. A complementary pilot on 42 real issues across 14 repositories yields 100% correctness preservation (CP; mean 122s on the hard tier). Manual inspection shows that about half of the resulting pull requests are well-targeted fixes. The other half place code at incorrect paths, a planner localization limitation we are addressing with retrieval. We also report the deployment failure modes (WAF filtering, token expiry, permission boundaries, flaky CI) that motivated each safety mechanism.
- Abstract（参考訳）: PhoenixはGitHubの問題をトリアージからプルリクエスト生成を通じて解決するマルチエージェントLLMシステムで、7つの階層化されたセーフティコントロールとベースライン対応のテスト評価戦略を組み合わせたものだ。
フェニックスは6つの専門エージェントで仕事を分解する。
Planner、reducer、coder、tester、失敗アナリスト、Pull Request(PR)エージェントは、すべてラベルベースのGitHub webhookステートマシンによって調整される。
すべての変更は、プルリクエストが開く前に、ベースラインテスト実行に対してチェックされる。
24-instance slice of SWE-bench Lite について
Phoenix oracle-resolvs 75%のインスタンスを運用中のwebhookパスで実行し、実行時にパス・ツー・パスのレグレッションがない。
42の実際の問題を14のリポジトリで補完するパイロットは、100%の正当性保存(CP、すなわちハード層の122s)が得られる。
手作業による検査では、結果のプルリクエストの約半数が、十分に目標とする修正であることが示された。
残りの半分のコードは間違った経路にあるが、これは検索で対処しているプランナーのローカライゼーションの制限である。
また、各安全メカニズムを動機付けるデプロイメント障害モード(WAFフィルタリング、トークン有効期限、パーミッションバウンダリ、フレキCI)についても報告します。
関連論文リスト
- StaminaBench: Stress-Testing Coding Agents over 100 Interaction Turns [45.43677974796221]
コーディングエージェントのスタミナを測定するベンチマークであるStaminaBenchを紹介する。
一般的な分数タスクのメトリクスとは異なり、これはセッションが数十回、数百回実行される実際のバイブコーディングと一致します。
論文 参考訳（メタデータ） (2026-06-17T21:36:09Z) - Is Agentic AI Ready for Real-World Hardware Engineering? A Deep Dive with Phoenix-bench [33.69401287706814]
我々は、ソフトウェアエンジニアリングを現実的なハードウェアエンジニアリングに移行するために構築されたエージェントAIシステムについて尋ねる。
textbfPhoenix-benchは、114のGitHubリポジトリから511の検証済みのVerilatorインスタンスの同期コーパスです。
Phoenix-benchを用いて、4つの商用エージェントと8つのオープンソースエージェント構造を均一に評価する。
論文 参考訳（メタデータ） (2026-05-13T14:14:54Z) - WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation [88.10947115397971]
この研究でWildClawBenchは、6つのテーマのカテゴリにまたがる60の人間によるバイリンガルなマルチモーダルタスクのネイティブランタイムベンチマークである。
各タスクは、約8分間のウォールクロック時間と20以上のツールコールで実行されます。
グラディングはハイブリッドであり、決定論的ルールベースのチェック、副作用の環境状態監査、意味的検証のためのLLM/VLM判定を組み合わせている。
論文 参考訳（メタデータ） (2026-05-11T17:49:43Z) - ClawMark: A Living-World Benchmark for Multi-Turn, Multi-Day, Multimodal Coworker Agents [77.22389710754452]
マルチターンマルチデイタスクを中心に構築された同僚エージェントのベンチマークであるベンチを紹介する。
現在のリリースには、13のプロのシナリオにわたる100のタスクが含まれており、5つのステートフルなサンドボックスサービスに対して実行される。
最強のモデルは75.8の重み付きスコアに達するが、最も厳格なタスク成功率は20.0%に過ぎず、部分的な進歩が一般的であることを示している。
論文 参考訳（メタデータ） (2026-04-26T16:05:02Z) - AgentForge: Execution-Grounded Multi-Agent LLM Framework for Autonomous Software Engineering [3.2126925586839623]
第一級原理として実行基盤検証を導入する。
我々はこの原理をマルチエージェントフレームワークである AgentFORGE でインスタンス化する。
AgentFORGEtokenはSWE-BENCH Lite上で40.0%の解像度を達成する。
論文 参考訳（メタデータ） (2026-04-13T13:51:13Z) - DRS-OSS: LLM-Driven Diff Risk Scoring Tool for PR Risk Prediction [3.17083738531489]
Diff Risk Scoring (DRS) は、差分が欠陥をもたらす可能性を推定し、レビューの優先順位付け、テスト計画、CI/CDゲーティングを改善する。
DRS-OSSは、パブリックAPI、Web UI、GitHubプラグインを備えたオープンソースのDSSシステムである。
論文 参考訳（メタデータ） (2025-11-26T22:52:18Z) - InfCode: Adversarial Iterative Refinement of Tests and Patches for Reliable Software Issue Resolution [31.874379525390967]
InfCodeは、リポジトリレベルの自動イシュー解決のための、対向的なマルチエージェントフレームワークである。
InfCodeは、テストパッチジェネレータとコードパッチジェネレータの間の逆インタラクションを通じて、テストとパッチの両方を反復的に洗練する。
DeepSeek-V3やClaude 4.5 Sonnetといったモデルを用いたSWE-bench LiteとSWE-benchの検証実験は、InfCodeが一貫して強力なベースラインを上回っていることを示している。
論文 参考訳（メタデータ） (2025-11-20T03:04:21Z) - Where LLM Agents Fail and How They can Learn From Failures [62.196870049524364]
大規模言語モデル(LLM)エージェントは、複雑なマルチステップタスクの解決において有望であることを示す。
単一ルート原因エラーがその後の決定を通じて伝播する、障害のカスケードに対する脆弱性を増幅する。
現在のシステムは、モジュール的で体系的な方法でエージェントエラーを包括的に理解できるフレームワークを欠いている。
AgentErrorTaxonomyは、メモリ、リフレクション、計画、アクション、システムレベルの操作にまたがる障害モードのモジュール分類である。
論文 参考訳（メタデータ） (2025-09-29T18:20:27Z) - SwingArena: Competitive Programming Arena for Long-context GitHub Issue Solving [90.32201622392137]
We present SwingArena, a competitive evaluation framework for Large Language Models (LLMs)。
従来の静的ベンチマークとは異なり、SwingArenaはLLMをイテレーションとして組み合わせて、テストケースを作成し、継続的インテグレーション(CI)パイプラインを通じてパッチを検証するパッチとレビュアーを生成することで、ソフトウェアのコラボレーションプロセスをモデル化する。
論文 参考訳（メタデータ） (2025-05-29T18:28:02Z) - MAGIS: LLM-Based Multi-Agent Framework for GitHub Issue Resolution [47.850418420195304]
大規模言語モデル(LLM)はコード生成において有望であるが、GitHubの問題を解決する上で困難に直面している。
ソフトウェア進化のためにカスタマイズされた4つのエージェントからなる、GitHub Issue Resolution, MAGISのための新しいMulti-Agentフレームワークを提案する。
論文 参考訳（メタデータ） (2024-03-26T17:57:57Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。