건강한 Oracle 샘플이 AI 에이전트의 재개를 자동으로 재개해서는 안 되는 이유

오랫동안 실행되는 AI 에이전트는 oracle 조건을 확인하고 halt 권고를 받습니다. 따라서 전략은 일시 중지됩니다.

다음 샘플을 보면 건강해 보입니다. 에이전트가 즉시 재개해야 할까요?

저는 복구(recovery)를 별도의 결정으로 간주할 것입니다. 단일한 건강한 응답만으로는 사고가 끝났음을 확립하지 못하며, 프로세스 재시작이 일시 중지를 지워서는 안 됩니다.

Insight Oracle Watch를 사용하여 이 경계를 처리하는 방법은 다음과 같습니다.

재시작을 거쳐도 halt 상태 유지하기

Oracle Watch는 stateAdapter를 통해 halted, recovering, monitor_unavailable와 같은 상태를 유지할 수 있습니다.

어댑터는 배포에 적합한 스토리지를 사용해야 합니다. 인-메모리 맵(in-memory map)은 재시작 시 상태가 손실되므로, 여러 워커(worker)에는 공유되고 조정된 스토어가 필요합니다.

이 예제는 스토어와 애플리케이션 액션을 의존성으로 받습니다:

import {
  InsightGuard,
  type OracleWatchTarget,
...

pauseNewActions를 전략 컨트롤러에 연결합니다. 애플리케이션 실행 경계(execution boundary)에서 assertCanStartNewAction()을 호출합니다. Guard의 스왑 실행 흐름(swap execution flow)을 사용하는 경우, 동일한 watchTarget을 전달하여 Watch halt가 그곳에도 적용되도록 합니다.

콜백은 알림과 애플리케이션 동작을 제공합니다. 실행 경계는 여전히 halt 상태를 확인해야 합니다.

복구에는 두 단계가 필요하다

stopOnHalt: false로 설정하면, Watch는 halt 이후에도 신호 수집을 계속합니다.

이 예제에서는 연속된 두 개의 새로운 건강한 샘플이 복구를 검토 준비(ready for review) 상태로 만듭니다. 이는 실행 중지(execution halt)를 해제하지 않습니다.

운영자가 사고와 현재 조건을 검토한 후, 애플리케이션은 다음을 호출할 수 있습니다:

await watch.acknowledgeRecovery();

여기서 watch는 startGuardedWatch()가 반환하는 핸들입니다. 승인(Acknowledgement)은 Watch의 복구 조건이 충족될 때 Watch halt를 해제합니다. 이는 지갑을 호출하거나, 거래를 제출하거나, 전략을 자체적으로 재개하지 않습니다.

애플리케이션은 현재의 사전 거래 평가 및 권한 요구 사항을 포함하여 후속 실행 결정을 스스로 내려야 합니다.

모니터링 가용성을 상태로 취급하기

실패한 Watch 요청, 소진된 API 예산, 또는 스토리지 실패 역시 실행 중인 전략에 영향을 미칩니다.

사건 발생 이유를 보존하고 모니터링 가용성을 눈에 보이게 만드세요. SDK는 영구 상태(durable state)를 저장할 수 없을 때 로컬 일시 정지(local halt)를 유지합니다. 실행 경로는 누락된 모니터링이 건강한 조건임을 가정하는 대신, 게이트를 확인해야 합니다.

Oracle Watch의 기본 주기(cadence)는 15분이며, 이는 Insight가 발표한 스냅샷 주기에 맞춰져 있습니다. 이는 초 단위 시장 관찰이 아닌, 예약된 모니터링을 제공합니다.

설계 질문

유용한 상태 머신은 다음 사항들을 분리해야 합니다:

• Halted (일시 중지됨): 신호 또는 모니터링 사고가 새로운 행동을 멈추게 함.
• Recovering (복구 중): 새로운 건강한 샘플이 도착했지만, 일시 정지는 유지됨.
• Acknowledged (승인됨): 복구 조건이 검토되었고 Watch 일시 정지가 명시적으로 해제됨.

자동화된 전략의 경우, 일시 중지된 에이전트가 다음 행동을 취하기 전에 어떤 증거가 요구되어야 할까요?

참고 자료

• Insight SDK: 실행 중인 전략 감시
• 영구 Watch 사고(Durable Watch incidents)
• Insight