agent-env-designerlisted

# Agent Environment Designer 입력으로 받은 "특정 문제(도메인)"에 대해, 그 문제를 잘 푸는 에이전트를 만들기 위한 환경 설계안을 E = {T, H, V, S, C} 프레임워크로 산출한다. - T (Tasks) — 풀게 시킬 문제 집합 - H (Harness) — 에이전트-환경 상호작용을 관리하는 스캐폴딩(툴, 롤아웃 프로토콜, 컨텍스트 관리, 실패 시 재시도/반성 루프) - V (Verifier) — 결과물을 점수/보상으로 바꾸는 채점기 - S (State) — 에피소드 간 상태가 이어지는지 여부 - C (Configuration) — 턴 제한, 컨텍스트 예산 등 설정값 핵심 원칙: **검증가능성(verifiability)이 판정가능성(judgeability)보다 우월하다.** 프로그램적으로 맞았는지 틀렸는지 판별 가능한 설계가, LLM에게 "이거 잘했는지 봐줘"라고 시키는 것보다 항상 우선한다. V 설계에 가장 많은 공을 들여야 한다. ## 진행 절차 ### 0단계 — 문제 정의 및 목적 확인 사용자가 문제를 한두 문장으로만 던졌다면, 다음을 짧게 확인한다(모호할 때만 AskUserQuestion 사용, 이미 충분히 구체적이면 생략하고 바로 진행): - 이 환경의 용도가 **(a) 실제 RL 훈련용**(API/파인튜닝 접근 권한과 컴퓨팅 예산이 있는 경우)인지, **(b) 추론 시점 에이전틱 루프/Skill 설계용**(Claude Pro 등 일반 개발 환경에서 프롬프트·툴·검증 스크립트로 구현하는 경우)인지. 대부분의 사용���는 (b)에 해당하므로 불확실하면 (b)를 기본값으로 삼고 명시한다. - "성공"의 정의: 이 문제가 풀렸다는 것을 어떻게 알 수 있는가 (최종 산출물 예시가 있으면 좋음) - 사용 가능한 리소스: 코드 실행 환경, 특정 도메인 데이터, 기존 테스트/체크리스트 유무 ### 1단계 — V (Verifier) 먼저 설계 T보다 먼저 V를 설계한다. 검증기 설계가 전체 환경의 성패를 좌우하기 때문이다. 문제를 다음 세 범주 중 하나로 분류한다: 1. **완전 검증 가능** — 정답 대조, 코드 실행/컴파일, 수치 계산, 형식 증명(Lean 등), 스키마/타입 검증. 가능하면 항상 이 범주로 문제를 재구성할 방법을 먼저 찾는다(예: "글이 좋은가" → "이 체크리스트 항목을 모두 만족하는가"로 쪼개기). 2. **부분 검증 가능** — 체크리스트, 루브릭, 다중 기준 채점. 각 기준을 최대한 이진(pass/fail)에 가깝게 쪼갠다. 3. **판정 필요(비검증)** — 개방형 산출물(글쓰기 톤, 디자인 취향 등). 이 경우에만 LLM-판정(LLM-as-judge)을 쓰고, 되도록 여러 후보를 상대비교(그룹 내 순위)시키는 방식을 권장한다(절대점수 채점보다 게임당하기 어려움). 각 범주에 대해 구체적인 검증 메커니즘, 필요한 도구(테스트 러너, 린터, 컴파일러, 체크리스트 등), 그리고 **보상 게임화(reward hacking) 위험**을 짚는다 — 특히 정적 루브릭이나