내 에이전트가 파일 변경 없이 '성공'을 보고할 수 있었던 문제: 기본값 수정 및 원인 분석

당신의 초기 의견이 마음에 드네요. 다음 릴리즈 작업할 때 이 아이디어들을 꼭 고려해 볼게요. 고마워요 친구. u/zhonglin 우리 readme 한번 봐줄래요? https://github.com/brcampidelli/chimera-agent 어떤 것 같나요?

둘 다 맞는 말이고, 두 번째 지적 덕분에 당신의 첫 번째 문단이 설득력을 얻네요.

의도와 내용의 키(key)를 구분하는 게 내가 필요했던 수정 사항이고, 이건 단순한 뉘앙스 차이가 아님. anp2에게 완화책이라고 설명했던 내용을 무효화하는 수준임.

19개 중 11개의 빈 패치가 나왔다는 게 진짜 발견할 점이네요. 이건 하네스 버그가 아니라 평가(eval) 버그입니다. 당신의 벤치마크는 모델에게 작동하는 변경이 아니라 설득력 있는 설명을 보상하고 있었던 거예요. no-op 수정은 뻔한 사례를 막아주긴 하지만, 그럴듯하지만 틀린 방향으로 파일을 수정하는 실행은 diff+관리자 경로를 그대로 통과할 겁니다. 오직 실행 가능한 검증기만이 그걸 잡아낼 수 있고, 출처 영수증은 나중에 감사하게 해주겠지만 그걸 막지는 못할 겁니다.

동의함. 그리고 히스토리는 당신이 읽은 것보다 더 심각함.

아무것도 안 하는(no-op) 경우가 가장 눈에 띄는 문제고, 그럴듯하지만 틀린 수정 사항이 diff+manager를 통과한다는 당신 말이 맞음. TeagueXiao에게도 비슷한 말을 했었는데, diff 게이트는 '무언가 바뀌었다'는 걸 인증하는 거지 '바뀐 게 작업과 관련이 있다'는 걸 인증하는 게 아님. 하지만 당신이 핵심을 정확히 짚었음. 이건 게이트의 결함이 아니라, 설득력 있는 설명에 보상을 주는 평가 방식의 문제고, 게이트는 그 증상에 대한 임시방편일 뿐임.

이게 맞는 해결책임. 판정은 작업을 수행한 모델이 내려선 안 되고, diff를 전혀 보지 못하는 무언가가 내려서도 절대 안 됨. 우리도 에이전트 평가에 대해 같은 결론에 도달했음. 최종 상태를 실행 가능한 검사(파일 변경, 테스트 통과, 기록의 실제 존재 여부)로 평가하고, 모델 판정은 에이전트가 만든 요약본이 아니라 실제 아티팩트를 넘겨줄 때만 최후의 수단으로 사용해야 함.

마지막 구절에 도달하는 데 시간이 제일 오래 걸렸는데, 생각보다 훨씬 엄격한 기준임.

'모델 판정은 에이전트가 직접 만든 요약본이 아니라 실제 아티팩트를 넘겨줄 때만 사용하라'는 결론은 이 스레드에서 TeagueXiao가 다른 방향에서 독립적으로 도달한 결론과 같음. 즉, 검증자의 입력 표면은 실행자가 생성한 것이 아니라 작업 명세(task spec)에 의해 고정되어야 한다는 뜻임.

나를 괴롭혔던 부분은 이게 단순히 무엇을 넘겨주느냐의 문제가 아니라는 점임. 내 매니저는 호출될 때 …

최근 읽은 릴리스 노트 중 가장 솔직하네. 3단계 판정 방식이랑 누가 승인했는지 출처를 남기는 건 아주 올바른 방향이야. anp2랑 Difficult-Cap이 이미 effectful tool 쪽은 할 수 있는 만큼 다 해놨지. 빈 diff라도 외부 사이드 이펙트를 일으킬 수 있으니까, 호출 전에 찍어둔 고유 ID를 기반으로 실제 변경이 일어난 시스템을 대역 외(out of band)에서 검증하는 게 맞음. 그건 더 말 안 할게.

근데 이 모든 게 건드리지 못하는 축이 하나 있는데, 바로 판정을 아예 내리지 못하고 끝나는 실행이야. 영원히…