例: エージェントスクリプトを使用したエージェントの指示の信頼性の向上

エージェントスクリプト前の手順

返金要求を処理するサブエージェントの従来のビルダーの手順を次に示します。顧客が有効な注文 ID を持っている場合、または顧客が VIP 顧客の場合、注文は返金の対象になります。注文が返品の対象である場合、エージェントは返金要求を作成します。注文が返品の対象ではない場合、エージェントは営業担当が顧客をフォローアップするためのケースの作成を申し出ます。

これは比較的単純な例です。(ご存じのように、ビジネスケースの処理に必要なワークフローは大幅に複雑になる可能性があります)。しかし、多くのことを正しく行うには LLM に依存します。

• エージェントは、正しい意思決定を行うためにビジネスコンテキストを理解する必要があります。たとえば、注文が返金の対象となる理由は?従来のビルダーでは、プレーンな表現を使用して定義できます。これにより、トークンが多くなり、エージェントが理解できるようにプロンプトを絞り込むのに時間がかかります。または、注文が対象かどうかを判断するアクションを実行するようにエージェントに指示できます。エージェントは、このアクションを推論プロセス中に実行するかどうかを決定します。
• エージェントは、従う命令の順序を理解する必要があります(注文番号を検証し、顧客が VIP であるかどうかを検証し、正しい情報を収集してから要求を作成します)。また、エージェントは毎回指示に正しく従う必要があります。従来のビルダーでは、1 つの命令項目に完全な命令シーケンスを含めて、明確な順序 (「First, do X... Second, do Y...Final, do 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 による推論が実行される前に、エージェントはサブエージェントの推論命令を上から下に解決し、途中の論理式を記述された順序で実行します。「How Subagent Instructions are Resolved to Build a Prompt」を参照してください。この場合、推論の手順は 2 つのアクション ([Validate Order (注文を検証)] と [Get Loyalty Tier (ロイヤルティランクを取得)]) で始まるため、エージェントは推論に使用するプロンプトを作成する前に主要な顧客情報にアクセスできます。(さらに、条件内でネストされているため、エージェントはデータが取得されていない場合にのみアクションを実行します)。これらのアクションは推論が実行される前に実行されるため、出力を使用してプロンプトをハイドレートし、微調整できます。

利点:

• 正確で信頼性の高い情報に毎回エージェントがアクセスできるようにします。
• 前提条件ステップ (「最初にデータを取得する」) を推論から除外することで、エージェントの指示の複雑さを軽減します。エージェントは、時間とトークンを費やして対応を考えるのではなく、実行するだけです。そのため、最も役立つ場所についての考え方を保存できます。

顧客と状態に関する最も重要な情報は、エージェントのコンテキストメモリに依存する代わりに変数に保存されます。

しくみ:エージェントは多くの場合、時間枠の入力と出力の入力を適切に行いますが、一部の情報は重要すぎて、特にサブエージェントや会話のターンで再利用する場合は、考慮せずに残しておきます。この場合、[注文を検証] および [ロイヤルティランクを取得] アクションの出力は変数に保存されるため、条件ステートメントで使用できます。

利点:

• サブエージェント、アクション、会話のターン全体で安定した値とデータをエージェントに提供することで、エージェントの精度を高めます。
• エージェントのコンテキストメモリから取得される情報とは異なり、変数に保存されている値とデータは、他のエージェントアクション、条件、検索条件への入力など、確定的ワークフローの下流で使用できます。

すべてのケースまたは状態で同じ大きなプロンプトを 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 は、関連する指示と関連のない指示を取捨選択する必要はありません。最初から適切な指示を取得します。
• LLM で使用できる命令とオプションを減らすことで、全体的な精度と応答品質を向上させます。エージェントが実行する必要のある選択肢が少ないほど、適切な選択を行う可能性が高くなります。