에이전트가 예약 도구의 응답을 못 받아 같은 요청을 다시 만들었습니다. 도구 호출 ID만으로 중복 예약을 막을 수 있나요?

도구 호출 ID는 모델·프로토콜의 한 호출과 결과를 연결하는 값일 수 있으며, 사용자의 같은 예약 의도를 계속 식별하는 멱등 키와는 다릅니다. 모델이 재시도할 때 새 호출 ID를 만들면 외부 API는 새 예약으로 볼 수 있습니다. 논리 작업 ID는 신뢰할 수 있는 런타임이 유지하고 인자와 실행 결과를 내구 기록에 연결하겠습니다.

재시도는 같은 의도와 인자를 유지합니다

예약이 실제 생성됐지만 응답만 유실됐다면 같은 논리 키로 상태를 조회하거나 API의 멱등 재요청을 사용합니다. 동일 키에 날짜·대상·금액이 다른 인자를 보내면 기존 결과를 임의 재사용하지 말고 충돌로 처리해야 합니다. 사용자가 조건을 바꾼 새 요청과 통신 실패의 반복을 구분하려면 정규화한 인자 해시와 사용자·작업 범위를 기록할 수 있습니다. 모델이 키를 직접 임의 생성·교체하게 하면 이 경계가 흔들립니다.

읽기 요청은 대체로 재시도하기 쉽지만 변경 도구의 timeout은 실행 여부 불확정입니다. 사전 검증 오류나 전송 전 실패와 구분하고, 무조건 다른 도구나 다른 에이전트에게 다시 실행시키지 않습니다. 멱등 키의 보관 기간이 최대 재시도·재개 기간보다 짧으면 오래된 작업이 다시 효과를 만들 수 있으므로 기간과 만료 뒤 정책도 명시합니다.

여러 효과를 한 번처럼 보이게 하지 않습니다

예약 생성과 결제, 알림을 별도 시스템에서 수행하면 하나의 멱등 키가 모든 경계를 원자적으로 묶지 않습니다. 단계별 키와 상태를 연결하고 가능한 곳에서는 처리 기록과 변경을 같은 DB transaction에 넣습니다. 완료 이벤트는 outbox로 남길 수 있지만 소비자 중복 방지도 필요합니다. 외부 서비스가 조회나 멱등성을 제공하지 않으면 보장 한계를 밝히고 불확정 결과를 사람에게 넘겨야 합니다.

평가에서는 모델이 같은 인자를 새 호출 ID로 생성하는 경우, 같은 키에 다른 인자, 외부 성공 후 프로세스 종료, 재개 세션의 중복 실행을 시험합니다. 최종 응답이 하나라는 사실보다 실제 예약·결제·원장 항목이 한 번만 생겼는지 확인합니다. 에이전트의 유연한 재계획이 분산 시스템의 재시도 계약을 없애지는 않으며, 모델 밖에서 안정적인 실행 식별을 유지하는 것이 핵심입니다.

실행 사례로 확인합니다

사용자 한 명이 같은 날짜에 두 개의 독립 예약을 요청할 수 있으므로 인자 값이 같다는 이유만으로 모두 같은 작업으로 합쳐서는 안 됩니다. 논리 키는 사용자 의도와 작업 생성 사건에서 발급하고, 재시도에는 그 키를 유지합니다. 반대로 모델이 문장을 다르게 표현해도 같은 요청의 재개라면 새 키를 만들지 않습니다. 키 저장소가 사라지거나 외부 API의 dedup 기간이 지난 뒤에는 동일 보장을 주장할 수 없으므로 결과 대사와 재실행 승인 절차를 둡니다. 평가에서는 의도된 두 예약과 실수로 반복된 한 예약을 모두 포함해 중복 제거가 정상 요청까지 삼키지 않는지 확인하겠습니다.