서비스를 다시 시작하면 홈 AI 에이전트가 완료한 작업을 잊어버리는 이유는 무엇인가요?

홈 AI 에이전트는 계획, 도구 결과, 완료 표시가 휘발성 프로세스 메모리에만 존재하면 재시작 후 완료된 작업을 잊어버립니다.

에이전트가 파일을 업데이트하거나, 이벤트를 생성하거나, 컨테이너를 재시작하거나, 배치 작업의 일부를 완료한 뒤에도 서비스가 재배포되거나 충돌하면 해당 사실을 잊을 수 있습니다. 외부에서 발생한 변경은 남아 있을 수 있지만 모델 대화, 루프 카운터, 보류 중인 계획, 도구 결과 객체는 사라집니다. 시작 후 에이전트는 작업을 반복하거나 아무 일도 일어나지 않았다고 판단할 수 있습니다. 안정적인 복구를 위해서는 의도, 도구 호출, 관찰 가능한 결과, 다음 미완료 단계를 연결하는 경계에서 실행 상태를 저장해야 합니다.

대화 기록은 영속적인 워크플로 상태가 아닙니다

채팅 기록에는 사용자의 요청과 에이전트의 설명이 포함될 수 있지만, 어떤 부작용이 커밋되었는지, 어떤 레코드가 건너뛰어졌는지, 어느 분기에서 재개해야 하는지는 기록되지 않을 수 있습니다.

Augment Code의 영속적인 워크플로 상태 가이드는 장시간 실행되는 작업을 단일 프로세스나 동기 요청과 분리합니다.

에이전트에는 작업 ID, 현재 단계, 완료된 작업, 도구 결과 해시, 대기 중인 승인, 재시도 횟수와 같은 구조화된 상태가 필요합니다. 재시작 후 자연어 채팅에서 이 상태를 재생성하는 방식은 모호합니다.

완료된 도구 호출에는 영속적인 커밋 경계가 필요합니다

에이전트가 로컬 완료 표시를 기록하기 전에 도구가 외부 작업을 성공시킬 수 있습니다. 그 사이에 재시작이 발생하면 작업은 실제로 완료되었지만 에이전트는 이를 알지 못합니다.

Zylos는 복구가 계속되기 전에 완료된 작업을 보존하는 영속적인 실행 경계를 설명합니다.

신뢰할 수 있는 경계는 작업 ID와 결과를 영속 저장소에 기록하거나, 외부 작업과 완료 레코드를 함께 커밋할 수 있는 하나의 트랜잭션 서비스를 사용합니다.

원자적 커밋이 불가능하다면 도구가 상태 조회 기능을 제공해야 하며, 재시작된 에이전트는 이를 사용해 불확실한 결과를 조정할 수 있어야 합니다.

스냅샷만으로는 안전한 실행을 재구성하지 못할 수 있습니다

모델 메시지나 직렬화된 그래프 상태를 저장하면 특정 시점에 에이전트가 무엇을 믿었는지는 기록할 수 있습니다. 하지만 재생 중 외부 호출이 중복되지 않는다는 보장은 자동으로 제공되지 않습니다.

Diagrid는 애플리케이션 체크포인트와 재시도, 이벤트 기록, 부작용 완료를 직접 관리하는 런타임을 구분합니다.

복구 설계에서는 어떤 코드가 결정적이고, 어떤 도구 호출을 재생할 수 있으며, 어떤 결과를 다시 실행하지 않고 기록에서 읽어야 하는지 정의해야 합니다.

그렇지 않으면 올바른 체크포인트에서도 메시지 중복 전송, 파일 이동 반복, 장치 명령 재실행이 발생할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

안정적인 실행 및 단계 ID는 실수로 새 작업을 시작하는 일을 막습니다

재시작 후 새로 생성된 대화 또는 실행 ID는 동일한 사용자 목표를 새로운 작업처럼 보이게 만들 수 있습니다. 그러면 에이전트는 이전 상태를 찾을 키를 갖지 못합니다.

Inference.sh는 영속적인 실행 ID를 사용하면 에이전트가 가장 최근에 완료된 체크포인트에서 재개할 수 있다고 설명합니다.

워크플로 ID를 컨테이너 외부에 저장하고 사용자, 작업, 데이터 범위, 권한에 연결하세요. 다른 워커가 요청을 처리한다는 이유만으로 서비스 검색이나 로드 밸런싱이 새로운 논리적 실행을 만들어서는 안 됩니다.

완료된 단계는 다시 추론하지 말고 재사용해야 합니다

이전 모델 호출을 다시 실행하면 다른 계획, 다른 도구 인수, 또는 어떤 작업이 완료되었는지에 대한 다른 해석이 나올 수 있습니다.

Pydantic의 런타임 관련 글은 복구 과정에서 실패한 경계만 다시 실행하고 완료된 체크포인트는 완료된 상태로 유지된다고 설명합니다.

이를 통해 토큰 비용을 줄이고, 재시작된 에이전트가 이미 변경된 가정용 시스템에 두 번째 경로를 임의로 실행하는 일을 막을 수 있습니다.

저장된 결과에는 도구 출력이 현재 대상 상태와 여전히 일치하는지 검증할 수 있을 만큼 충분한 근거가 포함되어야 합니다.

멱등성과 조정은 중복 작업으로부터 복구를 보호합니다

영속 상태가 외부 시스템보다 한 단계 늦게 기록될 수도 있습니다. 작업 ID, 멱등성 키, 상태 확인, 보상 작업을 사용하면 이러한 불확실성을 처리할 수 있습니다.

Restate의 복원력 있는 에이전트 루프 가이드는 재시작 후에도 반복 상태를 유지하고 제어된 실행 지속을 지원합니다.

ZimaSpace의 반복해도 안전한 자동화 글은 명령을 무작정 재생하는 것보다 의도한 최종 상태를 지정하는 편이 안전한 이유를 보여 줍니다.

작업을 멱등적으로 만들 수 없다면 재시작된 에이전트는 현재 상태를 조정하거나 검토를 위해 중지해야 하며, 로컬 레코드가 없다는 이유만으로 실패했다고 가정해서는 안 됩니다.

재시작 테스트에는 모든 장애 구간이 포함되어야 합니다

도구 호출 전, 호출 중, 외부 작업 후, 로컬 체크포인트 후, 승인 대기 중에 서비스를 종료하세요. 각 재시작은 예측 가능한 하나의 후속 실행을 만들어야 합니다.

DBOS는 API와 사람의 상호작용이 포함된 워크플로를 위한 충돌 방지 실행을 설명합니다.

완료된 작업이 재사용되는지, 불확실한 작업이 조정되는지, 대기 중인 작업이 계속 대기 상태로 남는지, 권한이 조용히 다시 생성되지 않는지 감사하세요.

에이전트는 이전 프로세스가 우연히 보유하고 있던 텍스트가 아니라, 진행 상황이 영속적인 운영 증거로 저장될 때만 완료된 작업을 기억합니다.

FAQ

채팅 기록을 저장하는 것만으로 충분한가요?

아니요. 채팅 기록에는 작업 ID, 커밋된 부작용, 재시도 상태, 승인, 실행을 재개해야 하는 정확한 경계가 빠져 있을 수 있습니다.

재시작 후 에이전트가 모든 도구 호출을 재생해야 하나요?

아니요. 완료된 호출은 영속적인 기록에서 재사용해야 하며, 불확실한 호출은 다시 시도하기 전에 멱등성 또는 조정 절차가 필요합니다.

데이터베이스 체크포인트가 모든 중복 작업을 막을 수 있나요?

아니요. 체크포인트는 외부 작업과 조율되어야 합니다. 작업과 체크포인트 사이에 충돌이 발생하면 결과가 불확실해집니다.