에이전트 엔터프라이즈를 위한 신뢰성

자율 에이전트는 기존의 Salesforce 자동화와 근본적으로 다른 결정적이지 않은 실행 패턴을 도입합니다. Salesforce 플로 및 Apex 제어된 조건에서 반복 가능한 결과를 생성하는 예측 가능한 경로를 따르지만 에이전트는 문제를 동적으로 설명합니다. 예를 들어, 같은 질문을 두 번 묻는 경우 다른 실행 경로를 따르고, 다른 자원을 소비하고, 다른 결과를 생성할 수 있습니다. 이 비결정성은 기존의 테스트 및 모니터링 접근 방식이 해결하지 못하는 신뢰도 문제를 야기합니다.

에이전트 신뢰도 실패 모드는 Salesforce 플로 또는 Apex 실패와 크게 다릅니다. 대규모 언어 모델(LLM) 유추 서비스는 Salesforce Platform과 별도의 가용성 특성이 있는 외부 종속성을 나타냅니다. 에이전트는 프롬프트 지침에도 불구하고 예상 구조를 위반하는 응답을 생성합니다. 에이전트 컨텍스트 준비는 예측할 수 없이 총괄자 제한을 사용합니다. 결정적 쿼리에서 명시적 범위 제어가 있는 동안 에이전트가 개방형 컨텍스트를 요청할 수 있으므로 제한되지 않은 데이터 검색이 에이전트에게 더욱 심각한 영향을 미칩니다.

신뢰할 수 있는 에이전트 아키텍처는 정교한 에이전트에서 좁은 컨텍스트를 가진 간단한 에이전트, 결정적 규칙 엔진, 마지막으로 옴니채널을 통한 인적 핸드오프에 이르기까지 우수하게 저하되는 다중 계층 대체 체인이 필요합니다. 플랫폼 이벤트는 검사점 패턴을 사용하여 지속적인 재시도 대기열을 지원하므로 실패한 워크플로가 마지막으로 성공한 단계에서 다시 시작될 수 있습니다. 회로 차단기는 플랫폼 캐시에서 실시간 상태의 LLM 서비스 상태를 추적하며, 임계값 및 구성에 대한 사용자 정의 메타데이터 유형이 지원하여 연속 실패 후 대체 패턴으로 라우팅합니다. 모니터링하려면 대화 성공률, 실패 사이의 평균 시간(MTBF), 복구까지의 평균 시간(MTTR), 기초 교육 정확도를 추적해야 합니다. Agentforce Observability는 세션 추적, 상태 및 지연 메트릭, 에스컬레이션 및 편향률을 제공하지만, MTBF, MTTR, 기초 교육 정확도와 같은 신뢰도 메트릭을 직접 계측해야 합니다.

이 문서에서는 에이전트가 사진에 나타날 때 변경되는 사항을 다룹니다. 모든 Salesforce 솔루션에 적용되는 기본 신뢰도 패턴(서비스 수준 개체(SLO) 설계, 오류 허용, 확장, 모니터링)은 신뢰도 기둥을 참조하십시오.

Agentforce 에이전트는 Salesforce 플로 또는 Apex 다른 방식으로 실패합니다. 이러한 실패 모드를 이해하면 신뢰도 아키텍처가 형성됩니다.

• LLM 서비스 가용성: LLM 유추 끝점은 경우에 따라 대기 시간이 급증하거나 가용성 문제가 발생합니다. Agentforce는 Analytics 및 기타 Salesforce 서비스와 함께 Trust.salesforce.com에 모니터링된 제품으로 나열됩니다. 그러나 세분화된 LLM 유추 대기 시간 및 요청당 성과 메트릭은 노출되지 않습니다. 임계값 및 구성에 대한 사용자 정의 메타데이터 유형에서 지원하는 낮은 대기 시간 실시간 상태에 대한 플랫폼 캐시를 사용하여 LLM 서비스 상태를 추적하여 회로 중단을 구현합니다. 플랫폼 캐시는 활성화 시간(TTL) 이전에 항목을 제거할 수 있으므로 캐시만이 아닌 지속적인 저장소(예: 사용자 정의 개체)에서 진행 중이거나 삭제된 상태를 유지합니다. 이동 조건을 끝점(연속 실패 횟수(예: 5개) 또는 롤링 기간 동안 임계값을 넘는 오류 비율)으로 조정합니다. 회로가 이동되면 성공적인 테스트 요청이 복구를 나타내기 전까지 회로를 열고 간단한 프롬프트, 캐시된 응답 또는 인적 핸드오프와 같은 대체 패턴으로 라우팅합니다.
• 응답 검증 실패: 에이전트는 프롬프트 지침에도 불구하고 예상 구조를 위반하는 응답을 생성하는 경우가 있습니다. 에이전트가 잘못된 JSON을 반환하거나 필수 필드를 생략하거나 예기치 않은 데이터 유형을 포함하는 경우가 있습니다. 플랫폼 캐시는 확인된 응답 스키마를 저장하여 빠른 유효성 검사를 지원합니다. 확인에 실패하면 확인 오류 및 올바른 구조의 예를 포함하여 세분화된 프롬프트를 사용하여 다시 시도합니다. 최대 재시도 수(3~5)를 설정하여 무한 재시도 루프를 방지합니다.
• 홀루신 감지: 기초 교육 데이터가 불완전하면 에이전트가 가능하지만 잘못된 정보를 생성합니다. “찾을 수 없음”을 반환하는 결정적 쿼리와 달리 에이전트는 추론으로 공백을 채웁니다. Einstein Trust 계층 감사 추적은 사후 관리 검토를 위해 모든 프롬프트, 마스킹 프롬프트, 응답, 독성 감지 결과 및 사용자 피드백을 기록합니다. 단계별 추론은 수집하지 않습니다. 단계별로 추론을 캡처하려면 Agentforce 세션 추적을 사용하여 추론 엔진 실행을 기록합니다. 에이전트가 Data 360(기존의 Data Cloud) 검색 증가 생성(RAG) 검색 소스를 인용해야 합니다. 작업을 실행하기 전에 실제 편차를 파악하기 위해 검색된 소스에 대한 교차 참조 에이전트 청구 인라인 확인은 이미 컨텍스트에 있는 소스에 대해 실행되므로 대기 시간이 적습니다. 두 번째 모델 통화 또는 외부 서비스와 같이 별도의 주행이 필요한 점검은 더 비용이 많이 부과됩니다. 재무 또는 주문 업데이트를 비롯한 영향력이 큰 쓰기에 대해 해당 확인을 예약하고 실시간 대화 중에 비동기식으로 실행합니다.
• 총리 한도: 에이전트 컨텍스트 준비는 대화 플로를 기반으로 예측할 수 없이 Salesforce 개체 쿼리 언어(SOQL) 쿼리, CPU 시간 및 힙 메모리를 사용합니다. Proactive Monitoring은 Salesforce가 고객 계정을 사전에 모니터링하는 Salesforce Success Plan의 서명 성공(이전의 서명 지원) 권한 서비스입니다. Proactive Monitoring 모든 고객이 사용할 수 있는 셀프 서비스 구성 가능한 경고가 아닙니다. 셀프 서비스 총괄자 제한 모니터링의 경우 스케일 센터를 사용하여 제한에 가까운 자원 집약 에이전트 작업을 식별합니다. 대규모 레코드 컬렉션을 검색하는 에이전트 작업에서 페이지 매김을 구현합니다. 자주 액세스하는 참조 데이터의 경우 플랫폼 캐시를 사용하십시오.
• 에이전트 컨텍스트의 데이터 왜곡: 기회가 10,000개가 넘는 계정 또는 활동 내역이 비교적 큰 사례에 대한 컨텍스트를 검색하는 에이전트는 배치 Apex 동일한 데이터 왜곡 문제에 직면합니다. 범위를 제어하는 결정적 쿼리와 달리 에이전트 추론은 예측할 수 없이 “모든 내역”을 요청할 수 있습니다. 이를 방지하려면 합리적인 하드 제한을 사용하여 에이전트 작업을 설계하고(예: 상위에 대한 하위 항목 수는 200개) 제한을 초과할 경우 샘플링 전략을 구현합니다. 한도는 에이전트의 컨텍스트에 들어가는 데이터의 양을 제한합니다. 색인화되지 않은 필터 또는 왜곡된 상위에 대한 집계가 적용되기 전에 전체 하위 집합을 스캔하므로 쿼리 자체가 저렴하게 유지되도록 선택적 인 색인화된 필터와 페어링합니다.

에이전트가 완전히 실패하지 않고 기능이 감소된 상태로 계속 작동할 수 있도록 다중 계층 대체 체인을 설계합니다.

• 전체 컨텍스트를 가진 기본 에이전트: 완벽한 Data 360 기초 교육, 광범위한 대화 내역, 복잡한 추론을 갖춘 정교한 에이전트입니다. 최고 품질이지만 자원 집약적이며 실패 위험이 가장 높습니다.
• 감소된 컨텍스트의 보조 에이전트: 축약된 컨텍스트를 사용하여 에이전트를 더 간단하게 만들 수 있습니다(예: 지난 30일과 모든 내역, 상위 5개의 벡터 검색 결과 및 상위 20개). 컨텍스트가 작을수록 토큰 수가 줄어들고 추론이 빠르고 실패 가능성이 줄어들지만 축소된 컨텍스트가 여전히 과업에 필요한 데이터를 포함하는 경우에만 해당 컨텍스트가 줄어듭니다.
• 결정적 규칙 엔진: 에이전트 추론이 실패할 때 일반적인 시나리오를 처리하는 기존 Salesforce 플로 또는 Apex 논리입니다. 규칙은 새로운 상황에 적용할 수 없지만 알려진 패턴을 신뢰할 수 있게 처리합니다. 주문 확인 에이전트는 표준 확인 규칙으로 되돌아가고, 리드 점수 매기기 에이전트는 규칙 기반 점수 계산으로 되돌아갑니다.
• 옴니채널을 통한 인간 핸드오프: 자동 옵션이 만료되면 사람 대기열로 라우팅합니다. 기술 기반 라우팅을 구성하여 에스컬레이션이 적절한 전문 지식에 도달하도록 합니다. 시도한 전략, 에이전트에 대해 계산하는 신뢰도 점수, 실패 이유 등 전체 대화 컨텍스트를 전달하여 효율적인 인적 중재를 지원합니다.

플랫폼 이벤트로 트리거된 오케스트레이션 Salesforce 플로 또는 Apex 대체 논리를 구현합니다. 각 계층은 성공한 전략을 기록하여 실패 패턴 및 대체 효과를 파악합니다.

이 섹션의 모든 플랫폼 이벤트 패턴은 72시간 재생 보존 기간을 제공하는 대용량 플랫폼 이벤트 유형을 가정합니다. 표준 볼륨 플랫폼 이벤트는 24시간 동안만 유지됩니다. 재생 지속성이 신뢰성 요구 사항인 모든 에이전트 복원, 재시도 대기열, 검사점 패턴에 대용량 이벤트 유형을 사용합니다. 플랫폼 이벤트는 에이전트 워크플로가 오류를 생존하고 자동으로 복구할 수 있도록 내구성 있는 메시지를 제공합니다.

• Checkpoint Agent 진행 상황: 다단계 에이전트 워크플로는 각 성공 단계 후 검사점 이벤트를 게시합니다. 계약 처리 에이전트가 문서 추출을 완료하고 추출된 데이터를 사용하여 ContractParsed 이벤트를 게시한 다음, 조항 분석을 진행합니다. 조항 분석에 실패할 경우 ContractParsed 이벤트를 재생하여 다시 구문 분석하지 않고 추출된 데이터에서 다시 시작합니다. 이는 재생 중에 워크플로를 다시 시작하는 대신 이벤트를 다시 전달하므로 검사점 페이로드가 해당 데이터를 전달하고 구독자가 동일한 권한이 있는 경우 작동합니다. 상관 관계 ID, 완료된 단계, 연속에 필요한 상태를 포함하여 이벤트 페이로드에 검사점 상태를 저장합니다.
• Exponential backkoff를 사용하는 재시도 대기열: 실패한 에이전트 요청은 페이로드에서 재시도 수가 있는 AgentRetryRequested 이벤트에 게시됩니다. 이벤트 구독자는 기하형 백오프 지연(예: 30초, 2분, 8분, 30분)을 사용하여 재시도를 처리합니다. 최대 재시도 수(일반적으로 5개) 후 대기열에 라우팅하고 경고 작업을 수행합니다. 고볼륨 플랫폼 이벤트는 72시간의 재생 기간을 유지합니다. 구독자가 조직 서비스 점검 기간 또는 배포 가동 중지 후에 확인할 수 있도록 에이전트 재시도 대기열에 대용량 이벤트 유형을 사용합니다. 표준 볼륨 플랫폼 이벤트는 24시간 동안만 유지됩니다.
• 이벤트 기반 오케스트레이션: 에이전트 워크플로를 느슨하게 연결된 이벤트 체인으로 설계합니다. 리드 만들기는 LeadCreated를 게시합니다. 리드 점수 매기기 에이전트가 LeadScored를 구독하고 점수를 매기고 게시합니다. 리드 라우팅 에이전트가 LeadScored를 구독하고 적절한 대기열에 할당합니다. 각 에이전트는 실패하고 독립적으로 다시 시도할 수 있습니다. 단일 에이전트 실패는 전체 워크플로를 차단하지 않으며 종속성이 복구되면 다운스트림 에이전트가 처리합니다.
• 상관 ID 추적: 모든 관련 이벤트 페이로드에 상관 관계 ID를 사용자 정의 필드로 포함합니다. 불투명하고 인접하지 않은 식별자인 replayId의 Pub/Sub API를 사용하여 이벤트를 재생하여 72시간 유지 기간 내에서 워크플로 내역을 재구성합니다. 상관 관계 ID 기반 디버깅을 활성화하려면 수신 이벤트를 replayId 및 상관 관계 ID로 사용자 정의 개체에 기록하는 구독자 측 패턴을 구현하여 교차 이벤트 추적 가능성을 활성화합니다. 이 로깅 패턴은 기본 플랫폼 쿼리 기능이 아닌 사용자 정의 구현입니다.

동기 제한을 초과하는 에이전트 작업을 비동기 컨텍스트로 이동하여 더 높은 총괄자 제한과 더 긴 시간 초과를 허용합니다.

• 대량 에이전트 작업에 대한 배치 Apex: 1,000개 이상의 레코드를 분석하는 에이전트는 200개의 SOQL 쿼리, 150개의 DML 문(최대 10,000개의 DML 행) 및 실행 방법당 60,000밀리초(60초)의 CPU 시간을 제공하는 배치 Apex 혜택을 누릴 수 있습니다. 야간 리드 가져오기를 처리하는 리드 점수 매기기 에이전트 내역 사례 전반의 사례 분위기 분석 전체 파이프라인을 분석하는 기회 예측
• 다단계 워크플로를 위한 대기열: 여러 개의 외부 API 호출, 대규모 데이터 집합 분석 또는 연장된 처리 시간이 필요한 복잡한 에이전트 워크플로에서는 대기 가능한 Apex 체인을 사용합니다. 각 대기 가능 작업은 CPU 시간 60개와 힙 12MB를 가져옵니다. 단일 작업 제한을 초과하는 워크플로의 경우 다음 대기 가능에 연결합니다. 실패한 작업이 마지막으로 완료된 단계에서 다시 시작되도록 사용자 정의 개체에서 진행 상황을 추적합니다.
• 단순 비동기식 핸드오프의 @future: 알림 보내기, 외부 시스템에 로그인 또는 비 긴급 업데이트와 같은 경량 에이전트 작업은 @future 메서드를 사용합니다. Fire-and-forget 패턴은 워크플로에서 결과를 반환할 필요가 없고 실패를 허용할 수 있는 경우에 적합합니다.

Apex 작업 페이지(설정 → Apex 작업) 및 Apex Flex 대기열을 통해 비동기 처리 용량을 모니터링합니다. 최대 5개의 동시 배치 작업은 병렬 에이전트 처리를 제한합니다. Apex Flex 대기열에 추가 작업 대기열이 있으며, 이는 최대 100개의 작업을 Holding 상태로 유지합니다. 모든 비동기식 Apex 유형(배치, 미래, 대기 가능 및 예약된 Apex)은 비동기식 Apex 실행에 대해 동일한 조직 전체 일일 제한(DailyAsyncApexExecutions)을 공유합니다. 사용자 라이센스 수의 250,000개 또는 200배 이상입니다. 빈도가 높은 에이전트 폴링을 실행하거나 구독자 대기열을 재시도하면 대기 가능성이 이 할당량을 빠르게 소모할 수 있습니다. 이를 방지하려면 이러한 대기열을 일괄 처리하거나 제한 범위 내에 유지하십시오. 이는 대기열에만 별도의 할당이 아닌 모든 비동기식 Apex 유형 전체에 적용됩니다. 팀이 수용력을 사전에 관리할 수 있도록 소비가 이러한 제한에 도달하면 경고를 보냅니다.

결정적이지 않은 동작을 해결하는 테스트 전략을 통해 프로덕션 전에 에이전트의 복원 능력을 검증합니다.

• 전체 복사 Sandbox에서 테스트 로드: 전체 데이터 볼륨을 사용하여 프로덕션 규모 로드에서 에이전트 성능을 테스트합니다. 최대 수요와 일치하는 동시 대화를 시뮬레이션합니다. 스트레스를 받는 상태에서 성능 저하를 식별하는 p95 및 p99 대기 시간을 측정합니다. 총괄자 제한 소비가 최대 로드 시 임계값 미만으로 유지되는지 확인합니다. 데이터가 줄어든 부분 복사 sandbox에서 테스트를 로드하면 데이터 용량이 에이전트 성과에 직접적인 영향을 미치므로 잘못된 신뢰를 얻을 수 있습니다. 해당 테스트를 실행하기 전에 Salesforce에서 승인을 받으십시오(성능 테스트 요청의 경우 최소 1주일 전). 승인되지 않은 테스트는 제한 또는 차단될 수 있습니다.
• 장애 주입: 복구 메커니즘을 확인하기 위해 의도적으로 실패를 도입합니다. 차단기 모니터링 서비스 계층에서 LLM 유추 실패를 시뮬레이션하여 차단기가 활성화되는지 확인합니다. SOQL 예외를 입력하여 오류 처리를 테스트합니다. 에이전트의 손상된 응답을 통해 확인 논리를 테스트합니다. 데이터 왜곡(하위 항목이 10,000개가 넘는 계정)을 도입하여 페이지 매김 논리를 테스트합니다. 적극적인 시간 초과를 설정하여 시간 초과 처리를 테스트하고 전략을 재시도합니다.
• 카오스 엔지니어링: 플랫폼 이벤트 구독자를 무작위로 비활성화하여 재생 복구를 테스트합니다. 실행 중에 비동기 작업을 종료하여 검사점 재시작을 테스트합니다. 외부 시스템에 변수 대기 시간을 도입하여 프로그레시브 시간 초과 전략을 테스트합니다. 혼란 실험은 실질적인 실패 조합의 복원 능력을 검증합니다. 스테이징 환경에서 정기적인 혼란 일정을 예약하여 에이전트가 발전함에 따라 복원력을 유지합니다.
• 장기 실행 안정성 테스트: 72시간 이상 에이전트 작업 부하를 지속적으로 실행하고 시간 종속 실패를 모니터링합니다. 오류가 누적되고 지속적인 작업에서만 성능이 점진적으로 저하됩니다. CPU 시간 추세를 추적하여 실행 과정에서 점진적인 저하를 식별합니다.

목표적인 신뢰도 측정을 지원하는 서비스 수준 지표(SLI)를 정의합니다. 프로덕션 실패 후가 아니라 에이전트 구축 전에 SLO를 설정합니다.

• 대화 성공률: 오류 또는 시간 초과 없이 완료된 에이전트 대화 비율 설계에 따라 최종 대체 계층인 에스컬레이션을 실패가 아닌 성공으로 인간에게 유익한 핸드오프를 계산합니다. 메트릭에 대해 실패하거나 의도하지 않은 에스컬레이션을 계산합니다. 이는 유용한 신뢰성 신호이지만, 정중한 사인오프는 해결되지 않은 문제를 마스킹할 수 있으므로 사용자 환경에 적합하지 않은 프록시입니다. 리드 점수 매기기 성공 기준은 계약 검토와 다르므로 에이전트 유형 및 사용 사례별로 별도로 추적합니다. 성공률이 SLO(일반적으로 95~99%) 아래로 떨어지면 경고합니다.
• 실패 사이의 평균 시간(MTBF): 에이전트 실패 사이의 평균 운영 시간입니다. MTBF가 높으면 실패 횟수가 줄어들고 신뢰도가 향상됩니다. 총 에이전트 운영 시간을 실패 수로 나눈 값으로 계산합니다. 에이전트 유형별로 추적하여 최적화 투자가 필요한 가장 신뢰할 수 없는 에이전트를 식별합니다.
• 복구까지의 평균 시간(MTTR): 오류 감지에서 서비스 복원까지의 평균 시간입니다. 플랫폼 이벤트 재생 및 회로 차단기를 통한 자동 복구는 실무 중재보다 훨씬 빠르고 수동 오류가 줄어듭니다. MTTR을 낮추면 사고당 비즈니스 영향이 줄어듭니다.
• 지정 정확도: 소스 데이터 확인을 기반으로 에이전트 응답의 실제 정확도 비율입니다. Data 360 소스에 대한 청구를 확인하는 샘플 임의의 에이전트 응답 95% 미만의 기초 교육 정확도는 신속하게 구체화하거나 더 나은 컨텍스트 검색이 필요한 환각 문제를 나타냅니다.
• 플랫폼 이벤트 재생 간격: 누락되었거나 전달되지 않은 이벤트 수입니다(예: 보존 기간이 벗어난 구독자 오프라인). 격차 제로는 건강한 이벤트 중심 아키텍처의 긍정적 신호입니다. 격차는 구독자 문제, 이벤트 게시 실패 또는 수용력 제약을 나타냅니다. 위에 설명된 구독자 측 로깅 패턴을 사용하여 이러한 공백을 추적하고 각 이벤트의 replayId 및 상관 관계 ID를 사용자 정의 개체에 기록합니다.

신뢰할 수 있는 에이전트는 실패를 위해 먼저 설계하여 SLI/SLO를 정의하고, 총괄자 제한을 인지하는 컨텍스트 처리를 수행하고, 구축하기 전에 다중 계층 대체 체인을 만들어야 합니다. 워크플로가 자동으로 복구되도록 레이어 차단기 및 플랫폼 이벤트 기반 재시도 및 검사점 논리를 사용하여 사람의 핸드오프를 마지막 수단으로 사용합니다. 체계적인 로드, 오류 삽입, 혼란 테스트를 통해 해당 설계를 확인한 다음, 프로덕션에서 동일한 SLI를 계속 모니터링하여 시간에 따른 유지 상태를 확인합니다.

주요 신뢰도 기둥의 신뢰도 지침은 플랫폼별 고려 사항이 포함된 에이전트에 적용됩니다. 성공적인 에이전트 아키텍처는 적절한 감독과 자동 기능의 균형을 맞추어 신뢰도가 떨어지거나 극단적인 사례가 발생할 때 에스컬레이션하면서 일시적인 실패로부터 자체 복구를 할 수 있습니다.

좋게 설계된 프레임워크에 대한 사용자 의견을 공유하십시오.