Gauntlet Loop
Claude of Duty의 방법론을 에이전트가 검사할 수 있는 모든 작업에 일반화한 것입니다. 하나의 프롬프트로 약 55,000줄의 플레이 가능한 AAA 스타일 슈팅 게임이 만들어졌으며, 인간의 개입은 전혀 없었습니다. 차별화 요소는 모델이 아니라 루프였습니다.
핵심 사이클:
분할 → 구축 → 외부 기준에 대한 판단 → 반복
Matt Shumer의 방법론입니다. references/origin.md를 참조하세요.
실행 계약
이 프로토콜은 당신(에이전트)이 실행합니다. 사용자는 실행하지 않습니다.
이 스킬이 발동되면, 프롬프트, 승인을 위한 계획, 또는 Gauntlet Loop의 설명을 사용자에게 다시 전달하지 마십시오. 기준을 설정하고, 목표를 분해하고, 빌더와 비평가를 생성하고, 라운드를 실행하고, 완성된 결과물을 전달하십시오.
사용자는 목표를 한 번 제시했습니다. 그 이후의 모든 것은 당신의 책임입니다.
- 명확화 질문을 하지 마십시오. 모든 미지의 사항은 당신이 결정하고 최종 요약에 기록합니다.
- 직접 기준을 선택하십시오. 한 문장으로 명시한 후 진행하십시오. 어떤 참조를 사용할지 묻지 마십시오.
- 직접 모델을 라우팅하십시오. 하네스가 제공하는 모델과 추론 노력을 각 생성된 에이전트에 할당하십시오. 어떤 모델을 사용할지 사용자에게 묻지 말고, 모든 것을 세션 기본값에 맡기지 마십시오.
- 중간 보고를 하지 마십시오. 진행 상황은 대화가 아닌 실시간 진행 파일에 기록됩니다.
- 다음 경우에만 중단하십시오: 차단된 자격 증명, 누락된 유료 리소스, 또는 해를 끼칠 수 있는 지시.
사용자가 명시적으로 체크포인트에서 상담을 요청하면 이를 존중하십시오. 그런 신호가 없으면 완료될 때까지 실행하십시오.
적용 조건
세 가지 조건:
- 요청이 질문에 답하는 것이 아니라 무언가를 만들거나 개선하는 것입니다.
- 출력물을 객관적으로 검사할 수 있어야 합니다: 렌더링, 실행, 열기, 측정, 테스트, 읽기.
- 한 라운드 이상을 감당할 수 있어야 합니다.
조회, 한 줄 수정, 설명에는 사용하지 마십시오. 실제 컴퓨팅 비용이 발생하며, 속도보다 품질이 중요할 때만 효과적입니다.
실행 가이드
1. 하네스 감지
references/harness-setup.md를 읽고 다른 모든 작업보다 먼저 연결 방식을 선택하십시오. 이에 따라 비평가가 병렬 하위 에이전트, 별도 세션 또는 하드 분리된 패스에서 제공되는지가 결정됩니다. 이 단계를 알리지 말고 적응하기만 하십시오.
이 단계에서 이 하네스가 노출하는 모델과 추론 노력 설정을 열거하십시오. 목록화하지 않은 것은 라우팅할 수 없습니다.
2. 예산 및 라우팅 테이블 설정
루프는 호출을 배가시킵니다. 라우팅되지 않으면 모든 호출이 세션의 모델과 노력을 상속받으며, 기계적인 편집의 팬아웃이 이득 없이 최대 추론으로 프론티어 모델에서 실행됩니다.
references/model-routing.md를 읽고 빌드 전에 한 번 결정하십시오:
- 계층. 사용 가능한 모델을 T0(명령어, 모델 없음), T1(작고 빠름), T2(중간), T3(높은 노력의 프론티어)에 매핑하십시오.
- 테이블. 각 역할에 어떤 계층을 할당할지: 리드 및 모든 판단 호출은 T3, 표준 빌드는 T2, 기계적 편집 및 기록 관리는 T1, 명령어로 확인할 수 있는 모든 것은 T0.
- 예산. 사용자가 제공한 예산이 있으면 존중하고, 그렇지 않으면 설정하십시오. 예산의 약 1/4은 비평가를 위해 비축하십시오.
두 가지 규칙이 절약보다 우선합니다. 판단은 가장 저렴한 계층으로 라우팅되지 않습니다. 약한 비평가는 조기에 승인하여 방법을 무효화하기 때문입니다. 그리고 취향이나 참신함에 관한 작업은 높은 계층에서 시작합니다. 저렴한 빌더가 4라운드를 잃는 것은 비싼 빌더가 한 번에 이기는 것보다 비용이 더 많이 들기 때문입니다.
테이블을 진행 파일에 기록하십시오. 발표하지 말고 사용자에게 승인을 요청하지 마십시오.
3. 기준 설정
기준은 실행의 성공 여부를 결정합니다. 기준이 아닌 것: "놀랍게 만들기", "프로덕션 품질", "모범 사례 따르기". 기준은 출력물과 비교하여 패배할 수 있는 실제 외부 아티팩트 또는 측정값입니다.
references/quality-bars.md를 사용하여 하나를 선택하십시오. 이 문서는 시각 작업, 프론트엔드, 제품 UI, 백엔드, 모바일, 글쓰기, 디자인 시스템, 연구, 데이터 및 마케팅을 다룹니다.
규칙:
- 실행 내에서 검사 가능해야 합니다. 작업 공간에 저장된 스크린샷, 열 수 있는 URL, 실행되는 테스트 모음, 읽을 수 있는 파일. 훈련 데이터에서 기억된 기준이 아닙니다.
- 도달 가능할 필요는 없습니다. Claude of Duty는 Call of Duty를 이기지 못했습니다. 기준은 실행이 "AI에게는 괜찮은" 수준에서 멈추는 것을 방지하기 위해 존재합니다.
- 1라운드에 기준을 통과했다면 기준이 너무 낮았던 것입니다. 기준을 높이고 계속하십시오.
기준 아티팩트를 지금, 빌드 전에 가져오거나 생성하여 작업 공간에 저장하여 모든 비평가가 접근할 수 있게 하십시오.
4. 목표를 취하고, 구현을 취하지 마십시오
사전에 자신의 아키텍처를 규정하지 말고, 아티팩트를 보기 전에 고안된 분해를 받아들이지 마십시오. 목적지를 다시 명시하고 형태가 드러나도록 두십시오.
사용자가 스택이나 아키텍처를 고정했다면 그것은 실제 제약 조건입니다. 존중하고 다른 모든 것은 열어 두십시오.
5. 작업 분할
목표를 개별적으로 개선하고 판단할 수 있는 가장 작은 조각으로 나누고, 어떤 조각을 병렬로 실행할지 결정하십시오.
세분성(Granularity)이 핵심입니다. "사이트를 더 좋게 만드세요"는 다루기 어렵습니다. "이 가격 책정 섹션이 참조 가격 책정 섹션을 이기도록 만드세요"는 승리할 때까지 공략할 수 있는 문제입니다. "이 부하에서 p95가 120ms를 이기도록 만드세요"와 "이 문단이 적어도 이 참조 문단만큼 명확하도록 만드세요"도 마찬가지입니다.
6. 동일한 컨텍스트에서 빌드하고 판단하지 마십시오
각 조각에 대해 하나의 빌더와 하나의 별도 비평가를 사용하십시오. 항상 다른 컨텍스트, 결코 동일한 에이전트가 아니어야 합니다.
빌더는 모든 결정을 보았고 왜 그 결정을 내렸는지 기억하므로 결과가 합리적인 이유를 설명하는 데 탁월합니다. 하지만 합리적인 것은 목표가 아닙니다.
assets/delegation-templates.md를 사용하여 지침을 제공하십시오. 비평가는 목표, 기준, 제약 조건 및 실제 아티팩트를 받습니다. 비평가는 빌더의 대본, 빌더의 설명 또는 우리 측이 어느 쪽인지 절대 받지 않습니다.
생성할 때 각 스폰을 라우팅하고 2단계의 테이블을 사용하십시오. 모든 빌더 전에 세 가지 질문을 하십시오: 성공이 명령어로 확인 가능한가(모델 없음, 실행), 대상 상태가 이미 완전히 지정되었는가(가장 작은 모델, 최소 노력), 또는 격차를 줄이는 데 무엇이 좋은지 결정해야 하는가(프론티어). 취향을 판단하는 비평가는 항상 프론티어이고, 숫자를 확인하는 비평가는 먼저 명령어를 실행하고 보고하는 데 작은 모델만 필요합니다.
전체 절차는 references/critic-protocol.md에 있습니다. 필수 사항: 맹목적인 A/B, 실제 제품 검사, 이진 판정, 가장 큰 단일 격차 명명, 다시 보내기.
7. 계속 반복하기
라운드 수를 절대 설정하지 마십시오. 합의된 최종 라운드는 상한선이 됩니다.
다음 중 하나가 참이 되면 중단하고, 어느 것인지 기록하십시오:
- 사용자가 진행 파일에서 완료되었다고 말합니다.
- 라운드당 이득이 목표에 더 이상 중요하지 않게 되었습니다.
- 2단계에서 설정한 예산이 소진되었습니다.
증거가 있을 때만 조각의 계층을 올리십시오: 동일한 격차에 대해 두 번 연속 손실은 노력을 높이고, 세 번째는 모델을 높입니다. 승리하기 시작한 조각은 나머지 실행 동안 다시 낮은 계층으로 내려갑니다. 예산의 80%가 소진되면 이미 승리하고 있는 조각에 라운드를 추가하는 것을 중단하고 나머지를 기준에서 가장 먼 조각에 투입하십시오.
동일한 격차가 세 번 연속 라운드에서 지속되면 해당 조각을 중단하고 리드 수준에서 다시 결정하십시오. 이는 구조적인 문제이거나, 해당 조각에 대한 기준이 잘못되었거나, 빌더와 비평가가 다른 것을 측정하고 있기 때문입니다. 이 시점에서 더 많은 비용을 지출하는 것은 아무것도 얻지 못하고 예산을 소진하는 가장 일반적인 방법입니다.
8. 실시간 진행 파일 유지
작업 공간에 간단한 HTML 페이지 또는 마크다운 파일을 유지하고 작업이 완료됨에 따라 업데이트하십시오: 스크린샷, 초안, 테스트 결과, 라운드별 판정, 미해결 격차. 형식을 과도하게 지정하지 말고, 첫 번째 출력 줄에서 사용자에게 위치를 알리십시오.
이는 사용자가 중단 없이 지켜볼 수 있도록 하기 위해 존재합니다. 중단은 컨텍스트 윈도우를 깨고 루프를 방해합니다.
9. 웨이브 사이의 평활화 패스
여러 에이전트가 하나의 아티팩트의 별도 부분을 편집할 때, 각 부분은 개별적으로 좋아지지만 전체적으로는 일관성이 없어집니다.
각 주요 웨이브가 끝날 때마다 하나의 새로운 에이전트를 생성하여 전체 결과를 검사하고 충돌을 해결하고 하나의 일관된 결과물처럼 느껴지도록 만드십시오. 아무것도 재설계하지 않습니다.
유용하지만 핵심은 아닙니다. 핵심은 그대로입니다: 분할, 구축, 판단, 반복.
실행 종료
결과물을 전달한 후 다음을 포함하는 짧은 요약을 제공하십시오:
- 사용된 기준과 그 이유.
- 기준에 비해 작업이 얼마나 진행되었는지.
- 마지막으로 해결되지 않은 격차. 이는 다음에 이 작업을 이어받는 사람을 위한 인계 사항입니다.
- 묻지 않은 질문 대신 내린 가정.
- 실행을 종료한 중단 조건.
- 비용: 실행된 라운드 수, 예산이 대략 어디에 사용되었는지, 큰 비중을 차지하면서도 진전이 없는 조각.
작업에 대한 칭찬은 하지 마십시오. 비평가의 판정이 이미 중요한 모든 것을 말했습니다.
안티패턴
| 증상 | 해결책 |
|---|---|
| 사용자에게 직접 실행할 프롬프트를 제공함 | 프로토콜을 직접 실행하십시오. 그것이 핵심입니다 |
| 빌더가 "이거 정말 좋아 보여요!"라고 말함 | 깨끗한 컨텍스트와 기록 없이 비평가를 생성하십시오 |
| 비평가가 아티팩트 대신 보고서를 읽음 | 실제 출력물 검사를 강제하십시오 |
| 주관적인 기준 ("세계적 수준", "Apple 수준") | 열 수 있는 구체적인 아티팩트로 대체하십시오 |
| 아티팩트를 보기 전에 분해가 고정됨 | 작업에서 형태가 드러나도록 두십시오 |
| "3회 반복하세요" | 명시적인 중단 조건으로 열린 루프를 사용하십시오 |
| 어떤 참조를 사용할지 물음 | 하나를 선택하고 한 문장으로 정당화한 후 진행하십시오 |
| 대화에서 상태 업데이트 | 실시간 진행 파일을 사용하십시오 |
| 좋은 부분, 일관성 없는 전체 | 웨이브 끝에 평활화 패스를 추가하십시오 |
| 1라운드에 기준 통과 | 기준이 너무 낮았습니다. 높이십시오 |
| 동일한 격차가 세 라운드 동안 지속됨 | 에스컬레이션하십시오. 구조적인 문제입니다 |
| 모든 에이전트가 세션 모델과 노력을 상속받음 | 각 스폰을 라우팅하십시오: 판단에는 프론티어, 기계적 작업에는 작은 모델 |
| 프론티어 모델이 최대 노력으로 변수 이름 변경 | T1에서 최소 노력, 또는 모델 없이 명령어 사용 |
| 라운드를 절약하기 위해 저렴한 비평가 사용 | 규칙 제로. 약한 비평가는 조기에 승인하여 방법을 무효화합니다 |
| 취향에 관한 작업에 저렴한 빌더 사용 | 네 번의 패배 라운드는 한 번의 비싼 승리보다 비용이 더 듭니다 |
| 작업이 어려워 보인다고 계층을 올림 | 반복된 판정에 근거하여 에스컬레이션하고 직감에 근거하지 마십시오 |
| 추가 빌드 라운드에 비평가 예산 사용 | 비축분은 공동 자금이 아닙니다. 판단이 사용합니다 |