다중 에이전트 오케스트레이션 패턴 및 모범 사례

생성 오케스트레이션은 한 에이전트가 다른 에이전트를 호출하는 다중 에이전트 시스템도 지원합니다. 문제를 여러 특수 에이전트로 분리하면 애플리케이션을 보다 모듈화하고 확장 가능하며 관리하기 쉽게 만들 수 있습니다.

인라인 에이전트

인라인 에이전트(자식 에이전트라고도 함)는 동일한 에이전트 내에서 작고 재사용 가능한 워크플로우입니다. 대부분 메인 에이전트가 서브루틴으로 사용하는 주제들입니다. 예를 들어, 메인 에이전트는 더 큰 계획의 한 단계로 "텍스트 번역" 주제를 호출할 수 있습니다. 인라인 에이전트는 메인 에이전트와 컨텍스트를 공유하기 때문에 데이터 주고가 간단합니다.

모범 사례: 인라인 에이전트가 하나의 책임에만 집중하도록 하고 충분히 테스트하세요.

연결된 에이전트

연결된 에이전트는 고유한 오케스트레이션, 도구, 지식을 가진 별도의 에이전트입니다. 주 대리인은 요청의 일부를 소년 대리인에게 위임합니다. 예를 들어 IT 에이전트는 판매 에이전트를 호출하여 가격 책정에 대한 정보를 가져옵니다. 연결된 에이전트는 모듈화 및 도메인 분리를 가능하게 하며 계획 제한을 무시할 수 있습니다. 이들은 서로 다른 권한이나 지식을 가질 수 있으니, 거버넌스와 감사 통제를 적용하세요.

하지만 연결된 에이전트를 사용하려면 신중한 거버넌스가 필요합니다:

  • 조율:: 상위 오케스트레이터는 연결된 에이전트에게 언제 인계할지에 대한 명확한 기준을 가지고 있어야 합니다. 오케스트레이터는 일반적으로 사용자의 의도가 연결된 에이전트의 도메인과 일치할 때 해제됩니다. 이 과정을 돕기 위해, 연결된 에이전트의 목적을 부모 설정에서 명확히 설명하세요. 연결된 전체 에이전트를 부모의 관점에서 설명이 포함된 에이전트 "도구"로 처리합니다.

  • 데이터 핸드오프: 데이터 핸드오프를 관리해야 합니다. 상위에서 연결된 에이전트로 전달할 컨텍스트를 결정합니다. 연결된 에이전트는 대화 기록을 받는지 여부를 제어하는 컨텍스트 포함 설정이 있으므로, 자동으로 전송된다고 가정하지 말고 그 설정을 확인하세요. 반면 자식 에이전트는 항상 부모의 컨텍스트를 받습니다. 특정 매개변수를 통과해야 할 수도 있습니다. 예를 들어, 메인 에이전트가 이미 이전 사용자 이름을 알고 있다면, 다시 묻지 않도록 연결된 에이전트에게 그 이름을 보낼 수 있습니다.

  • 보안: 연결된 에이전트는 부모 에이전트가 접근할 수 없는 것에 접근할 수 있습니다. 연결된 상담원에게 전화하는 것이 제한을 우회하지 않도록 주의하세요. 예를 들어, 부모 에이전트는 레코드를 삭제할 수 없지만 연결된 에이전트는 할 수 있다면, 적절한 승인 없이 삭제가 발생할 수 있는 상황에서 부모 에이전트가 연결된 에이전트에게 전화를 걸어서는 안 됩니다. 연결된 에이전트 통화를 다른 강력한 행동과 동일하게 다루세요. 민감한 작업을 한다면 필요한 점검이나 사용자 동의를 받으세요.

  • 감사 및 모니터링: 연결된 에이전트가 언제 호출되었는지, 그리고 그 에이전트가 무엇을 했는지 기록합니다. 별도의 에이전트라서 별도의 성적 증명서를 작성해야 합니다. 디버깅에서는 부모 세션과 연결된 세션을 연관시키는 것이 중요합니다. 일반적으로 텔레메트리 내 식별자는 두 장치를 연결합니다.

에이전트를 언제 분리해야 할까요

모든 하위 작업마다 별도의 에이전트를 만들지 마세요. 하위 업무가 다음과 같으면 별도의 에이전트를 사용하세요:

  • 자체적으로 다양한 도구나 지식(전문 분야가 다름)이 필요할 만큼 복잡합니다.
  • 메인 에이전트와는 다른 거버넌스 규칙이나 접근 제어가 필요합니다
  • 다양한 주 에이전트에서 재사용할 수 있습니다(서비스 에이전트와 같아서).

이러한 조건이 적용되지 않는 경우 간단한 인라인 에이전트는 전체 연결된 에이전트보다 간단하면서도 작업을 잘 처리할 수 있습니다. 별도의 에이전트는 시스템에 오버헤드를 유발합니다. 컨텍스트 전환 및 여러 에이전트 유지 관리의 복잡성으로 인해 실행 시간이 약간 더 길어집니다. 그러니 신중하게 사용하세요. 실용적인 접근 방식을 위해 하나의 에이전트로 시작합니다. 그런 다음 모듈화가 필요하거나 단일 에이전트가 넘지 말아야 할 경계가 있다고 명확히 판단될 때에만 여러 에이전트로 분리하세요.

다중 에이전트 오케스트레이션에 대한 모범 사례

다음 모범 사례는 다중 에이전트 설정에서 부모 및 스바겐트에 대한 지침을 작성할 때 적용됩니다.

1. 단일 응답 원칙

턴당 하나의 에이전트만 사용자와 대화하는지 확인합니다. 다중 에이전트 설정에서 부모 에이전트는 최종 응답을 제공해야 하는 유일한 에이전트입니다. 서브에이전트는 응답하는 역할이 아니라 연구하는 역할입니다.

  • 할 일: 부모 지침에 추가: "사용자와 통신하는 유일한 에이전트입니다. 모든 자식 에이전트의 결과를 하나의 응답으로 결합하세요.
  • 하지 마세요: 모호하게 두지 마세요. 명시적 지침이 없으면 스바겐트가 사용자에게 직접 회신하여 중복되거나 부분적인 메시지를 발생시킬 수 있습니다.

Note

모든 사용자 통신을 부모 통신을 통해 라우팅하는 것은 하나의 유효한 설계이지 유일한 설계는 아닙니다. 자식이나 연결된 상담원도 의도된 선택일 때 사용자에게 직접 응답할 수 있습니다. 어느 쪽이든 설계 단계에서 방지해야 할 위험은 같습니다. 즉, 하위 에이전트가 이미 처리한 요청에 부모가 응답하는 것입니다. 중복 메시지를 방지하는 서브에이전트 설계에서 두 가지 설계 모두에서 중복 메시지를 방지하는 컨텍스트 계약에 대해 알아보세요.

2. 서브에이전트 지침은 해당 역할을 명시해야 합니다.

항상 서브에이전트에게 자신이 서브에이전트임을 알리세요. 서브에이전트는 기본적으로 자신이 오케스트레이션의 일부라는 사실을 알지 못합니다. 명시적 지침이 없으면 독립 실행형 에이전트로 동작하고 사용자에게 직접 메시지를 보냅니다.

  • 실행: 모든 서브에이전트의 지침에 다음 내용을 추가하세요: "당신은 서브에이전트입니다. 사용자에게 직접 회신하지 마세요. 작업은 정보를 검색하고 결과를 부모 에이전트에 반환하는 것입니다. 부모 에이전트는 사용자와의 모든 통신을 처리합니다."
  • 하지 마세요: 하위 에이전트가 스스로 오케스트레이션 패턴을 파악할 것이라고 가정하지 마세요.

3. 지침에 명확하고 직접적인 언어 사용

항상 지시문 언어를 사용합니다. 부드럽고 예의 바른 관용구를 사용하지 마십시오. 플랫폼은 강력한 언어(MUST, DO NOT, NEVER)를 사용하여 시스템 수준 지침을 삽입합니다. 완곡한 표현("가능하면 ~해 주세요", "~하는 것이 좋습니다" 등)으로 작성된 지침은 서로 충돌할 경우 우선순위가 낮아집니다.

  • 할 일: "사용자에게 직접 회신하지 마십시오. 결과만 반환합니다."
  • 할 일: "사용자 질문당 정확히 하나의 최종 응답이 있어야 합니다."
  • "사용자에게 메시지를 보내지 말고 대신 결과를 반환하십시오."
  • 하지 마십시오: "이상적으로, 우리는 하나의 결합 된 대답을 원한다."

4. 스바겐트당 하나의 기술 자료 사용(겹치지 않음)

각 스바겐트마다 고유하고 오버랩되지 않는 기술 원본을 할당합니다. 두 스바겐트가 동일한 기술 자료를 검색하는 경우 한 스바겐트가 먼저 답을 찾습니다. 두 번째 스바겐트는 중복 결과를 반환하거나 검색을 완전히 건너뛰어 값을 추가하지 않습니다.

  • 할 일: CA-1은 기술 자료 A(예: HR 정책)를 검색합니다. CA-2는 지식 원본 B(예: IT 설명서)를 검색합니다.
  • 금지: 두 하위 에이전트에 동일한 문서, Dataverse 테이블 또는 SharePoint 사이트에 대한 액세스 권한을 부여하지 마세요.
  • 참고: 하나의 기술 자료만 있는 경우 두 개의 스바젠트로 분할하는 대신 지식이 있는 단일 에이전트를 사용합니다. 다중 에이전트는 원본이 진정으로 다른 경우에만 값을 추가합니다.

5. 하위 에이전트에 대해 정확하고 서로 구분되는 설명을 사용하세요

부모에 표시되는 각 스바겐트에 대해 명확하고 고유한 설명을 작성합니다. 부모 에이전트는 스바겐트 설명을 사용하여 라우팅을 결정합니다. 설명이 모호하거나 동일하거나 부정확한 경우 부모는 적절한 라우팅 결정을 내릴 수 없습니다.

  • 할 일: CA-1: "HR 정책 문서에서 직원 관련 질문을 검색합니다." CA-2: "기술 지원 질문에 대한 IT 기술 자료를 검색합니다."
  • 사용하지 마세요. 두 에이전트가 서로 다른 도메인을 제공할 때 동일한 설명을 제공합니다.
  • 사용하지 마세요. "이 에이전트는 질문에 도움이 될 수 있습니다."와 같은 일반적인 설명을 사용합니다.

6. 부모 지침은 오케스트레이션 패턴을 정의해야 합니다.

부모 에이전트에 오케스트레이션 방법을 알려줍니다. "자식 에이전트 사용"이라고 말하지 마십시오. 부모는 패턴에 대한 명시적 지침이 필요합니다. 에이전트 호출, 결과 대기, 결합, 응답.

  • 할 일: "사용자가 질문을 할 때: 1. 두 자식 에이전트를 호출하여 정보를 수집합니다. 2. 두 하위 에이전트가 결과를 반환할 때까지 기다립니다. 3. 결과를 단일 통합 응답으로 결합합니다. 4. 사용자에게 정확히 하나의 응답을 전달합니다. 하위 에이전트는 사용자에게 직접 회신해서는 안 됩니다."
  • 하지 마세요: "사용자가 질문하면 하위 에이전트를 호출하고, 두 소스의 응답을 받아 하나로 통합된 답변을 제공하세요." (너무 모호합니다. 이 지침은 하위 에이전트에게 침묵을 유지하라고 지시하지 않습니다.)

7. 작업 위임에 "직접 회신 없음" 지시문을 포함합니다.

명확한 서브에이전트 지침이 있더라도 위임된 작업에 추가로 강조해 두면 안전장치 역할을 합니다.

  • 실행: 부모 지침에 다음 내용을 추가: "하위 에이전트에 작업을 위임할 때, 항상 작업에 다음 내용을 포함: '결과만 반환하라. 사용자에게 회신하지 마세요.'"
  • 하지 마세요: 하위 에이전트 자체의 지침에만 전적으로 의존하지 마세요. 작업 컨텍스트는 하위 에이전트에 패턴을 강화하는 데 도움이 되는 더 많은 신호를 제공합니다.

8. 도메인 불일치 쿼리로 테스트

항상 스바겐트의 도메인과 일치하지 않는 질문으로 테스트합니다. 이 테스트는 하위 에이전트가 "정보를 찾을 수 없음"이라고 적절히 반환하는지, 아니면 잘못된 정보일 수 있는 내용을 반환하거나, 멈추거나, 혼란스러운 메시지를 보내는지를 드러냅니다.

  • Do: 모든 스바겐트 도메인 외부의 쿼리를 사용하여 테스트합니다(예: 에이전트가 HR 및 IT를 처리할 때 날씨에 대해 질문).
  • 할 일: 상위가 "두 에이전트 모두 아무것도 찾을 수 없음"을 정상적으로 처리하는지 확인합니다.
  • 사용하지 마세요. 하나의 스바겐트의 도메인과 완벽하게 일치하는 가장 간단한 사례 쿼리로만 테스트합니다.

9. 후속 응답이 예상될 때는 알리는 것보다 묻는 것을 선호하세요.

사용자가 응답할 것으로 예상할 때 질문/질문 스타일 상호 작용을 사용합니다. 최종 단방향 메시지에만 inform/send-style을 사용합니다. 에이전트가 단방향 메시지(알림)를 사용하여 사용자에게 무언가를 요청하는 경우 사용자의 회신은 새로운 쿼리로 부모 플래너로 돌아갑니다. 이 경우에는 서브에이전트와 같은 대화를 계속 이어가는 것이 좋습니다.

  • 할 일: "설명이 필요한 경우 사용자에게 질문을 하고 응답을 기다립니다."와 같은 지침을 작성합니다.
  • 사용하지 마세요. "사용자에게 옵션에 대해 알리고 선택하도록 하세요."와 같은 지침을 작성합니다. "Inform"은 단방향 메시지를 알리는 반면 "ask"는 양방향 교환을 신호합니다.

빠른 참조 검사 목록

# 수표
1 상위 지침에는 "사용자에게 응답하는 것은 오직 나뿐이다"라고 명시적으로 밝히고 있습니다.
2 모든 스바겐트 명령은 "사용자에게 직접 회신하지 마십시오"라고 말합니다.
3 지침에서는 강한 지시적 표현(MUST, NEVER, ONLY)을 사용합니다.
4 각 하위 에이전트에는 고유하고 서로 겹치지 않는 지식 소스가 있습니다.
5 하위 에이전트 설명은 정확하고 서로 구별되며 구체적입니다.
6 상위 지침은 전체 오케스트레이션 패턴(호출 → 대기 → 결합 → 응답)을 정의합니다.
7 위임된 작업 컨텍스트에서 상위가 "직접 회신 없음"을 전달합니다
8 도메인 불일치 쿼리로 테스트
9 질문과 정보 구분이 구용 지침에서 정확하다는 것을 알 수 있습니다.
  • Last updated on