가정용 AI 에이전트가 반복할 수 없는 작업을 재시도하면 왜 위험할까요?

외부 상태를 변경하는 작업에서 에이전트가 첫 번째 시도가 이미 성공했는지 입증할 수 없다면, 가정용 AI 에이전트의 재시도는 위험합니다.

로컬 모델은 시간 초과, 도구 충돌, 네트워크 중단, 잘못된 응답 또는 오케스트레이션 재시작 후에 재시도할 수 있습니다. 이러한 복구 동작은 검색이나 기타 반복 가능한 작업에는 유용하지만, 메시지 전송, 일정 생성, 파일 삭제, 문 잠금 해제, 구매 실행 또는 일회성 스크립트 시작에서는 위험해집니다. 핵심적인 모호성은 응답을 받지 못했다고 해서 작업 수행에 실패했다는 뜻은 아니라는 점입니다. 아래 섹션에서는 이러한 불확실성이 어떻게 가정 내 중복 부작용으로 이어지는지 살펴봅니다.

시간 초과만으로는 부작용이 발생했는지 알 수 없습니다

에이전트가 요청을 보내고 도구가 작업을 완료했지만, 에이전트가 성공을 기록하기 전에 응답이 유실될 수 있습니다. 에이전트 입장에서는 해당 시도가 여전히 미해결 상태로 남습니다.

복원력 있는 에이전트 네트워크에 관한 연구에서는 이를 모호한 실행 결과라고 하며, 이를 처리하려면 영구적인 작업 식별자와 복구 증거가 필요하다고 설명합니다.

무작정 재시도하면 불확실성이 두 번째 실행으로 바뀝니다. 모든 재시도를 거부하면 중복은 피할 수 있지만, 첫 번째 시도가 실제로 실패했을 때 작업이 완료되지 않을 수 있습니다.

반복할 수 없는 작업은 시도할 때마다 새로운 효과를 누적합니다

상태를 두 번 읽으면 대개 또 다른 관찰 결과를 반환합니다. 하지만 같은 메시지를 두 번 보내거나, 같은 레코드를 두 번 추가하거나, 같은 설정을 두 번 증가시키면 상태가 추가로 변경됩니다.

Flux는 재시도 기반 장애 허용이 예기치 않은 가시적 부작용을 만들 수 있기 때문에 멱등성 일관성을 형식화합니다.

따라서 에이전트 작업은 도구 호출이 동일한 JSON 인수를 사용하는지가 아니라 의미론에 따라 분류해야 합니다. 요청이 동일해도 메시지 두 개, 일정 두 개 또는 결제 두 건이 발생할 수 있습니다.

삭제 작업도 주의해야 합니다. 이미 존재하지 않는 객체를 삭제하는 것은 무해할 수 있지만, “가장 최근 백업 삭제”는 두 번째 시도에서 다른 객체를 대상으로 할 수 있습니다.

워크플로 엔진은 일반적으로 최소 한 번 실행되는 시도를 제공합니다

재시도가 반드시 에이전트의 버그인 것은 아닙니다. 큐와 워크플로 시스템은 외부 부작용이 커밋되었는지 원자적으로 확인할 수 없기 때문에 작업자 장애 후 작업을 반복하는 경우가 많습니다.

분산 실행 연구에서는 인프라가 재생을 통해 복구를 제공할 때 재시도되는 상태 저장 요청에 애플리케이션 수준의 멱등성이 필요하다고 설명합니다.

정전 후 재시작하는 가정용 에이전트는 종료 시점에 실행 중이던 단계를 다시 실행할 수 있습니다. 대상 서비스는 해당 논리적 작업이 이미 적용되었는지 식별해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

멱등성 키는 논리적 작업을 식별해야 합니다

에이전트는 첫 번째 시도 전에 안정적인 작업 ID 하나를 생성하고, 동일한 의도된 작업의 모든 재시도에 이를 재사용할 수 있습니다. 수신자는 결과와 함께 ID를 저장하고, 중복 요청을 거부하거나 이전 결과를 반환합니다.

정책 우선 에이전트 시스템은 작업 식별자를 사용해 재시도를 각각 새로운 요청으로 처리하지 않고 하나의 승인된 작업에 연결합니다.

키에는 대상, 작업, 중요한 인수, 사용자 및 승인 컨텍스트가 포함되어야 합니다. 변경된 매개변수에 동일한 키를 재사용하면 정당한 새 작업이 차단되거나 이전의 잘못된 결과가 반환될 수 있습니다.

수신 서비스는 중복 제거를 시행해야 합니다. 에이전트의 프롬프트나 로그에만 키를 넣으면 이를 무시하는 도구에는 아무런 효과가 없습니다.

중복 제거를 사용할 수 없다면 재시도 전에 현재 상태를 확인하세요

일부 가정용 도구는 멱등성 키나 트랜잭션 기록을 제공하지 않습니다. 이 경우 에이전트는 의도한 효과가 이미 표시되는지 확인하는 조정 단계를 거쳐야 합니다.

충돌 전용 시스템 설계는 재시작 동작을 명시적이고 테스트 가능하게 만드는 복구 상태를 강조합니다.

재시도하기 전에 첫 번째 시도가 생성한 이벤트 ID, 메시지 초안, 출력 파일, 장치 상태, 작업 레코드 또는 트랜잭션 마커를 검색하세요.

부작용이 즉시 관찰되지 않거나 서로 유사한 여러 작업이 일치할 수 있다면 조정은 신뢰하기 어렵습니다. 이러한 작업은 추측으로 진행하지 말고 사람의 검토를 위해 중지해야 합니다.

안전한 재시도 계약을 중심으로 에이전트 도구를 설계하세요

읽기 작업, 본질적으로 멱등적인 쓰기 작업, 키를 지원하는 쓰기 작업, 보상 가능한 작업 및 진정한 일회성 부작용을 분리하세요. 각 분류에 고유한 시간 초과 및 재시도 정책을 적용하세요.

ZimaSpace의 안전한 반복 가능 자동화 문서에서는 덧셈식 명령을 반복해서 내리는 것보다 의도한 최종 상태를 설정하는 편이 왜 더 안전한지 설명합니다.

반복할 수 없는 작업의 경우 실행 전에 의도를 저장하고, 하나의 작업 ID를 연결하며, 최종 결과를 기록하고, 상태 조회 기능을 제공하세요. 중복 피해를 되돌리기 어렵다면 초안, 미리 보기, 격리, 예약 전송 또는 승인을 사용하세요.

신뢰할 수 있는 에이전트는 모든 실패를 동일하게 재시도하지 않습니다. 반복된 시도가 하나의 논리적인 가정 내 작업을 유지한다는 것을 도구 계약으로 입증할 수 있을 때만 재시도합니다.