저는 지난 몇 달 동안 오케스트레이터 에이전트(다른 에이전트들을 관리하는 에이전트)를 구축하고 운영해 왔습니다. 다음은 유용한 오케스트레이터와 혼란스러운 오케스트레이터를 구분 짓는 네 가지 요소입니다.

1. 미션 문서 (A mission document)
   가장 큰 실수는 오케스트레이터가 모델의 기본 지능(default model intelligence)에만 의존하게 두는 것입니다. 여러분이 일하는 방식처럼 작동하게 만들어야 합니다. 여러분이 내릴 결정을 내리도록 해야 합니다.
   저는 각 오케스트레이터를 위해 "미션 문서"를 작성합니다. 이것은 직무 기술서(job description)와 같습니다: 무엇을 할지, 어떻게 할지, 언제 에스컬레이션(escalate)할지 등을 정의합니다.
   예를 들어, 저는 버그 리포트를 처리하는 오케스트레이터를 가지고 있습니다. 그 미션은 다음과 같습니다:

• 제목에 "customer feedback"이 포함된 이메일 메시지 확인
• 로컬에 티켓(ticket) 생성
• 버그를 재현하고 복합 공학(compound engineering) 또는 다른 플러그인(superpowers, GSD 등)을 사용하여 수정을 구현할 자식 에이전트(child agent) 생성
• QA 준비가 되면 나에게 알림

저는 4단계 전까지는 손대지 않습니다. 최악의 경우 코드가 버려지겠지만, 최선의 경우 많은 시간을 절약해 줍니다.

2. 하트비트 (A heartbeat)
   루프(loop)가 없는 오케스트레이터는 그저 일회성 스크립트일 뿐입니다. 진정한 힘은 리듬(cadence)에 있습니다. 정해진 일정(10분마다, 1시간마다, 혹은 적절한 주기)에 따라 미션 문서를 다시 읽도록 하세요.
   대부분의 에이전트 CLI는 이를 위한 루프(loop) 또는 cron 프리미티브(primitive)를 제공합니다. 매 틱(tick)마다 오케스트레이터는 새로운 작업을 확인하고, 기존 작업의 진행 상황을 모니터링하며, 미션 문서에 명시된 다음 작업에 따라 행동합니다.

3. 에이전트 간 통신 (Inter-agent communication)
   이것은 가장 과소평가된 부분 중 하나입니다. 오케스트레이터는 여러분이 자식 에이전트들에게 로드하지 않은 컨텍스트(context)를 보유하고 있습니다. 오케스트레이터는 자식들의 질문에 답하거나, 그들 사이의 접근 방식을 조정하거나, 한 에이전트가 다른 에이전트의 작업을 검토하는 적대적 리뷰(adversarial reviews)를 실행할 수 있습니다.
   구현 방법은 간단할 수 있습니다: 구조화된 규칙이 담긴 공유 마크다운(markdown) 파일, 메시지 전달(message-passing) 도구, 또는 백채널(backchannel) 시스템 등이 있습니다. 메커니즘 자체보다는 채널이 존재하는지 확인하는 것이 더 중요합니다.

4. 감사 가능한 제어 (Auditable control)
   오케스트레이터가 기록을 생성하도록 구축하세요. 무엇을 결정했는지, 무엇을 생성(spawn)했는지, 자식들이 무엇을 만들어냈는지에 대한 기록 말입니다.

어떤 자식 에이전트(child agent)로든 즉시 뛰어들어 그 작업을 검토하고, 어느 시점에서든 중단할 수 있어야 합니다. 설령 자주 들여다보지 않더라도, 모든 것에 대한 가시성(visibility)을 확보해야 합니다.
당신은 모든 출력물에 대한 책임을 지기 때문에, 모든 단계를 확인할 수 있도록 만드는 것이 그것이 생성한 결과물을 신뢰할 수 있는 유일한 방법입니다.

고지 사항: 이 포스트의 영상은 제가 구축 중인 도구를 보여주지만, 위의 모든 내용은 해당 도구 없이도 적용됩니다. 여러분이 이미 사용 중인 어떤 에이전트 툴링(agent tooling)을 사용하더라도 오케스트레이터(orchestrator)를 구축할 수 있습니다.
submitted by /u/croovies
[link] [comments]