모델 성능과 상관없는 조용한 툴 실패: 서술보다 영수증을 믿기 시작함

정확히 이 문제를 해결하려고 만든 작은 오픈소스 프로젝트가 있음. 완전히 로컬에서 돌아가고 오프라인이며, API 키도 필요 없고 오버헤드는 1ms 미만임. 실행 전에 의도를 로그로 남기고 실제 영수증이 있어야만 상태를 업데이트해서, 호출은 안 됐는데 됐다고 우기는 경우를 '완료'가 아닌 '알 수 없음'으로 처리함. MIT 라이선스임. https://github.com/cruxial-ai/cruxial

본인 툴에 맞는 영수증 리더 작성하는 거 기꺼이 도와줄 수 있고, 아직 지원 안 되는 툴이면 같이 해결해 보겠음. 답글이나 DM 줘.

나도 똑같이 느꼈던 패턴임. 에이전트가 제대로 작동 안 할 때 사람들이 기본적으로 '더 큰 모델'을 쓰려고 하는데, 사실 모델 문제는 거의 아님. 영수증 방식이 정답임. 그 외에 도움 됐던 거 두 가지:

1. 각 툴 호출 후 명시적인 상태 단언(state assertion). 단순히 반환값만 확인하는 게 아니라, '상태 검증' 단계를 따로 둬서 파일이 실제로 존재하는지, 행 개수가 변했는지, API 응답 본문에 예상 필드가 있는지 확인하는 거임. 모델이 그냥 서술해 버릴 만한 모든 것들을...

파일 존재 여부나 행 개수 변화처럼 쿼리 가능한 근거가 있을 때는 상태 단언이 잘 먹히지. 근데 외부 API가 주는 정보가 유일한 증거인 경우엔 좀 막막함. 이메일 전송, 카드 결제, 외부 포스팅 같은 거 말이야. 비용 효율적으로 상태를 재확인할 방법이 없어서 결국 반환된 영수증에만 의존해야 하거든.

그런 경우에는 뭘 기준으로 단언을 함?

이게 딱 맞는 경계선임. 난 툴 결과를 하나의 작은 계약처럼 다룸: 액션 이름, 요청 ID, 성공 플래그, 영향받은 리소스, 그리고 변경 사항을 검증할 수 있을 만큼의 반환 데이터. 어시스턴트가 그 영수증을 요약할 순 있어도, 영수증 자체를 만들어낼 순 없음. 파일 쓰기 작업이면 경로랑 기본 메타데이터를 다시 읽어오고, 작업 변경이면 레코드를 다시 가져옴. 원격 액션이면 제공자 응답 ID를 보관하고. 영수증이 없거나 비어있으면 상태는 계속 '대기 중'으로 두는 거지. 마법 같은 느낌은 덜해도 훨씬 쓸만함.

Fire-and-forget 외부 API의 경우 문제를 두 가지로 나눔: '내가 요청을 제대로 보냈는가?' (검증 가능) vs '외부 시스템이 그걸 처리했는가?' (관찰 가능, 검증 불가능). 검증 가능한 부분은 아웃바운드 호출을 모킹해서 내 코드가 올바른 페이로드 형태, 인증 헤더, 멱등성 키를 보냈는지 확인하고, 관찰 가능한 부분은 영수증 ID(Stripe payment_intent ID, SES message_id 등)를 로그로 남긴 뒤 5~15분 후에 지연 작업(job)을 돌려서 예상되는 다운스트림 상태가 실제로...