설계자와 개발자가 언어 모델 기능을 최대한 활용하도록 워크로드를 설계함에 따라 AI 에이전트 시스템은 점점 더 복잡해지고 있습니다. 이러한 시스템은 종종 많은 도구 및 지식 원본에 액세스할 수 있는 단일 에이전트의 기능을 초과합니다. 대신 이러한 시스템은 다중 에이전트 오케스트레이션을 사용하여 복잡하고 공동 작업 작업을 안정적으로 처리합니다. 이 가이드에서는 다중 에이전트 아키텍처에 대한 기본 오케스트레이션 패턴을 설명하고 특정 요구 사항에 맞는 접근 방식을 선택하는 데 도움이 됩니다.
개요
여러 AI 에이전트를 사용하는 경우 복잡한 문제를 특수한 작업 단위 또는 지식 단위로 분석할 수 있습니다. 특정 기능이 있는 전용 AI 에이전트에 각 작업을 할당합니다. 이러한 접근 방식은 인적 팀워크에서 찾은 전략을 반영합니다. 여러 에이전트를 사용하면 모놀리식 단일 에이전트 솔루션에 비해 몇 가지 이점이 있습니다.
전문화: 개별 에이전트는 코드 및 프롬프트 복잡성을 줄이는 특정 도메인 또는 기능에 집중할 수 있습니다.
확장성: 전체 시스템을 다시 디자인하지 않고 에이전트를 추가하거나 수정할 수 있습니다.
유지 관리: 테스트 및 디버깅은 개별 에이전트에 중점을 두어 이러한 작업의 복잡성을 줄일 수 있습니다.
최적화: 각 에이전트는 고유한 모델, 작업 해결 방법, 지식, 도구 및 컴퓨팅을 사용하여 결과를 달성할 수 있습니다.
이 가이드의 패턴은 함께 작동하고 결과를 달성하기 위해 여러 에이전트를 오케스트레이션하는 입증된 접근 방식을 보여 줍니다. 각 패턴은 다양한 유형의 조정 요구 사항에 최적화되어 있습니다. 이러한 AI 에이전트 오케스트레이션 패턴은 AI 기반 워크로드 기능에서 자율 구성 요소를 조정하는 고유한 과제를 해결하여 기존 클라우드 디자인 패턴을 보완하고 확장합니다.
순차 오케스트레이션
순차 오케스트레이션 패턴은 미리 정의된 선형 순서로 AI 에이전트를 체인합니다. 각 에이전트는 시퀀스에서 이전 에이전트의 출력을 처리하여 특수화된 변환의 파이프라인을 만듭니다.
순차 오케스트레이션 패턴은 각 단계가 이전 단계에서 빌드되는 단계별 처리가 필요한 문제를 해결합니다. 명확한 종속성이 있는 워크플로에 적합하며 점진적 구체화를 통해 출력 품질을 향상시킵니다. 이 패턴은 파이프 및 필터 클라우드 디자인 패턴과 유사하지만 사용자 지정 코딩된 처리 구성 요소 대신 AI 에이전트를 사용합니다. 다음에 호출되는 에이전트 선택은 워크플로의 일부로 결정적으로 정의되며 프로세스의 에이전트에 제공되는 선택이 아닙니다.
순차 오케스트레이션을 사용하는 경우
다음 시나리오에서 순차적 오케스트레이션 패턴을 고려합니다.
명확한 선형 종속성과 예측 가능한 워크플로 진행이 있는 다단계 프로세스
각 단계가 다음 단계에 따라 달라지는 특정 값을 추가하는 데이터 변환 파이프라인
병렬 처리할 수 없는 워크플로 단계
초안, 검토, 다듬기와 같은 점진적 정교화 요구 사항
파이프라인 내의 모든 AI 에이전트의 가용성과 성능 특성을 이해하고, 하나의 AI 에이전트의 처리에서 발생하는 실패나 지연이 전체 작업의 완료에 미치는 영향을 허용할 수 있는 시스템.
순차 오케스트레이션을 피해야 하는 경우
다음 시나리오에서는 이 패턴을 사용하지 않습니다.
단계는 병렬성이 극단적입니다. 품질을 손상시키거나 공유 상태 경합을 만들지 않고 병렬 처리할 수 있습니다.
단일 AI 에이전트가 효과적으로 수행할 수 있는 몇 단계만 포함하는 프로세스입니다.
초기 단계가 실패하거나 낮은 품질의 출력을 생성할 수 있으며 누적된 오류 출력을 사용하여 이후 단계의 처리를 방지하는 합리적인 방법은 없습니다.
AI 에이전트는 작업을 중단하는 대신 공동 작업해야 합니다.
워크플로에는 역추적 또는 반복이 필요합니다.
중간 결과를 기반으로 하는 동적 라우팅이 필요합니다.
순차 오케스트레이션 예제
법률 회사의 문서 관리 소프트웨어는 계약 생성을 위해 순차 에이전트를 사용합니다. 지능형 애플리케이션은 4개의 특수 에이전트 파이프라인을 통해 요청을 처리합니다. 순차적이고 미리 정의된 파이프라인 단계는 각 에이전트가 이전 단계의 전체 출력과 함께 작동하도록 합니다.
템플릿 선택 에이전트는 계약 유형, 관할권 및 관련 당사자와 같은 클라이언트 사양을 받고 회사의 라이브러리에서 적절한 기본 템플릿을 선택합니다.
조항 맞춤화 에이전트는 선택한 템플릿을 기반으로 협상된 비즈니스 조건에 따라 지불 일정 및 책임 제한을 포함한 표준 조항을 수정합니다.
규정 준수 에이전트는 관련 법률 및 업계별 규정에 대해 사용자 지정된 계약을 검토합니다.
위험 평가 에이전트는 전체 계약에 대한 포괄적인 분석을 수행합니다. 위험 등급 및 보호 언어 권장 사항을 제공하면서 책임 노출 및 분쟁 해결 메커니즘을 평가합니다.
동시 오케스트레이션
동시 오케스트레이션 패턴은 동일한 작업에서 동시에 여러 AI 에이전트를 실행합니다. 이 방법을 사용하면 각 에이전트가 고유한 관점이나 특수화에서 독립적인 분석 또는 처리를 제공할 수 있습니다.
이 패턴은 다양한 인사이트 또는 동일한 문제에 대한 접근 방식이 필요한 시나리오를 해결합니다. 순차적 처리 대신 모든 에이전트가 병렬로 작동하여 전체 런타임을 줄이고 문제 공간을 포괄적으로 검사합니다. 이 오케스트레이션 패턴은 'Fan-out/Fan-in' 클라우드 설계 패턴과 유사합니다. 각 에이전트의 결과는 최종 결과를 반환하기 위해 집계되는 경우가 많지만 필수는 아닙니다. 각 에이전트는 작업을 수행하기 위해 도구를 호출하거나 다른 데이터 저장소를 병렬로 업데이트하는 등 워크로드 내에서 자체 결과를 독립적으로 생성할 수 있습니다.
에이전트는 독립적으로 작동하며 결과를 서로 전달하지 않습니다. 에이전트는 자체 오케스트레이션 접근 방식을 독립적인 처리의 일부로 사용하여 추가 AI 에이전트를 호출할 수 있습니다. 사용 가능한 에이전트는 처리에 사용할 수 있는 에이전트를 알고 있어야 합니다. 이 패턴은 등록된 모든 에이전트에 대한 결정적 호출과 작업 요구 사항에 따라 호출할 에이전트의 동적 선택을 모두 지원합니다.
동시 오케스트레이션을 사용하는 경우
다음 시나리오에서 동시 오케스트레이션 패턴을 고려합니다.
고정된 에이전트 집합을 사용하거나 특정 작업 요구 사항에 따라 AI 에이전트를 동적으로 선택하여 병렬로 실행할 수 있는 작업입니다.
여러 독립적인 관점이나 기술, 비즈니스 및 창의적인 접근 방식과 같은 다양한 전문화의 이점을 활용하는 작업으로, 모두 동일한 문제에 기여할 수 있습니다. 이 협업은 일반적으로 다음과 같은 다중 에이전트 의사 결정 기술을 특징으로 하는 시나리오에서 발생합니다.
브레인스토밍
앙상블 추론
쿼럼 및 투표 기반 결정
병렬 처리가 대기 시간을 줄이는 시간에 민감한 시나리오입니다.
동시 오케스트레이션을 피해야 하는 경우
다음 시나리오에서는 이 오케스트레이션 패턴을 사용하지 않습니다.
에이전트는 서로의 작업을 기반으로 빌드하거나 특정 시퀀스에서 누적 컨텍스트를 필요로 합니다.
작업에는 정의된 시퀀스에서 실행된 특정 작업 순서 또는 결정적이고 재현 가능한 결과가 필요합니다.
모델 할당량과 같은 리소스 제약 조건은 병렬 처리를 비효율적이거나 불가능하게 만듭니다.
에이전트는 동시에 실행되는 동안 공유 상태 또는 외부 시스템에 대한 변경 내용을 안정적으로 조정할 수 없습니다.
각 에이전트의 모순되거나 충돌하는 결과를 처리하기 위한 명확한 충돌 해결 전략은 없습니다.
결과 집계 논리가 너무 복잡하거나 결과의 품질을 낮춥니다.
동시 오케스트레이션 예제
금융 서비스 회사는 다양한 유형의 분석을 전문으로 하는 동시 에이전트를 사용하여 동일한 주식을 동시에 평가하는 지능형 애플리케이션을 구축했습니다. 각 에이전트는 신속한 투자 결정을 위한 다양하고 시간에 민감한 입력을 제공하는 특수한 관점에서 인사이트를 제공합니다.
시스템은 병렬로 실행되는 4개의 특수 에이전트에 동일한 시세 기호를 디스패치하여 주식 분석 요청을 처리합니다.
기본 분석 에이전트는 재무제표, 수익 추세 및 경쟁력 있는 위치를 평가하여 본질적인 가치를 평가합니다.
기술 분석 에이전트는 가격 패턴, 볼륨 지표 및 모멘텀 신호를 검사하여 거래 기회를 식별합니다.
감정 분석 에이전트는 뉴스 기사, 소셜 미디어 멘션 및 애널리스트 보고서를 처리하여 시장 감정과 투자자의 신뢰를 측정합니다.
ESG(환경, 사회 및 거버넌스) 에이전트는 환경 영향, 사회적 책임 및 거버넌스 사례 보고서를 검토하여 지속 가능성 위험 및 기회를 평가합니다.
그런 다음, 이러한 독립적인 결과를 포괄적인 투자 권장 사항으로 결합하여 포트폴리오 관리자가 정보에 입각한 결정을 신속하게 내릴 수 있도록 합니다.
그룹 채팅 조정
그룹 채팅 오케스트레이션 패턴을 사용하면 여러 에이전트가 토론을 통해 공동 작업하는 공유 대화 스레드에 참여하여 문제를 해결하거나, 결정을 내리거나, 작업의 유효성을 검사할 수 있습니다. 채팅 관리자는 다음에 응답할 수 있는 에이전트를 결정하고 협업 브레인스토밍에서 구조적 품질 게이트에 이르기까지 다양한 상호 작용 모드를 관리하여 흐름을 조정합니다.
이 패턴은 의사 결정에 도달하기 위해 그룹 토론을 통해 가장 잘 수행되는 시나리오를 해결합니다. 이러한 시나리오에는 공동 작업 아이디어, 구조적 유효성 검사 또는 품질 관리 프로세스가 포함될 수 있습니다. 이 패턴은 자유로운 브레인스토밍에서 고정 역할 및 승인 게이트가 있는 공식 검토 워크플로에 이르기까지 다양한 상호 작용 모드를 지원합니다.
이 패턴은 사용자가 필요에 따라 동적 채팅 관리자 책임을 맡아 생산성을 높이는 대화를 안내할 수 있는 휴먼 인더 루프 시나리오에 적합합니다. 이 오케스트레이션 패턴에서 에이전트는 일반적으로 읽기 전용 모드입니다. 실행 중인 시스템을 변경하는 데 도구를 사용하지 않습니다.
그룹 채팅 오케스트레이션을 사용하는 경우
해결하고자 하는 시나리오를 자발적인 공동 작업이나 반복적인 검사자-확인자 루프를 통해 해결할 수 있는 경우에는 그룹 채팅 조정을 고려하십시오. 이러한 모든 접근 방식은 실시간 인간의 감독 또는 참여를 지원합니다. 루프의 모든 에이전트와 인간은 출력을 단일 누적 스레드로 내보내므로 이 패턴은 투명성과 감사 가능성을 제공합니다.
공동 작업 시나리오
서로 다른 관점과 지식 소스를 가진 에이전트가 채팅에 대한 서로의 기여를 기반으로 하는 창의적인 브레인스토밍 세션
토론과 합의 구축을 통해 이익을 얻는 의사 결정 프로세스
토론을 통해 반복적인 구체화가 필요한 의사 결정 시나리오
기능 간 대화가 필요한 다학제 문제
유효성 검사 및 품질 관리 시나리오
구조적 검토 프로세스 및 반복을 포함하는 품질 보증 요구 사항
여러 전문가의 관점이 필요한 규정 준수 및 규정 유효성 검사
만들기와 유효성 검사 간의 문제를 명확하게 구분하여 편집 검토가 필요한 콘텐츠 만들기 워크플로
그룹 채팅 오케스트레이션을 피해야 하는 경우
다음 시나리오에서는 이 패턴을 사용하지 않습니다.
간단한 작업 위임 또는 선형 파이프라인 처리로 충분합니다.
실시간 처리 요구 사항은 토론 오버헤드를 용인할 수 없습니다.
토론 없이 명확한 계층적 의사 결정 또는 결정적 워크플로가 더 적합합니다.
채팅 관리자는 작업이 완료되었는지 여부를 결정하는 객관적인 방법이 없습니다.
대화 흐름을 관리하고 무한 루프를 방지하려면 특히 더 많은 에이전트가 제어를 유지 관리하기가 더 어려워짐에 따라 주의해야 합니다. 효과적인 제어를 유지하려면 그룹 채팅 오케스트레이션을 3개 이하의 에이전트로 제한하는 것이 좋습니다.
메이커-체커 반복
maker-checker 루프는 작성자라는 하나의 에이전트가 무언가를 생성하거나 제안하는 특정 유형의 그룹 채팅 오케스트레이션입니다. 또 다른 에이전트인 검사기는 결과에 대한 비판을 제공합니다. 이 패턴은 반복적이며, 검사기 에이전트가 대화를 다시 작성자 에이전트로 푸시하여 업데이트를 수행하고 프로세스를 반복합니다. 그룹 채팅 패턴에서 에이전트가 번갈아 채팅을 할 필요는 없지만 Maker-checker 루프에는 채팅 관리자가 구동하는 공식적인 턴 기반 시퀀스가 필요합니다.
그룹 채팅 조정 예제
도시 공원 및 레크리에이션 부서는 그룹 채팅 오케스트레이션을 포함하는 소프트웨어를 사용하여 새로운 공원 개발 제안을 평가합니다. 소프트웨어는 초안 제안을 읽고, 여러 전문 에이전트는 다른 지역 사회 영향 관점을 토론하고 제안에 대한 합의를 향해 노력. 이 프로세스는 받을 수 있는 피드백을 예상하는 데 도움이 되는 커뮤니티 검토를 위해 제안이 열리기 전에 발생합니다.
이 시스템은 여러 시민 관점에서 작업에 참여하는 전문 시 대리인과 그룹 협의를 시작하여 공원 개발 제안을 처리합니다.
커뮤니티 참여 에이전트는 접근성 요구 사항, 예상 거주자 피드백 및 사용 패턴을 평가하여 공평한 커뮤니티 액세스를 보장합니다.
환경 계획 에이전트는 생태 영향, 지속 가능성 조치, 네이티브 식물 변위 및 환경 규정 준수를 평가합니다.
예산 및 운영 에이전트는 건설 비용, 지속적인 유지 관리 비용, 인력 요구 사항 및 장기 운영 지속 가능성을 분석합니다.
채팅 관리자는 에이전트가 서로의 권장 사항에 이의를 제기하여 추론을 방어하는 구조적 토론을 용이하게 합니다. 공원 부서 직원이 채팅 스레드에 참여하여 인사이트를 추가하고 에이전트의 지식 요청에 실시간으로 응답합니다. 이 프로세스를 통해 직원은 식별된 문제를 해결하고 커뮤니티 피드백을 더 잘 준비하기 위해 원래 제안을 업데이트할 수 있습니다.
핸드오프 오케스트레이션
핸드오프 오케스트레이션 패턴을 사용하면 특수 에이전트 간에 작업을 동적으로 위임할 수 있습니다. 각 에이전트는 현재 작업을 평가하고 컨텍스트 및 요구 사항에 따라 작업을 직접 처리할지 또는 보다 적절한 에이전트로 전송할지 결정할 수 있습니다.
이 패턴은 작업에 대한 최적의 에이전트를 미리 알 수 없거나 처리 중에만 작업 요구 사항이 명확해지는 시나리오를 해결합니다. 지능형 라우팅을 사용하도록 설정하고 태스크가 가장 지원되는 에이전트에 도달하도록 합니다. 이 패턴의 에이전트는 일반적으로 병렬로 작동하지 않습니다. 한 에이전트에서 다른 에이전트로 모든 권한을 전송합니다.
핸드오프 오케스트레이션을 사용하는 경우
다음 시나리오에서 에이전트 핸드오프 패턴을 고려합니다.
특수 지식 또는 도구가 필요하지만 필요한 에이전트 수 또는 해당 순서를 미리 정할 수 없는 작업
처리 중에 전문 지식 요구 사항이 나타나 콘텐츠 분석을 기반으로 하는 동적 작업 라우팅이 발생하는 시나리오
각 분야의 전문가가 개별적으로 대응해야 하는 다분야 문제
한 에이전트가 기능 제한에 도달하는 시기와 다음 작업을 처리해야 하는 에이전트를 나타내기 위해 미리 결정될 수 있는 논리적 관계 및 신호
핸드오프 오케스트레이션을 피해야 하는 경우
다음 시나리오에서는 이 패턴을 사용하지 않습니다.
적절한 에이전트와 그 순서는 항상 미리 알려져 있습니다.
태스크 라우팅은 동적 컨텍스트 창 또는 동적 해석을 기반으로 하지 않고 간단하고 결정적으로 규칙 기반입니다.
최적이 아닐 경우 라우팅 의사 결정으로 인해 사용자 환경이 저하되거나 좌절될 수 있습니다.
작업을 해결하기 위해 여러 작업이 동시에 실행되어야 합니다.
무한한 전달 루프를 방지하거나 에이전트 간의 과도한 반송을 방지하는 것은 어려운 일입니다.
에이전트 핸드오프 패턴 예제
CRM(통신 고객 관계 관리) 솔루션은 고객 지원 웹 포털에서 핸드오프 에이전트를 사용합니다. 초기 에이전트는 고객을 돕기 시작하지만 대화 중에 전문 지식이 필요하다는 것을 알게 됩니다. 초기 에이전트는 고객의 문제를 해결하기 위해 가장 적절한 에이전트에 작업을 전달합니다. 한 번에 하나의 에이전트만 원래 입력에서 작동하며 핸드오프 체인은 단일 결과를 생성합니다.
이 시스템에서 심사 지원 요원은 요청을 해석하고 일반적인 문제를 직접 처리하려고 시도합니다. 한계에 도달하면 네트워크 문제를 기술 인프라 에이전트에 맡기고, 청구 분쟁을 금융 해결 에이전트에 맡깁니다. 현재 에이전트가 자체 기능 제한을 인식하고 다른 에이전트가 시나리오를 더 잘 지원할 수 있는지 알고 있는 경우 이러한 에이전트 내에서 추가 핸드오프가 발생합니다.
각 에이전트는 고객의 성공이 달성되었거나 다른 에이전트가 고객에게 더 이상 혜택을 줄 수 없다고 판단되는 경우 대화를 완료할 수 있습니다. 일부 에이전트는 문제를 해결하는 것이 중요하지만 현재 문제를 해결할 수 있는 기능이 있는 AI 에이전트가 없는 경우 사용자 환경을 사용자 지원 에이전트에 전달하도록 설계되었습니다.
핸드오프 인스턴스의 한 가지 예가 다이어그램에 강조 표시됩니다. 작업을 기술 인프라 에이전트에 전달하는 분류 에이전트로 시작합니다. 그런 다음 기술 인프라 에이전트는 재무 확인 에이전트에 작업을 전달하기로 결정하여 궁극적으로 작업을 고객 지원으로 리디렉션합니다.
자력 오케스트레이션
복잡하고 사전에 계획된 접근 방법이 없는 개방형 문제를 해결하기 위해 설계된 마그네틱 오케스트레이션 패턴입니다. 이 패턴의 에이전트에는 일반적으로 외부 시스템에서 직접 변경할 수 있는 도구가 있습니다. 이 접근 방식을 구현하는 것과 마찬가지로 문제를 해결하기 위한 접근 방식을 빌드하고 문서화하는 데 중점을 두고 있습니다. 작업 목록은 특수 에이전트와 magentic Manager 에이전트 간의 협업을 통해 워크플로의 일부로 동적으로 빌드되고 구체화됩니다. 컨텍스트가 발전함에 따라 magentic Manager 에이전트는 목표 및 하위 항목을 사용하여 접근 계획을 개발하기 위해 작업 원장을 빌드하며, 최종적으로는 최종적으로 완료되고, 따르고, 추적하여 원하는 결과를 완료합니다.
관리자 에이전트는 특수 에이전트와 직접 통신하여 업무 장부를 작성하고 개선하면서 정보를 수집합니다. 성공적으로 수행할 수 있는 전체 계획을 빌드하기 위해 필요한 만큼 반복하고, 역추적하며, 업무를 위임합니다. 관리자 에이전트는 원래 요청이 완전히 충족되었는지 아니면 중단되었는지를 자주 평가합니다. 장부를 업데이트하여 계획을 조정합니다.
어떤 면에서 이 오케스트레이션 패턴은 그룹 채팅 패턴의 확장입니다. 돋보기 오케스트레이션 패턴은 접근 방식 계획을 작성하는 에이전트에 중점을 두고 다른 에이전트는 기술 자료만 사용하여 결과에 도달하는 대신 도구를 사용하여 외부 시스템을 변경합니다.
돋보기 오케스트레이션을 사용하는 경우
다음 시나리오에서 자기 패턴을 고려합니다.
미리 결정된 솔루션 경로가 없는 복합 또는 개방형 사용 사례입니다.
유효한 솔루션 경로를 개발하기 위해 여러 전문 에이전트의 입력 및 피드백을 고려해야 하는 요구 사항입니다.
AI 시스템이 구현 전후에 검토할 수 있는 완전히 개발된 접근 방식 계획을 생성하기 위한 요구 사항입니다.
외부 시스템과 상호 작용하거나, 외부 리소스를 사용하거나, 실행 중인 시스템의 변화를 유도할 수 있는 도구를 갖춘 에이전트. 에이전트가 작업을 수행하도록 허용하기 전에 사용자에게 해당 에이전트를 시퀀싱하는 방법을 보여 주는 문서화된 계획입니다.
돋보기 오케스트레이션을 피해야 하는 경우
다음 시나리오에서는 이 패턴을 사용하지 않습니다.
솔루션 경로가 개발되었거나 결정적인 방식으로 접근해야 합니다.
원장을 생성할 필요가 없습니다.
태스크의 복잡성이 낮고 더 간단한 패턴으로 해결할 수 있습니다.
이 패턴은 최종 결과를 최적화하지 않고 실행 가능한 계획을 구축하고 논의하는 데 중점을 두기 때문에 시간이 중요합니다.
명확한 해결 경로가 없는 빈번한 중단 또는 무한 루프가 예상됩니다.
마그네틱 오케스트레이션 예제
SRE(사이트 안정성 엔지니어링) 팀은 위험 수준이 낮은 인시던트 대응 시나리오를 처리하기 위해 돋보기 오케스트레이션을 사용하는 자동화를 구축했습니다. 자동화 범위 내에서 서비스 중단이 발생하면 시스템은 동적으로 수정 계획을 만들고 구현해야 합니다. 선불로 필요한 특정 단계를 모르고 이 작업을 수행합니다.
자동화 시스템이 적격 인시던트를 감지하면 magentic manager agent가 서비스 가용성을 복원하고 근본 원인을 식별하는 등의 고수준 목표를 가진 초기 작업 원장을 작성하는 것으로 시작합니다. 그런 다음 관리자 에이전트는 전문 에이전트와 협의하여 정보를 수집하고 수정 계획을 구체화합니다.
진단 에이전트는 시스템 로그, 성능 메트릭 및 오류 패턴을 분석하여 잠재적인 원인을 식별합니다. 결과를 관리자 에이전트에 다시 보고합니다.
진단 결과에 따라 관리자 에이전트는 특정 조사 단계로 작업 원장을 업데이트하고 인프라 에이전트 를 참조하여 현재 시스템 상태 및 사용 가능한 복구 옵션을 이해합니다.
통신 에이전트는 관련자 알림 기능을 제공하며, 관리자 에이전트는 SRE 팀의 에스컬레이션 절차에 따라 진화하는 계획에 통신 검사점 및 승인 게이트를 통합합니다.
시나리오가 명확해지면 배포 반전이 필요한 경우 관리자 에이전트가 롤 백 에이전트 를 계획에 추가하거나 인시던트가 자동화 범위를 초과하는 경우 사용자 SRE 엔지니어에게 에스컬레이션할 수 있습니다.
이 프로세스 전체에서 관리자 에이전트는 새 정보를 기반으로 작업 원장을 지속적으로 구체화합니다. 인시던트가 진화함에 따라 작업을 추가, 제거 또는 다시 정렬합니다. 예를 들어 진단 에이전트가 데이터베이스 연결 문제를 검색하는 경우 관리자 에이전트는 전체 계획을 배포 롤백 전략에서 데이터베이스 연결 복원에 중점을 둔 계획으로 전환할 수 있습니다.
관리자 에이전트는 서비스 복원 시 과도한 중단을 감시하고 무한 수정 루프를 방지합니다. 인시던트 후 검토에 대한 투명성을 제공하는 진화하는 계획 및 구현 단계의 완전한 감사 내역을 유지 관리합니다. 이러한 투명성을 통해 SRE 팀은 학습된 교훈을 기반으로 워크로드와 자동화를 모두 개선할 수 있습니다.
구현 고려 사항
이러한 에이전트 디자인 패턴을 구현하는 경우 몇 가지 고려 사항을 해결해야 합니다. 이러한 고려 사항을 검토하면 일반적인 문제를 방지하고 에이전트 오케스트레이션이 강력하고 안전하며 유지 관리가 가능한지 확인할 수 있습니다.
단일 에이전트, 다중 도구
도구 및 기술 자료에 대한 충분한 액세스 권한을 부여하면 단일 에이전트에서 몇 가지 문제를 해결할 수 있습니다. 지식 원본 및 도구 수가 증가함에 따라 예측 가능한 에이전트 환경을 제공하기가 어려워집니다. 단일 에이전트가 시나리오를 안정적으로 해결할 수 있는 경우 해당 접근 방식을 채택하는 것이 좋습니다. 의사 결정 및 흐름 제어 오버헤드는 종종 작업을 여러 에이전트로 나누는 이점을 초과합니다. 그러나 보안 경계, 네트워크 시야 및 기타 요인은 여전히 단일 에이전트 접근 방식을 사용할 수 없게 만들 수 있습니다.
결정적 라우팅
일부 패턴에서는 에이전트 간의 흐름을 결정적으로 라우팅해야 합니다. 다른 사용자는 에이전트를 사용하여 자신의 경로를 선택합니다. 에이전트가 코드 없음 또는 하위 코드 환경에서 정의된 경우 이러한 동작을 제어하지 않을 수 있습니다. Microsoft Agent Framework 또는 의미 체계 커널과 같은 SDK를 사용하여 코드에서 에이전트를 정의하는 경우 더 많은 제어가 있습니다.
컨텍스트 창
AI 에이전트에는 컨텍스트 창이 제한된 경우가 많습니다. 이 제약 조건은 복잡한 작업을 처리하는 기능에 영향을 줄 수 있습니다. 이러한 패턴을 구현할 때 다음 에이전트가 적용해야 하는 컨텍스트를 결정합니다. 일부 시나리오에서는 지금까지 수집된 전체 원시 컨텍스트가 필요합니다. 다른 시나리오에서는 요약되거나 잘린 버전이 더 적합합니다. 에이전트가 누적된 컨텍스트 없이 작업할 수 있고 새 명령 집합만 필요한 경우 에이전트의 작업을 수행하는 데 도움이 되지 않는 컨텍스트를 제공하는 대신 해당 방법을 사용합니다.
신뢰도
이러한 패턴에는 제대로 작동하는 에이전트와 에이전트 간에 안정적인 전환이 필요합니다. 노드 오류, 네트워크 파티션, 메시지 손실 및 연속 오류와 같은 클래식 분산 시스템 문제가 발생하는 경우가 많습니다. 이러한 문제를 해결하기 위한 완화 전략이 마련되어야 합니다. 에이전트와 해당 오케스트레이터는 다음 단계를 수행해야 합니다.
시간 제한 및 재시도 메커니즘을 구현합니다.
패턴 오류 내에서 하나 이상의 에이전트를 처리하는 정상적인 성능 저하 구현을 포함합니다.
오류를 숨기는 대신 노출하므로 다운스트림 에이전트 및 오케스트레이터 논리가 적절하게 응답할 수 있습니다.
에이전트 종속성에 대한 회로 차단기 패턴을 고려합니다.
에이전트 간에 단일 실패 지점이 공유되지 않으므로 서로 실용적으로 격리되도록 에이전트를 디자인합니다. 다음은 그 예입니다.
에이전트 간의 컴퓨팅 격리를 보장합니다.
에이전트가 동시에 실행될 때 단일 모델 형태의 서비스(MaaS) 모델 또는 공유 지식 저장소를 사용하면 속도 제한이 발생할 수 있는 방법을 평가해 보세요.
SDK에서 사용할 수 있는 검사점 기능을 사용하여 오류 또는 새 코드 배포와 같이 중단된 오케스트레이션에서 복구할 수 있습니다.
안전
이러한 디자인 패턴에서 적절한 보안 메커니즘을 구현하면 AI 시스템이 공격 또는 데이터 유출에 노출될 위험이 최소화됩니다. 에이전트 간의 통신을 보호하고 각 에이전트의 중요한 데이터에 대한 액세스를 제한하는 것이 주요 보안 설계 전략입니다. 다음 보안 조치를 고려합니다.
인증을 구현하고 에이전트 간에 보안 네트워킹을 사용합니다.
에이전트 통신의 데이터 개인 정보 보호 영향을 고려합니다.
규정 준수 요구 사항을 충족하도록 감사 내역을 디자인합니다.
최소 권한 원칙을 따르도록 에이전트 및 해당 오케스트레이터를 디자인합니다.
에이전트에서 사용자의 ID를 처리하는 방법을 고려합니다. 에이전트는 모든 사용자의 요청을 처리하기 위해 지식 저장소에 대한 광범위한 액세스 권한이 있어야 하지만 사용자에게 액세스할 수 없는 데이터를 반환해서는 안 됩니다. 보안 트리밍은 패턴의 모든 에이전트에서 구현되어야 합니다.
관찰 가능성 및 테스트
여러 에이전트에 AI 시스템을 배포하려면 적절한 기능을 보장하기 위해 각 에이전트뿐만 아니라 시스템 전체를 개별적으로 모니터링하고 테스트해야 합니다. 관찰 가능성 및 테스트 전략을 설계할 때는 다음 권장 사항을 고려합니다.
모든 에이전트 작업 및 핸드오프를 계측합니다. 분산 시스템 문제 해결은 컴퓨터 과학 과제이며 오케스트레이션된 AI 에이전트도 예외는 아닙니다.
기준을 설정하고 병목 상태를 찾고 최적화할 수 있도록 각 에이전트에 대한 성능 및 리소스 사용 메트릭을 추적합니다.
개별 에이전트에 대한 테스트 가능한 인터페이스를 디자인합니다.
다중 에이전트 워크플로에 대한 통합 테스트를 구현합니다.
일반적인 문제 및 안티패턴
에이전트 오케스트레이션 패턴을 구현할 때 다음과 같은 일반적인 실수를 방지합니다.
간단한 순차적 또는 동시 오케스트레이션으로 충분할 때 복잡한 패턴을 사용하여 불필요한 조정 복잡성을 만듭니다.
의미 있는 특수화를 제공하지 않는 에이전트를 추가합니다.
다중 홉 통신의 대기 시간 영향을 간과합니다.
동시 에이전트 간에 변경 가능한 상태를 공유하면 에이전트 경계를 넘어 동기 업데이트를 가정하기 때문에 트랜잭션이 일치하지 않는 데이터가 발생할 수 있습니다.
본질적으로 비결정적인 워크플로에 대해 결정적 패턴을 사용합니다.
본질적으로 결정적 워크플로에 비결정적 패턴을 사용합니다.
동시 오케스트레이션을 선택할 때 리소스 제약 조건을 무시합니다.
에이전트가 더 많은 정보를 누적하고 모델을 참조하여 작업을 진행하면 컨텍스트 창이 커지므로 과도한 모델 리소스를 사용합니다.
오케스트레이션 패턴의 결합
애플리케이션에서 요구 사항을 해결하기 위해 여러 오케스트레이션 패턴을 결합해야 하는 경우가 있습니다. 예를 들어 초기 데이터 처리 단계에 순차적 오케스트레이션을 사용한 다음 병렬 처리 가능한 분석 작업을 위해 동시 오케스트레이션으로 전환할 수 있습니다. 워크로드의 여러 단계가 서로 다른 특성을 가지며 다른 패턴을 사용하여 각 단계의 이점을 누릴 수 있는 경우 하나의 워크플로를 단일 패턴에 맞추려고 하지 마세요.
클라우드 디자인 패턴과의 관계
AI 에이전트 오케스트레이션 패턴은 지능형 자율 구성 요소를 조정하는 고유한 과제를 해결하여 기존 클라우드 디자인 패턴을 확장하고 보완합니다. 클라우드 디자인 패턴은 분산 시스템의 구조적 및 동작 문제에 중점을 두지만, AI 에이전트 오케스트레이션 패턴은 특히 추론 기능, 학습 동작 및 비결정적 출력을 사용하여 구성 요소의 조정을 해결합니다.
SDK 기반 구현
이러한 패턴의 대부분은 오케스트레이션 논리를 해결하기 위해 코드 기반 구현을 사용합니다. 에이전트 프레임워크를 지원하는 SDK는 종종 많은 에이전트 오케스트레이션 패턴을 지원합니다.
Microsoft 에이전트 프레임워크
Microsoft Agent Framework SDK에는 에이전트 프레임워크 오케스트레이션에 대한 구현 지침이 있습니다.
- 에이전트 프레임워크를 사용한 순차 오케스트레이션
- 에이전트 프레임워크를 사용한 동시 오케스트레이션
- 에이전트 프레임워크를 사용한 핸드오프 오케스트레이션
- 에이전트 프레임워크를 사용하는 Magentic 오케스트레이션
실습 구현을 위해 GitHub에서 이러한 패턴 중 일부를 실제로 보여 주는 에이전트 프레임워크 선언적 워크플로 샘플을 탐색합니다.
시맨틱 커널
의미 체계 커널 SDK에는 에이전트 프레임워크에 대한 구현 지침이 있습니다.
- 의미 체계 커널을 사용한 순차 오케스트레이션
- 의미 체계 커널을 사용하는 동시 오케스트레이션
- Semantic Kernel을 사용한 그룹 채팅 오케스트레이션
- 시멘틱 커널을 사용한 핸드오프 조정
- 시맨틱 커널을 사용하는 마그네틱 오케스트레이션
실습 구현을 위해 GitHub에서 이러한 패턴을 실제로 보여 주는 의미 체계 커널 다중 에이전트 오케스트레이션 샘플을 탐색합니다.
Magentic-One과 같은 AutoGen에서 이러한 많은 패턴을 찾을 수도 있습니다.
Azure AI Foundry 에이전트 서비스의 구현
Azure AI Foundry 에이전트 서비스를 사용하여 연결된 에이전트 기능을 사용하여 비교적 간단한 워크플로에서 에이전트를 함께 연결할 수도 있습니다. 이 서비스를 사용하여 구현하는 워크플로는 주로 비결정적이므로 이 코드 없는 환경에서 완전히 구현할 수 있는 패턴을 제한합니다.
기여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 작성자:
기타 기여자:
- 헤마바티 알라가난담 | 주요 소프트웨어 엔지니어
- James Lee | 데이터 과학자 2
- 리테시 모디 | 주요 소프트웨어 엔지니어
- Mahdi Setayesh | 주요 소프트웨어 엔지니어
- Mark Taylor | 주요 소프트웨어 엔지니어
- Yaniv Vaknin | 선임 기술 전문가
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.