Agentforce實現可靠的代理行為指南

Olfa Kharrat，Agentforce產品管理總監
Reinier van Leuken，Agentforce產品管理資深總監

Salesforce於1999年成立至今，始終以信任為首重價值，這項價值帶領本公司，率先推出雲端運算和SaaS的全新技術模型。企業相當信任Salesforce，於是將深具價值的公司資料存放在雲端，深知這些資料會獲得適當的存取控制管理，得以確保安全無虞。信任如今仍然重要，但在代理式AI的時代，信任的定義更為廣泛。隨著公司愈來愈倚賴自主代理執行關鍵業務功能，代理必須成為值得信賴的業務合作夥伴，確保作業準確、相關且可靠，其中又以可靠性最為重要。

這樣的話，如何打造可靠的代理呢？可靠性通常意味著相同的輸入會提出相同的結果。不過，代理不一定會如此運作，因為代理是由大型語言模型(LLM)所推動，這些模型在本質上不具確定性。這使得代理能夠針對具體情況，靈活開發量身打造的創意解決方案，卻無須清楚設定所遇到的各種條件或情況。然而，代理同樣需要管理，方可符合業務要求且遵循營運準則。在執行業務流程時，代理必須展現穩定可靠的效能，並產生符合確定性限制的業務成果。確定性會帶來僵化和紀律，與代理提供的自主性和流動性相抵觸。因此，成功打造代理的關鍵，是在創意流動性與企業控制之間取得適度平衡。

本文件旨在說明發展可靠代理的關鍵考量要點。文中定義了五個代理控制層級，並提出掌握及控管各層級代理行為的最佳實務。這些指引處理了Agentforce推理引擎的運作方式。本文件將隨著Agentforce的成長滾動式更新，以期反映出最新的最佳實務。

本文件假設讀者熟悉設計和打造Agentforce代理的基本知識。為了介紹Agentforce，我們建議讀者：

• 檢視agentforce.com上的資源。
• 瀏覽教學課程「成為Agentblazer冠軍 」。該課程探討核心AI概念，並協助您為關鍵任務打造基本代理。
• 在help.salesforce.com 上閱讀更多Agentforce的相關資訊，尤其是「設計與實施代理 」。這份學習地圖將帶領您完成所有重要的生命週期步驟，包括構思解決方案、設定和配置代理、進行測試，部署和監控。

我們首先比較代理與其一板一眼的對手：聊天機器人，以便您瞭解後面將談到的代理行為。

聊天機器人：固定規則的遵循者

聊天機器人會遵循預先決定的決策樹，這些決策樹建構了它們可參與的對話。在決策樹的移動軌跡，取決於使用者提出的答案。此答案可能選自預先決定的一組選項，或是自由文字的答案。若是自由文字的答案，則使用預測模型分類其意圖。決策樹會規劃所有可能的對話路徑，並指定聊天機器人在每個步驟的回應。預設規則嚴格規範了聊天機器人的行為。當使用者的輸入不同於已知路徑，或是預測模型未經訓練，無法分辨出使用者的特定意圖時，聊天機器人就無法妥善回應。

代理：適應性與直覺性

相對之下，代理則是運用LLM的力量，還有在自然語言處理(NLP)方面的先進功能。LLM讓代理能理解使用者輸入背後的意圖，即使其措辭不同於預期亦然。代理接著依據對意圖的理解，即可從諸多可能性之中，選出最為合適的動作。代理甚至能建構截然不同的全新回應。這種靈活度與適應性，讓代理展現出有別於聊天機器人的優點。

以烹飪為例

我們以新手廚師和熟練主廚為例，說明聊天機器人與代理的差異之處。

• 新手廚師(聊天機器人)非常依賴鉅細靡遺的食譜，其中涵蓋精密的測量值、逐步說明及指定烹調時間。只要偏離食譜，烹調上就會釀成大錯。同樣地，聊天機器人必須在預先設定的決策樹範圍內運作。
• 至於經驗豐富的主廚(代理)，則擁有長年累積而來的烹飪經驗和直覺。只要全面瞭解您的喜好，並簡要說明利用的食材，就能烹調出符合需求的美食。每次採用的確切步驟可能有所不同，不同版本的菜色或許有細微差異，但整體結果始終一致，令人滿意。同樣地，代理可以根據使用者輸入的情境和意圖，調整其方法以達成成功互動。

綜上所述，代理與聊天機器人的根本差異，就在於兩者的適應力，以及輸入不符預期時的應對能力。

代理智慧具備的一項獨特功能，在於能適時協調及觸發最為恰當的動作。這種靈活度消弭了針對每名潛在使用者詳細設定以利互動的必要性。

在Agentforce，打造代理與主題、動作及自然語言指示與描述密不可分。

主題

主題是代理的「待辦事項」。主題有分類說明、範圍和指示等屬性，藉此定義各項工作及完成方式。主題包括代理可執行的動作，還有控制這些動作如何執行的指示。

行動

動作是代理在進行工作時可以履行的預先定義任務。這些動作可分為五種不同類型：

• 執行Apex程式碼
• 呼叫API
• 執行流程
• 取得提示詞範本的LLM回應
• 呼叫預測模型

自然語言的指示與描述

代理的定義所含的自然語言指示，用於描述代理資產及界定操作準則。指示是針對動作和主題撰寫。

• 動作。動作包含：
  • 說明動作的用處，據此告知推理引擎何時執行此動作的指示。
  • 輸入自然語言描述以利代理做好準備。
  • 輸出則包含如何格式化及使用動作的自然語言描述。
• 主題。主題包含管理如何在更高層級執行動作的指示。例如，指示可以規範攸關語調、所需動作順序、可能前提條件，或是將對話轉接給真人的安全機制。主題還包含分類說明及範圍描述。這一切可確保代理維持在定義角色的範圍內，並如實履行工作。
• 資料。代理需要資料才能順利完成工作。資料可以是CRM一類的結構化資料，或是類似公司知識文章的非結構化資料。代理使用動作輸入以存取資料。舉例來說，動作可呼叫根據CRM資料產生的提示詞範本，或是使用RAG技術增強的非結構化資料區塊。

這些各式各樣的建構組塊，若經正確打造，可協助代理在適當邊界內運作，同時履行其預期目的。

Agentforce的推理引擎會將這些建構組塊安排成適當的代理行為。這是運用在主題和動作定義的自然語言指示與描述達成。推理引擎建立在ReAct之上，其為Yao等人在2022年引進的一種創新LLM推理機制。這種機制透過推理問題、採取行動、觀察動作結果，並重複循環直到完成任務，以模擬人類如何管理任務。

Salesforce代理即是依循這種機制：

1. 原因：理解使用者的意圖，並對應適當的主題和動作。
2. 行動：啟動正確的連續動作。
3. 觀察：對照使用者意圖以評估動作結果。未能達成意圖時，可根據至今獲得的結果，依主題/動作指示和描述進一步推理。如果達成意圖，則提出最終回應，同時遵循可能的格式化指示。
4. 重複：反覆執行這些步驟，直到達成最終指示的步驟為止。

推理引擎會在每道原因及觀察步驟運用LLM。根據動作類型，推理引擎也會在「行動」步驟中使用LLM。

本節概述的分層方法，用於強化代理的確定性。每個層級建立在前一層級之上，複雜度和能力隨之增加，據此對代理行為打造更高的控制力。

第一層著重在讓代理自主識別相關主題，然後使用目標而非明確指示，選擇適當的動作。核心機制是理解情境以回應使用者輸入。雖然就技術上來說，可以追加任何動作類型，但我們在此層級是假設為提示動作。運用無提示的主題及選擇提示動作，快速有效地處理常見查詢。

在這個層級，重點在於透過動態理解，制定代理回應能力和自主性的基準層級。

此層級是在無指示下選擇動作，引進明確指示引導代理行為。新增精確的指示可提高代理回應不同情況的控制力。對於代理的指示，可透過規則、準則、安全機制和範例表達。這些功能可提供代理具體方向，以利處理各種主題、執行動作和處理輸出。此層級的目標是為代理提供明確的指引，進而增進一致性及促進遵循公司準則與流程。

接地(grounding)是指將代理的理解和回應，連結外部的知識來源。接地有助於確保代理提供更準確且貼近事實的最新資訊。此層級整合了存取資料庫、知識庫及其他資訊存放庫的資料。讓代理根據經過驗證的資料給予回應，能夠提升其可靠性與可信度。

此層級讓代理可以使用變數運作。變數可讓代理依個人打造專屬互動，保留多個互動的情境，並根據代理工作階段期間維護的特定資料點，滾動式調整其行為。舉例來說，代理可以擷取使用者的偏好設定、訂單詳情及其他相關資訊，然後將這些資料用於量身打造互動。有了變數，代理在處理更複雜、更精準且更個人化的互動上，就能提升效率。

最後一道步驟是整合代理與Salesforce的核心功能：Apex、API與流程。整合可讓代理在Salesforce生態系統內部執行複雜的動作，例如存取和處理資料、觸發工作流程，還有與其他系統互動。

• Apex提供程式化控制。
• API可與其他應用程式無縫整合
• 流程則是讓複雜的業務流程自動化。

此層級會將代理轉型成功能強大的工具，能執行複雜的任務，並直接促進業務成果。

首先從代理的回應性和自主性基準開始，設想僅包含主題與動作且搭配相應描述的代理。我們接著以這個代理為例，介紹推理引擎的不同步驟，並展示如何利用這些描述選出正確的主題，然後執行動作。省略此例的主題指示後，可以觀察到與較高層級的代理相比，一級代理具有最高的自由度。一級代理完全可以根據進行中的對話，著手選擇其認為合適的動作。

檢視推理引擎的下列考量要點：

• 推理引擎的LLM組態設定固定。代理建置器無法變更。目前，OpenAI LLM是用於提升推理功能。然而，隨著愈來愈多模型加入，這一點可能會有所變更。
• 推理引擎的預設歷程記錄： 每當向推理引擎提出要求時(步驟2至5)，引擎便會自動檢索最近要求和回應的歷程記錄。此舉可確保推理引擎採用的對話情境保持不變。除了客戶互動外，對於規劃器LLM的呼叫，還包括為了其他要求(例如選擇主題)而呼叫推理引擎LLM。

推理過程的主要步驟有四：

1. 主題選擇
2. 動作選擇
3. 代理循環
4. 接地檢查

主題旨在提高代理分類適當動作或動作順序的準確性。每個主題應由不同語義的動作構成，這些動作可以是簡明扼要的主題描述，所以屬於類似的代理功能。

推理引擎LLM選擇適當的主題(圖中步驟2-3)。引擎使用主題提示詞，選出分類說明最貼近最後一句話的主題。此主題提示詞涵蓋所有主題的分類說明及對話歷程記錄。除了語句和代理回覆外，對話歷程記錄還包括已執行的動作及其結果。另外，提示詞包含的關鍵指示，會在對話歷程情境中強制進行分析，並要求LLM分享其思考過程。

其他考量：

• 除了顯示主題外，「離題」語句會自動存入另一個隱藏主題。若沒有其他現有主題與語句相符時，即會選擇該主題。這有助於避免代理在分類時出錯。此主題沒有相應動作，其存在用意不過是協助推理引擎稍後構思適當的回應。
• 主題提示詞只會使用主題名稱和分類說明。
• 推理引擎LLM一次只能選擇一個主題。
• 對話走向可能會突然改變。推理引擎每當接收到語句時，即會進行主題選擇步驟，代表每次接收到新口語時，都可以選取新主題。

主題有雙重目的：

1. 利用動作分組降低推理引擎產生混淆的風險，以避免其選擇錯誤的動作。
2. 使用指示引導選擇及執行動作(更多資訊收錄於二級：代理控制：新增指示。

藉由將代理能力仔細安排至相關動作構成的明確定義主題，代理運作效率更佳且可預測，更新和擴展上更輕而易舉。設計主題有兩種可行方法：由上而下與由下而上。

• 在由上而下法，首先將主題設計為代理負責完成的整體待辦事項，然後為這些主題定義個別動作。
• 在由下而上法，則是先定義所有個別動作，再於主題內加以分組。

若有正確遵循，兩種方法都會得出不錯的結果。

由下而上法

本節循序漸進介紹由下而上法，因為此法與推理引擎需要以主題為起點的原因甚為相符。

步驟1： 列出代理的所有動作

一開始，先列出代理應能執行的所有特定動作。此階段列出非常具體的動作為宜，請勿過於籠統。避免過早嘗試分組或簡化動作。目標是對於代理能力所及範圍，具有全面又詳細的瞭解。

例如，以客戶服務代理為例，初步清單可包括：

• 訂單退貨：用於啟動訂單退貨流程。
• 檢查現有庫存：用於驗證產品是否有庫存。
• 查看產品換貨政策：用於擷取換貨規則相關資訊。
• 用知識回答問題：用於回答一般性質或常見問題形式的問題。
• 查看促銷：用於檢視是否有任何可用促銷或折扣。
• 預估交貨日期：用於估算預期交貨日期/時間。
• 檢查訂單狀態：用於搜尋客戶訂單的現況。
• 尋找客戶訂單：用於擷取特定客戶過去或目前履行中的所有訂單。
• 疑難排解技術問題：用於解決產品或服務相關的技術問題。
• 尋找客戶訂單條款：用於擷取攸關訂單的所有條款。
• 尋找客戶資產：用於識別或擷取攸關客戶的資產。
• 變更交貨地址。

請注意，像「解決客戶投訴」的動作，就此層級而言過於廣泛。動作是指最為精細的代理行為。投訴可能有多種類型，不同的動作已經涵蓋了這些類型：

• 交貨後問題，例如受損或故障產品的疑難排解，已涵蓋於「疑難排解技術問題」。
• 交貨前問題，例如缺貨、需要變更交貨日期或修改訂單等，已涵蓋於「檢查訂單狀態」、「預估交貨日期」或「訂單退貨」等動作。
• 一般客戶問題，例如詢問保固單，已涵蓋於「用知識回答問題」或「查看產品換貨政策」。

步驟 2：標示可能造成推理混淆的動作配對(或多組)

標示類似性質的動作，因為有可能導致推理引擎產生混淆。這些動作描述在語義上沒有顯著差異，所以推理引擎不明白在步驟5要選擇哪項動作。

舉例來說，「疑難排解技術問題」和「用知識回答問題」的描述相似，但兩者的功能可能大相逕庭。標示這類語義重疊的動作，有助於分辨哪些動作需要在多重主題中分別處理。

步驟 3：建立初步動作群組且歸類至主題

一旦明確定義動作且找出語義重疊處之後，即可將動作分組歸類至初步主題。主題是功能的邏輯類別，這是一組動作，共同代表代理具備的一致能力或技能。

建立這些群組時：

• 使用所低限度的主題數，以免語義重疊。
• 確保每個主題含有相關意義的動作。
• 確保必須接連執行的支援動作，出現在相同的主題中。

下面是客戶服務代理的初步分組範例：

主題1：

• 訂單退貨
• 檢查現有庫存
• 查看產品換貨政策
• 查看促銷
• 預估交貨日期
• 尋找客戶訂單條款
• 檢查訂單狀態
• 尋找客戶訂單
• 尋找客戶資產
• 用知識回答問題
• 變更交貨地址

主題2：

• 疑難排解技術問題
• 尋找客戶資產

步驟 4：撰寫主題的分類說明，必要時可以拆解主題

完成初步分組後，請為每個主題撰寫分類說明。

• 在這裡的範例中，主題2顯然與產品的技術問題有關。
• 主題1則涵蓋較為廣義的範疇。這主要是關於訂單管理，但其中包含一些與訂單管理無關的動作，例如「查看促銷活動」及「以知識回答問題」。主題1無法以一個句子簡明扼要地描述，所以該主題應拆解為不同主題。

經過調整後，我們得到：

• 主題1：訂單管理：描述關於管理及修改客戶訂單與相關物流的動作，惟換貨及退貨相關內容則除外。
  • 檢查現有庫存：判斷產品是否有庫存。
  • 預估交貨日期：估算訂單抵達的時間。
  • 檢查訂單狀態：尋找客戶訂單的狀態。
  • 尋找客戶訂單：擷取客戶所下的全部訂單。
  • 變更交貨地址。
• 主題2：疑難排解
  • 尋找客戶資產：擷取客戶已註冊的裝置或產品。
  • 疑難排解技術問題：提供技術協助或診斷。
• 主題3：換貨： 描述關於訂單換貨與退貨的動作。
  • 訂單退貨：啟動訂單退貨流程。
  • 查看產品換貨政策：提供產品換貨規則。
  • 尋找客戶訂單：擷取客戶所下的全部訂單。
  • 尋找客戶訂單條款：用於擷取攸關訂單的所有條款
• 主題4：產品支援：描述用於資訊檢索與路由的跨領域動作。
  • 用知識回答問題：使用知識庫的資訊回應一般性質的客戶詢問。
  • 查看促銷：檢視目前的促銷或折扣。

為了回顧起見，請先建立所有可能動作的完整清單，然後標示這些動作之間的語義重疊處。接著建立一組主題，至少能全數解決語義重疊的問題(如此一來，推理引擎就不會在單一主題的範圍內產生混淆)。然後，寫下每個主題的分類說明。如果主題範圍太廣泛，請將其拆解成更精細的主題。導入本指南，您便能打造出不僅績效優異，又易於維護與升級的代理。

這種結構有助於在代理行為的範圍內，讓推理更出色、執行更準確，決策邊界更明確。此外，此結構亦倚賴設計師、工程師和主題專家的合作無間，使代理的功能更公開透明且模塊化。

有效建立主題的進一步考量

• 最佳主題數量：為提升LLM在分類適當主題上的效能，通常建議主題數量以10個為限。這不過是大致原則。此外，每個主題都應有清楚明確的描述。最後，最佳主題數量取決於主題分類說明之間的語義距離。如果主題的分類說明差異甚鉅，主題重疊的風險就會降到最低。關於避免主題重疊的更多最佳實務，請參照這裡 的介紹。
• 平衡主題規模與清晰度：雖然將動作和指示細分至小型主題的作法通常相當實用，但建立太多具有描述甚為相似的主題，可能會導致混淆，類似於動作之間語義重疊造成分類出錯的情況。所以，主題描述在語義上清楚區隔至關重要。您可以使用LLM以協助建立這些差異顯著的分類。
• 標準語言與情境清晰度：LLM可能不會意識到特定的公司或業務意義及縮寫。請使用標準語言，或在特定情境中，非常明確地解釋單詞含義。
• 只有主題名稱與說明會放入主題提示詞傳送。因此，變更主題的範圍或指示，不會對選擇主題施加任何影響。

實例

假設有位服務代理接獲客戶詢問手錶保固單。保固問題似乎與換貨或支援服務無關。訂單管理看來才是處理此要求的最適主題。因此，推理引擎選擇後者，作為最有可能達成要求的主題。

推理引擎選好主題後，接著從選定的主題中，選出要執行的正確動作。同樣，推理引擎LLM也負責這件事，其使用另一個稱為「觀察提示詞」的提示詞。觀察提示詞的用意在於進入推理流程的下一步。這個下一步可以是下面任何一項：

• 啟動動作
• 要求使用者輸入動作
• 要求使用者釐清要求
• 完成整個動作循環後，將最終答案傳送給使用者(以達成使用者要求)(如需詳情，請參照推理步驟3)

至於觀察提示詞的輸入內容，是由取自主題及對話歷程記錄的所有動作描述構成。

動作設計的最佳實務

動作是代理在進行工作時可以履行的預先定義任務。動作是最為細緻的工作定義。代理動作分為五種不同類型：(1)執行Apex程式碼，(2)呼叫API，(3)執行流程，(4)取得LLM回應提示詞範本，以及(5)呼叫預測模型。這些動作大多為確定性。例外是收到對於提示詞範本的回應(前提是外部系統、流程或Apex動作不含啟動提示詞等機率元素)。我們將在五級代理控制中討論這些問題。

1. 控制提示動作中的代理行為。有兩種方法可強制控制代理在提示動作中的行為：(1)透過提示詞工程新增更多指示至提示詞範本，以及(2)設定產生提示詞回應的LLM超參數，尤其是溫度(請參照文件 )。降低溫度以減少產生回應的變異性，進而提高其重複性和代理可靠性。
2. 單一主題內部的最佳動作數量：類似最大主題數量，主題內部的動作數量以10個為限。不過，這同樣是大致原則。真正的驅動要素是動作之間的語義距離。若能從描述清楚區分動作時，此數字會更大。然而，語義距離沒有數值衡量指數，而是取決於代理建置器的解釋。不同動作描述的意義差異愈大，語義距離就愈大。這裡務必要避免重疊。
3. 動作說明：不同於名稱所暗示，「動作指示」實際上是讓推理引擎LLM用於從主題選出正確動作的指示。請注意，使用語義獨樹一格的動作說明，可以大幅提升其分類品質。請詳閱這些說明，尤其是比較隸屬單一主題的所有動作說明。

實例

繼續前面的例子，服務代理接獲關於手錶保固單的問題。選擇訂單管理主題後，接著選擇最有可能的動作。由於這是訂單管理主題，就邏輯而言，首先是啟動查詢訂單動作以查詢訂單(不然的話，有什麼需要檢索保固資訊？)。

使用者提出的語句可觸發執行多重動作，然後再將答案回傳給使用者。這是代理循環所致，該循環會繼續選擇並執行下一個最為合適的動作，直到符合以下任一條件：

• 推理引擎LLM判斷要求已完成。在這種情況下，引擎會發現回應已完成使用者的要求。請注意，接地檢查屬於此檢查的一環，其用意是驗證回應是否依據動作輸出。任何回應資訊不得由推理引擎LLM自創，這可能引發幻覺或其他錯誤回應。
• 找不到更多合適的動作。
• 目前已達到此步驟允許的最大LLM呼叫數。推理引擎自行設定此數字。

動作不受特定時間限制。這是為了避免動作執行時間隨著複雜性而改變。有些動作較其他動作更易於執行。

實例

啟動訂單查詢後，推理引擎會評估至今為止所產生的回應，然後決定需要進行更多工作，才能將回應傳回給使用者。訂單如今已出現在對話歷程記錄了，接著將查詢保固政策。

然而，這樣一來，代理意識到客戶其實購買了兩只手錶，這是利用「訂單查詢」動作檢索得出。所以，在代理循環中，推理引擎現在決定請客戶指出需要索取保固資訊的是哪只手錶。

避免過度編寫

避免過度編寫代理與使用者對話的方式。過度編寫會妨礙代理建立和諧關係、瞭解獨特使用者需求以及有效即時回應動態環境的能力。此外，冗長的指示可能延宕代理的回應速度，並混淆推理引擎。透過指示強制實現確定性並非首選方法。

不該做的事項

例如，沒必要告訴代理在回答服務問題時，應避免提及競爭對手。這可能導致代理行為不如預期，因為代理也可能由於供應商兼具競爭對手的身分，而拒答相關的整合問題。該指示可能反而成為類似「在討論競爭廠商時，秉持公司的最佳利益提出回應」。此舉可避免出現帶有限制性或條件性的條件指示，例如「在…的情況下，僅提及競爭對手xyz」，並改為利用LLM的推理能力。此例顯示如何在更整體、更抽象的層級上提出指示，類似真人客服到職後的訓練方式。

接著看看更多不該做事項的範例。下面是針對招募網站上的應徵者個人檔案，關於服務代理在處理方面所提出的一些錯誤指示。這些指示會試著預測各種可能浮現的客戶語句，所以應避免：

指示1： 代理收到下列語句：「我可以新增照片至個人檔案嗎？」然後隨即詢問客戶：「請問您的個人檔案類型是什麼？」

指示2： 客戶表示是高級會員個人檔案時，則回答「請讓我查一下您的合約詳細資訊」，接著搜尋合約細節，並瞭解是否同意他們可以更新個人檔案照片。

如果同意應徵者可以進行，則回答「可以，請讓我為您更新。您可以提供新照片嗎？」收到照片後，據此更新應徵者的個人檔案。合約內容不含變更個人檔案照片時，請說「很抱歉，您無法變更。我將您轉接給真人客服人員。」

指示3： 非高級會員個人檔案時：如果客戶表示不是高級會員個人檔案時，請回答：「您無法更新照片。如果有此意願，請告訴我，我會將您轉接給真人客服人員。」

指示4： 如果個人檔案類型資訊不清楚，請回答：「我無法理解您的個人檔案類型。」

這時該怎麼辦

與其糾結於這種管理細節，不如改用更靈活的指示，描述代理的行為舉止。不妨考慮以下最佳實務：

1. 對於知識文章收錄的政策和規則，請使用RAG/知識動作(而不是將其寫成指示)。在正確的時間擷取相關資訊。在前例中，即表示在名稱為「更新照片」的知識文章，應指出：「只有具備高級會員個人檔案且合約允許變更照片的應徵者，才能更新照片。」
2. 請逐條列出主要準則和安全機制，不要依賴對話加以理解或說明。向代理簡明扼要地說明預期的行為或程序。

根據這些最佳實務，更恰當的指示可能如下所示：

指示1 ：「接獲帳戶變更要求時，使用知識動作以查看政策。」

指示2 ：「請勿回應找不到適用保固單的問題。」

應用上述準則可改善代理結果。現在，客戶若要求代理變更個人檔案，代理將瞭解需要從知識庫擷取所需的保固單，判讀擷取的規則，將這些規則套用至情境，最後答覆客戶。相較於過度撰寫的情況，這種行為方法更加通用，更能廣泛適用。代理現在無須撰寫所有可能發生的對話，所以能利用所需行為，靈活回應更廣泛的對話主題。

強制執行動作順序

觀察提示詞包含指示和動作說明，卻沒有明定順序。如果動作順序是關鍵，務必在同一指示中明確說明。

繼續看招募網站代理的例子。代理應能與適任的面試者一起規劃面試。為此，代理應先確認招聘人員何時有空，接著向應徵者推薦三個可能的職缺。

在這種情況下，為了維持執行順序，指示不應放在不同的方塊中：

1. 指示1：查看面試者何時有空。
2. 指示2：然後向應徵者推薦合適的時段。

這些指示無法運作，因為推理引擎不瞭解指示2所述的「然後」是什麼意思。原因在於指示是以群組形式傳送至推理引擎，而不是以任何特定順序傳送。

所以，序列定義指示應合併為一個敘述，並寫成：

1. 指示1：查看面試者何時有空。然後向應徵者推薦合適的時段。

強制執行動作輸出，無需重新撰寫

推理引擎本身就是LLM，其負責根據代理循環產生最後的答案。需要使用此方法以強制執行代理指示，藉此提供產生回應的安全機制，或結合隸屬代理循環的多重動作輸出，以滿足使用者的要求。

但是，當預期只有執行一個提示動作時，可執行指示以指定代理永不變更動作輸出。如此一來，便能確保提升代理行為的可預測性和可靠性。

在部分情境中，尤其是一致性、合規性和預先定義的訊息甚為重要時，在核准通過的提示詞範本中，切實嚴格遵循這一原則，於是變得至關重要。以下是兩個範例：

• 監管產業：在受到嚴格監管的產業部門(例如金融、醫療照護或法律)營運的組織，通常需要嚴謹控制與客戶互動的所有通訊。採用經核准的提示詞範本，可確保回應符合法律與法規要求，進而大幅減少遭到誤解、背負責任或傳播不實資訊的風險。
• 預先測試與驗證回應：當提示詞範本經過嚴謹測試和驗證，確保其準確性、有效性和期望結果時。偏離這些範本可能損及其效能和價值。嚴格遵循可確保一致傳送經過驗證的訊息。

此指示限制代理變更動作輸出的自由度。請確認指示參照提示詞範本的輸出(例如此計劃追蹤器所示的「promptResponse」)。

因此，這種情況下的指示可以是：

「 無論代理通道為何，請勿變更promptResponse(提示詞回應)輸出。 」

強制嚴格遵循的限制：

當互動需要多個不同的代理動作時，強制嚴格遵循單一範本的作法並不可行。事實上，在這種情境中，推理引擎需要將這些動作整合至單一回應，以改變每個單一動作的輸出。

最佳指示數量

根據一般LLM特性，目標指示數量為5個到10個之間，具體數字取決於指示的複雜性和互動性。這些指示特徵會影響推理引擎可遵循的指示數量：

• 清晰性與特異性：定義明確的規則更易於遵循。
• 規則相抵觸：如果規則相互矛盾，則需要新增邏輯加以解決。
• 長度與複雜性：如果每項規則都需要深層推理，請考慮將其拆解為較小的指示。

如果明確遵循指示非常重要，請新增反映其重要性的術語：

• 緊急性與重要性(立即、緊急、關鍵、必要、強制)
• 權力與執行(必要、義務、嚴格執行)
• 後果與警告(違規將導致、不遵守將導致、不遵守可能導致、施以嚴懲、零容忍)
• 清晰度與直接性(必須、阻止、禁止、不允許、務必/絕不)

透過接地(grounding)連結資料中的答案，可大幅提升代理的可靠性及可信度。連結的回應是出自於事實資訊，而不是猜測或過時的知識。檢索增強生成(RAG)是廣獲採用的技術，讓代理能存取及使用知識庫，以構思更準確且符合情境的答案。代理會根據使用者提出的詢問，使用RAG從適用的資料來源擷取相關資訊，接著利用這些資訊補充提示詞，再將提示詞送出至LLM。代理使用RAG技術，其品質、準確性和代理互動的整體效用更優異，得以提升使用者的信任和滿意度。RAG的最佳實務在公開白皮書《Agentforce與RAG：提升代理的最佳實務》 中有詳盡闡述。

知識與指示

在指引與靈活性之間取得適度平衡時，區分知識與指示甚為重要，因為兩者達成的目的不同：

• 知識：不妨將知識想成是代理在產生答案時所存取的書庫。此類範例包括文件、知識文章和白皮書。請注意，其中可能包括政策和一般公司規定。知識也可能是指交易檔案，例如電子郵件、通話記錄，甚至是(代理)對話的歷程記錄。最後，知識包含結構化資料的長文字欄位。知識通常會透過RAG傳遞給代理。
• 指示：不妨將指示想成是最為基本的規則集，用於向代理說明何時使用每個動作。指示也可以為完整對話設下安全機制，例如所需的語調。指示通常可以變得更簡潔靈活，卻不會犧牲清晰度或意圖。不要針對每個可能的客戶情境，提供具有特定回應的僵硬腳本，而是考慮實施一般性準則和原則，幫助代理在各種情況下選擇正確的行動。

檢索增強生成

檢索增強生成(RAG)的作用是知識的智慧資料層。該技術讓代理存取各種格式的資訊，並提供相關的文字片段以回答問題。有了RAG技術，代理可獲得更精準的LLM回應，卻不會讓LLM的提示詞內容過於雜亂，或者超出其情境容量限制。

RAG在執行時，會進行三個步驟：

1. 擷取：AI系統會搜尋大型資料庫或知識來源，以收集LLM提示詞的相關資訊。這是使用語義搜尋功能完成，相較於傳統的關鍵字搜尋，技術上更加複雜。不同於需要與術語完全相符的關鍵字搜尋，語義搜尋能理解單字隱含的意義或情境。它根據概念或術語的關係識別相關資訊，而不是僅尋找精確的配對單字。關鍵字搜尋也可以在這項檢索過程中發揮作用，透過關鍵字配對強化語義搜尋，以針對特定術語或名稱進行配對。這種搜尋類型稱為混合式搜尋。
2. 增強：擷取的資訊會新增至提示詞。
3. 生成：LLM透過以檢索取得的知識強化的提示詞，產生合乎情境且更準確的回應。

在Agentforce，RAG不一定會與提示詞範本一併使用：

1. 根據RAG的提示詞：在這種方法中，用於規範如何產生回應的指示，位於提示詞範本的提示詞指示中。在這種情況下，回應全然取決於LLM產生的內容。除了提示詞指示外，還有其他方法可以影響回應，例如Einstein Studio的LLM組態設定，但結果仍不具確定性。
2. 根據推理引擎的RAG：代理沒有使用提示詞範本，而是改用擷取區塊(透過流程或Apex類別)且儲存至變數的動作(請參閱下一節)。這種方法下的推理引擎(而不是LLM)，是根據檢索到的資料直接產生答案。管理回應產生的指示是代理指示，而不是提示詞範本指示。保留擷取內容的變數，還是可以視為輸入而明確傳遞至動作。此外，也可以透過授予預設存取權限以取得變數內容，再提供給推理引擎。這種方法有利也有弊。推理引擎有內容和責任超出負荷的潛在風險。而且，不同於提示詞的是，推理引擎的LLM參數無法設定。另一方面，推理引擎可使用檢索區塊和對話歷程記錄產生答案。

建議的方法是選項1。此方法減少了推理引擎應執行的任務數，進而提高其回答品質。下一節將探討此規則的例外情況，在此情況下，內容會在整個對話中予以保留，據此明確交付給某個動作。

RAG最佳實務

• 避免編寫RAG指示：與其將特定問題的指示，直接連結至特定文章，不如發揮RAG技術的智慧，動態尋找最為相關的資料來源及精確的文字片段。RAG的配對流程奠定在對問題脈絡的廣泛理解，而不僅是將問題如實對應至來源。
• 整合主題：將相關的問題類別歸類至單一主題。就算是範圍廣泛的主題，RAG也能根據問題類型，有效分辨出相關的答案。舉例來說，維護和電池故障等產品問題，可以彙整為更全面性的主題。

將RAG輸出儲存至變數：當互動數可能達到上限時，則將RAG輸出儲存至變數。此舉便於存取資訊，引導超出標準臨界值的代理進行互動。下一節將舉出這方面的範例。

有些業務流程需要可預測性更高的執行能力，例如強制執行特定的動作順序，或是觸發動作或主題的條件。

變數正是用於實現這種確定性行為。變數是充當代理短期記憶的結構化形式，可作為動作輸入或輸出。此外，變數的狀態可用於控制觸發特定主題和動作。

變數支援確定性的方式

變數可透過以下方式，協助實現代理的引導式確定性：

1. 持續動態接地：變數讓代理可以繼續更新對於世界的理解內容，同時保有不受任何後續互動影響的重要資訊。這種方法可確保在完整對話中，可以保留關鍵資訊(可以是透過RAG擷取的非結構化資料，也可以是使用者個人檔案資訊一類的結構化資料)，而不受對話長度所限制。
2. 動作輸入/輸出：變數可作為動作的輸入和輸出。動作會明確地引用變數，執行上則不會倚賴推理引擎，以設定這些輸入和輸出，代理的確定性得以增加。
3. 篩選：變數可用於確定動作或主題的執行條件。變數可讓動作之間有特定的資訊流，並讓動作的執行具有確定性。這項功能對於安全規則尤其重要，在安全規則中，如果未驗證特定的輸入變數(例如電子郵件)，便無法啟動動作。

Agentforce採用的變數類型

Agentforce有兩種類型的變數：

• 前後關聯變數是系統產生的變數，其中保存有關使用者及對話工作階段的資訊。
• 使用者可以實例化自訂變數。其中保存各種資訊，用於以變數支援確定性的三種方式之一。

變數類型支援以下功能：

我們接著舉出使用個案的範例以深入探討變數：與客戶互動的疑難排解代理。變數在此例中用於所有三種用途，即是持續動態接地、動作輸入/輸出和篩選。

此例中的代理會協助客戶排除技術性裝置問題。疑難排解過程通常涵蓋許多步驟。代理應提供模擬真人服務人員的服務體驗。為此，代理不得同時提供客戶所有疑難排解步驟，而是應循序漸進地說明，並根據客戶的回應，引導他們進行不同的步驟(包括回到先前涵蓋的步驟)。

這方面所遇到的一大挑戰是，代理在對話中保留所有疑難排解步驟的能力。由於代理可儲存的互動數有限，可知代理的記憶量有限，如果對話變得冗長，這些步驟可從提供推理引擎的上下文中刪除。

解決此項挑戰的方法，即是使用在疑難排解步驟中使用變數，以動態方式接地推理引擎。透過擷取資訊並儲存至變數，該變數就能在整個對話中維持可用狀態，並於整個對話中更新。推理引擎使用儲存於此變數的資訊進行動態接地。

在此範例中，一個主題包含兩個動作。這兩個動作是維持一致資料流所需。第一個動作是填入包含所有疑難排解步驟的變數。第二個動作則是在疑難排解過程中使用該變數。

1. 動作1：「填入問題解決步驟」。這是初始動作，由代理首次導入問題而觸發。該動作使用檢索增強生成技術，從索引知識庫提取所有必要的解決步驟。接著動作會將產生的輸出，儲存在名為「Resolution Steps」的變數中。
2. 動作2：「在解決問題的過程中使用」。這是根據提示詞採取的動作，在疑難排解過程期間，輸出最有可能用到的下一個疑難排解步驟。代理會依指示在解決問題中用到此動作。

客戶原本的問題會輸入這兩個動作。第二個動作則有另一個輸入：即是變數「Resolution Steps」的內容。此變數由第一個動作設定。請注意，第二個動作不會直接擷取疑難排解步驟，而是透過變數從第一個動作取得輸入。下圖描述了這兩個動作之間的資料流。

「在解決問題的過程中使用」動作將隨時參照「問題解決步驟」動作檢索到的原始疑難排解步驟。這種資料流程可確保，無論對話長度如何，疑難排除步驟皆會維持一致且始終存在。

此範例所定義的動作，需要使用特定指示加以執行，例如「永遠先執行『填入解決步驟』」。然而，鑑於代理所用的LLM不具確定性，此舉可能導致在部分情況下的順序有所不同。為了確保執行順序的確定性，在這些變數上導入條件篩選器，強制執行正確的動作順序。代理會讀取變數「Resolution Steps」的值，並根據該變數是否有值，定義兩個篩選器。

• 「問題解決步驟」動作只能在變數「Resolution Steps」為空時執行。
• 「在解決問題的過程中使用」動作唯有在填入變數「Resolution Steps」後才能執行。

這些條件篩選器現在可以確定地強制執行動作順序：「在解決問題的過程中使用」動作必須等到「問題解決步驟」動作完成工作，才能確保變數「Resolution Steps」始終具有值。

為確保正確執行動作起見，如果問題完全解決，則需要第三個動作以重設變數「Resolution Steps」。所以，代理會重設為所需狀態，以協助處理可能出現的全新不同問題。這裡的第三個動作稱為「清空解決方案變數」。完整的動作流程圖如下所示。

變數對於疑難排解代理解決客戶問題至關重要，因為其允許：

• 持續動態接地：變數儲存疑難排解步驟，確保無論互動時間長短或次數為何，都能在完整對話中使用。這可防止代理遺忘情境。
• 資料流程：變數可促進動作之間的資料流。例如，變數「Resolution Steps」儲存擷取自「問題解決步驟」動作的疑難排解步驟，並提供這些步驟作為「在解決問題的過程中使用」動作的輸入。
• 確定性：變數可作為篩選器使用，以利強制執行特定順序的動作。舉例而言，唯有在填入變數「Resolving Step」，確保先執行「問題解決步驟」動作後，才會執行「在解決問題的過程中使用」動作。

在生成式AI盛行的時代，預測式AI仍至關重要，因為其構成了引導、強化和情境化生成式能力的基礎智慧。生成式AI雖然著重於形成新內容，例如文字、圖片或影片，但預測式模型能根據即時業務資料輸入預測未來。業務成果的例子包括客戶流失可能性、轉換可能性、個案升級可能性、客戶終身價值和個案分類。預測有助於提前考量使用者需求、個人化輸出、制定決策、即時最佳化內容相關性，這一切都是透過分析趨勢和數字所完成。例如，在個人化學習、醫療照護或財務規劃等應用中，預測式AI可確保產生的輸出，符合個別情境及未來可能發生的情境。預測式和生成式AI共同創造出強大的協同效應，將遠見與創造力相結合，進而推動更智慧、更具適應力和影響力的技術解決方案。

如何將預測模型輸出整合至代理工作流程

若要將預測模型輸出整合至代理工作流程，只需將預測模型的動作新增至Agentforce的資產即可。模型產生器提供建立或註冊(BYO)預測模型的方法，代理會接著使用這些模型進行預測。據此產生的預測(及預測因子)，都可以儲存在自訂變數中。代理可使用這些變數值作為輸入，並設定執行特定動作和主題的條件。

整合預測模型的使用個案範例

• 區隔：為區隔客戶執行多類別分類，並使用產生的區隔篩選特定動作。將高級動作保留給高級客戶即是一例。
• 升級可能性：預測服務個案升級的可能性。如果可能性超過特定臨界值，則允許執行動作以求更快解決個案，或是縮短轉接給真人服務人員的時間。
• CPG：僅在銷售提升程度(由預測模型計算的分數)超過特定臨界值時，才規劃促銷活動。
• 商務：僅在購買傾向超過特定臨界值時才推薦產品。

有些業務流程需要以精密的順序執行，在執行過程中無須使用者輸入。在這種情況下，可透過流程、API或Apex，強制執行預先定義的步驟流程。如果您目前在生產環境中倚賴現有的某個流程，這就是一個不錯的指標，代表該流程可以保留下來，然後由代理用於執行該業務流程。以下所有範例都包含預先定義的步驟順序，代理可在沒有使用者輸入下執行這些步驟。此時的代理行為包括找出欲執行的確定性過程、如何收集必要的輸入，還有如何解釋和處理輸出。

若業務流程的連續步驟繁多(依大致原則為超過三個步驟)且對變數的依賴性高，則會變得過度複雜繁瑣，無法依指示強制執行。這時可以使用本節列出的確定性動作類型，對這些流程進行硬編碼即可。最後需要留意的是，這些實作可能包含非確定性元素，例如以處理後的提示詞範本呼叫LLM。因此，它們不一定是完全確定的端對端，仍可以展現出代理所熟知的理想流動性水平。

行銷歷程中的步驟順序取決於固定規則，而不是取決於任何對話使用者輸入。所以，流程可視為Agentforce的動作使用。建立可調用動作以完成源自解決方案元件的背景或事件觸發任務，該元件可呼叫流程或Apex類別。將可調用動作新增至流程或Apex類別，並指定代理需要完成的任務，以及觸發代理的條件。可調用動作也能攜帶代理的前後關聯變數，據此傳遞重要資訊。

Salesforce流程可用於自動化例行任務，例如建立後續任務、傳送提醒電子郵件或更新記錄。流程讓工作更具效率和生產力。代理也可以使用流程動作執行流程。由於流程具有確定性，當業務流程需要以特定順序執行時，流程正是引導代理行為的高招。如果主題原本會包含「先執行此動作，再執行此動作，最後執行此動作」一類的指示，則表示該情況適合優先使用流程動作。若要強制執行三個步驟以上的順序，透過指示和變數管理就變得異常繁複。

流程還可以透過呼叫提示詞以納入非確定性元素。流程中的提示詞節點會呼叫提示詞範本，並收集可以傳遞給流程中其他元素的回應。諸如此類的其他元素，同樣可以是提示詞節點，例如摘要先前的回應，據此建立一連串提示詞。當鏈接提示詞的規則是由固定元素定義，亦不依賴使用者輸入時，則特別實用。代理式RAG即是一例，其中預先定義的檢索器順序或流程中的提示詞，可按照特定順序存取特定資料來源，例如在必要時諮詢其他來源前，先從使用者所在的國家/地區文件擷取資料。這種鏈接機制會以可靠又井然有序的方式，強制擷取相關資訊。

與流程類似，Apex和API動作可以編碼預先定義的動作順序，所以具有確定性。這些動作可包含非確定性元素，例如叫出提示詞範本或LLM呼叫。然而，根據定義，這些動作會以確定性方式執行步驟，並透過適時呼叫動作，收集必要輸入及處理輸出，以降低代理變異性。這些責任仍需要以代理指示加以管理，所以其不具確定性。Apex與API動作是等同於流程動作的專業程式碼。

若要實現可靠的代理行為，需要一種結構化方法，藉此平衡大型語言模型(LLM)的固有靈活性與企業級控制及可預測性的需求。本文闡述了執行「引導式確定性」的分層策略，不僅能建立智慧和自主兼具的代理，還能始終準確並搭配業務流程。打造這些值得信賴的代理，其關鍵在於逐步實施控制機制，每個機制都能新增一層可靠性：

1. 基礎主題與行動設計：這個過程的起點是將代理的能力，仔細安排成不同主題和精細的行動。透過建立語義上有顯著差異的邏輯群組，得以降低混淆推理引擎選錯動作的風險，進而為可預測的行為奠定基礎。
2. 明確指示：代理指示根據這個基礎，便能提供更高層級的控制。這些指示作為安全機制和指引，指導推理引擎如何在其權限範圍內執行動作、遵循公司政策及管理對話流程，而不會過度編寫互動。
3. 使用RAG進行資料接地：為了以事實和相關性改善回應，資料接地會將代理連結經過驗證的知識來源。檢索增強生成(RAG)等方法，讓代理能夠從知識文章和公司資料中，即時提取準確的資訊，大幅減少猜測且增進可信度。
4. 使用變數的情境與狀態管理：對於較為複雜且帶有狀態的互動，變數導入了一種短期記憶形式。變數可以讓代理保留當時情境，在整個對話中繼續使用重要資料，並根據變數狀態執行動作，以強制執行確定順序的操作。
5. 使用流程、Apex和API的確定性執行：對於要求嚴格固定執行的業務流程，透過確定性動作可達成最高的控制程度。整合代理與Salesforce流程、Apex和API，可精準執行預先定義的順序，移除關鍵步驟對於使用者輸入或LLM輸入的依賴性。

開發人員若系統化套用這些控制層，包括以設計構思和清楚指示，達到資料接地、狀態管理和確定性流程自動化，即可成功因應打造可靠代理並達成一致業務成果帶來的挑戰。這種策略性方法，可確保Agentforce代理能以企業環境所需的準確性和一致性，執行重要的業務功能，值得信賴。