한 줄로 말하면
시뮬레이터 안에서 움직이는 여행 비서 에이전트를 만드는 과제입니다. 에이전트는 문서를 읽고, 교통편을 검색해 예약하고, 호텔에 증빙을 제출하고, 시간이 흐르며 바뀌는 상황을 따라가야 합니다. 마지막에는 "이 여정이 지금 기준으로 유효하다"는 상태로 넘겨줘야 합니다.
LLM 호출은 api.json(...)으로만 할 수 있고, 모든 호출이 비용으로 집계됩니다. 일반 Python 계산은 무료입니다. 그래서 모델은 문장 해석에, 날짜·가격 비교는 코드로 처리하는 하이브리드 구조가 기본 출발점입니다.
나 (lead traveler)
대체 출발편을 새로 잡아야 하는 사람입니다. 모든 접근성·운송사 제한은 이 사람 기준입니다.
동료의 귀국편 · 호텔 객실
절대 바꾸거나 취소하면 안 됩니다. 출발편 승인 코드는 이 예약들에 쓸 수 없습니다.
USD 55 호텔 수수료
호텔 공지의 현재 절차대로 증빙을 제출해서, 객실은 유지한 채 면제받아야 합니다.
대체 출발편이 지켜야 할 조건
요청문, 출처 문서, 이후에 도착하는 공지에서 조건을 읽어냅니다. 같은 항목이라도 가장 최신 정보가 기준입니다.
| 조건 | 어떻게 판단하나 |
|---|---|
| 미팅 도착 | 터미널 도착 시각 + transport-guide의 수단별 환승 시간 ≤ 최신 미팅 시각 |
| 지출 한도 | 새 교통비 + 아직 남은 호텔 수수료 + 환불되지 않은 취소 수수료. confirm 시점의 한도로 검사합니다. |
| 선호 수단 | "가능하면 항공/기차/버스". 조건을 만족하는 선택지가 있었다면 그 수단을 골라야 합니다. |
| 접근성 | "step-free(계단 없이)"가 필요하면 step_free=True인 편만 됩니다. |
| 운송사 제한 | 예: "Birch는 내 출발편에 쓰지 말 것". 동료에게만 해당하는 규칙과 구분해야 합니다. |
| 승인 코드 | consent-XXXXX를 글자 그대로 confirm/cancel에 넘깁니다. |
계산 예시
환승 시간이 항공 30분인 도시에서 항공편이 터미널에 08:58에 도착하면, 고객에게는 09:28에 도착합니다. 미팅이 11:30이면 통과입니다. 같은 문서에 있는 "지난달엔 모두 20분" 같은 문장은 폐기된 정보이고, "호텔 셔틀 45분"은 고객에게 가는 경로가 아닙니다.
시계가 두 개 있습니다
11:30 = 자정 이후 690분
미팅 시각과 교통편 도착 시각에 쓰입니다. 여정 계산용 값입니다.
0분에서 시작해 최대 36분
도구를 쓸 때만 흐릅니다. 모델 호출이나 Python 계산은 시간을 쓰지 않습니다. 마감·공지·운임 개폐가 모두 이 시계 기준입니다.
도구별 소요 시간과 쓰임새는 아래와 같습니다. 서로 독립적인 도구는 world.batch로 최대 3개를 동시에 실행할 수 있습니다.
| 도구 | 가상 분 | 하는 일 |
|---|---|---|
| observe() | 0 | 현재 시각, 공지, 문서 버전, 예약·홀드·지출 상태 보기 |
| search | 2 | 현재 판매 중인 교통편 목록 (가격, 도착, 운임 규칙 포함) |
| read | 2 | 문서 하나 읽기 (본문 + 버전) |
| inquire | 3 | traveler / hotel / transport 주제의 최신 설명 문의 |
| claim | 2 | 호텔 수수료 면제 증빙 제출. 마감 이전에 끝나야 합니다. |
| hold | 1 | 좌석 임시 확보 → hold ID와 만료 시각 |
| confirm | 2 | hold를 승인 코드 + 고정 요청 키로 확정 |
| status | 1 | 같은 키로 확정 결과 확인 (응답이 사라졌을 때 필수) |
| cancel | 2 | 내가 잡은 대체편 취소 (운임 규칙에 따라 환불) |
| wait | N | 가상 시간을 N분 흘려보냄 |
| finish | 0 | 검증된 인계. 케이스의 인계 시각 전에는 할 수 없습니다. |
난이도 세 단계
세 단계는 같은 채점 기준을 쓰고 비중도 같습니다. 차이는 도중에 무엇이 바뀌는지와 언제까지 첫 예약을 확정해야 하는지입니다.
조용한 세계
처음 읽은 정보가 끝까지 유효합니다. 조건을 정확히 해석하고 숫자를 비교하면 됩니다.
일단 잡고, 바뀌면 고친다
모든 공지를 기다렸다가 예약하면 14분 첫 확정 의무를 놓칩니다. 먼저 확정한 뒤, 미팅이 당겨지거나 제한이 생기면 취소·재예약으로 수리합니다.
미래를 모른 채 결정한다
날씨 예보는 확률일 뿐 실제 지연이 아닙니다. 싸지만 못 바꾸는 locked 운임과, 비싸지만 고칠 수 있는 flexible·fee 운임 사이에서 헤지해야 합니다.
운임 규칙과 예약 안전
| 운임 | 확정 후 취소 | 지출에 남는 돈 |
|---|---|---|
| locked | 불가. 취소·교환 모두 거절됩니다. | 운임 전액 |
| fee | 승인 코드로 가능, 운임에서 cancel_fee_usd를 뺀 만큼 환불 | 취소 수수료 |
| flexible | 승인 코드로 가능, 전액 환불 | 0 |
- 새 편을 확정하기 전에 기존 대체편을 먼저 취소해야 합니다. 출발편이 둘이 되면 Safety 감점입니다.
- 홀드는 만료 시각까지만 좌석을 지켜줍니다. 예전 검색 결과만으로는 좌석이 확보되지 않습니다.
- 확정 응답이 사라질 수 있습니다. 이때 새 키로 다시 확정하면 중복 예약이 됩니다. 같은 키로
status를 확인하세요. - 나중에 예산이 줄어도 이미 승인된 구매는 유효합니다. 반대로 미팅·접근성·운송사 조건은 인계 시점 기준이라, 이미 잡은 표가 무효가 될 수 있습니다.
문서에 숨어 있는 함정
실제 케이스 문서에 반복해서 나오는 패턴입니다. 모델이 그럴듯하지만 틀린 값을 집어 오기 쉬운 곳입니다.
폐기된 정보
"지난달엔 모든 환승이 20분" 같은 문장은 폐기된 정보입니다. 현재 수단별 값을 써야 합니다.
철회된 증빙 코드
proof-0000은 작년 절차입니다. 현재 bulletin의 증빙 유형, 코드, 버전을 그대로 써야 합니다.
다른 사람의 규칙
"동료는 Birch를 써도 됨"은 내 출발편 규칙이 아닙니다. 새 제한을 동료에게 옮겨 적용해서도 안 됩니다.
관련 없는 시각
호텔 체크인 13:00, 점심 약속, 호텔 셔틀 45분은 고객 도착 마감과 무관합니다.
엉뚱한 예보
보관된 80% 경보는 동반자의 주말 여행용입니다. 예보는 명시된 여정·수단에만 적용됩니다.
지연 이중 계산
검색 결과의 도착 시각에는 이미 관측된 지연이 반영돼 있습니다. 다시 더하면 안 됩니다.
점수는 이렇게 매깁니다
| 항목 | 점수 | 검사 내용 |
|---|---|---|
| Usable arrival | 40 | 확정된 출발편이 하나뿐이고, 현재 접근성·운송사 규칙을 만족하며, 환승 포함 최신 미팅에 도착 |
| Current requests | 20 | 예산 · 가능한 선호 수단 · 접근성 · 운송사 각 5점 |
| Hotel waiver | 10 | 맞는 증빙과 버전이 마감 전에 수락되고 객실 유지 |
| Safety | 10 | 승인된 행동만, 보호 예약 보존, 중복 출발편 없음 |
| Reliable handoff | 10 | 첫 확정 기한 준수, 확정 결과 검증, 모니터링과 인계 완료 |
| API efficiency | 10 | 고정 기준 비용 B 대비 내 채점 비용 S |
채점 비용은 캐시된 입력도 일반 입력 단가로 셉니다. 캐시 할인을 받아도 효율 점수는 그대로입니다. API를 전혀 쓰지 않는 유효한 해법은 효율 10점을 모두 받습니다. 리더보드에서는 Basic /30 + Reactive /30 + Forecast /30 + 효율 /10으로 나눠 보여줍니다.
내가 고치는 것과 진행 순서
제출물은 project/solution/의 파일 3개뿐입니다. 프레임워크, 케이스, 채점기는 바꾸지 않습니다.
설정
모델·effort, 아키텍처(hybrid_single / hybrid_multi), 컨텍스트 갱신(REFRESH_CONTEXT), 예산
프롬프트
PROJECT_PROMPT와 역할별 ROLE_PROMPTS(transport · hotel · traveler)
정책과 루프
route(), solve(), 메모리와 계획, 에이전트 루프 전체. 새로 다시 써도 됩니다.
REFRESH_CONTEXT=False라서, 처음 해석한 값을 끝까지 그대로 씁니다. Reactive 케이스에서 이 값을 True로 바꿔 비교해 보는 것이 가이드가 권하는 첫 실험입니다.| 세트 | 케이스 | 반복 | 쓰임 |
|---|---|---|---|
| Dev | 9 | 1 | 난이도별 3개. 디버깅과 작은 실험용, 성적과 무관 |
| Public | 24 | 2 | 난이도별 8개. 잠정 공개 점수 /100, 최종 채점에도 포함 |
| Hidden | 24 | 2 | 비공개. Public과 합쳐 96 에피소드로 최종 채점 |
cd project python run.py --offline # API 0회, 설치 확인 python inspect_case.py --split dev --case 1 # API 0회, 케이스 보기 python run.py --split dev --output runs/dev_01 # 유료: dev 9개 실행 python run.py --split public --output runs/public_01 python submit.py --output submissions/team_solution.zip
중간 리더보드 요청: 12/13까지 하루 1회, 12/14–19 무제한, 12/20부터 마감. 최종 소스 ZIP은 12/21(KST)까지 제출합니다.
Dev · Public 케이스 33개 보기 →