RL 에이전트 샌드박스는 상태를 격리하고, 리소스를 제어하며, 작업과 출력을 기록하고, 시행 간에 환경을 리셋하여 실험을 반복 가능하게 만들어야 합니다. 이는 강화 학습, 평가 루프, 코딩 에이전트, 브라우저 에이전트, 그리고 에이전트가 명령을 실행하고, 파일을 변경하고, 도구를 호출하거나 학습 중인 환경을 변경할 수 있는 모든 시행착오 시스템에서 중요합니다.
RL 에이전트가 샌드박스를 필요로 하는 이유
강화 학습은 상호작용을 기반으로 구축됩니다. 에이전트는 환경을 관찰하고, 행동을 선택하며, 피드백을 받고, 정책 또는 의사 결정 프로세스를 업데이트합니다. 장난감 수준의 시뮬레이터에서 이 루프는 그리드 위의 토큰 하나만 움직일 수도 있습니다. 하지만 현대적인 에이전트 시스템에서는 행동이 Python 실행, 패키지 설치, 리포지토리 편집, 웹 앱 탐색, 도구 호출, 또는 평가자가 평가할 파일 생성을 포함할 수 있습니다.
이로 인해 런타임은 실험의 일부가 됩니다. 두 번의 시행이 파일 시스템, 캐시, 브라우저 세션, 백그라운드 프로세스 또는 부분적으로 수정된 리포지토리를 공유한다면, 두 번째 시행은 첫 번째 시행과 동일한 상태에서 시작하는 것이 아닙니다. 보상이 향상된 것은 에이전트가 학습했기 때문일 수도 있고, 환경이 실수로 종속성, 자격 증명, 컴파일된 바이너리, 브라우저 쿠키 또는 생성된 헬퍼 파일을 유지했기 때문일 수도 있습니다. 격리와 리셋 동작 없이는 그 차이를 구분하기 어렵습니다.
샌드박스는 각 시행에 명확한 실행 경계를 제공합니다. 그 자체로 완전한 안전 전략은 아니며, 보상 설계, 정책 검토, 접근 제어 또는 사람의 승인 필요성을 대체하지 않습니다. 이는 빌더에게 에이전트 작업을 실행하고, 부작용을 관찰하고, 아티팩트를 캡처하고, 다음 시도 전에 환경을 리셋할 수 있는 통제된 장소를 제공합니다.
RL 스타일의 에이전트 작업에서 유용한 질문은 단순히 "이 샌드박스가 안전한가?"가 아닙니다. 더 나은 질문은 다음과 같습니다: 이 런타임이 한 번의 시행이 조용히 다음 시행을 오염시키지 않으면서 반복 가능한 실험을 지원할 수 있는가?
RL 에이전트 시행에서 리셋 가능성이 의미하는 것
리셋 가능성은 새로운 에피소드, 평가 또는 훈련 배치 전에 환경을 알려진 기준선으로 되돌릴 수 있는 능력입니다. 실제로 이 기준선은 깨끗한 디렉토리 이상을 포함합니다.
RL 에이전트 샌드박스는 다음을 리셋해야 할 수 있습니다:
- 시행 중에 생성, 편집, 삭제 또는 다운로드된 파일.
- 설치된 패키지, 빌드 캐시, 컴파일된 아티팩트 및 임시 파일.
- 실행 중인 프로세스, 포트, 소켓, 브라우저 세션 및 백그라운드 작업.
- 환경 변수 및 범위가 지정된 자격 증명.
- 데이터베이스 fixture, 로컬 서비스, 큐 또는 모의 API.
- 네트워크 정책, 패키지 레지스트리 구성 및 도구 권한.
- 평가 상태, 보상 로그 및 평가자 입력.
리셋 메커니즘은 작업 부하에 따라 달라집니다. 코딩 벤치마크는 리포지토리 체크아웃과 테스트 fixture를 복원해야 할 수 있습니다. 브라우저 작업은 쿠키, 로컬 스토리지, 다운로드 및 브라우저 프로필을 지워야 할 수 있습니다. 데이터 분석 에이전트는 승인된 출력 아티팩트만 보존하면서 입력 데이터셋을 리셋해야 할 수 있습니다. 다단계 에이전트 평가는 일시 중지, 검사, 그리고 샌드박스를 재개하거나 폐기해야 할 수 있습니다.
실수는 리셋을 끝에 실행되는 정리 스크립트로 취급하는 것입니다. 정리 스크립트는 실패합니다. 에이전트가 이를 종료시키거나, 실행 전에 멈추거나, 디스크를 가득 채우거나, 백그라운드 프로세스를 남겨두거나, 스크립트가 모르는 경로를 생성할 수 있습니다. 더 강력한 설계는 각 시행을 알려진 템플릿 또는 스냅샷에서 시작하고, 변경된 사항을 기록한 다음, 전체 런타임 경계를 해체하거나 리셋하는 것입니다.
반복 가능한 환경 및 상태 스냅샷
반복 가능한 RL 시행에는 명확한 기준선이 필요합니다. 이 기준선은 운영 체제 이미지, 언어 런타임, 패키지, 데이터셋 버전, 환경 변수, 파일, 네트워크 정책, 리소스 제한 및 진입점 명령을 정의해야 합니다.
세 가지 일반적인 기준선 패턴이 있습니다:
| 패턴 | 가장 적합한 경우 | 주의할 점 |
|---|---|---|
| 템플릿에서 새 샌드박스 생성 | 독립적인 에피소드, 일괄 평가, 코딩 작업, 브라우저 작업 | 시작 시간 및 패키지 설치 시간이 짧은 시행을 지배할 수 있음 |
| 스냅샷 및 복원 | 각 시도 전에 준비된 환경이 필요한 다단계 작업 | 스냅샷이 버전 관리되지 않으면 스냅샷 드리프트가 변경 사항을 숨길 수 있음 |
| 통제된 체크포인트가 있는 장기 실행 샌드박스 | 대화형 디버깅, 커리큘럼 작업, 사람-인-더-루프 수정 | 체크포인트가 명시적이지 않으면 상태가 시행 간에 누출될 수 있음 |
템플릿은 대부분의 시행이 동일한 알려진 이미지에서 시작할 때 유용합니다. 스냅샷은 값비싼 설정(종속성 설치, 공개 fixture 다운로드, 프로젝트 컴파일 또는 브라우저 사용 가능 작업 공간 열기) 후에 유용합니다. 장기 실행 세션은 진정으로 메모리와 상태가 필요한 에이전트 워크플로에 도움이 될 수 있지만, 상태 모델이 실험의 일부가 아니라면 평가의 기본값이 되어서는 안 됩니다.
실용적인 규칙: 시행이 시작되기 전에 무엇이 지속될 수 있는지 정의하십시오. "승인된 아티팩트 외에는 아무것도 없음"이 답이라면, 새 샌드박스 또는 스냅샷 복원을 사용하십시오. "에이전트가 이전 시도를 기반으로 구축해야 함"이 답이라면, 그 지속성을 실험의 일부로 취급하고 그렇게 기록하십시오.
결정론적 및 비결정론적 실행
모든 에이전트 시행이 완벽하게 결정론적일 수는 없습니다. 언어 모델 샘플링, 외부 API, 브라우저 타이밍, 패키지 레지스트리 가용성, 병렬 프로세스 및 네트워크 지연은 모두 변동될 수 있습니다. 그럼에도 불구하고 샌드박스는 피할 수 있는 변동 원인을 줄일 수 있습니다.
더 반복 가능한 실행을 위해, 제어할 수 있는 부분을 제어하십시오:
- 패키지 버전, 컨테이너 이미지, 데이터셋, 프롬프트, 평가자 코드 및 모델 구성을 고정하십시오.
- 모델, 환경 또는 평가자가 지원하는 경우 무작위 시드를 기록하십시오.
- 벤치마크 fixture 및 예상 출력을 고정하십시오.
- 승인된 레지스트리 또는 캐시를 통해 패키지 설치를 라우팅하십시오.
- 작업이 명시적으로 라이브 통합에 관한 것이 아니라면, 라이브 프로덕션 시스템을 보상 소스로 사용하지 마십시오.
- 실행 중 사용된 정확한 명령, 도구 호출, 파일 및 네트워크 대상을 캡처하십시오.
그런 다음 결정론적 실패와 확률론적 행동을 분리하십시오. 시행 7이 에이전트가 다른 계획을 선택했기 때문에 실패했다면, 그것은 유용한 정보입니다. 시행 7이 이전 시행이 동일한 포트에 프로세스를 남겼기 때문에 실패했다면, 그것은 환경 오염입니다. 시행 7이 패키지 레지스트리가 다른 버전을 반환했기 때문에 실패했다면, 그것은 종속성 드리프트입니다.
샌드박스는 이러한 차이점을 볼 수 있게 해야 합니다. 목표는 모든 RL 에이전트 실행이 결정론적인 척하는 것이 아닙니다. 목표는 숨겨진 상태를 제거하고 실행이 변경된 이유를 설명할 수 있는 충분한 증거를 보존하는 것입니다.
시행 루프를 위한 리소스 및 시간 제한
RL 및 평가 루프는 많은 시행을 실행할 수 있습니다. 단일 에이전트 버그는 빠르게 배가될 수 있습니다: 무한 루프, 통제 불능 패키지 설치, 포크된 프로세스, 대규모 다운로드, 무제한 로그 또는 반복적인 브라우저 세션. 리소스 제어는 잘못된 시행이 전체 평가 예산을 소비하는 것을 방지합니다.
에이전트 프롬프트 내부뿐만 아니라 샌드박스 수준에서 제한을 설정하십시오:
| 제한 | RL 에이전트에게 중요한 이유 |
|---|---|
| 벽시계 시간 초과 | 중단된 에피소드가 배치를 차단하는 것을 방지 |
| CPU 및 메모리 할당량 | 한 시행이 이웃 시행을 굶주리게 만드는 것을 방지 |
| 디스크 할당량 | 로그, 캐시, 패키지 설치 및 생성된 아티팩트 제어 |
| 프로세스 제한 | 통제 불능 하위 프로세스 및 백그라운드 작업 실패 감소 |
| 네트워크 정책 | 예상치 못한 호출, 다운로드 또는 내부 접근 방지 |
| 출력 크기 제한 | 모델 컨텍스트 및 원격 측정 파이프라인을 사용 가능하게 유지 |
| 동시 샌드박스 상한 | 스윕 중 예산 및 공유 인프라 보호 |
시간 초과에는 미묘함이 필요합니다. 하드 시간 초과는 짧은 벤치마크 에피소드에 적합합니다. 장기 실행 작업은 사람이 계속할지 결정하기 전에 진행 상황을 검사할 수 있도록 일시 중지, 재개 또는 체크포인팅이 필요할 수 있습니다. 중요한 것은 런타임 정책이 명시적이라는 것입니다. 보상 루프가 완료되지 않았다고 해서 에이전트가 무제한 컴퓨팅을 받아서는 안 됩니다.
보상, 평가 및 디버깅을 위한 원격 측정
보상 신호는 설명할 수 있을 때만 유용합니다. 에이전트 시스템에서 점수는 종종 여러 가지를 결합합니다: 작업 성공, 테스트 결과, 명령 종료 코드, 파일 차이, 브라우저 상태, 지연 시간, 토큰 사용량, 사람 레이블 및 평가자 출력. 샌드박스는 불필요한 비밀 또는 개인 데이터를 저장하지 않고 점수를 이해하는 데 필요한 증거를 캡처해야 합니다.
유용한 원격 측정에는 다음이 포함됩니다:
- 샌드박스 ID, 시행 ID, 작업 ID, 템플릿 또는 스냅샷 버전 및 시작 시간.
- 실행에 사용된 모델 및 에이전트 구성.
- 도구 호출, 셸 명령, 종료 코드 및 런타임 지속 시간.
- 읽기, 쓰기, 생성, 삭제 또는 내보낸 파일.
- 연락한 네트워크 도메인 및 설치된 패키지 이름.
- 관련된 경우 브라우저 작업, 스크린샷, 다운로드 및 최종 페이지 상태.
- 평가자 입력, 보상 출력, 테스트 결과 및 평가자 오류.
- 검토를 위해 샌드박스에서 복사된 아티팩트.
원시 로그는 범위를 제한하십시오. 전체 명령 출력, 원시 프롬프트, 브라우저 스크린샷 및 생성된 파일은 민감한 정보를 포함할 수 있습니다. 많은 시스템에서 더 나은 기본값은 구조화된 원격 측정과 선택적으로 보관된 아티팩트입니다. 실행을 재현하고 디버그하기에 충분히 저장하고, 로그가 자격 증명, 고객 데이터 및 검토되지 않은 모델 출력으로 가득 찬 두 번째 데이터 레이크가 되지 않도록 하십시오.
보상 설계는 또한 샌드박스 제한을 고려해야 합니다. 에이전트가 공개 인터넷에 접근할 수 없는 경우, 라이브 웹사이트를 사용할 수 없어서 실패한 것으로 점수를 매기지 마십시오. 샌드박스에 작은 디스크 할당량이 있는 경우, 에이전트가 해당 제약 조건을 처리했는지 측정하고, 저장 공간을 무차별 대입할 수 있는지 여부를 측정하지 마십시오. 환경 정책과 보상 함수는 일치해야 합니다.
파일, 네트워크 및 안전하지 않은 작업 경계
샌드박싱은 에이전트가 접촉할 수 있는 범위를 좁힐 때 가장 효과적입니다. RL 스타일 시행의 경우, 에이전트가 놀라운 작업을 발견할 수 있다는 가정에서 시작하십시오. 프롬프트에서 언급하지 않은 명령을 실행하고, 숨겨진 파일을 검사하고, 차단된 네트워크 경로를 재시도하고, 패키지를 설치하거나, 이후 단계에서 동작을 변경하는 스크립트를 생성할 수 있습니다.
작업에 맞는 파일 시스템 경계를 사용하십시오:
- 에이전트가 검사만 하면 되는 경우 입력을 읽기 전용으로 마운트하십시오.
- 생성된 출력을 별도의 쓰기 가능 디렉토리에 넣으십시오.
- 자격 증명, 호스트 구성, 브라우저 프로필 및 배포 키를 작업 공간 밖에 두십시오.
- 시행 간에 쓰기 가능 디렉토리를 리셋하십시오.
- 기본적으로 전체 작업 공간이 아닌 승인된 아티팩트만 복사하십시오.
네트워크 정책도 동일한 정밀도가 필요합니다. 코딩 벤치마크는 인터넷 접근이 필요하지 않을 수 있습니다. 패키지 설치 작업은 레지스트리 허용 목록이 필요할 수 있습니다. 브라우저 에이전트 평가는 특정 공개 웹사이트와 차단된 내부 메타데이터 엔드포인트가 필요할 수 있습니다. 데이터 에이전트 워크플로는 광범위한 사설 네트워크 연결 가능성 대신 좁은 API가 필요할 수 있습니다.
실험이 명시적으로 포함하고 검토 경로가 명확하지 않는 한, 안전하지 않은 작업은 자동 루프 밖에 있어야 합니다. 예를 들어 프로덕션 배포, 고객 대상 메시지, 청구 변경, 접근 제어 편집, 대규모 내보내기, 파괴적인 데이터베이스 쓰기 및 인프라 수정이 있습니다. 샌드박스는 런타임 부작용을 포함할 수 있습니다. 어떤 비즈니스 작업이 승인을 받을 자격이 있는지 결정할 수는 없습니다.
아티팩트 캡처 및 사람 검토
RL 에이전트 시행의 끝은 검토 가능한 기록을 생성해야 합니다. 이는 모든 것을 보존한다는 의미가 아닙니다. 이는 시행을 평가, 감사 및 학습하는 데 필요한 아티팩트를 보존한다는 의미입니다.
코딩 에이전트의 경우, 이는 패치, 테스트 로그, 생성된 보고서 및 최종 작업 공간 차이일 수 있습니다. 브라우저 에이전트의 경우, 이는 스크린샷 시퀀스, 다운로드된 파일, 최종 URL 및 DOM 요약일 수 있습니다. 데이터 분석 에이전트의 경우, 이는 노트북, 차트, 변환된 데이터셋 및 평가자 점수일 수 있습니다. 안전에 민감한 워크플로의 경우, 거부된 작업 및 승인 요청이 포함될 수 있습니다.
사람 검토는 샌드박스 실험이 그렇지 않으면 외부 시스템에 영향을 미칠 경계에 속합니다. 좋은 검토 지점은 다음과 같습니다:
- 샌드박스에서 프로덕션 작업 공간으로 파일을 내보내기 전.
- 메시지 보내기, 티켓 열기, 페이지 게시 또는 코드 배포 전.
- 새로운 네트워크, 파일 시스템 또는 비밀 권한을 부여하기 전.
- 라이브 사용자 또는 고객 데이터에 학습된 정책을 사용하기 전.
- 보상 해킹, 프롬프트 인젝션 또는 환경 오용을 암시하는 반복적인 실패 후.
검토는 에이전트가 광범위한 접근 권한을 가진 후에 덧붙이는 것이 아니라 루프에 설계되어야 합니다. 샌드박스는 제안된 작업, 지원 아티팩트 및 시행 기록을 쉽게 검사할 수 있게 해야 합니다.
Novita Agent Sandbox의 위치
Novita Agent Sandbox는 코드 실행, 파일 시스템 작업, 브라우저 스타일 워크플로 및 장기 실행 작업을 위해 격리된 환경이 필요한 AI 에이전트를 위한 클라우드 샌드박스 런타임입니다. 현재 Novita 문서는 명령 실행, 파일 작업, 템플릿, 스냅샷, 일시 중지 및 재개, 백그라운드 실행, SDK/CLI 수명 주기 관리와 같은 샌드박스 기능을 설명합니다.
RL 스타일 에이전트 작업의 경우, 이러한 프리미티브는 핵심 환경 요구 사항에 매핑됩니다:
| RL 에이전트 요구 사항 | 찾아야 할 샌드박스 프리미티브 |
|---|---|
| 각 시행을 알려진 기준선에서 시작 | 템플릿 또는 스냅샷 기반 샌드박스 생성 |
| 호스트 접근 없이 에이전트 작업 실행 | 격리된 명령 실행 및 범위가 지정된 파일 시스템 |
| 선택된 출력만 보존 | 파일 작업 및 아티팩트 내보내기 정책 |
| 장기 실행 평가 지원 | 백그라운드 실행, 일시 중지/재개, 시간 초과 정책 |
| 실패했거나 놀라운 시행 디버그 | 로그, 명령 결과, 파일 차이 및 캡처된 아티팩트 |
| 평가와 앱 로직 분리 | 각 실행 주변의 SDK/CLI 수명 주기 제어 |
제품 경계를 명확히 유지하십시오. Novita Agent Sandbox는 평가 및 RL 에이전트 인프라를 지원할 수 있는 런타임 프리미티브를 제공하지만, 빌더는 여전히 보상 함수, 환경 템플릿, 도구 정책, 네트워크 규칙, 원격 측정 스키마, 비밀 처리 및 사람 승인 워크플로를 정의합니다. 어떤 샌드박스 제공자도 자율 에이전트를 위한 완전한 안전 계층으로 취급하지 마십시오.
RL 에이전트 샌드박스 체크리스트
반복되는 RL 스타일 시행 또는 대규모 평가 배치를 실행하기 전에 이 체크리스트를 사용하십시오:
| 영역 | 답변해야 할 질문 |
|---|---|
| 기준선 | 각 시행이 시작하는 템플릿, 스냅샷, 데이터셋, 종속성 세트 및 평가자 버전은 무엇입니까? |
| 리셋 | 시행 간에 어떤 상태가 지워지고, 어떤 상태가 의도적으로 보존됩니까? |
| 결정론 | 어떤 시드, 패키지 버전, 모델 설정 및 fixture가 고정되어 있습니까? |
| 파일 시스템 | 어떤 경로가 읽기 전용, 쓰기 가능, 숨김 또는 내보내집니까? |
| 네트워크 | 이그레스가 차단, 허용 목록, 프록시, 로깅 또는 작업별로 지정됩니까? |
| 리소스 | CPU, 메모리, 디스크, 프로세스, 시간 초과 및 동시성 제한은 무엇입니까? |
| 도구 | 에이전트가 호출할 수 있는 명령, 패키지 관리자, 브라우저 및 API는 무엇입니까? |
| 보상 | 어떤 증거가 보상에 제공되며, 캡처된 아티팩트에서 점수를 설명할 수 있습니까? |
| 원격 측정 | 명령, 파일 변경, 네트워크 호출, 출력 및 평가자 결과가 비밀을 저장하지 않고 기록됩니까? |
| 아티팩트 | 어떤 출력이 복사, 보관, 수정 또는 폐기됩니까? |
| 사람 검토 | 어떤 작업이 샌드박스를 떠나거나 외부 시스템에 닿기 전에 승인이 필요합니까? |
한 행이라도 불명확하면, 루프를 확장하기 전에 이를 수정하십시오. 작은 모호함은 수백 또는 수천 번의 시행에 걸쳐 곱해지면 비용이 많이 듭니다.
FAQ
RL 에이전트 샌드박스란 무엇입니까?
RL 에이전트 샌드박스는 에이전트가 작업을 수행하고, 피드백을 받고, 시행 간에 알려진 환경 상태로 리셋할 수 있는 격리된 런타임입니다. 이는 실험을 반복 가능하게 유지하고, 부작용을 포함하며, 점수 매기기 및 디버깅을 위한 증거를 캡처하는 데 사용됩니다.
강화 학습 에이전트에게 리셋 가능성이 중요한 이유는 무엇입니까?
리셋 가능성은 한 시행의 파일, 프로세스, 캐시, 브라우저 세션 또는 설치된 패키지가 다음 시행에 영향을 미치는 것을 방지합니다. 안정적인 리셋이 없으면, 보상 변화는 더 나은 에이전트 행동보다는 숨겨진 환경 드리프트를 반영할 수 있습니다.
RL 에이전트 샌드박스가 자율 에이전트를 안전하게 만듭니까?
아니요. 샌드박스는 런타임 폭발 반경을 줄이고 부작용을 관찰하기 쉽게 만들 수 있지만, 완전한 안전 보장은 아닙니다. 빌더는 여전히 범위가 지정된 권한, 네트워크 정책, 비밀 처리, 보상 설계, 모니터링 및 민감한 외부 작업에 대한 사람 검토가 필요합니다.
모든 RL 시행이 새 샌드박스에서 시작해야 합니까?
항상 그렇지는 않습니다. 새 샌드박스는 독립적인 평가에 가장 좋습니다. 스냅샷 복원은 값비싼 설정 후에 더 효율적일 수 있습니다. 장기 실행 샌드박스는 대화형 또는 커리큘럼 스타일 작업에 적합할 수 있지만, 지속적인 상태는 명시적이고 기록되어야 합니다.
RL 에이전트 샌드박스는 무엇을 기록해야 합니까?
시행 ID, 샌드박스 기준선, 명령, 도구 호출, 종료 코드, 파일 변경, 네트워크 대상, 리소스 사용량, 평가자 입력, 보상 출력 및 승인된 아티팩트를 기록하십시오. 기본적으로 원시 비밀, 불필요한 고객 데이터 또는 전체 미검토 파일 내용을 기록하지 마십시오.
