에이전트 자기성찰 디버깅은(는) 무엇을 하나요?
에이전트 실행이 반복적으로 실패하고, 진전 없이 토큰을 소모하며, 동일한 도구를 반복 사용하거나, 의도한 작업에서 벗어날 때 이 스킬을 사용하세요.
이것은 워크플로 스킬이지 숨겨진 런타임이 아닙니다. 에이전트가 사람에게 에스컬레이션하기 전에 체계적으로 자체 디버깅하도록 가르칩니다.
활성화 시점
- 최대 도구 호출 / 루프 한도 초과 실패
- 진전 없는 반복 재시도
- 출력 품질을 저하시키는 컨텍스트 증가 또는 프롬프트 표류
- 기대와 현실 사이의 파일 시스템 또는 환경 상태 불일치
- 진단과 소규모 수정 조치로 복구 가능한 도구 실패
범위 경계
다음의 경우 이 스킬을 활성화하세요:
- 무조건 재시도하기 전에 실패 상태 캡처
- 일반적인 에이전트별 실패 패턴 진단
- 통제된 복구 조치 적용
- 구조화된 사람이 읽을 수 있는 디버그 보고서 생성
다음의 경우 이 스킬을 기본 소스로 사용하지 마세요:
- 코드 변경 후 기능 검증:
verification-loop사용 - 더 좁은 ECC 스킬이 이미 존재하는 프레임워크별 디버깅
- 현재 하네스가 자동으로 강제할 수 없는 런타임 약속
4단계 루프
1단계: 실패 캡처
복구를 시도하기 전에 실패를 정확히 기록하세요.
캡처할 항목:
- 가능한 경우 오류 유형, 메시지 및 스택 추적
- 마지막 의미 있는 도구 호출 시퀀스
- 에이전트가 수행하려고 했던 작업
- 현재 컨텍스트 압력: 반복된 프롬프트, 지나치게 큰 붙여넣은 로그, 중복된 계획, 또는 통제 불능의 노트
- 현재 환경 가정: cwd, 브랜치, 관련 서비스 상태, 예상 파일
최소 캡처 템플릿:
## 실패 캡처
- 세션 / 작업:
- 진행 중인 목표:
- 오류:
- 마지막 성공 단계:
- 마지막 실패 도구 / 명령:
- 관찰된 반복 패턴:
- 확인할 환경 가정:
2단계: 근본 원인 진단
무엇이든 변경하기 전에 실패를 알려진 패턴과 대조하세요.
| 패턴 | 가능한 원인 | 확인 방법 |
|---|---|---|
| 최대 도구 호출 / 동일한 명령 반복 | 루프 또는 종료되지 않는 관찰자 경로 | 마지막 N개 도구 호출에서 반복 검사 |
| 컨텍스트 오버플로 / 추론 능력 저하 | 무제한 노트, 반복된 계획, 과도한 로그 | 최근 컨텍스트에서 중복 및 저신호 대량 데이터 검사 |
ECONNREFUSED / 시간 초과 | 서비스를 사용할 수 없거나 잘못된 포트 | 서비스 상태, URL 및 포트 가정 확인 |
429 / 할당량 소진 | 재시도 폭주 또는 백오프 누락 | 반복 호출 횟수 및 재시도 간격 검사 |
| 쓰기 후 파일 누락 / 오래된 diff | 경합, 잘못된 cwd, 또는 브랜치 표류 | 경로, cwd, git 상태 및 실제 파일 존재 재확인 |
| "수정" 후에도 테스트 여전히 실패 | 잘못된 가설 | 정확히 실패하는 테스트를 격리하고 버그 재도출 |
진단 질문:
- 이것은 논리 실패, 상태 실패, 환경 실패, 또는 정책 실패인가?
- 에이전트가 실제 목표를 잃고 잘못된 하위 작업을 최적화하고 있는가?
- 실패가 결정론적인가 일시적인가?
- 진단을 검증할 수 있는 가장 작은 되돌릴 수 있는 조치는 무엇인가?
3단계: 통제된 복구
진단 표면을 변경하는 가장 작은 조치로 복구하세요.
안전한 복구 조치:
- 반복 재시도를 중단하고 가설을 재진술
- 저신호 컨텍스트를 정리하고 활성 목표, 차단 항목 및 증거만 유지
- 실제 파일 시스템 / 브랜치 / 프로세스 상태 재확인
- 작업을 하나의 실패 명령, 하나의 파일, 또는 하나의 테스트로 좁힘
- 추론적 사고에서 직접 관찰로 전환
- 위험이 높거나 외부적으로 차단된 경우 사람에게 에스컬레이션
실제 도구를 통해 현재 환경에서 실제로 수행하지 않는 한 "에이전트 상태 재설정" 또는 "하네스 구성 업데이트"와 같은 지원되지 않는 자동 복구 조치를 주장하지 마세요.
통제된 복구 체크리스트:
## 복구 조치
- 선택된 진단:
- 수행된 가장 작은 조치:
- 이것이 안전한 이유:
- 수정이 작동했음을 증명할 증거:
4단계: 성찰 보고서
복구 과정을 다음 에이전트나 사람이 이해할 수 있도록 보고서로 마무리하세요.
## 에이전트 자체 디버그 보고서
- 세션 / 작업:
- 실패:
- 근본 원인:
- 복구 조치:
- 결과: 성공 | 부분 성공 | 차단됨
- 토큰 / 시간 소모 위험:
- 필요한 후속 조치:
- 나중에 인코딩할 예방적 변경:
복구 휴리스틱
다음 개입을 순서대로 선호하세요:
- 실제 목표를 한 문장으로 재진술
- 기억을 신뢰하는 대신 세계 상태 확인
- 실패 범위 축소
- 하나의 식별 검사 실행
- 그런 다음에만 재시도
나쁜 패턴:
- 동일한 작업을 약간 다른 표현으로 세 번 재시도
좋은 패턴:
- 실패 캡처
- 패턴 분류
- 하나의 직접 검사 실행
- 검사가 지지하는 경우에만 계획 변경
ECC와의 통합
- 코드가 변경된 경우 복구 후
verification-loop사용 - 실패 패턴을 본능이나 나중에 사용할 스킬로 전환할 가치가 있는 경우
continuous-learning-v2사용 - 문제가 기술적 실패가 아닌 결정 모호성인 경우
council사용 - 실패가 충돌하는 로컬 상태 또는 저장소 표류에서 발생한 경우
workspace-surface-audit사용
출력 표준
이 스킬이 활성화된 경우, "고쳤습니다"로만 끝내지 마세요.
항상 다음을 제공하세요:
- 실패 패턴
- 근본 원인 가설
- 복구 조치
- 상황이 개선되었거나 여전히 차단되었음을 나타내는 증거