로컬 모델로 서브 에이전트와 다중 에이전트를 어떻게 사용하시나요? 몇 개나 돌리시나요?

솔직히 큰 에이전트 세션 8개를 동시에 돌리면 보통 엄청난 혼란과 메모리 문제가 생김.

나한테 훨씬 잘 먹히는 방식은 이거임:

1. 에이전트 8개를 계속 띄워두지 마셈. 에이전트가 작은 작업 하나를 끝내면 디스크에 저장하고 즉시 종료하게 하셈.

2. 작업을 파동(wave) 형태로 실행하셈: 한 번에 독립적인 작업 2~3개를 하고, 코드가 잘 작동하는지 확인한 뒤 다음 단계로 넘어가셈.

3. 모든 것에 제일 큰 모델을 쓰지 마셈. 기본적인 코드 수정에는 작고 빠른 모델을 쓰고, 계획을 세우거나 결과를 확인하는 데 똑똑한 모델을 아껴두셈.

이렇게 하면 장비를 녹이지 않고도 훨씬 깔끔한 결과를 얻을 수 있음.

그렇게 작동하는 게 아님. 세션마다 262k까지 가능하고, 풀은 훨씬 더 커질 수 있음. 난 3090 2개로 800k 정도 돌림.

난 보통 똑똑한 모델(GLM 5.3 같은 거)이 로컬 모델을 위한 구현 계획을 짜게 하고, 계획 안에 병렬화 내용을 직접 넣게 함. 모델들이 오케스트레이션 시점에 서브 에이전트를 관리하기엔 좀 멍청하다는 걸 알게 됐음. 작동한다 해도 토큰이나 컨텍스트 효율이 안 좋음. 내 생각엔 구현 시작 전에 추론을 끝내는 게 오케스트레이터의 사고를 최소화해서 결과물 품질을 높이는 데 더 합리적임. 병렬화된 계획에 파일 소유권 매트릭스를 포함하는 것도 좋아. 그래야 오케스트레이터가 그걸 고민할 필요가 없으니까.

계획을 세울 때 하네스(harness) 기능에 대한 짧은 설명을 포함하는 것도 도움이 됨. 내가 사용하는 하네스(OpenCode)는 서브 에이전트가 원샷 프롬프트만 가능하게 지원하는데, 모델들이 서브 에이전트가 오케스트레이터에게 명확한 설명을 요구할 수 있다고 가정하고 계획을 짜기도 했거든. 지시사항이 혼란을 피할 만큼 명확하지 않아서 모델들이 그 계획을 따르는 데 애를 먹었음.

다른 모델들을 위해서는 여기를 참고하셈: https://unswarm.dev

클라우드 에이전트가 opencode에서 여러 로컬 모델을 오케스트레이션하는 애니메이션과 영상이 몇 개 있음.