AOrchestra 해설: 서브 에이전트를 (Instruction·Context·Tools·Model)로 즉석 생성하는 법 (2026)

에이전트 시스템을 처음 짜면 대부분 이렇게 한다. "코더 에이전트, 검색 에이전트, 리뷰어 에이전트"를 미리 정의한다. 조직도를 그리듯 역할을 고정하는 것이다. 편하다. 그런데 실제 업무는 조직도대로 오지 않는다. "이번엔 PDF 3개 대조해서 표로 뽑아줘" 같은 게 오면, 어느 상설 부서에도 안 맞는다.

AOrchestra(2026)는 이 "상설 부서" 방식을 버린다. 대신 일이 올 때마다 딱 맞는 임시 담당자를 즉석에서 만든다. 그 담당자를 정의하는 공식이 이 논문의 전부다.

원문: arXiv:2602.03786 · 코드: FoundationAgents/AOrchestra

 

한 공식만 기억하면 된다

에이전트 = ⟨지시문, 맥락, 도구, 모델⟩

(Instruction, Context, Tools, Model) 4칸짜리 레시피다. 이 4칸을 어떻게 채우느냐가 곧 "어떤 담당자인가"를 정한다.

• 지시문(Instruction): 이 담당자가 뭘 해야 하는지
• 맥락(Context): 전체 업무 중 이 담당자에게만 넘길 정보
• 도구(Tools): 검색/코드실행/브라우저 중 무엇을 쥐어줄지
• 모델(Model): 어떤 LLM으로 돌릴지 (비싼 것/싼 것)

메인 오케스트레이터는 매 스텝마다 이 4칸을 즉석에서 채워 서브 에이전트를 "스폰"한다. 상설 부서가 아니라 일회용 태스크포스다.

 

기존 두 방식이 왜 부족한가

논문은 서브 에이전트를 다루는 세 방식을 그림으로 비교한다.

방식	장점	단점
(a) 격리된 새 채팅창	컨텍스트 오염 방지	전문화 안 됨. 만능 일꾼을 창만 나눔
(b) 고정 역할 (코더/검색/리뷰어)	전문화됨	경직됨. 새 업무마다 사람이 역할 추가. 커버 안 되는 구멍
(c) AOrchestra: 온디맨드	전문화 + 유연	오케스트레이터 설계 부담

(a)는 유연하지만 멍청하고, (b)는 똑똑하지만 뻣뻣하다. (c)는 지금 이 일에 맞춰 "PDF만 읽는 담당자, 도구는 파일읽기, 모델은 싼 것"처럼 그때그때 만든다.

 

메인이 매 스텝 고르는 3가지

메인 오케스트레이터의 행동 공간은 크게 셋이다.

1. 환경 액션: 자기가 직접 도구를 쓴다
2. 위임(Delegate): 서브 에이전트를 만들어 넘긴다
3. 종료(Finish): 최종 답을 낸다

핵심은 "위임할지 말지도 메인이 판단"한다는 점이다. 모든 걸 무조건 쪼개지 않는다. 이게 비용을 지킨다. 논문의 목표식도 이걸 명시한다. 성공 확률 − λ×비용을 최대화한다. λ를 키우면 시스템이 "덜 쪼개고 싸게" 가는 쪽으로 기운다.

 

워크드 예시: GAIA에서 무슨 일이 일어나나

GAIA는 실세계 복합 과제(멀티홉 검색, 파일 처리, 멀티모달) 벤치다. 메인이 큰 목표를 받으면, 필요한 순간에 "이 URL만 읽고 특정 값 추출하는 서브"를 만들고, 결과만 회수한다. 검색은 Serper, 페이지 읽기는 Jina, 코드 실행은 E2B 샌드박스로 도구가 붙는다.

GAIA 성적 (Gemini-3-Flash를 메인·서브 공용)

• AOrchestra: pass@1 80.00, pass@3 86.06
• OpenHands(최강 베이스라인): pass@1 66.06
• 차이: +13.94점

서브 모델을 더 약한 Claude-4.5-haiku로 낮춰도 GAIA pass@1 60.61을 냈다. 즉 개선이 "제일 센 모델 한 방"에서만 나오는 게 아니라, 구조 자체의 효과라는 근거다. 세 벤치(GAIA/SWE-Bench/Terminal-Bench) 종합으로 최강 베이스라인 대비 상대 16.28% 개선.

 

어떻게 이 능력을 학습시켰나

그냥 프롬프트로만 되는 게 아니다. 논문은 두 갈래로 오케스트레이터를 강화했다.

• SFT: TaskCraft를 씨앗으로 Gemini-3-Flash로 오케스트레이션 궤적 2,000개를 모아 파인튜닝(2 epoch, lr 1e-5).
• 인컨텍스트 최적화: Claude Sonnet 4.5를 "코치"로 써서 오케스트레이터 지시문을 5라운드에 걸쳐 반복 개선.

즉 "언제 쪼개고, 무엇을 넘길지"를 데이터로 가르쳤다. 이게 MoA와의 결정적 차이다. MoA는 학습 없이 프롬프트만으로 답을 합치지만, AOrchestra는 위임 판단 자체를 훈련한다.

 

내일 당장 쓸 인사이트

1. 서브 에이전트를 만들 때 이름(코더)만 짓지 말고 4칸을 명시하라: 지시 / 넘길 맥락 / 허용 도구 / 모델.
2. 메인엔 전체 히스토리, 서브엔 지금 조각에 필요한 것만. 검색 로그를 메인에 쌓지 마라.
3. "위임 안 함"도 선택지로 둬라. 쉬운 스텝은 메인이 직접 처리하는 게 싸다.
4. 비싼 모델은 위임·설계 판단에, 싼 모델은 좁은 실행에.
5. opencodex처럼 모델 피커가 있으면, 서브 후보 5개를 역할별로 깔아두면 AOrchestra식 운영에 근접한다.

 

한계

• 메인의 위임 판단이 틀리면 서브가 통째로 헛돈다. 오케스트레이터 품질이 전부.
• 동적 생성이 많아질수록 로그·감사·재현이 어렵다.
• 벤치는 Serper/Jina/E2B 같은 외부 도구 환경 기준. 사내 도구 연결은 별도 설계 필요.

 

참고: arXiv:2602.03786 · GitHub · 관련: 하네스 효과