에이전트가 검색과 수정을 계속 반복하며 비용만 늘어납니다. 완료·실패·중단 조건과 실행 예산은 어떻게 정하나요?

모델이 스스로 끝났다고 말하기를 기다리지 않고 런타임에 시간·호출·비용·행동 범위의 상한을 두겠습니다. 완료는 목표 상태가 검증된 경우, 실패는 정한 방법으로 달성할 수 없는 경우, 중단은 예산 소진이나 승인 대기처럼 아직 결론을 낼 수 없는 경우로 구분합니다. 반복 수 하나만 제한하면 한 번의 비싼 도구 호출이나 긴 하위 작업은 통제하지 못합니다.

여러 예산을 함께 관리합니다

예를 들어 조사 작업에 전체 2분, 최대 검색 8회, 외부 변경 0회를 허용할 수 있습니다. 각 호출 전 남은 예산을 검사하고, 병렬 하위 작업에는 예산을 예약해 전체 합이 상한을 넘지 않게 합니다. 토큰 예산과 실제 비용은 모델·캐시·도구 요금에 따라 달라지므로 별도 집계합니다. 모델에 '절약하라'고 지시하는 것과 런타임이 실제 호출을 거부하는 것은 다른 통제입니다.

진전 여부도 관찰합니다. 같은 인자와 같은 오류가 반복되거나 새 근거 없이 계획만 바뀌면 순환을 의심할 수 있습니다. 다만 같은 상태 조회를 반복하는 장기 작업은 정상일 수 있으므로 호출 종류와 예상 상태 변화 시간을 고려합니다. 무조건 동일 호출을 금지하기보다 반복 이유·진전 신호·다음 확인 시점을 정합니다. 검증을 계속 약하게 바꾸어 성공으로 만드는 것은 진전이 아니라 기준 훼손입니다.

중단해도 결과를 정직하게 남깁니다

deadline이 끝났다고 이미 실행 중인 외부 요청이 취소됐다고 가정하지 않습니다. 취소 가능한 작업은 중단을 요청하고 종료를 확인하며, 불확정 변경은 요청 ID와 조회 경로를 기록합니다. '시간이 끝나 실패했다'는 사용자 응답과 '외부 예약이 없었다'는 사실은 다를 수 있습니다. 다음 세션이 안전하게 이어갈 수 있도록 완료한 항목, 미확인 결과, 사용한 예산을 분리해 남깁니다.

예산 설정은 쉬운 과제와 어려운 과제를 섞은 평균만으로 정하지 않습니다. 추가 호출 한 번이 해결률을 얼마나 높이는지, 실패 과제의 비용 꼬리가 얼마나 긴지 비교합니다. 작은 모델의 저렴한 호출을 수십 번 반복하는 것보다 강한 모델의 제한된 호출이 싸게 끝날 수도 있습니다. 안전한 보류와 사람에게 넘기는 결과를 정상 종료 유형으로 설계하면 억지로 성공을 만들어 내는 압력도 줄일 수 있습니다. 목표는 최소 호출 수가 아니라 허용 비용과 위험 안에서 검증된 결과를 얻는 것입니다.

실행 사례로 확인합니다

예산이 100인 부모가 세 하위 작업에 각각 60을 주면 로컬 제한은 지켜도 총량은 180이 됩니다. 예약·사용·반환을 부모에서 합산하고, 대기나 취소된 작업의 남은 예산을 실제 상태에 맞춰 돌려받아야 합니다. 비용 API가 지연 보고되는 경우 보수적인 예약 상한을 두고 실제 사용량과 대사합니다. 남은 예산이 결과 검증에 필요한 최소량보다 작다면 새 탐색을 시작하기보다 현재 결과를 정리하고 검증할 여유를 남기는 편이 낫습니다. 예산 종료 메시지에는 시도한 일과 확인된 사실만 적고, 남은 작업을 자동으로 예약하거나 다른 실행기로 넘기는 것은 별도 권한과 수명이 필요한 행동으로 다룹니다.