예: 에이전트 스크립트로 더 신뢰할 수 있는 에이전트 지침

에이전트 스크립트 전 지침

다음은 환불 요청을 처리하는 하위 에이전트에 대한 레거시 빌더 지침입니다. 고객에게 유효한 주문 ID가 있거나 고객이 VIP 고객인 경우 주문을 환불할 수 있습니다. 주문이 반품할 수 있는 경우 에이전트가 환불 요청을 만듭니다. 주문이 반품할 자격이 없는 경우 에이전트가 담당자가 고객을 팔로우업할 수 있도록 사례를 만들 것을 제안합니다.

이는 상대적으로 간단한 예입니다. 또한 비즈니스 사례를 처리하는 데 필요한 워크플로는 훨씬 더 복잡할 수 있습니다. 그러나 많은 사항을 올바르게 만들려면 LLM에 의존합니다.

• 올바른 결정을 내리려면 에이전트가 귀하의 비즈니스 컨텍스트를 이해해야 합니다. 예를 들어, 주문에 환불을 받을 자격이 있는 이유는 무엇입니까? 레거시 빌더에서 일반 언어를 사용하여 정의할 수 있으며, 이를 통해 에이전트가 이해할 수 있도록 프롬프트를 구체화하는 데 소요되는 최대 많은 토큰과 시간을 추가할 수 있습니다. 또는 에이전트에게 주문 자격이 있는지 여부를 결정하기 위한 작업을 실행하도록 지시할 수 있으며, 이를 수행할지 여부는 에이전트가 추론 프로세스 동안 결정합니다.
• 에이전트는 주문 번호를 확인한 다음, 고객이 VIP인지 확인한 다음, 올바른 정보를 수집한 다음, 요청을 작성해야 하는 계속 지침을 이해해야 합니다. 또한 에이전트는 매번 지침을 올바르게 따라야 합니다. 레거시 빌더에서 가장 좋은 방법은 단일 명령 필드에 지침의 전체 순서를 포함하고 명확한 주문 용어를 사용하는 것입니다(예: "첫 번째, X... 두 번째, Y... 마지막으로, Z..."). 그러나 LLM은 순서가 아닌 다음의 가장 가능성 높은 단계를 예측하는 데 가장 적합합니다. 자연어 교육이 복잡할수록 에이전트가 혼동할 가능성이 높습니다.
• 에이전트는 어떤 상태와 조건과 따라서 어떤 지침이 적용되는지 이해해야 합니다. 레거시 빌더에서 일반 언어를 사용하여 가능한 사용자 상태를 나타내는 논리와 값을 설명해야 하므로 메시지가 크고 대기 시간이 길어질 수 있습니다. 어떤 상태 및 조건이 true인지에 관계없이 전체 프롬프트가 매번 LLM에 전송됩니다. 즉, LLM은 관련이 없는 정보를 살펴보고 관련 정보를 올바르게 식별한 다음 관련 지침만 준수해야 합니다. 이는 내용 테이블 없이 긴 지침 설명서를 전달하는 것과 유사합니다. 특히 방해를 받으면 잊어버리고 단계를 건너뛰거나 자리를 잃을 가능성이 높습니다.

에이전트 스크립트 후 지침

새 빌더에서 그래프 기반 Atlas 추론 엔진 및 에이전트 스크립트는 에이전트의 동작을 제어하고 프롬프트를 미세 조정할 수 있는 추가 도구를 제공하여 에이전트가 필수 비즈니스 프로세스를 준수하도록 합니다. 다음은 에이전트 스크립트에 작성된 유사한 하위 에이전트에 대한 지침의 예입니다.

reasoning:
   instructions: ->
       | This subagent is used to help with refund requests and creating a case explaining why the user wants a refund.

       if @variables.orderValidated == None
	 run @actions.Validate_Order
	  with Customer_ID=@variables.verifiedCustomerId
	  with Order_ID=@variables.orderId
	  set @variable.orderValidated=@outputs.Order_Validated

       if @variables.loyaltyTierLevel == None
	 run @actions.Get_Loyalty_Tier
	  with Customer_ID=@variables.verifiedCustomerId
	  set @variable.loyaltyTierLevel=@outputs.Loyalty_Tier

       if @variables.orderValidated == True
           | Help the customer create a refund request. Ask the customer to explain why they want a refund and pass the details into {!@actions.Create_Refund_Request}.

       if @variables.orderValidated == False and @variables.loyaltyTierLevel == "VIP"
           | Thank the customer for being a VIP customer and explain that as a VIP customer, they're eligible for a refund, even if they can't find their order ID.
Ask the customer to explain why they want a refund and pass the details into {!@actions.Create_Refund_Request}.

       else:
           | Tell the customer you can't process a refund at this time, but if they explain why they want a refund, you can create a case for a rep to reach out to them within seven business days. To create a case, ask them to explain why they
want a refund and use {!@actions.Create_New_Case}.

다음은 이러한 지침이 추론 및 결정주의를 결합하여 에이전트의 신뢰도를 높이는 몇 가지 주요 방법입니다.

에이전트가 결정적으로 작업을 실행하여 고객 및 고객의 현재 상태에 대한 정보를 가져옵니다.

작동 방식: 에이전트 스크립트로 작성된 에이전트의 경우 LLM을 사용한 추론이 이루어지기 전에 에이전트가 하위 에이전트의 추론 지침을 상단에서 하단으로 해결하고 논리 식을 작성된 순서대로 실행합니다. 하위 에이전트 명령을 해결하여 프롬프트 구축 방법을 참조하십시오. 이 경우, 추론 지침은 두 가지 작업(주문 확인 및 충성도 계층 가져오기)으로 시작되므로 에이전트가 추론에 사용하는 프롬프트를 구성하기 전에 주요 고객 정보에 액세스할 수 있습니다. 또한 조건부에 중첩되어 있으므로 에이전트는 데이터가 아직 가져오지 않은 경우에만 작업을 실행합니다. 이러한 작업은 논리하기 전에 실행되므로 출력을 사용하여 프롬프트를 유압하고 미세 조정할 수 있습니다.

혜택:

• 에이전트에게 항상 정확하고 신뢰할 수 있는 정보에 액세스할 수 있는 권한을 부여합니다.
• 사전 요구 사항 단계("첫 번째, 데이터 가져오기")를 추론에서 제외하여 에이전트 지침의 복잡성을 줄입니다. 에이전트는 작업을 수행하기 위해 시간과 토큰을 소비하는 대신 작업을 수행합니다. 따라서 가장 도움이 되는 위치에 대한 사고를 저장할 수 있습니다.

고객 및 상태에 대한 가장 중요한 정보는 에이전트 컨텍스트 메모리에 의존하지 않고 변수에 저장됩니다.

작동 방식: 에이전트가 종종 슬롯 채우기를 통해 입력 및 출력을 충분히 채우는 작업을 수행하지만, 특히 하위 에이전트 또는 대화 순서에서 정보를 재사용하려는 경우 일부 정보는 우연하게 남기지 않아도 됩니다. 이 경우 주문 확인 및 충성도 계층 가져오기 작업의 출력이 변수에 저장되므로 조건부 문에서 사용할 수 있습니다.

혜택:

• 하위 에이전트, 작업 및 대화 전반에서 안정적인 에이전트 값 및 데이터를 제공하여 에이전트 정확성을 향상합니다.
• 에이전트의 컨텍스트 메모리에서 검색되는 정보와 달리 변수에 저장된 값 및 데이터는 다른 에이전트 작업, 조건 또는 필터에 대한 입력과 같은 결정적 워크플로에서 다운스트림으로 사용할 수 있습니다.

모든 사례 또는 상태에 대해 LLM에 같은 대규모 프롬프트를 보내는 대신 조건부 문 및 변수는 에이전트 추론에서 LLM에 전송되는 지침 및 옵션을 제한하고 구체화합니다.

작동 방식: 에이전트에게 집중적이고 직접적인 자연어 지침을 제공하면 가장 적합한 이유가 있습니다. 추론을 시작하기 전에 Agentforce 변수 값을 기반으로 각 조건부 문을 결정적으로 평가합니다. 그런 다음 에이전트가 추론 프롬프트를 구성하면 해당하는 지침만 포함됩니다.

현재 컨텍스트	LLM에 전송된 지침
주문이 확인됨 @variables.orderValidated == True	Help the customer create a refund request. Ask the customer to explain why they want a refund and pass the details into {!@actions.Create_Refund_Request}.
주문이 확인되지 않지만 고객이 VIP 고객임 @variables.orderValidated == False AND @variables.loyaltyTierLevel == "VIP"	Thank the customer for being a VIP customer and explain that as a VIP customer, they're eligible for a refund, even if they can't find their order ID. Ask the customer to explain why they want a refund and pass the details into {!@actions.Create_Refund_Request}.
기타 모든 사례 else	Tell the customer you can't process a refund at this time, but if they explain why they want a refund, you can create a case for a rep to reach out to them within seven business days. To create a case, ask them to explain why they want a refund and use {!@actions.Create_New_Case}.

노트 이 예에서는 하위 에이전트 추론 지침만 살펴봅니다. 그러나 동일한 변수 및 원칙을 사용하여 에이전트 작업에 필터를 적용하고 에이전트에게 더 큰 프로세스에서 고객의 현재 상태 및 단계와 관련된 작업만 표시되도록 할 수 있습니다.

혜택:

• 추론을 시작하기 전에 명령을 미세 조정하여 명령 준수를 개선하고 대기 시간을 줄입니다. 관련 및 관련 없는 지침을 살펴볼 필요가 없으므로 처음부터 올바른 지침을 얻을 수 있습니다.
• LLM에 사용 가능한 지침 및 옵션을 줄여 전반적인 정확도 및 응답 품질을 향상합니다. 에이전트가 선택해야 하는 항목이 적을수록 올바른 항목을 선택할 가능성이 높습니다.