Wooldridge 다중 에이전트 시스템
이 스킬은 질문이 "여러 모델이 대화하도록 만드는 방법"이 아니라 "이 환경이 나에게 어떤 종류의 자율 시스템을 구축하도록 강제하는가?"일 때 사용하십시오.
사용 시기
- 반응형, 숙의형, 또는 하이브리드 에이전트 아키텍처 중에서 선택해야 할 때.
- 누구도 완전한 정보나 이의 없는 제어권을 가지고 있지 않아 조정이 계속 실패할 때.
- 에이전트가 불확실성 하에서 협상, 할당, 또는 커밋먼트 전략이 필요할 때.
- 설계가 에이전트가 무엇을 알고 있는지, 모두가 무엇을 알고 있는지, 또는 공통 지식이 달성 가능한지에 의존할 때.
- "다중 에이전트" 설계가 실제로는 비동기 객체 오케스트레이션에 불과한지 진단해야 할 때.
사용하지 말아야 할 때
- 조정 요구사항이 없는 단일 에이전트 계획 또는 최적화 문제.
- 하나의 컨트롤러가 이미 전역 결정 권한을 소유한 중앙 집중식 스케줄러.
- 별도의 목표, 신념, 또는 제어 범위가 없는 프롬프트 전용 롤플레이 스웜.
- 에이전트 자율성과 지식 비대칭성이 무관한 일반 분산 시스템 설계.
핵심 멘탈 모델
환경 속성이 아키텍처를 결정한다
관찰 가능성, 결정론성, 역학, 시간 압력부터 시작하십시오. 아키텍처 선택은 환경 형태의 하류에 있으며, 유행하는 에이전트 패턴에 대한 개인적 선호가 아닙니다.
자율성은 제어의 역전이다
에이전트는 단순한 비동기 객체가 아닙니다. 그들은 준수 여부와 시기를 결정하므로, 요청에는 암묵적 복종이 아닌 의미론, 거부, 조정 로직이 필요합니다.
조정은 제약 조건에서 발생한다
부분적 관찰 가능성, 자원 경쟁, 상호 의존적 목표가 조정 압력을 만듭니다. 좋은 프로토콜 설계는 협력이 항상 바람직하다고 가정하는 대신 그 압력을 명명하는 것에서 시작합니다.
커밋먼트 전략은 변동성과 일치해야 한다
대담한 에이전트는 빠르게 변화하는 환경에서 과잉 약속하고, 신중한 에이전트는 안정적인 환경에서 지나치게 변경합니다. 재고 빈도는 환경 역학에 묶인 설계 매개변수이지, 보편적인 모범 사례가 아닙니다.
지식 수준이 중요하다
개인 지식, 모두가 아는 지식, 공통 지식, 분산 지식은 서로 대체할 수 없습니다. 잘못된 수준을 요구하면 프로토콜이 불가능해지거나 불필요하게 비용이 많이 들 수 있습니다.
의사결정 포인트
flowchart TD
A[에이전트 아키텍처 필요] --> B{환경이 완전히 관찰 가능하고 안정적인가?}
B -->|예| C[단순 반응형 또는 계획 중심 설계로 충분할 수 있음]
B -->|아니오| D{불확실성 하에서 실시간 반응이 필요한가?}
D -->|예| E[하이브리드 아키텍처]
D -->|아니오| F[숙의형 아키텍처]
E --> G{에이전트가 왜 조정해야 하는가?}
F --> G
G -->|부분 정보| H[정보 공유 프로토콜]
G -->|자원 경쟁| I[협상 또는 할당 메커니즘]
G -->|작업 의존성| J[커밋먼트 또는 위임 프로토콜]
G -->|실제 자율성 없음| K[더 간단한 중앙 집중식 설계 사용]
- 에이전트 아키텍처를 선택하기 전에 환경을 특성화하십시오.
- 에이전트가 요청을 거부, 지연, 또는 재해석할 수 없다면 에이전트 자율성이 있다고 가장하지 마십시오.
- 지식 요구사항을 의도적으로 선택하십시오. 많은 시스템이 공통 지식이 아닌 분산 지식을 필요로 합니다.
- 커밋먼트 대담성을 환경 변화율과 재고 비용에 맞게 조정하십시오.
실패 모드
아키텍처 우선 설계
징후: 팀이 환경을 설명하기 전에 BDI, 토론, 또는 화려한 에이전트 프레임워크를 원합니다.
해결책: 먼저 환경 특성화를 강제하십시오.
의인화된 자율성
징후: 설계가 신념과 욕망에 대해 이야기하지만, 이를 로컬 상태, 관찰, 또는 프로토콜 의무에 매핑할 수 없습니다.
해결책: 정신적 언어를 구체적인 계산 상태에 근거하십시오.
조정을 위한 조정
징후: 통신 트래픽이 증가하지만, 어떤 환경적 압력이 이를 필요로 하는지 설명할 수 있는 사람이 없습니다.
해결책: 실제 강제 함수를 식별하고 이를 처리하는 최소한의 프로토콜을 설계하십시오.
숨겨진 중앙 컨트롤러
징후: 하나의 "에이전트"가 조용히 모든 중요한 결정을 내리고 다른 에이전트는 단지 실행만 합니다.
해결책: 아키텍처가 중앙 집중식임을 인정하거나 진정한 결정 권한을 재분배하십시오.
불가능한 지식 가정
징후: 프로토콜 정확성이 모든 에이전트가 다른 모든 에이전트가 사실을 알고 있다는 것에 의존하지만, 네트워크가 신뢰할 수 없습니다.
해결책: 환경이 허용하는 대로 분산 지식, 확인 응답, 또는 최종 일관성으로 완화하십시오.
작업 예시
전문 LLM 리뷰 스웜
코딩 시스템이 보안, 성능, 스타일 에이전트를 사용합니다. 보안 리뷰는 스타일 리뷰와 다른 증거에 의존하며, 단일 리뷰어가 전역 가시성을 가지고 있지 않습니다. 모든 리뷰어가 전체 컨텍스트를 보아야 한다고 가정하는 대신 하이브리드 코디네이터와 대상 정보 공유를 사용하십시오.
분산 차량 모니터링
센서 에이전트가 중복되지만 불완전한 영역을 커버합니다. 단일 에이전트가 종단 간 추적 연속성을 유지할 수 없기 때문에 조정이 필요합니다. 일반적인 "협력" 대신 부분적 관찰 가능성을 중심으로 프로토콜을 설계하십시오.
품질 게이트
- 아키텍처 선택 전에 환경이 명시적으로 특성화되었습니다.
- 설계가 조정 압력의 실제 근원을 명명합니다.
- 지식 요구사항이 올바른 수준으로 명시되었습니다.
- 커밋먼트 전략이 변동성과 재고 비용에 연결되었습니다.
- 주장된 모든 자율성에는 요청의 거부, 지연, 또는 로컬 해석이 포함됩니다.
식별 질문
- 누군가 시스템을 다중 에이전트라고 부르지만 모든 중요한 결정이 여전히 하나의 컨트롤러를 통해 라우팅된다면, 그들은 자율성을 설계하는 것이 아니라 분산 실행의 이름을 바꾸고 있는 것입니다.
- "공통 지식"이 통신 모델 없이 무심코 사용된다면, 프로토콜이 아마도 과소 명세된 것입니다.
- 팀이 에이전트가 왜 조정해야 하는지 말할 수 없다면, 설계가 아마도 에이전트 자체를 필요로 하지 않는 것입니다.
참고 자료 라우팅
references/environment-characterization-drives-architecture.md: 아키텍처 선택이 주요 질문일 때 로드하십시오.references/coordination-as-necessity-not-luxury.md: 조정을 정당화하거나 최소화해야 할 때 로드하십시오.references/commitment-strategies-and-environment-dynamics.md: 대담성 또는 재계획 주기가 주요 조정 문제일 때 로드하십시오.references/grounded-epistemic-logic-for-distributed-agents.md: 지식 주장이 안전성 또는 정확성을 결정할 때 로드하십시오.references/negotiation-and-resource-allocation-mechanisms.md: 자율성이 희소 자원과 충돌할 때 로드하십시오.