Hermes 에이전트가 코드를 작성한 후에도 프로젝트가 여전히 오류를 보고한다면, 먼저 LSP 진단과 실제 테스트 결과를 보고 단순히 '수정됨'이라고 믿지 마세요. v0.14는 각 write_file 또는 patch 후에 LSP 의미 진단을 추가하여, 새로운 유형의 오류, 정의되지 않은 심볼, 누락된 가져오기 등을 에이전트에게 더 일찍 노출시킬 수 있지만, 완전한 빌드와 테스트를 대체할 수는 없습니다.
LSP 진단은 무엇을 포착할 수 있을까요?
LSP는 편집 직후 바로 판단할 수 있는 문제를 더 잘 포착합니다: 변수 이름 작성이 잘못되었거나, 임포트가 누락되었거나, 타입 불일치, 함수 서명이 잘못됐거나, JSON/YAML/TOML 구조 오류, 파이썬 문법 오류 등이 있습니다. 이것은 단순한 포맷보다는 에디터의 레드라인 힌트에 더 가깝고, Hermes 에이전트가 당신이 방금 쓴 명백한 문제들을 다음 라운드에서 볼 수 있게 해줍니다.
왜 아직도 새고 있지?
데이터베이스 마이그레이션이 정확한지 반드시 알지 못하며, 실행 권한, 네트워크 오류, 서드파티 서비스 반환, 브라우저 호환성, 동시성 문제를 무시하지도 않습니다. 또 다른 흔한 상황은 프로젝트에 좋은 언어 서버가 없거나, 의존성이 완전히 설치되어 있지 않아 LSP가 효과적인 진단을 제공하지 못하는 경우입니다.
권장 문제 해결 순서
- Hermes Agent가 변경한 파일을 먼저 요약하게 하고, 단순히 큰 변경만 계속하지 마세요.
- LSP 진단에 새로운 오류가 있는지 확인하고 먼저 새 항목을 수정하세요.
- 그 다음 프로젝트 자체 테스트를 실행하고, 체크 타이핑을 하거나, 빌드 명령을 실행하세요.
- 테스트가 실패하면 첫 번째 오류와 재현 명령을 Hermes로 반환합니다.
- 프로덕션 코드의 경우에는 여전히 차이를 수동으로 봐야 합니다.
한마디로: LSP 진단은 미리 브레이크를 밟는 것이지, 자동으로 정확성을 보장하는 것이 아닙니다. "작성 후에야 발견되는 저수준 오류"의 수를 줄이지만, 진정한 수용은 여전히 테스트, 실행, 코드 검토에 있습니다. 공식 창고 주소: https://github.com/NousResearch/hermes-agent.
