SKILL.md — AgentSpeak(L) 및 BDI 에이전트 아키텍처
자율 개체가 진행 중인 작업을 포기하지 않고 경쟁 목표를 관리하며 이벤트에 대응하면서 인식, 숙고, 행동해야 할 때.
의사 결정 포인트
기본 아키텍처 선택
IF 시스템이 지속적인 목표 없이 이벤트-반응만 필요한 경우
→ 반응형/규칙 시스템 사용 (BDI는 과잉)
ELIF 정적 환경에서 인터럽트 없이 계획만 필요한 경우
→ 고전적 플래너 사용
ELIF 동적 환경에서 반응성과 목표 지속성 모두 필요한 경우
→ BDI 아키텍처 사용
선택 함수 호출 테이블
| 상황 | 사용 함수 | 결정 기준 |
|---|---|---|
| 새 이벤트 도착 | SE (이벤트 선택) | 우선순위, 긴급성, 리소스 제약 |
| 이벤트에 계획 필요 | SO (옵션 선택) | 컨텍스트 가드, 계획 성공 이력, 위험 허용 수준 |
| 여러 활성 의도 | SI (의도 선택) | 마감 시간, 리소스 할당, 공정성 정책 |
| 계획 실패 발생 | SO then SI | 실패 처리 계획 찾기, 의도 재스케줄링 |
계획 실패 복구 결정 트리
계획 P가 액션 A 실행 중 실패:
IF 이 실패 유형에 대한 실패 처리 계획이 존재하는 경우
→ 실패 이벤트 게시, SO가 복구 계획 선택하도록 함
→ 수정된 의도 스택으로 계속 진행
ELIF 동일한 트리거 이벤트에 대한 대체 계획이 존재하는 경우
→ 이벤트로 롤백, SO가 다음 적용 가능한 계획 시도하도록 함
→ 실패한 계획은 고려 대상에서 제외
ELIF 대체 계획이 없는 경우
→ 의도 스택 위로 실패 전파
→ IF 상위 계획이 존재하는 경우 → 상위 수준에서 실패 이벤트 트리거
→ ELSE 의도 완전히 드롭
믿음 업데이트 영향 평가
새 믿음 B 도착:
IF B가 기존 믿음과 모순되는 경우
→ 믿음 수정 프로토콜 실행
→ 모든 활성 의도의 컨텍스트 가드 위반 여부 확인
→ IF 컨텍스트가 더 이상 유효하지 않은 경우 → 의도 일시 중단 (드롭하지 않음)
ELIF B가 새로운 적용 가능 계획을 활성화하는 경우
→ 이제 적용 가능한 계획이 있는 대기 이벤트를 이벤트 큐에서 확인
→ SE를 사용하여 재우선순위화
ELIF B가 보류 중인 목표 조건을 충족시키는 경우
→ 달성 표시, 관련 의도 정리
→ 계획 정리를 위한 달성 이벤트 게시
실패 모드
1. 계획 쓰래싱
증상: 에이전트가 진전 없이 계획을 빠르게 순환함; 동일한 이벤트가 반복적으로 다른 계획을 트리거함. 감지 규칙: 동일한 이벤트가 N 실행 주기 내에 3회 이상 처리되고 매번 다른 계획이 선택되면 계획 쓰래싱입니다. 근본 원인: SO(옵션 선택) 함수가 비결정적이거나 컨텍스트 가드가 너무 약하거나 중복됨. 해결책: SO를 명시적으로 우선순위 순서로 정렬; 컨텍스트 가드를 상호 배타적으로 강화; 선택 기준에 계획 성공/실패 이력 추가.
2. 오래된 믿음으로 인한 마비
증상: 에이전트가 오래된 세계 모델을 기반으로 계획을 선택함; 환경에 대한 잘못된 가정으로 인해 계획이 즉시 실패함. 감지 규칙: 계획 실패율이 50%를 초과하고 실패가 (계획 시간이 아닌) 실행 시간의 컨텍스트 가드 위반으로 인한 경우, 오래된 믿음이 있습니다. 근본 원인: 환경 변화율에 비해 믿음 업데이트 빈도가 너무 낮음; 믿음 수정이 의도 컨텍스트 검사로 전파되지 않음. 해결책: 인식 주기 증가; 믿음 오래됨 타임스탬프 추가; 컨텍스트 가드가 유효하지 않게 될 때 의도 일시 중단.
3. 무한 의도 루프
증상: 에이전트가 동일한 목표에 대해 더 많은 의도를 생성하는 이벤트를 게시하는 의도를 생성함; 의도 스택이 제한 없이 증가함. 감지 규칙: 의도 스택 깊이가 시간이 지남에 따라 단조롭게 증가하고 해당 목표 달성이 없으면 의도 루프입니다. 근본 원인: 계획이 종료 조건 없이 결국 원래 목표로 되돌아오는 하위 목표를 생성함. 해결책: 컨텍스트 가드에 달성 감지 추가; 의도 포함(중복 의도 병합) 구현; 최대 재귀 깊이 제한 추가.
4. 계획 내 정책 안티패턴
증상: 동일한 이벤트가 계획 본문 내 조건문에 따라 다른 동작을 트리거함; 에이전트 정책이 분산되어 변경하기 어려움.
감지 규칙: 계획 본문에 우선순위/긴급성 조건문(if high_priority then X else Y)이 포함되어 있으면 정책이 잘못된 위치에 있습니다.
근본 원인: 에이전트 합리성이 선택 함수 대신 계획 로직에 인코딩됨.
해결책: 모든 우선순위/정책 로직을 SE/SO/SI 함수로 이동; 계획을 정책 중립적이고 컨텍스트에만 민감하게 만듦.
5. 단일 의도 병목
증상: 에이전트가 인터럽트를 처리할 수 없음; 긴급 이벤트가 장기 실행 작업이 완료될 때까지 대기함; 동시성 없음. 감지 규칙: 에이전트가 항상 최대 하나의 활성 의도를 가지면 단일 의도 병목입니다. 근본 원인: SI(의도 스케줄링) 함수가 진정한 동시성을 구현하지 않음; 의도를 동시적이 아닌 배타적으로 취급. 해결책: 여러 활성 의도 허용; SI에서 선점형 스케줄링 구현; 계획을 인터럽트 가능한 시퀀스로 설계.
실제 예제
예제 1: 계획 충돌이 있는 다중 에이전트 작업 할당
시나리오: 두 에이전트(A1, A2)가 deliver(package, destination)을 달성하기 위해 협력합니다. 둘 다 계획을 가지고 있지만 능력이 다릅니다.
초기 상태:
- A1 믿음:
location(A1, warehouse),can_carry(A1, small_items),location(package, warehouse) - A2 믿음:
location(A2, depot),can_carry(A2, any),has_vehicle(A2) - 공유 믿음:
size(package, large),destination(customer_site)
이벤트: +!deliver(package, customer_site)가 두 에이전트에 게시됨
결정 과정:
-
A1 계획 선택 (SO):
- 계획 P1:
+!deliver(X,Y) : can_carry(A1,small_items) & size(X,small) <- pickup(X); transport(X,Y) - 컨텍스트 가드 실패:
size(package,large)가size(X,small)와 모순됨 - 적용 가능한 계획 없음 →
plan_failure(deliver, no_capability)게시
- 계획 P1:
-
A2 계획 선택 (SO):
- 계획 P2:
+!deliver(X,Y) : can_carry(A2,any) & has_vehicle(A2) <- pickup(X); drive(X,Y); dropoff(X) - 컨텍스트 가드 성공 → P2 선택
- 의도 I1 생성:
[pickup(package), drive(package,customer_site), dropoff(package)]
- 계획 P2:
-
A1 믿음 업데이트:
- 메시지 수신:
attempting(A2, deliver, package) - 믿음 업데이트:
+delegated(deliver, package, A2) - 실패한 의도 드롭
- 메시지 수신:
초보자 오류: 두 에이전트가 모두 배달을 시도하여 리소스 충돌이 발생했을 것입니다. 전문가 통찰: 조정은 하드코딩된 에이전트 지식이 아닌 믿음 공유와 계획 컨텍스트 가드를 통해 이루어집니다.
예제 2: 의도 재고를 통한 인터럽트 처리
시나리오: 장기 실행 데이터 처리 작업을 실행 중인 에이전트가 긴급 보안 경보를 수신합니다.
초기 상태:
- 활성 의도 I1:
[process_batch(data1), process_batch(data2), generate_report()] - 현재 실행:
process_batch(data1)중간 (앞으로 10분 더 소요)
이벤트: +security_alert(intrusion_detected, server_3)
결정 과정:
-
이벤트 선택 (SE):
- SE 우선순위: security_events > routine_processing
security_alert이 I1 계속 실행보다 선택됨
-
계획 선택 (SO):
- 계획 P3:
+security_alert(Type,Location) : has_admin_access <- isolate_system(Location); notify_team(Type) - 컨텍스트 가드 충족 → P3 선택
- 의도 I2 생성:
[isolate_system(server_3), notify_team(intrusion_detected)]
- 계획 P3:
-
의도 스케줄링 (SI):
- 현재 의도: I1 (
process_batch(data1)에서 일시 중단됨), I2 (새롭고 긴급) - SI 정책: 보안 의도가 처리 의도를 선점함
- 실행을 위해 I2 선택
- 현재 의도: I1 (
-
실행:
isolate_system(server_3)즉시 실행notify_team(intrusion_detected)실행- I2 완료, 의도 집합에서 드롭
-
재개:
- I1만 남음:
[process_batch(data1), process_batch(data2), generate_report()] - 일시 중단 지점에서
process_batch(data1)재개
- I1만 남음:
초보자 오류: 보안 경보를 무시하거나 처리 작업을 완전히 포기했을 것입니다. 전문가 통찰: 의도 일시 중단은 반응형 동작을 가능하게 하면서 진행 상황을 보존합니다. SI 스케줄링 정책은 명시적이고 구성 가능합니다.
품질 관문
- 에이전트 아키텍처에 문서화된 정책이 있는 명시적인 SE, SO, SI 선택 함수가 있음
- 각 계획에 현재 믿음에 대해 평가할 수 있는 명확한 트리거 이벤트와 컨텍스트 가드가 정의되어 있음
- 계획 라이브러리에 각 주요 계획 유형에 대한 실패 처리 계획이 포함되어 있음 (성공 경로만이 아님)
- 믿음 업데이트 메커니즘이 모순된 정보를 처리하고 변경 사항을 활성 의도에 전파할 수 있음
- 여러 의도가 명확한 스케줄링/선점 규칙으로 동시에 활성화될 수 있음
- 이벤트 큐 처리가 명시적인 우선순위 할당으로 우선순위가 지정됨 (FIFO 아님)
- 계획 실패가 시스템 충돌이나 조용한 실패가 아닌 이벤트를 트리거함
- 컨텍스트 가드가 상호 배타적이거나 계획 선택이 비결정성을 피하기 위해 명시적으로 정렬됨
- 에이전트가 의도 스택과 트리거 이벤트를 노출하여 자신의 행동을 설명할 수 있음
- 높은 이벤트 부하에서 시스템 성능이 우아하게 저하됨 (무한 루프나 스택 오버플로 없음)
NOT-FOR 경계
적용 불가: 모든 동작이 반응형인 단순 규칙 기반 시스템 (지속적인 목표 없음) → 대신 사용: 기본 규칙 엔진 또는 이벤트-액션 시스템
적용 불가: 실행 중 환경이 변하지 않는 정적 계획 문제
→ 대신 사용: 고전적 플래너 (A*, STRIPS, HTN)
적용 불가: 보장된 응답 시간이나 엄격한 마감 시간이 필요한 실시간 시스템 → 대신 사용: 타이밍 분석이 포함된 실시간 스케줄링 시스템
적용 불가: 모든 조정을 중앙 컨트롤러로 처리할 수 있는 시스템 → 대신 사용: 워크플로우 오케스트레이션 또는 중앙 집중형 작업 큐잉
적용 불가: 자율적인 의사 결정이 없는 순수 데이터 변환 파이프라인 → 대신 사용: ETL 도구, 스트림 처리 프레임워크
적용 불가: 기본 기능으로 기계 학습이나 통계적 추론이 필요한 애플리케이션 → 대신 사용: 필요한 경우 BDI를 조정 계층으로 사용하는 ML 프레임워크