이 텍스트는 Salesforce의 자동 번역 시스템을 사용하여 번역되었습니다. 이 콘텐츠에 대한 피드백을 제공하고 다음에 원하는 내용을 알려주려면 저희의 설문 조사을 참조하십시오.

진화하는 다중 에이전트 환경에서 특정한 세분화된 과업을 할당하면 에이전트가 가장 효과적입니다. 이를 위해 재사용 가능한 전문 에이전트의 다양한 네트워크가 필요합니다. 그러나 핵심 과제는 다양한 소스에서 생성될 수 있는 이러한 수많은 이기종 에이전트를 조율하여 일반적인 비즈니스 목표를 향해 효과적으로 공동 작업하는 것입니다. 통합 플랫폼이 없으면 이러한 복잡성으로 인해 에이전트가 확산되고 중요한 거버넌스가 부족합니다.

해당 AI 에이전트는 빠르게 증가하고 있으며 SaaS 플랫폼에 포함되거나, 자체 개발되거나, 인기 있는 LLM과 함께 패키징됩니다. 이 곱하기로 인해 조직의 연결이 끊어집니다. 에이전트가 기본 응용 프로그램 내에서 과업을 최적화하는 동안 종종 종합적인 엔터프라이즈 뷰가 부족합니다. 가시성 부족으로 인해 에이전트가 다양한 도메인 및 시스템 전반에서 작업을 효과적으로 오케스트레이션, 보호, 관리할 수 없습니다.

MuleSoft 에이전트 패브릭은 "에이전트 확산"을 관리하고 출신지에 관계없이 다양한 에이전트를 원활하게 오케스트레이션할 수 있는 과제를 해결합니다. 아키텍처 모범 사례를 설정하고 에이전트 네트워크를 만드는 데 필요한 도구를 제공합니다. 에이전트 네트워크는 복잡한 다단계 비즈니스 프로세스를 실행하기 위해 함께 작업하는 AI 에이전트, 도구, 자원의 조정 컬렉션을 말합니다.

MuleSoft Agent Fabric은 모든 엔터프라이즈가 구축된 위치와 상관없이 에이전트를 쉽게 검색, 오케스트레이션, 관리, 관찰할 수 있는 통합 플랫폼입니다.

MuleSoft Agent Fabric 기둥

검색: 에이전트 레지스트리는 조직 전반의 모든 AI 에이전트 및 도구의 중앙 집중화된 카탈로그를 제공합니다. 내부 구축, SaaS 내장형, 외부 자산을 검색하고 재사용할 수 있습니다. 에이전트 레지스트리는 모든 에이전트 자산에 대한 신뢰할 수 있는 단일 소스를 제공하여 중복을 없애고 개발자가 대규모로 기존 기능을 활용할 수 있도록 합니다.

오케스트레이트: MuleSoft 에이전트 브로커는 가장 적합한 에이전트 또는 도구에 과업을 동적으로 일치시키는 지능형 라우팅 솔루션입니다. 선택한 LLM을 기반으로 복잡한 다단계 요청 및 비즈니스 프로세스가 높은 신뢰성과 추적 가능한 결과로 실행되도록 에이전트 및 도구 간에 조율됩니다.

구버: MuleSoft Agent Governance는 Flex Gateway를 활용하고 모델 컨텍스트 프로토콜(MCP)Agent2Agent(A2A) 프로토콜을 지원합니다. Flex 게이트웨이를 사용하면 엔터프라이즈에서 모든 에이전트-에이전트 및 에이전트-도구 상호 작용에 보안 및 규정 준수 정책을 적용할 수 있습니다.

참고: 에이전트 시각화 프로그램은 동적 대화형 에이전트 상호 작용 맵을 통해 실시간 관찰 가능성을 제공합니다. 결정을 추적하고 시스템 상태를 모니터링하여 전체 에이전트 에코시스템을 지속적으로 최적화하고 신뢰할 수 있는 감독할 수 있습니다.

에이전트 패브릭은 사용자가 메타데이터 설명자("YAML 파일")를 통해 에이전트 네트워크를 정의하는 사양 우선(YAML) 접근 방식을 옹호합니다. 이 YAML 파일은 MuleSoft에 무시적이며, 실행에서 에이전트 네트워크의 정의를 분리합니다.

각 에이전트 네트워크(YAML)는 운영 규칙 및 정책을 포함하여 에이전트 자산을 사용하여 특정 기능 영역을 정의합니다. YAML은 다음의 4가지 에이전트 패브릭 기둥을 활성화하는 데 사용됩니다.

  1. 검색: 에이전트 레지스트리를 다음과 같은 기존 에이전트 자산으로 채웁니다.
    1. 다양한 플랫폼에 배포된 에이전트(MuleSoft 또는 기타)
    2. MCP 서버
    3. LLM 공급자
  2. 오케스트레이트: 오케스트레이션을 위한 에이전트 브로커 만들기
  3. 관리: 보안 및 거버넌스를 위한 자산에 정책 적용
  4. 관찰: 정의된 자산에 대한 연결을 정의하고 재사용합니다. 또한 에이전트 네트워크에 관찰 가능성 및 모니터링 기능을 사용할 수 있습니다.

사용자 여정은 Anypoint 코드 빌더에서 시작됩니다. "MuleSoft: 명령 팔레트를 통해 사용할 수 있는 새 명령을 사용합니다. 에이전트 네트워크 프로젝트 만들기"를 사용하여 새 프로젝트를 만듭니다. 이 명령은 두 개의 파일이 포함된 새 프로젝트("에이전트 네트워크")를 만듭니다.

  • agent-network.yaml: 이 파일은 외부 도구(MCP를 통해) 및 에이전트(A2A 프로토콜을 통해)를 사용하여 AI 에이전트를 오케스트레이션할 수 있도록 다중 에이전트 시스템에 대한 구성을 정의합니다. 이 형식은 에이전트 기능, 종속성, 통합을 정의하는 선언적 방법을 제공합니다.

  • exchange.json: 모든 에이전트 네트워크 프로젝트에는 exchange.json 파일도 있습니다. 이 파일에는 에이전트 네트워크 자산이 게시된 후 Anypoint Exchange에서 사용할 수 있는 자산 메타데이터가 포함되어 있습니다.

에이전트 네트워크 개발은 다음의 네 가지 주요 단계를 포함하는 표준 소프트웨어 개발 수명 주기(SDLC)를 따릅니다.

  1. 환경 설정: 런타임 환경 및 게이트웨이 설정
  2. 프로젝트 작성 및 설계: 에이전트 네트워크 프로젝트 사양 만들기
  3. 건축 및 출판: 에이전트 레지스트리에 자산 구축 및 게시
  4. 배포: 지정된 환경에 에이전트 네트워크 배포 또는 승격

프로젝트를 구축하고 필요한 MuleSoft 응용 프로그램 및 자산을 생성한 후 Exchange에서 사용할 수 있도록 지정합니다. Anypoint Code Builder 내에서 "MuleSoft: 명령 팔레트를 통해 Agent Broker Project to Exchange” 명령을 게시합니다.

게시 단계는 YAML 파일의 각 에이전트 자산을 A2A, MCP 또는 LLM 사양으로 변환하고 Exchange에 게시합니다.

또한 새 Agent-Network 자산 유형을 사용하여 Exchange에 YAML을 게시합니다. 이 자산은 에이전트 등록 UI에서 보기하고 Exchange API를 통해 해당 자산을 검색할 수 있습니다.

엔터프라이즈에 대한 에이전트 네트워크를 정의하는 에이전트 네트워크 파일을 참조하십시오. 이 에이전트 네트워크는 단일 정책 관리 환경을 통해 Salesforce, Stripe, 다른 주문 처리 에이전트, 재고 MCP 서버 전반에 걸쳐 주문 처리를 위한 네트워크를 활성화합니다.

  • 검색
    재사용할 수 있도록 기존 에이전트 및 도구(Salesforce, Stripe, 주문 처리, 재고 등)를 Exchange 자산으로 게시합니다. 또한 버전이 지정되고 공유 가능하여 플로를 다시 구축하지 않고 역할, 지역 또는 자회사에 대한 빠른 조정이 가능합니다.
  • 오케스트레이트
    에이전트 중개인이 LLM을 사용하여 주문 처리 프로세스를 고객 세부 사항 확인, 재고 할당, 배송 비용 계산과 같은 일련의 과업으로 세분화합니다. 그런 다음 MCP 및 A2A 에이전트를 호출하여 이 워크플로를 실행하여 필요할 때마다 즉시 승인을 요청합니다.
  • 관리
    Anypoint Flex 게이트웨이는 인증, 최소 권한 액세스, 가드 레일을 적용합니다. API 관리자 정책은 모든 통화 및 데이터 교환 전반에서 일관된 제어를 보장합니다.
  • 관찰
    모니터링 및 추적을 통해 진행 상황, 실패, 대기 시간을 전체적으로 파악할 수 있습니다. 시각화는 상호 작용한 에이전트와 지체 지점을 보여줍니다.
  • 신뢰 및 규정 준수
    중앙 집중식 자격 증명, 감사 추적, 정책 상속은 보안, 개인정보보호, 규제 요구 사항(PII 처리, 승인, 업무 분리)을 지원합니다.

이 다이어그램은 YAML에 정의된 에이전트 네트워크(메타데이터)의 다양한 노드를 보여줍니다.

  • 목적: Exchange는 에이전트, 도구 및 기타 자산의 카탈로그입니다. 기본 목표는 이기종 에이전트의 검색, 큐레이팅, 수명 주기 관리를 위한 단일 관리 카탈로그를 제공하여 "에이전트 확산"을 해결하는 것입니다. 이를 통해 개발자가 에이전트, 플랫폼 소유자가 가시성을 유지하고 오케스트레이터가 기능을 검색할 수 있습니다.
  • 설계에 따른 이기종: 이제 Anypoint Exchange에서 에이전트, MCP, LLM의 세 가지 새 자산을 지원합니다. Exchange는 모든 유형의 에이전트를 등록하고 관리할 수 있는 범용 카탈로그로 설계되었습니다. 타사, Agentforce 및 맞춤형 MuleSoft 에이전트를 비롯한 모든 소스의 A2A 호환 에이전트, MCP 서버 및 LLM 공급자를 지원합니다.
  • 핵심 메타데이터: 등록된 모든 자산에는 고유 이름 및 버전, 소유권 및 게시자 등 변경할 수 없는 메타데이터의 기준 집합이 있습니다. 수명 주기 상태(개발, 스테이징, 프로덕션, 폐기)도 추적됩니다.
  • 검색:
    • 설계-시간: 개발자는 기존 Exchange UI를 통해 또는 Anypoint Code Builder 내에서 Vibes를 사용하여 자연어 검색을 통해 등록된 에이전트를 검색할 수 있습니다.
  • 태그 지정 및 분류: 기본 키 값 태그 지정 시스템을 사용하여 자산을 유형(에이전트, MCP, LLM, 중개인) 및 도메인(예: HR, 날씨)별로 분류하고 동적 연결, 검색, 선택 정책을 활성화할 수 있습니다.
  • 카탈로그: 리포지토리는 조직 내에서 에이전트를 공유하기 위한 비공개 및 내부 카탈로그 모델을 모두 지원합니다.
  • 시각화: 네트워크 보기를 지원하는 시각적 도구를 제공하며 단일 자산 또는 조직 전체의 노드 및 링크 맵에 대한 연결을 표시하고 필터링 기능을 제공합니다.

에이전트 네트워크 내의 중개인은 Anypoint Exchange에 저장된 등록된 에이전트, MCP 서버, LLM 공급자를 참조할 수 있습니다. 그러나 아직 등록되지 않은 경우 에이전트 네트워크(YAML)의 메타데이터에서 선언할 수 있으며 자동으로 등록됩니다. 이 예에서는 여러 에이전트, MCP 서버, LLM 공급자가 Anypoint Exchange에 선언 및 등록됩니다.

에이전트 중개인은 엔터프라이즈의 전문 에이전트 전체에서 과업 위임을 조율하는 지능형 라우팅 에이전트입니다. 과업을 수행하는 데 사용하는 에이전트 및 MCP 서버에 의해 정의됩니다.

중개인은 에이전트 네트워크 자산을 게시하고 다른 중개인이 재사용한 후 Anypoint Exchange에 나타나는 전문 에이전트입니다.

브로커는 YAML의 브로커 섹션에서 정의됩니다. 정의된 중개인은 Mule에 대한 사전 Knowledge 필요하지 않아도 응용 프로그램에 투명하게 "구성"됩니다. 생성된 응용 프로그램이 CloudHub 2.0(CH2)에 배포되고 강력한 CH2 인프라를 활용합니다.

즉, 에이전트 중개인이 로깅 및 메트릭 기능 등 CloudHub 2.0의 설정된 성능 특성에서 혜택을 누릴 수 있습니다. "운영 비용" 및 "모니터링/경고/도구"와 같은 운영 측면은 다른 모든 작업 부하와 동일합니다.

사람이 개입해야 하는 시나리오(Human-in-the-Loop)의 경우 MuleSoft Object Store를 사용하여 각 상호 작용의 상태를 유지합니다. 이는 고동시 환경에서 효과적인 상태 관리를 위해 고안된 분산 솔루션입니다.

중개인 정의는 카드 및 사양과 같은 두 섹션으로 구성됩니다.

카드 섹션은 에이전트-에이전트(A2A) 사양을 따릅니다. 중개인 에이전트의 계약, 기술 및 기능을 설명합니다. 카드 URL에 ${ingressgw.url}/broker-name 값이 자동으로 채워집니다. 배포 시 ${ingressgw.url} 자리 표시자가 에이전트 진입 요청을 전면 처리하는 Anypoint Flex 게이트웨이의 URL로 자동으로 대체됩니다.

사양 섹션은 중개인의 "소스 코드"를 구성합니다. 여기에서 개발자는 사용할 LLM, 지침, 사용 가능한 도구, 오류 처리, 그리고 가장 중요한 것은 이 중개인이 사용할 수 있는 다양한 에이전트 및 MCP 도구를 지정할 수 있습니다.

LLM 공급자

이 섹션은 각 중개인의 사양에 포함됩니다. 이는 서비스 섹션에 정의된 LLM 중 하나에 대한 참조입니다. 모든 중개인 간에 하나의 LLM을 공유할 것인지 또는 필요한 경우 여러 중개인이 과업에 더 적합한 LLM을 사용할 것인지 선택할 수 있습니다.

중개인은 LLM 공급자를 가리킬 수 있습니다. 필요에 따라 해당 공급자의 모델을 선택할 수 있습니다.

** 지침**

이 섹션은 선택 사항이며 이 섹션을 사용하여 이 중개인 에이전트와 관련된 지침을 지정할 수 있습니다. 해당 지침은 특정 비즈니스 지향 우려 사항에 중점을 둡니다. 예를 들어 고객 보고 사고에 대한 관리를 조정하는 고객 서비스 에이전트 가정합니다.

브로커가 직접 처리할 수 있으므로 명시적 지침(예: "업무 분할" 또는 "최상의 도구 선택")을 제공할 필요가 없습니다. 해당 지침은 특정 비즈니스 프로세스를 설명하는 경우에만 필요합니다.

도구 구성

도구는 에이전트에게 외부 기능을 제공합니다. 중개인이 외부 시스템(기존 API 또는 SaaS 서비스 등 다른 에이전트가 아닌)에 액세스해야 할 때마다 MCP(모델 컨텍스트 프로토콜) 서버에 연락합니다.

MCP 서버는 교환 자산의 이름으로 참조됩니다. 서비스 섹션에 연결 세부 사항이 지정되어 있습니다.

기본적으로 중개인은 MCP 서버에서 사용할 수 있는 모든 도구에 액세스할 수 있습니다. 관찰 결과에 따르면 대부분의 최신 LLM은 컨텍스트당 약 20~25개의 도구만 처리할 수 있으므로 부정확성이 생성되거나 컨텍스트가 손실됩니다. 따라서 일반적으로 필요한 최소한으로 사용 가능한 도구를 제한하는 것이 좋습니다. 허용 목록을 통해 해당 필터링을 적용할 수 있습니다.

에이전트 링크

이 섹션은 전체 정의의 가장 중요한 부분입니다. 링크 섹션은 에이전트 간 커뮤니케이션 및 오케스트레이션을 지원합니다. 즉, 이 중개인은 여기에 연결된 에이전트에 의존하여 사용자의 목표를 완료하기 위한 적절한 작업을 실행합니다.

실제로 이 섹션은 공동 작업을 위한 에이전트-네트워크를 정의합니다.

에이전트 거버넌스는 신뢰할 수 있는 에이전트 네트워크를 구축하고 보안 및 규정 준수를 보장하는 데 중요한 에이전트 패브릭의 중요한 기둥입니다.

거버넌스의 경우 비공개 공간 내에 총 2개의 Flex 게이트웨이(1개 입력 및 1개 출력)가 필요합니다.

거버넌스는 전체 ADLC(에이전트 개발 수명 주기)를 안전하게 확장하기 위해 필요한 구조, 제어, 증거를 설정합니다. 특히, 거버넌스는 에이전트 인증, 카탈로그, 수명 주기 결정, 런타임 정책 시행과 같은 주요 프로세스를 구현합니다.

  • 카탈로그:
    • 교환: 에이전트 목적, 소유자, 환경, 데이터 및 분류 경계의 녹음을 지원합니다. 또한 기능, 도구, 리소스, 프롬프트 및 외부 종속성을 버전과 함께 등록합니다.
  • 버전 관리 및 수명 주기:
    • 전체 에이전트 개발 수명 주기 동안 에이전트, 도구, 자산의 시맨틱 버전 관리를 문서화하고 관리합니다.
    • 버전 관리는 에이전트 사용 중지 시간 표시 막대를 관리하는 데 도움이 되며, 가능한 경우 이중 실행을 지원하여 원활한 마이그레이션을 보장합니다.
  • 정책 집행:
    • 에이전트 AI 아키텍처는 공격 표면(대화 인터페이스, 프롬프트 및 MCP와 같은 새로운 프로토콜)을 확장합니다. 구성 요소가 저하되면 프로토콜, 프롬프트, API 또는 도구와 같은 구성 요소를 제공하는 여러 시스템에 계단식 효과가 발생할 수 있습니다.
    • 엔터프라이즈 에이전트 AI 배포를 보호하려면 이러한 자율적이고 예측할 수 없는 환경이 기본적으로 에이전트 간 상호 작용을 통해 공격 영역을 넓히기 때문에 전문적인 접근 방식을 필요로 합니다. 정적 시스템에 대한 기존 보안 도구는 필수이지만 더 이상 자체적으로 충분하지 않습니다. 기업은 사전에 에이전트 AI와 관련된 심각한 비즈니스 위험을 직접 해결하는 네 가지 특정 보안 솔루션을 계획하고 구현해야 합니다.
    • Flex 게이트웨이: 대상 시스템이 안전하지 않은 경우에도 모든 A2A 및 MCP 트래픽이 Flex 게이트웨이를 통해 라우팅되어 모든 끝점에 정책이 적용되도록 합니다. 이 라우팅은 에이전트 통신을 보호하고 인가 서버와 통합하는 데 매우 중요합니다.
    • 정책 번들: 사용자는 실행 전에 워크플로에 미리 정의된 정책의 번들을 정의하고 적용하여 일관된 보안 및 운영 정책 집합을 적용할 수 있습니다.
    • 정책 유형: 플랫폼은 다음을 포함하여 다양한 인바운드 및 아웃바운드 정책을 지원합니다.
      • A2A 정책: 에이전트 카드, PII 감지기, 프롬프트 데코레이터, 스키마 유효성 검사.
      • MCP 정책: 특성 기반 액세스 제어, 스키마 유효성 검사, MCP 지원.
      • LLM/AI 정책: AI 프롬프트 데코레이터, AI 프롬프트 가드(해로운 콘텐츠 필터링), AI 프롬프트 템플릿(사전 정의된 템플릿 적용), AI 기본 토큰 속도 제한.
      • Telemetry 정책: A2A 및 MCP Telemetry - 로그 데이터 수집 및 내보내기를 위한 오픈 Telemetry 솔루션을 확장합니다.
  • :로깅**** 자동 추적 덕분에 에이전트 네트워크 전반에서 로그를 사용하여 모든 에이전트의 상호 작용을 추적하고, 행동을 설명하고 Trust 구축할 수 있습니다.

이 예는 에이전트 네트워크 메타데이터를 사용하여 구성된 메시지 로깅에 대한 정책을 설명합니다. Orderfullfillment 브로커는 Salesforce 에이전트라는 기존 에이전트를 참조하며 메타데이터를 사용하여 메시지에 대한 정책이 구성됩니다. 에이전트 패브릭은 Flex Gateway의 "사양" 섹션 아래 언급된 모든 정책을 자동으로 구성합니다. 추가 단계는 필요하지 않습니다.

LLM 에이전트 및 다중 에이전트 배포의 결정적이고 복잡하지 않은 특성으로 인해 관찰 가능성 및 모니터링이 중요합니다.

  • 기본 로그 및 추적: 로그를 통해 사유 및 도구 실행 추적이 제공됩니다. 워크플로 실행의 로그 및 추적은 런타임 관리자에서 실행 후에 볼 수 있습니다.
  • 메트릭: 초기 단계에서 플랫폼은 a2a_total_calls 및 mcp_total_calls를 레이블(경로, 상태, 메서드, 도구 등)이 있는 카운터로 게시하여 총 통화, 성공 통화, 실패 통화를 결정합니다. 해당 메트릭은 기본적으로 mcp_support_policy 및 a2a_agent_card_policy와 같은 기존 정책을 통해 Envoy(Flex Gateway)의 기본 통계 인터페이스를 사용하여 정책 코드에서 게시됩니다.
  • 개시성 향상(미래): 계획에는 향후 버전에서 배포된 추적에 대한 Open Telemetry 사용이 포함됩니다. 고급 관찰 기능에는 다음이 포함됩니다.
    • 세부 요청 추적: 요청에 대한 전체 가시성을 확보하고 프롬프트, 플래너 프로세스, 호출된 작업, 하위 에이전트와의 상호 작용을 포괄합니다.
    • 에이전트 상태 모니터링: 에이전트 가동 시간, 응답 대기 시간, 처리량, 오류 비율, 기본 자원 사용량(CPU, 메모리, 네트워크, GPU)을 모니터링합니다.
    • 다중 에이전트 조정 모니터링: 에이전트 간 상호 작용의 성공률 및 실패율을 수집하고, 순환 호출 패턴(루프)을 감지하고, 과업 완료 및 호출 수와 같은 에이전트별 메트릭을 추적합니다.
    • 비용 추적: 대시보드 및 경고를 사용하여 각 LLM 호출에 대한 토큰 사용 및 관련 비용을 추적합니다(에이전트당 이상).
    • 지능 추적: 내부 생각 프로세스 및 모든 도구 호출 등 에이전트의 세션에 대한 자세한 추적을 수집하고 표시하며, 변경할 수 없는 감사 추적 역할을 합니다.
    • 에이전트 세션 재생: 딥 디버깅을 위해 에이전트의 인지 추적을 단계별로 시각적으로 "재생"할 수 있는 UI입니다.
    • DAG 시각화: 복잡한 다중 에이전트 상호 작용에 대한 에이전트 워크플로 실행의 DAG(Directed Acyclic Graph) 시각화를 제공합니다.

에이전트 시각화 도우미는 에이전트 네트워크의 일부를 식별하고 함께 작동하는 방식을 확인하는 데 사용됩니다.

  • 노드 유형(에이전트 및 MCP 서버)을 구분합니다.
  • 선언된 상호 작용 및 런타임 상호 작용을 보려면 가장을 봅니다.
  • 레이어를 사용하여 특정 환경에 대한 보기 집중
  • 노드의 메타데이터 및 메트릭을 검사하고 로그 및 추적에 액세스하는 세부 사항 카드 열기
  • Flex 게이트웨이 보호 및 적용된 정책과 같은 거버넌스 지표를 검토합니다.

Agent Visualizer의 구성 요소에 대한 자세한 내용은 여기에 있습니다.

MuleSoft Agent Fabric은 이러한 네 가지 기초를 함께 사용하여 내장된 거버넌스가 있는 모든 에이전트에게 보안 및 제어를 확장합니다. 에이전트는 A2A(에이전트-에이전트) 및 MCP(모델 컨텍스트 프로토콜)와 같은 새로운 프로토콜을 활용하여 비즈니스 프로세스를 구축하고 확장하여 어디서나 작업할 수 있습니다. 애플리케이션, 데이터, 시스템 등 모든 항목을 연결하여 전체 비즈니스에서 작업할 때 에이전트의 권한을 부여하고 관리합니다. 인텔리전트 도구는 AI를 기본적으로 사용하거나 타사 AI 도구를 가져와 비즈니스 프로세스 또는 API 생성 및 확장을 지원합니다.

4개의 기둥을 모두 함께 사용하는 것은 필수 항목이 아니지만 권장됩니다. 필요에 따라 독립적으로 기둥을 선택할 수 있습니다. 예를 들어 오케스트레이션 레이어를 사용하지 않고도 등록 및 거버넌스에 에이전트 패브릭을 활용할 수 있습니다. 마찬가지로 중개인을 사용하여 다른 플랫폼을 통해 관리되는 에이전트를 오케스트레이션할 수 있습니다.

다음 다이어그램은 네 가지 구성 요소가 모두 상호 작용하는 방식을 보여줍니다.

  1. Anypoint 코드 빌더의 에이전트 네트워크 YAML에서 에이전트 네트워크(중개인, 에이전트, MCP 서버)를 정의한 후 검색 및 재사용을 위해 Anypoint Exchange에 에이전트 자산을 게시합니다.
  2. 에이전트 자산을 CloudHub 2.0(런타임 관리자에서 관리)에 배포합니다.
  3. 중개인 및 API 끝점 앞에 있는 접속 Flex 게이트웨이를 사용하여 네트워크에 수신되는 트래픽에 정책을 적용합니다.
  4. 탈출 Flex 게이트웨이를 사용하여 정책을 적용하고, 연결을 관리하고, Telemetry 데이터를 발송합니다. 이 게이트웨이는 중개인 및 에이전트에서 외부 서비스로의 아웃바운드 경로에 위치합니다.
  5. Anypoint Monitoring에서 Flex 게이트웨이 및 런타임에서 로그, 메트릭, 추적을 수집합니다.

사용 가능한 모든 AI 자산에 액세스하여 모든 과업을 처리할 수 있는 단일 오케스트레이터를 사용하여 평면하고 제한되지 않은 아키텍처에서 모든 전문 에이전트에게 즉시 액세스할 수 있도록 만드는 것은 유용합니다. 그러나 이 접근 방식은 전체 시스템의 효율성과 신뢰성을 손상시킬 수 있습니다. 초과 개별 툴에 적용되는 원칙과 마찬가지로, 많은 에이전트 옵션은 중앙 브로커 에이전트(또는 오케스트레이터)에게 상당한 소음과 복잡성을 제공합니다. 이러한 복잡성 증가로 인해 중개인의 의사 결정 정확도(작업에 적합한 에이전트 선택)와 시스템의 응답 결정성(비슷한 쿼리에 대해 예측 가능한 일관된 결과)이 크게 떨어집니다. 중개인 에이전트는 효과적으로 옵션 마비로 인해 라우팅이 느리고 신뢰도가 떨어집니다.

평면 구조 대신 에이전트 네트워크 구조화에 대한 다단계 계층 접근법을 강력히 옹호합니다. 이 조직 원칙은 여러 가지 중요한 이점을 제공합니다. 첫째, 그것은 본질적으로 추적 가능성 및 관리를 선호한다. 계층 구조는 설정된 조직 모범 사례를 미러링하여 요청 플로를 더욱 쉽게 감사하고, 실패 레이어를 파악하여 문제를 디버그하고, 특정 에이전트 또는 하위 네트워크의 배포 및 사용 중지를 관리할 수 있습니다.

두 번째로, 이 에이전트를 강화하는 대규모 언어 모델(LLM)의 맥락에서 계층 구조는 컨텍스트 크기를 확인하는 데 크게 도움이 됩니다. 에이전트 환경을 세분화하면 지정된 계층의 중개인 에이전트가 바로 아래에 있는 제한된 에이전트 집합 또는 하위 중개인만 고려합니다. 이 구조는 기본 오케스트레이터가 모든 에이전트의 설명, 기능, 내역 컨텍스트를 작업 메모리에 로드하지 않도록 방지하여 LLM의 컨텍스트 기간 제한을 빠르게 초과하고 비용 및 대기 시간이 오래 걸릴 위험을 방지합니다.

여러 방법으로 에이전트 네트워크를 구현할 수 있습니다. 두 가지 방법은 다음과 같습니다.

  1. Conway의 법칙 - 직관적으로 실제 계층 구조에 매핑할 수 있습니다.
  2. 도메인 중심 설계 - 비즈니스 도메인에 더 집중

옵션 1: 실제 계층 구조를 사용한 매핑

계층 조직에서 커뮤니케이션은 관리자에서 하위 역할에 이르기까지 세로로 흐르며 결정은 주로 중앙 집중화됩니다. Conway의 법에 따라:

  • 해당 조직에서 구축한 시스템 또는 소프트웨어 아키텍처는 계층화되고 계층화되는 경향이 있습니다.
  • 각 팀은 자체 경계 및 권한을 반영하는 하위 시스템을 설계하는 경향이 있습니다.
  • 시스템 간의 인터페이스는 부서 간의 통신 채널을 반영합니다.

에이전트 네트워크는 또한 Conway의 법칙에 따라 대기업의 실제 계층 구조에 직관적으로 매핑할 수 있습니다.

  • 개념 모델: 기업에 고유한 디비전, 부서 및 관리 계층(예: C-suite, VP, 디렉터, 관리자)이 있는 것처럼 특정 도메인 내에서 운영되는 에이전트 네트워크도 병렬 조직 차트로 모델링할 수 있습니다.
  • 노드와 잎: 이 계층에서:
    • 나무 구조의 특수 대리인 또는 MCP입니다. 이는 실제 작업을 수행하는 기능 단위입니다(예: "데이터베이스 쿼리 에이전트", "고객 인증 에이전트", "분위기 분석 에이전트"). 조직의 개별 공동작업자 또는 작업 단위를 나타냅니다.
    • 루트 및 중간 계층을 포함하여 계층의 기타 노드메로커 에이전트(또는 하위 오케스트레이터)입니다. 해당 에이전트는 최종 과업을 수행하지 않지만 특정 도메인 또는 계층 내에서 라우팅, 위임, 집계, 충돌 해결에 대한 책임이 있습니다. 상위 수준 중개인은 "세일즈 도메인 중개인"에 과업을 위임하며, 그러면 "기회 관리 중개인"에 위임하여 "기회 상태 업데이트 에이전트"(리프)를 통해 과업을 수행합니다.

이 구조를 통해 복잡성이 로컬로 관리되고, 컨텍스트가 포함되며, 시스템이 예측 가능하고 신뢰할 수 있도록 확장됩니다. 새 전문가 에이전트를 조직 트리의 특정한 적절한 분기에 도입할 수 있습니다.

디지털 공임에 대한 조직 차트의 아날로그를 고려하십시오. 각 YAML 파일은 각 내부 조직(직원 성공, 보안, 재무 등)을 나타냅니다. 각 조직(에이전트-네트워크) 내에서 작업자가 공동 작업을 수행하고 작업을 과업으로 분할하고 할당하는 계층 구조가 있을 수 있습니다. 위 다이어그램에서 커뮤니케이션은 상단에서 하단으로 흐릅니다. 또한 리드는 중개인 에이전트 집합에 의한 소비만으로 제한되지 않습니다.

인적 조직 차트를 기반으로 에이전트 네트워크를 모델링하면 특히 자주 재구성을 수행하는 회사에서 자주 재구성해야 할 위험이 있습니다. 다른 방법은 기능적 도메인별로 에이전트를 구성하는 것입니다. 이 그룹화는 기존의 인적 조직 경계를 넘어야 할 수 있습니다. 예를 들어, 새 직원 온보딩은 하드웨어 및 사용자 프로비저닝에 대한 IT 작업을 포함하며, 세일즈 작업에는 운영 및 마케팅이 모두 필요합니다.

Nikhil Aggarwal은 MuleSoft 및 Salesforce Automation Cloud의 아키텍처를 이끄는 Salesforce의 주 아키텍처입니다. Nikhil은 대규모 제품을 제공하는 데 18년 이상의 경험을 보유하고 있으며 확장 가능한 아키텍처, 직관적인 개발자 경험, 고성능 팀 구축에 열정적입니다. Salesforce 이전에는 Microsoft Power Platform, Dataverse, Office 365의 여러 이니셔티브를 개념부터 출시까지 이끌었습니다. 그는 계속해서 AI 우선 시대의 현대 기업이 시스템을 연결하고, 워크플로를 자동화하고, 비즈니스 가치를 확보하는 방식을 구축합니다.

Mariano Gonzalez는 2011년 MuleSoft에 입사하여 미션 크리티컬 분산 시스템, 통합, PaaS, 클라우드 컴퓨팅을 전문으로 했습니다. 현재 Mariano는 특히 거버넌스, 오케스트레이션, 검색, 관찰 가능성에 중점을 두고 AI 플랫폼을 발전시키는 데 중점을 두고 있습니다. IT 업계에서 20년 이상 근무한 Mariano는 소프트웨어 아키텍처 및 팀 리더로서 농업, 에너지, 정부, IT, 통신, 콘텐츠 관리 분야에서 BPM, ERP, 통합 솔루션을 설계 및 제공했습니다.

Pedro Colunga는 Salesforce의 API 및 메타데이터 아키텍처 전문 소프트웨어 엔지니어 아키텍처입니다. Pedro는 전체 플랫폼 수명 주기에 중점을 두고 조직이 시스템 인텔리전스, 의미론, 메타데이터 중심 솔루션과 상호 작용하는 방식을 구성하는 데 중요한 역할을 합니다. 기업가 경험을 포함한 Pedro의 20년 경력은 후고, BEA Systems, Oracle, 나중에 MuleSoft에 인수된 TekGenesis와 같은 회사에 걸쳐 있으며, 그곳에서 지속적으로 플랫폼 방식 아키텍처를 구동하여 BPM, RAD, 통합과 같은 영역에서 심층적인 전문 지식을 제공했습니다.

Gulal Kumar는 데이터 및 통합 아키텍처에 중점을 둔 Salesforce의 소프트웨어 엔지니어링 아키텍처입니다. 통합 및 API, 현대화 프로그램, 보안, AIML 이니셔티브 분야에서 20년 이상의 경험을 보유한 그는 풍부한 전문 지식을 제공합니다. Gulal은 비즈니스 전환 이니셔티브를 발전시키고, 보안 및 복원 능력을 향상하고, 아키텍처 우수성을 촉진하고, 다양한 도메인 전반에 걸쳐 AIML 이니셔티브를 선도하기 위해 노력하고 있습니다.