멀티 에이전트 데모는 지금 어디에나 있습니다.
문제는 많은 데모가 실제 생활에서 아픈 부분 바로 직전에 멈춘다는 것입니다: 배포 형태, 서비스 연결, 상태, 텔레메트리, 런타임 경계, 분산 시스템의 일반적인 혼란.
그래서 새로운 Aspire + Microsoft Agent Framework 샘플이 주목할 가치가 있습니다.
아니요, 흥미로운 부분은 스키 리조트 컨시어지 시나리오가 아닙니다.
흥미로운 부분은 샘플이 다음과 함께 분산 에이전트 시스템을 구축하기 위한 훨씬 더 현실적인 패턴을 보여준다는 것입니다:
- 사용자 정의 호스팅 에이전트
- 프롬프트 에이전트
- 여러 런타임
- 서비스 참조
- 라이브 데이터 소스
- 관찰 가능성 및 배포 구조
그것이 진짜 이야기입니다.
이것은 “도구를 사용하는 에이전트” 그 이상입니다
샘플의 아키텍처는 친숙한 단일 루프 에이전트 모델을 넘어섭니다.
다음이 있습니다:
- 좁은 책임을 가진 전문 에이전트
- 그들을 오케스트레이션하는 어드바이저 에이전트
- Foundry 관리 리소스
- 동일한 그래프의 .NET, Python, Go 서비스
- 음성 및 채팅 진입점
이것은 진지한 에이전트 시스템이 실제로 실제로 어떻게 보일지에 훨씬 더 가깝습니다.
그리고 바로 거기서 Aspire가 갑자기 매우 중요해집니다.
Aspire는 인간이 보통 머릿속에 유지하는 어려운 부분을 처리하고 있습니다
제가 여기서 가장 마음에 드는 것은 에이전트 로직조차 아닙니다. 애플리케이션 그래프가 명시적이라는 사실입니다.
Aspire는 다음을 설명하는 데 사용됩니다:
- 어떤 서비스가 존재하는지
- 그들이 무엇에 의존하는지
- 어떤 모델 배포가 필요한지
- 각 서비스가 어떤 런타임을 사용하는지
- 어떤 상태 및 배포 관계가 존재하는지
분산 에이전트 시스템이 빠르게 지저분해지기 때문에 이것은 중요합니다. 토폴로지가 사람들의 머리와 임의의 설정 문서에만 존재하면, 시스템은 즉시 취약해집니다.
그 토폴로지를 AppHost에 넣는 것은 재현 가능한 것을 향한 큰 발걸음입니다.
도구로서의 전문 에이전트는 여전히 주목할 패턴입니다
아키텍처에서 제가 가장 좋아하는 부분 중 하나는 전문 에이전트가 오케스트레이터를 위한 호출 가능한 기능으로 표시되는 방식입니다.
그 패턴은 계속 나타나는 데는 이유가 있습니다. 다음을 제공합니다:
- 관심사의 분리
- 더 나은 도메인 경계
- 더 명확한 관찰 가능성
- 모든 것을 다시 작성하지 않고도 한 전문가를 더 쉽게 교체
.NET 팀에게 이것은 모든 것을 아는 거대한 에이전트를 구축하고 프롬프트 지침이 안정적으로 유지되기를 바라는 것보다 훨씬 더 건강한 멘탈 모델입니다.
내 생각
이 샘플이 증명하는 중요한 것은 멀티 에이전트 앱이 가능하다는 것이 아닙니다. 우리는 이미 그것을 알고 있었습니다.
다음 질문에 대한 일관된 답변을 Microsoft 스택이 제공하기 시작했음을 증명합니다:
여전히 작동 가능한 멀티 에이전트 시스템을 어떻게 구축합니까?
그래프를 위한 Aspire. 런타임 추상화를 위한 Agent Framework. 관리형 AI 리소스 및 호스팅을 위한 Foundry. 그 조합은 덜 실험적이고 더 실제 플랫폼 스토리처럼 느껴지기 시작하고 있습니다.
그것이 제가 여기서 주목하는 부분입니다.
원문: Distributed multi-agent systems with Aspire and Microsoft Agent Framework
