멀티 에이전트 시스템을 너무 남용하고 있는 것 아닐까

맞음, 이게 에이전트를 분리해야 하는 가장 강력한 근거라고 봄. 모든 작업에 다른 '역할'이 필요해서가 아니라, 결국 하나의 컨텍스트가 도구, 기술, 지시사항으로 과부하가 걸리기 때문임. 아마 더 나은 규칙은 컨텍스트나 도구 복잡성이 병목 현상이 될 때까지는 에이전트 하나를 유지하다가, 그 부분만 분리하는 것일지도.

가장 큰 실패 모드 중 하나가 다른 에이전트를 판단하거나 감독하기 위해 에이전트를 사용하는 거임.

만약 무언가가 실제로 통제, 경계, 승인 조건, 혹은 안전 점검이라면 가능한 한 결정론적이어야 하고, 거의 항상 그렇게 할 수 있음.

에이전트는 모호함을 추론하는 데는 좋지만, 다른 확률적 시스템이 제대로 작동했는지에 대한 최종 권한을 부여하기에는 최악의 장소임.

멀티 에이전트는 병렬 작업이나 완전히 다른 컨텍스트...

실제로도 똑같은 걸 느꼈음. 대부분의 워크플로우는 좋은 도구, 깔끔한 상태, 강력한 가드레일을 갖춘 에이전트 하나를 먼저 최적화할 때 더 신뢰할 수 있게 됨. 나는 전문화나 병렬 작업이 확실하게 측정 가능한 이점을 줄 때만 여러 에이전트로 분리할 것 같음.

비평가 에이전트(critic agents) 쓰다가 똑같은 경험을 했음. 데모에서는 유용해 보이는데, 실제로는 비평가의 기준이 실제 작업과 달라지면서 잘 작동하는 결과물까지 거부하기 시작함. 나한테는 에이전트 하나에 측정 가능한 모든 것에 대한 결정론적 검사를 붙이는 방식이 훨씬 더 잘 먹혔음.

동의함. 나는 결정론적 워크플로우와 에이전트를 결합하는 방식을 지지함. 워크플로우는 상태와 지속성(충돌 후에도)을 제공하고, 에이전트는 유연성과 언어 이해력을 제공함. 괜찮은 워크플로우 엔진은 보상 조치와 버전 관리도 제공해서, 프로덕션에 들어간 후에도 안전하게 업그레이드할 수 있음. 나는 이걸 위해 Dapr Workflow를 선호하지만, 코드 기반이든 선언적이든 다른 것들도 많음.

멀티 에이전트는 독립성이 방법론의 일부일 때 제값을 함: 별도의 권한 경계, 완전히 다른 도구 접근 권한, 병렬적인 증거 수집, 혹은 생성자가 변경할 수 없는 미지의 테스트 세트를 보는 평가자 같은 경우임. 모든 에이전트가 같은 컨텍스트를 공유하고 같은 목표를 최적화한다면, 추가적인 역할들은 대부분 상태, 지연 시간, 그리고 실패 원인 파악만 더 어렵게 만들 뿐임.

우리가 그냥 제대로 못 하고 있는 거임. 효과적인 오케스트레이션은 각 계층에 완벽한 재료의 조합이 구워져야 함. 모델의 용량과 학습 데이터가 증가함에 따라(눈 감고도 이걸 네이티브로 처리하는 Sol 5.6 Ultra, Grok 4.6 (xhigh) 참조) 이 문제는 천천히 하지만 확실하게 해결되고 있고, 시간이 지날수록 이런 시스템은 점점 더 흔해지고 효과적이 될 거임.

코딩 분야에서 단일 에이전트에서 일회성 목표를 가진 다양한 사용 사례를 위한 에이전트 스웜으로 진화한 것만 봐도 알 수 있음. 시간이 지나면...

나를 다시 단일 에이전트로 돌아가게 만든 건 디버깅이었음. 감독관 + 비평가 설정에서는 결과가 잘못됐을 때 계획이 나빴던 건지, 작업자가 계획을 무시한 건지, 아니면 비평가가 괜찮은 답변을 더 나쁘게 고쳐 쓴 건지 알 수가 없었음. 용의자는 셋인데 말이 되는 추적 기록이 없었음.

나한테 실제로 제값을 한 유일한 분할은 실제 경계와 일치할 때였음: 한 에이전트는 레포에 쓰기 권한이 있고, 다른 에이전트는 읽기 권한과 테스트 결과만 볼 수 있고 코드는 건드릴 수 없게 한 거임. 그건 조직도가 아님...

역할극과 상관없이 두 번째 에이전트가 제값을 하는 기계적인 경우가 하나 있음: 컨텍스트 격리임. 검색 서브 에이전트가 파일과 도구 출력을 읽느라 100k 토큰을 태우고, 500 토큰짜리 결론만 반환하면 부모의 컨텍스트는 깨끗하게 유지됨. 그건 연구원/비평가/작성자 조직도와는 별개의 문제고, 최종 결정을 내리는 창에 쓰레기가 들어오지 않게 하는 것에 관한 거임. 만약 분할이 컨텍스트, 권한, 도구를 격리하지 않는다면, 보통은 그냥 같은 모델이 자기 자신과 대화하는 것뿐임.