-
Notifications
You must be signed in to change notification settings - Fork 0
Agent and Verification
b-studio에서 모델의 최종 문장은 완료 조건이 아닙니다. 다음 게이트를 통과해야 변경을 체크포인트로 인정합니다.
- 변경 파일이 샌드박스에 실제로 반영됐는지 확인
- 영향받은 서비스를 재시작
- 컨테이너 상태와 HTTP readiness 확인
- OpenAPI를 다시 추출하고 기준 계약과 비교
- 통과한 파일과 데이터베이스를 체크포인트로 저장
게이트가 실패하면 컴파일 로그, 준비 상태, 계약 차이를 모델에 돌려주어 다음 턴에서 고치게 합니다. 요청을 취소하거나 한도에 도달하면 검증 전 변경을 버리고 마지막 체크포인트로 돌아갑니다.
기본 정책은 기존 필드·엔드포인트 삭제나 타입 변경을 막는 것입니다. 의도적인 breaking change는 사용자 요청에 목적이 명시되어야 하고 CLI에서는 --allow-breaking도 필요합니다.
AGENTS.md나 시스템 프롬프트는 모델에게 작업 방법을 알려 주지만, b-studio의 실행 정책은 모델이 잘못 판단해도 도구가 실제로 실행되지 않게 하는 마지막 경계입니다.
모델 도구 호출 → 실행 정책 검사 → 감사 이벤트 기록 → 허용 또는 차단 → 샌드박스
기본적으로 git push, git reset --hard, git clean, kubectl, helm, terraform apply/destroy, Docker·Podman CLI와 psql, mysql, redis-cli, mongosh를 차단합니다. sh -c 같은 셸 래퍼 안에 위험 명령을 넣는 우회도 검사합니다. 프로젝트 테스트와 빌드는 계속 run_in_service로 실행할 수 있습니다.
통합 실행자는 RunAgentOptions.policy로 허용 도구 목록과 추가 차단 명령을 지정할 수 있습니다. requireApprovalFor를 설정한 도구는 승인 콜백이나 별도 승인 토큰 없이는 실행되지 않습니다. 허용·차단 여부와 사유는 policy 이벤트로 남기며, 파일 내용과 토큰 값은 기록하지 않습니다.
구현 상세와 예시는 저장소의 실행 정책 문서를 참고하세요.
파일만 되돌리면 이미 적용된 마이그레이션 때문에 코드와 DB가 다른 시점이 될 수 있습니다. databases에 등록한 PostgreSQL은 검증을 통과할 때 덤프를 남기고 체크포인트를 되돌릴 때 함께 복원합니다.
API 모드에서는 공급자별 모델을 공통 도구 계약으로 실행합니다. 라우터는 요청 위험·복잡도, 과거 게이트 결과, 지연과 비용을 비교하고 선택 이유를 기록합니다.
Agent Fleet는 같은 요청을 2~4개의 독립 세션·브랜치·샌드박스에 보냅니다. 후보들은 서로의 파일을 공유하지 않으며, 사용자가 검증 결과와 변경 내용을 비교한 뒤 하나를 선택합니다.
Docker E2E, 실제 브라우저, kind/gVisor, 인증과 배포 등 확인한 범위는 검증 기록에 있습니다. 재현 가능한 실패와 수정 과정은 문제 해결에서 찾을 수 있습니다.
b-studio 저장소 · 문서 · Issue