LLM 기반 다중 에이전트 시너지를 통한 통합 디버깅 접근 방식: 복구 확인

LLM 기반 다중 에이전트 시너지를 통한 통합 디버깅 접근 방식은 에이전트가 자신의 대화에서 살아남는 증거를 남길 때만 유용합니다. 로컬라이저는 확실하게 소리를 낼 수 있고, 수리자는 패치를 내보낼 수 있으며, 검토자는 원래의 실패가 재현되지 않았거나 결정적인 경계 사례가 테스트되지 않은 동안 이를 승인할 수 있습니다. 따라서 합리적인 기본값은 전문 상담원이 수리를 제안하고 이의를 제기하도록 하고 연결된 영수증이 재생산, 계보, 테스트 적용 범위, Oracle 품질 및 검토를 입증한 후에만 패치를 홍보하는 것입니다. 해당 운영 규칙은 연구 결과와 생산 보장을 혼동하지 않고 FixAgent 논문의 아키텍처를 따릅니다. 이 문서에서는 전문 에이전트 전반에 걸쳐 오류 위치 파악, 패치 생성 및 사후 오류 분석을 구분합니다. 또한 수동 검증을 통해 설정된 올바른 패치와 사용 가능한 테스트를 통과한 타당한 패치를 구별합니다. 그 구별이 바로 건강 경계입니다. FixAgent 결과가 증명하는 것과 증명하지 않는 것 FixAgent의 공개된 디자인은 "여러 모델에 디버깅을 요청하는 것"보다 더 구체적입니다. 방법론은 로컬라이저, 수리자, 재방문자를 사용하고 추가 테스트를 위해 입력 제작 에이전트를 사용합니다. 에이전트는 자신의 추론을 설명하고 중요한 변수를 추적하며 이전 단계 결과를 다운스트림으로 전달합니다. 생성된 패치가 실패하면 테스트 피드백을 통해 복구 단계를 다시 샘플링할 수 있습니다. 이 논문은 QuixBugs, Codeflaws 및 ConDefects에 대한 강력한 결과를 보고합니다. 이는 논문의 데이터 세트, 모델, 프롬프트 및 검증 절차에 따른 연구 결과입니다. 임의의 저장소 패치가 병합해도 안전한지 확인하지 않습니다. 기본 소스의 두 가지 세부 사항이 운영 결정을 변경합니다. 1. 이 논문에서는 그럴듯한 패치를 사람이 작성한 테스트를 통과한 패치로 정의하고, 정확성에는 별도의 수동 검증이 필요합니다. 2. 제한 사항에는 추가 테스트 입력 에이전트가 자체적으로 예상 출력을 계산할 수 없다고 명시되어 있습니다. 신뢰할 수 있는 오라클 없이 생성된 입력은 완전한 테스트가 아닙니다. 출시된 Rudra 구현은 경계를 검사 가능하게 만듭니다. 다중 라운드 실행기는 관찰된 실패 사례 0건을 성공적인 수리로 간주하고 해당 플래그를 실행 프로그램에 반환합니다. 이는 실험의 테스트 루프에 적합합니다. 운영자는 여전히 어떤 제품군이 실행되었는지, 오라클이 신뢰할 수 있는지, 결과가 이 패치에 속하는지, 리뷰어가 실제 차이점을 수락했는지 여부를 물어봐야 합니다. 상담원 검토가 쓸모없다는 것이 교훈이 아닙니다. 전문가의 의견 불일치로 인해 잘못된 현지화 또는 취약한 패치가 드러날 수 있습니다. 교훈은 한 에이전트의 텍스트가 다음 에이전트가 소비하는 유일한 증거가 되어서는 안 된다는 것입니다. 모든 디버깅 단계를 수리 영수증과 연결 최소 수리 영수증에는 내용이 없을 수 있습니다. 프롬프트, 소스 코드, 테스트 출력 또는 모델 추론이 필요하지 않습니다. 인간 또는 결정론적 게이트가 경계를 재구성할 수 있도록 하는 안정적인 ID와 판정이 필요합니다. 경계 최소 영수증 필드 실패가 잡는다 재생산 실행 ID, 명령 해시, 원래 오류가 관찰됨 재현되지 않은 버그에 대한 패치 현지화 실행 ID, 소스 개정, 증거 타임스탬프 다른 개정판에서 재사용된 지역화 결과 패치 패치 해시, 상위 개정, 변경된 줄 수 비어 있거나 오래되었거나 관련이 없는 수리 검증 필수 제품군 ID, 관찰된 제품군 ID, 실패한 개수 필수 제품군이 실행되지 않은 경우 "모든 테스트 통과" 오라클 확인되었거나 알 수 없거나 논쟁의 여지가 있음 신뢰할 수 있는 예상 결과가 없는 사례 생성 검토 승인, 거부 또는 소유 대기 병합 권한으로 오인된 모델 계약 성과 완료 청구 및 목적지 영수증 패치가 확인되지 않거나 전달되지 않은 완료된 실행 실행 ID가 특히 중요합니다. run old 의 현지화 답변은 run 42 의 패치를 자동으로 정당화해서는 안 됩니다. 패치 해시도 똑같이 중요합니다. 하나의 차이점에 대한 녹색 테스트 기록은 이후의 재샘플에 첨부할 수 없습니다. 이는 일반적인 계보이지만 대화 컨텍스트로 인해 주변 메시지가 관련되어 있는 것처럼 보이기 때문에 에이전트 워크플로에서 계보가 손실되는 경우가 많습니다. 함께 제공되는 고정 장치에서 사용되는 모양은 다음과 같습니다. 문자열은 저장된 콘텐츠가 아닌 식별자입니다. 실제 시스템에서 해시는 표준 입력 및 아티팩트에 대해 계산되어야 하며 테스트 기록에는 도구 버전, 구성 개정, 시작 시간, 종료 시간 및 종료 출처가 포함되어야 합니다. 비밀, 프롬프트, 파일 콘텐츠 및 원시 도구 인수는 상태 영수증 외부에 있어야 합니다. 녹색을 신뢰하기 전에 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가지 사례 고정 장치는 두 가지 오류 사례가 서로 다른 결과에 도달하기 때문에 "관찰된 오류가 0이면 확인된 수리를 의미합니다"라는 지름길을 위조합니다. 이는 Sidewisp가 현재 FixAgent를 실행하거나 코딩 에이전트 수리를 모니터링한다는 주장이 아니라 작동 패턴입니다. Sidewisp는 현재 비공개 프리뷰 단계입니다. AI 에이전트 헬스 플랫폼이지만 프로덕션 모니터링 엔진, 런타임 어댑터, 복구 실행기는 일반적으로 배송되지 않습니다. 의도된 건강 계층은 인간과의 병합 권한을 남기면서 유용한 진행, 합법적인 대기, 잘못된 완료 및 불확실한 증거를 구별하기 때문에 여기에서 관련이 있습니다. 반복되는 디버깅 작업 흐름에서 먼저 영수증을 사용하세요. 기록을 읽지 않고 확인된 수리에서 누락된 제품군을 알 수 없다면 증거 계약은 여전히 ​​너무 약한 것입니다.