Opus4.8's /ultracode agents using Haiku 4.5
Opus 4.8 에이전트가 복잡한 작업 수행 중 Haiku 4.5를 하위 에이전트로 활용하는 현상에 대한 사용자들의 경험 공유.
처음 겪는 일인데, 이전에는 Opus 4.8만 에이전트 작업을 처리했었음. 이게 의도된 설계인지(에이전트를 생성하는 복잡한 작업이라서) 아니면 그냥 트래픽을 처리하는 또 다른 방식인지는 잘 모르겠음.
사용자들은 하위 에이전트 모델 선택의 지능적인 측면을 긍정적으로 평가하면서도, 성능 불안정성과 과도한 토큰 소모에 대해서는 우려를 표하고 있습니다.
좀 별로임. 처음에 xhigh+workflows로 설정했을 때 두 번이나 망쳤고, 구현해야 할 것들을 많이 빼먹었음. 세 번째에 그냥 일반 xhigh 모드로 돌리니까 제대로 되더라.
/goal 설정해봤어? 작업이 안 끝났는데도 다 끝났다고 멈추는 걸 방지하는 데 꽤 괜찮더라고.
나도 마찬가지. 한 번은 작업을 꼬아버려서 에이전트 100개를 생성하더니 각각 글자 하나씩만 처리하게 만들더라. 5시간 세션 중 50%를 날려 먹었음.
이거 새로운 거 아님. 나도 꽤 전부터 알고 있었음.
Haiku는 이번처럼 결과물이 명확하게 정의된 작은 작업에는 충분히 괜찮음.
하위 에이전트는 가끔 쉬운 작업에 더 가벼운 모델을 쓰기도 해. Haiku나 Sonnet을 쓰도록 하위 에이전트를 직접 설계할 수도 있고.
하위 에이전트한테 엄청나게 구체적인 지시를 내리기 때문에 잘 작동하는 거임. Opus가 하위 에이전트로 쓰이는 것도 본 적 있는데, 작업 복잡도에 따라 호출하는 에이전트가 판단하는 듯. 그리고 Haiku가 쓰인 적도 있는데, 호출자(Opus)가 결과물이 복잡하다고 판단하면 Sonnet을 통해 추가 검증을 돌리기도 하더라. 진짜 똑똑함.
내 경험상으로는 괜찮음. 메인 에이전트가 하위 에이전트에서 올라오는 보고서나 결과물을 검증하니까. 근데 워크플로우는 진짜 토큰 먹는 하마임 ㅋㅋ
미국 기업들이 비용 절감과 데이터 보안을 이유로 비싼 프론티어 AI 모델 대신 오픈 소스 모델로 눈을 돌리고 있음.
미국 기업들이 비용 절감과 데이터 보안을 이유로 비싼 프론티어 AI 모델 대신 오픈 소스 모델로 눈을 돌리고 있음.
