솔직히 말해서, 대부분의 '멀티 에이전트 시스템'은 그냥 트렌치코트 입은 에이전트 하나일 뿐임

"오케스트레이션 의상을 입은 컨텍스트 문제"라는 표현이 내 '트렌치 코트' 비유보다 낫네 ㅋㅋ 맞아, 핸드오프를 정보 가져오기용으로 쓰는 것도 사실이지. '두 번째 에이전트'가 첫 번째 에이전트가 이미 가졌어야 할 정보를 가져오는 경우를 봤는데, 위임인 척하지만 사실은 나쁜 컨텍스트를 땜질하는 거잖아. 고립된 컨텍스트와 병렬 실행이 진짜 기준이라는 걸 다시 상기시켜주네. "모델이 헷갈려 하니까 다른 이름 붙인 버전한테 물어보자"가 아니라 말이야.

이건 모델마다 강점이나 능력이 다르다는 현실을 간과하는 거임. 전체적인 의견에는 동의하지만, 그걸 단순히 오케스트레이션 문제로 퉁치지는 말자.

그게 다중 에이전트가 진짜 필요한지 확인하는 최고의 테스트일 듯. 프롬프트랑 직함만 바꾼 거라면, 결국 다 똑같은 뇌를 가진 놈들이 서류만 서로 토스하는 작은 회사 하나 만든 거나 다름없지.

그래 친구, 우리 생각이 똑같네. 그래도 여기서 받은 제안들을 좀 반영해서 어떻게든 개선해 보려고 노력할게!

맞는 말임. 하지만 '에이전트'라는 개념 자체는 매우 유용함.
'마이크로 서비스'가 사실은 따로 배포하고 확장하는 API 접근 가능 메서드일 뿐인 것과 같음.
그리고 사람들(특히 영업직)은 항상 버즈워드에 환장하기 마련이지.
참고로, 에이전트를 사용해서 자동화를 몇 개 만들어봤는데, 범용 에이전트를 돌려보면 꽤 모호하고 방대한 목표도 몇 시간씩 작업해서 해결해내는 게 참 신기함. 클라우드에 배포된 자동화는...

마이크로서비스 비교는 타당한 지적이야. 유용한 개념인데, 의미가 변질될 정도로 버즈워드화되는 게 문제지. 범용 에이전트 대 특화 에이전트 문제는 너만 느끼는 게 아냐. 범용 에이전트는 탐색하고, 되돌아가고, 다른 각도로 시도할 여지가 있거든. 특화 에이전트는 여유가 없어서, 초반에 잘못된 가정 하나만 해도 대안 없이 꽉 막혀버리지.

내가 보고 싶은 비교는, 동일한 총 토큰 예산과 두 번째 패스(second pass)를 준 단일 에이전트와, 전체 팀을 비교하는 거임. 안 그러면 핸드오프가 도움이 된 건지, 아니면 그냥 시도 횟수를 늘리는 데 돈을 쓴 건지 알기 어려움. 만약 팀이 이긴다면, 뭔가 성능이 떨어질 때까지 역할을 하나씩 제거해 보셈. 가상의 동료들이 자기 월급값을 하게 만들어야지 ㅋㅋ

토큰 예산 제어는 진짜 좋은 지적이다. 그냥 더 많은 시도를 하려고 돈을 쓴 건데 '팀' 덕분이라고 치부하기 쉽지 ㅋㅋ "뭔가 고장 날 때까지 역할을 제거해라"는 소유권 테스트는 경험적인 방식이라 마음에 드네. 동료들도 어떻게든 자기 몫은 해야지 ㅋㅋ