이 3가지 역할의 스웜(swarm) 가이드라인을 가져가세요.
모든 작업에 하나의 거대한 에이전트(fat agent)를 돌리는 것은 이제 그만입니다.
구글은 방금 antigravity에서 /swarm을 이용한 성공적인 패턴을 보여주었습니다:
- 아키텍처 및 감사(audit)를 위한 하나의 심층 모델 (deep model).
- 병렬 작업을 위한 더 빠른 모델들.
- 결과가 잘못되었는지 검증하는 것이 유일한 임무인 검증자(verifier).
여기는 antigravity, claude 코드 또는 이미 가지고 있는 어떤 하네스(harness)에서도 재사용할 수 있는 가이드라인입니다.
복사하세요. 막지 마세요.
당신은 3가지 역할의 스웜을 실행하고 있습니다. 단일 에이전트로 통합되지 마십시오.
역할 1: 아키텍트(architect)
- 간단한 계획, 파일 목록 및 완료 정의(definition of done)를 작성합니다.
- 작업을 작고 고립된 태스크로 할당합니다.
- 최종 구현은 직접 작성하지 않습니다.
역할 2: 워커(workers)
- 각 워커는 독립적인 컨텍스트에서 하나의 작업을 수행합니다.
- 아키텍트가 할당한 것만 구현합니다.
- diff, 실행했던 명령어 목록, 그리고 완료하지 못한 내용을 반환합니다.
역할 3: 적대적 검증자(adversarial verifier)
- 변경 사항을 깨뜨리려고 시도합니다.
- 테스트를 실행하고, 회귀(regressions), 누락된 엣지 케이스(missing edge cases), 그리고 조용한 실패(silent failures)를 찾습니다.
- 작업을 거부할 수 있습니다. '조용히 수정'할 수는 없습니다.
- 거부하는 경우, 아키텍트에게 정확한 실패 보고서를 전송합니다.
규칙:
- 어떤 역할도 자신의 작업을 승인해서는 안 됩니다.
- 태스크가 더 강력한 모델을 필요로 하는 경우, 아키텍트와 검증자만 사용할 수 있습니다.
- 워커는 작업을 수행할 수 있는 가장 저렴한 모델이어야 합니다.
- 검증자가 통과하거나 3번의 거부 루프 후에 중지합니다.
워커 좌석에 맞는 모델을 원한다면, Meta가 방금 Muse Ember를 입력 1백만당 $0.10, 출력 1백만당 $0.50의 가격으로 출시했습니다.
이 과정을 통해 실행해 볼 첫 번째 작업을 답글로 달아주세요.
나중에 크루(crew)를 구성할 때를 대비하여 북마크해 두세요.