Agentforce達成可靠的代理行為指南：6層確定性的框架

奧爾法·卡拉特, 產品管理總監 -Agentforce
雷尼爾·范洛肯, 產品管理高級總監-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與Flow。整合讓代理能在Salesforce生態系內執行複雜動作，例如存取與操作資料、觸發工作流程，以及與其他系統互動。

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

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

在第5層的技術整合基礎上，這個最終層級引入確定性推理，以彌合機率型AI與僵硬商業邏輯之間的落差。先前層級仰賴LLM決定要使用哪個工具，而代理腳本讓您可以對推理流程本身進行「硬編碼」。透過文件式畫布或直接撰寫程式碼，您可以定義不可變更的路徑—例如必須通過的驗證閘門、if/else條件分支，以及強制的主題切換—讓代理無論使用者輸入為何都必須遵循。這種混合式推理方法，讓您能把LLM的對話彈性「夾」在具保證執行的層層機制之間。第6層把代理轉變為零信任、企業級的夥伴，能以絕對精準處理高風險的合規、法規揭露，以及複雜的多步驟相依關係。

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

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

• 推理引擎的LLM組態設定固定。代理建置者無法變更它們。目前，代理建置者可以在OpenAI的LLM與Anthropic的LLM之間擇一，並使用託管在Salesforce基礎架構上的模型來進行推理。隨著加入更多模型，這可能會有所變動。
• 推理引擎預設歷史: 每當向推理引擎提出要求時(步驟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中的「Then」敘述是指什麼。這是因為指令是以一個群組的形式送到推理引擎，而不是依照任何特定順序。

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

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

強制動作輸出且不重寫

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

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

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

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

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

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

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

強制嚴格遵循的限制：

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

指令的最佳數量

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

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

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

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

基於資料中的答案可大幅提升代理的可靠性和可靠性。有根據的回應基於事實信息，而不是猜測或過時的知識。Retri eval 增強生成（RAG）是一種廣泛採用的技術，允許代理訪問和使用知識庫，以便制定更準確和情境相關的答案。根據使用者的查詢，代理會使用 RAG 從適用的資料來源擷取相關資訊，然後再將提示增加此資訊，然後再提交給 LLM。使用 RAG 的代理具有更高的代理互動品質、準確度和整體實用性，從而提高使用者的信心和滿意度。一份名為 Agentforce 和 RAG：更好代理的最佳做法，詳細描述了 RAG 的最佳做法。

知識vs.指令

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

• 知識：不妨將知識想成是代理在產生答案時所存取的書庫。此類範例包括文件、知識文章和白皮書。請注意，其中可能包括政策和一般公司規定。知識也可能是指交易檔案，例如電子郵件、通話記錄，甚至是(代理)對話的歷程記錄。最後，知識包含結構化資料的長文字欄位。知識通常會透過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動作是等同於流程動作的專業程式碼。

從機率式推理到確定性推理

在確定性的第1到第5層中，我們逐步為代理的環境加入結構。我們定義它能夠做什麼(第1層：主題)，接著引導它應該如何行為(第2層：指令)，我們讓它立基於真實(第3層：資料)，我們管理它的狀態(第4層：變數)，並給它嚴謹的工具(第5層：確定性動作)。然而，核心的決策引擎在本質上仍然是機率式的。推理引擎仍然自行決定要選哪個工具或下一個要問什麼問題，而這個決策我們完全仰賴大型語言模型(LLM)。

第6層：代理腳本，從根本上改變了這個架構。它引入了對推理流程本身進行「硬編碼」的能力。

透過代理腳本，我們從提示模型，轉向為代理撰寫腳本。這不是回到僵硬、老派的聊天機器人。相反地，我們稱之為混合式推理。它讓您能把LLM富有創意、具對話能力的力量，夾在不可變更、確定性的邏輯層之間。您可以明確定義關鍵的執行路徑(「必做事項」)，同時保留特定的自由空間，讓LLM處理自然語言理解與回應生成。

在設計工作流程時，務必避免使用以腳本驅動的LLM型代理，去取代那些下一步已經清楚且固定的確定性邏輯。如果流程走的是可預測的路徑，且不需要複雜推理來解讀後續動作，那麼引入生成式模型只會增加不必要的延遲、成本與出錯空間。對於純粹確定性、且不需要推理的流程，傳統的程式化流程仍然更勝一籌。把LLM用在簡單路由或線性轉換，是一種過度工程的選擇，會犧牲原本可以用標準程序流程處理之系統的可靠性。

作為經驗法則，當系統要處理非結構化輸入，且在做出決策之前，必須把來自不同且高變異來源(可能包含對話輸入)的資訊加以整合時，才應考慮代理式解決方案。

但要如何達到這種程度的控制呢？有兩條截然不同的路徑，分別為商務架構師與專業程式開發者而設計。

把第6層的確定性帶進您的代理，並不嚴格要求一定要寫程式碼。Salesforce提供兩種模式來產生底層的代理腳本，讓確定性推理的使用更普及。

對商業分析師、管理員與低程式碼實作者而言，第6層可直接在Agent Builder中使用。

我們引入了文件式畫布，作為文字轉腳本的介面。您不用寫程式碼，而是用結構化的自然語言撰寫主題的邏輯。建置者接著會解讀您的意圖，並在背景將其編譯成代理腳本。

• 您撰寫：「首先，檢查訂單是否已超過30天。如果是，告訴使用者我們無法接受退貨，並禮貌地結束對話。如果不是，詢問商品的狀況。」
• 系統會將這段自然語言敘述自動編譯成所需的if/else結構、變數檢查與end_conversation命令。

這讓您可以用自然語言撰寫邏輯，並由平台將其轉換為程式碼，確保即使不是程式開發者，也能強制套用嚴謹的護欄與確定性。

對於追求最高精準度的開發者而言，您也可以直接在Agent Builder中撰寫代理腳本。帶有自然語言敘述的畫布可以翻面查看底層腳本，讓開發者可以直接用程式碼撰寫腳本。這種方式甚至支援混合式撰寫體驗：有些指令以自然語言寫在畫布上，而其他指令則直接用程式碼撰寫(或修改既有內容)。在這兩種體驗之間來回切換時，您會看到兩種模式始終保持完全一致。

兩種模式都能發揮第6層的完整潛力：

• 詳細追蹤：您可以逐步執行腳本，精準查看變數在哪裡變更，或走了哪一個分支。
• 複雜迴圈處理：管理難以用自然語言描述的進階重試邏輯，或多變數的狀態變更。
• 版本控管：把代理行為視為程式碼，與git及CI/CD管線相容，用於代理版本管理。

無論您透過建置者產生代理腳本，或是手動撰寫，產出都相同：代理腳本會被轉換成代理圖，並由Atlas推理引擎執行。

要掌握第6層，就必須理解底層實際發生了什麼。代理腳本透過推理區塊內特定的程式化結構來控制行為。不同於標準提示只是提供LLM遵循的建議，這些是命令，會無論如何都會執行。也就是在推理流程之前、期間或之後，而且它們包含數種不同類型的確定性。我們會先概略檢閱其中一些模式並提供一些輕量的範例，接著再以腳本化代理的架構藍圖範例進一步說明。

在第1到第5層中，我們希望代理會在流程的某個步驟之前或之後做某件事(執行某個動作)。在第6層中，我們強制它必須這麼做。寫在before_reasoning與after_reasoning區塊中的內容，分別一定會在呼叫LLM依指令進行推理之前與之後執行。這些內容可以是執行其他動作、切換到其他主題、設定變數等。

例如，在主題的before_reasoning指令中使用run命令，您就可以在呼叫LLM產生回應之前先執行一個動作。這能確保資料立即可用，消除推理延遲，或降低代理忘記呼叫工具的風險。

腳本結構：

透過條件式確定性，您可以使用標準程式邏輯來控制流程。這對於步驟不能被跳過或重新詮釋的合規工作流程而言至關重要。

腳本結構：

在這個範例中，LLM從未被給予選項去為非VIP使用者幻覺出一個核准結果。分支會由引擎以確定性的方式走向。

另一個強而有力的控制方式，是能強制代理離開目前主題並進入另一個主題。這能避免代理卡住，或偏離到不相關的對話。

腳本結構：

這個轉換不是建議。這是依據變數值而定的執行流程強制轉向。請注意，雖然這個轉向是強制且不可協商的，但在代理被強制切入的那個主題內，仍會再次進行一般的推理流程。

此外，使用代理腳本時，您也能明確強制在某個動作完成後，立刻從該動作轉換到下一個動作。這項功能可確保代理遵循嚴謹、確定性的流程，而不是在每一步都依賴機率式或自主的決策。透過把這些動作依預先定義的順序串接起來，您可以確保特定任務以精準的順序執行，讓您能完全掌控代理的邏輯與行為。

代理腳本讓您可以直接讀寫代理的短期記憶(變數)。您可以依據動作輸出明確設定變數，避免出現傳話遊戲，因為LLM可能會誤解工具的JSON輸出。

腳本結構：

要真正理解代理腳本的威力，我們必須超越單一命令，觀察它們如何協同運作。以下的架構模式(源自我們的 代理腳本範例集 )展示了第6層確定性如何解決複雜的企業挑戰。

問題：標準代理常常會遇到推理延遲。它們會等使用者提問，接著思考要用哪個工具，然後甚至可能會向使用者詢問其實早就能擷取到的資訊，最後才呼叫動作。這會造成延遲、斷裂的體驗。代理腳本：推理前的確定性。

我們使用run命令，在LLM甚至還沒「醒來」之前就先注入資料。

範例：緊急分級代理。想像有一個代理在處理停電通報。它不會向使用者詢問地址並等待，而是在工作階段一開始的當下，腳本就會自動執行get_current_location_by_IP與check_grid_status命令。

結果：代理不會以「我能怎麼幫您？」開場。它會使用以下內容開場：「我看到您是從北區來電，那裡已確認發生變壓器起火。我已將您家加入優先復電名單。您有啟用備用發電機嗎？」

邏輯：

冗長的提示(一次把所有規則都給代理)會提高推理過程中產生幻覺的機率。代理會因為正在看規則Z而忘了規則A。

代理腳本的解法：結合RAG與條件邏輯，透過條件式立基進行即時指令注入。它只把適用於對話當下確切時刻的規則顯示給代理。

範例：提供不符合資格之優惠的規則。當客戶的信用分數根本不允許申請調高信用額度時，為什麼還要把申請調高信用額度的規則給代理？

邏輯：

條件式立基是在不需要時，把干擾資訊完全移除，藉此消除出錯的可能性。

問題：在複雜的代理對話(例如房貸申請、求職篩選面談或技術疑難排解工作階段)中，代理會維護一份必答問題清單，以便向使用者收集所有必要資訊。然而，使用者常常會離題。標準代理可能會跟著離題內容走，並忘記回到這些必答問題，導致申請或對話不完整。

這個系統的核心是具狀態的導覽，它把對話視為一份嚴謹的檢核清單，必須完全勾選完成後才能進行任何轉換。

透過具狀態的導覽，代理會嚴格依據目前的變數狀態在主題之間移動，或是鎖定在某個主題內直到符合特定條件為止。即使使用者試圖用離題內容讓對話偏航，這也能避免代理走上不被允許的路徑。例如，在高風險的房貸申請中，如果使用者詢問分行營業時間，代理不會只是嘗試把對話拉回正軌。相反地，腳本會偵測到偏離，並可觸發強制轉換到合規重設主題。透過把代理鎖在特定的「邏輯房間」中，它在數學上就不可能討論未核准的主題，也不可能在所有必備變數都成功取得之前結束工作階段。

範例：維修檢查員：一個代理正在引導技術人員，針對飛機引擎進行10點安全檢查。技術人員說：「等等，我也注意到機身上有一道刮痕。」

行為：

1. 代理會確認這道刮痕(自然語言)。
2. 它會把這道刮痕記錄到變數中(狀態管理)。
3. 在它確認以下事項之前，它會拒絕結束工作階段或切換主題：「我已記下機身刮痕，但在您確認進氣閥的扭力設定之前，我們不能轉到『外部』。那個讀值是多少？」

邏輯：

不過，引導式對話不應該只是依序排列的一串問題。否則代理會像是一個「偽裝成對話的表單」。它的主要價值在於智慧分流：用一開始的探索性問題，把使用者導向正確的表單或工作流程。

當複雜度提升時，從簡單腳本轉向強健的代理腳本就變得合理。代理不再只是提問，而是開始執行：例如，代理可能會從文件中擷取疑難排解步驟、瀏覽內部政策，或呼叫外部系統的API來即時解決問題。

隨著在確定性層級框架中引入第6層的代理腳本，您現在擁有完整的控制光譜：從第1層主題的開放式創造力，到第6層代理腳本的固定、以程式碼驅動的邏輯。

但手上有了鎚子，不代表每個問題都是釘子。

最常見的錯誤，是以為「越高越好」，認為代理現在應該在所有事情上都用腳本來完全控制。這並不正確。代理架構與設計真正的功力，在於恰如其分地調整確定性：施加剛剛好的控制來確保安全，同時不犧牲讓AI在一開始就有價值的對話彈性。不要把代理過度腳本化到只剩下「高級一點的聊天機器人」。

本章提供一個決策框架，協助您判斷何時應依賴第1到第5層的引導式自主，以及何時應強制採用第6層的腳本化精準。這些不是嚴格的法則，而是經驗法則，目的是提供一個情境化的框架，幫助您思考確定性的不同選項與層級。

為了簡化決策，我們可以把六個層級分成兩個截然不同的策略區：

• 理念：「信任，但要驗證。」您給代理目標、資料與工具(工具可能是確定性的，見第5層)，但讓推理引擎決定達成目標的最佳路徑。
• 機制：機率式推理。代理會分析使用者意圖，並動態選出最適合的工具來完成任務。
• 最適合：探索、一般問答、低風險任務、廣泛的服務範圍。

在以下情況下，您應依賴第1到第5層的標準機率式行為：

1.正確路徑不一定總是相同

在許多對話情境中，固定、硬編碼的路徑反而是劣勢，因為正確的對話路徑是會變動的。對於個人購物或旅遊規劃這類動態互動，並沒有唯一正確的順序；使用者可能會依自己選擇的任何順序，優先考量價格、地點或設施。在這些情況下，強制使用具狀態的腳本會帶來令人挫折的機器人式體驗，因此更有效的做法，是依靠指令來定義代理的角色與目標，同時讓使用者主導流程。這種做法也能大幅提升上市速度，因為對於內部HR常見問題代理這類任務，建置包含巢狀變數與分支的複雜第6層腳本往往是殺雞用牛刀。透過讓代理立基於資料與RAG，您可以略過需要詳盡手寫腳本的需求，並讓檢索引擎依據您既有的知識庫，動態處理對話。

2.透過模組化確定性進行擴展：避免維護惡夢

當您的代理範圍擴大到非常龐大的規模，例如要處理500種各自有流程的IT支援問題時，主要挑戰不是您是否能建出單一的確定性代理式腳本，而是您該不該這麼做。試圖把500個任務的所有可能組合都映射到一個龐大的代理腳本中，會變成一場維護 惡夢。每次政策變更或新增一個疑難排解步驟時，您都可能會破壞那張龐大且彼此相連的邏輯網。

解法是遠離單體腳本，轉向第5層的確定性動作。您不必把整段對話都寫成腳本，而是為最重要、最高價值的動作建立強健且彼此隔離的流程，例如重設密碼或解鎖帳號。接著讓推理引擎扮演交通指揮的角色，從使用者獨特的表述辨識其意圖，並將其導向適當的確定性動作。這種做法讓您兼得兩者優點：關鍵任務具備腳本的可靠性，同時也擁有彈性、可擴展的架構，不會在任務庫擴大時因自身重量而崩壞。

• 理念：「無論您做什麼、怎麼推理，不管如何，都要照這樣做。」您定義路徑。代理是用來執行您邏輯的介面。它把代理的創造力夾在一層層必做邏輯之間。
• 機制：確定性推理。「大腦」會遵循預先編譯好的圖；LLM只會在腳本允許的地方，用於推理、自然語言理解與回應生成。
• 最適合：合規、金融交易、診斷樹、高風險工作流程、合規，以及高度受監管的產業。

請注意，在第6層所鋪設的確定性軌道內，第1到第5層的所有選項仍然都可使用！

當「大致正確」已經不夠好時，您就應該升級到代理腳本。

1.必須通過的關卡(安全與身分驗證)

如果使用者要轉帳，您不能指望LLM大概會去要求身分驗證。您需要數學保證，確保身分驗證流程會在交易流程之前執行。

• 代理腳本的解法：在before_reasoning區塊內或腳本最上方使用run @actions.verify_identity，強制在LLM生成任何權杖之前先完成合規。

2.法規遵循

在醫療或金融等產業中，代理常常必須逐字宣讀免責聲明，或依照法律規定的順序提問。

• 代理腳本的解法：將揭露內容硬編碼。

3.複雜的多步驟相依關係與強制的動作順序

如果步驟B需要步驟A的輸出，而步驟C又仰賴步驟B的計算結果，那麼依賴LLM透過提示脈絡在傳話遊戲中傳遞這些變數是有風險的。此外，當某個動作在另一個動作之後的執行是嚴格強制時，順序就需要硬編碼。

• 代理腳本的解法：使用set @variables.x = @outputs.y，在步驟之間明確綁定資料，確保完全不失真。使用run與@utils.transition敘述把順序寫成程式碼。

4.防止主題漂移

在高風險的疑難排解中(例如「我的心律調節器在嗶嗶叫」)，如果使用者突然問「天氣怎麼樣？」，您不希望代理因此分心。

• 代理腳本的解法：使用@utils.transition把使用者鎖定在「緊急處置流程」主題中，直到問題解決為止，並明確停用偏離的能力。

最成熟的代理架構不會二選一或選擇另一個；它們以第6層作為骨架，以第1到第5層作為肌肉。接著形成的模式就是一種確定性的三明治結構。您可以用代理腳本處理對話關鍵的開頭與結尾，同時讓中段保留彈性推理的空間。

• 步驟1(第6層)：代理腳本強制執行分流與身分驗證。
  • 結果：使用者被安全地識別，且意圖被分類。
• 步驟2(第1-5層)：代理腳本交接到標準主題。
  • 結果：代理使用標準RAG與動作、指令，甚至可能也使用變數，以彈性的方式解決使用者的問題。
• 步驟3(第6層)：代理偵測到問題已解決，並轉換回代理腳本以執行結尾動作。
  • 結果：代理腳本強制收集CSAT分數與合規的道別用語。

最終建議：為了速度與探索，先從第1到第5層開始，並監控您的日誌。當您看到代理在一致性上掙扎、無法遵循順序，或對參數產生幻覺時，就針對該特定工作流程選擇性地用第6層加固。

代理腳本是讓代理具備確定性的最後一塊拼圖。它承認AI是機率式的，但商務是確定性的。透過採用代理腳本(不論是透過支援以自然語言建置代理的畫布，或直接用程式碼)，您不是在限制代理的智慧，而是在聚焦它。您正在打造一個系統，讓對話的藝術與流程執行的科學相遇，確保您最關鍵的工作流程每一次都能完全依設計運作。

第6層也體現出自主不代表失控。

多年來，產業在決策與流程最佳化上一直在辯論規則vs.AI。嚴格規則派主張可預測性。AI派主張彈性。代理腳本結束了這場辯論，證明正確的架構不是或，而是且。

透過採用代理腳本，您正在打造混合式代理：同時具備程式碼的剛性骨幹，以及LLM的彈性思維的系統。企業AI的未來不在於更大的模型。而在於更好的控制。有了代理腳本，那個控制權終於回到您手上。