응답 분류(triage) 에이전트에 이 기능이 정말 유용하다고 생각합니다. 현재 첫 테스트를 진행 중인데, 결과를 지켜보는 중입니다. 의사결정을 위한 새로운 모델들이 매우 정밀하고 빠르다는 점은 이해하고 있으며, Discourse에서 이를 활용할 수 있게 되어 기쁩니다.
이 모델을 일반 에이전트에도 통합할 계획이 있는지, 또는 기술적으로 가능한지 궁금합니다. 먼저 분류한 후 작업을 위임하는 '시니어 헬퍼(Senior Helpers)'를 개발할 수 있을 것 같습니다. 아니면 그런 방식은 전혀 의미가 없는 걸까요?
아직 이 기능의 진정한 최적 사용 사례를 완전히 이해하지 못했을 수도 있고, 제 질문이 맥락에 맞지 않을 수도 있다고 생각합니다.
우리의 구성을 예로 들어, 제가 상상하는 구조는 다음과 같습니다. 메인 에이전트에는 다섯 개의 서브에이전트가 있습니다:
서브에이전트
선택되는 경우
publicator
회원이 게시 전에 개선할 텍스트를 공유할 때
links
게시글 초안으로 다듬을 느슨한 링크들
web
포럼 외부에서 변화하는 사항들
base
큐레이션된 아카이브: 오래된 토론, 문서, 책
at
회원이 공유한 차트를 우리의 공개 기준에 맞춰 검토할 때
현재 부모 LLM은 서브에이전트의 설명을 읽고 spawn_agent를 통해 하나를 선택합니다. 게이트(Gate)는 이 결정을 LLM으로부터 가져오게 됩니다:
에이전트에 게이트 설정을 추가하여 의사결정 모델(decision model)을 지정합니다.
선택지는 이미 존재하는 서브에이전트 설명들과 "직접 답변하기"입니다. 관리자가 새로 작성해야 할 내용은 없습니다.
현재 사용자가 접근할 수 있는 서브에이전트만 제시됩니다.
신뢰도 임계값 이상이면 해당 서브에이전트가 직접 실행됩니다. 임계값 미만이면 결과가 힌트(hint)로 부모 LLM에게 전달되고, LLM이 현재와 마찬가지로 판단합니다.
의사결정 모델은 이미지를 분류하므로, "회원이 차트를 공유했다"는 정보는 이미지 자체에서 유추됩니다.
동일한 게이트를 예/아니오 질문 형태로 사용하면, LLM 실행 전 가드(Guard) 역할로도 기능할 수 있습니다.
저희는 교육 커뮤니티이며 시그널, 목표 가격 또는 투자 조언을 제공하지 않으므로, “이것은 트레이딩 시그널을 묻는 것인가?” → 고정된 답변으로 처리됩니다. 현재 이 규칙은 모든 프롬프트에 한 줄로 포함되어 있지만, 모델은 압박 상황에서 이로부터 벗어나는 경향이 있습니다.
