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

奧爾法·卡拉特, 產品管理總監 -Agentforce
雷尼爾·范洛肯, 產品管理高級總監-Agentforce

_{自2026年4月起，代理主題現稱為子代理，而主題選擇器現稱為代理路由器。功能沒有任何變更。在此轉換期間，您可能會在我們的文件與UI中看到新舊術語混用。}

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決定要使用哪項工具，而Agent Script可讓您將推理流程本身「硬編碼」。透過文件式畫布或直接編寫程式碼，您可以定義代理無論使用者輸入為何都必須遵循的不可變更路徑，例如必要驗證關卡、if/else條件式分支，以及強制子代理轉移。這種混合式推理方法可讓您將LLM的對話彈性，夾在多層保證執行的邏輯之間。第6層把代理轉變為零信任、企業級的夥伴，能以絕對精準處理高風險的合規、法規揭露，以及複雜的多步驟相依關係。

先從代理回應能力與自主性的基準開始，假設有一個代理只包含子代理與動作，以及各自對應的說明。我們可以運用這個範例代理介紹推理引擎的不同步驟，並展示它如何利用這些說明選擇正確的子代理，接著選擇要執行的動作。透過在這個範例中省略子代理指示，我們可以觀察到，相較於較高層級的代理，第1層代理擁有最高的自由度。在第1層中，代理完全可以只根據進行中的對話，自由選擇它認為合適的動作。

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

• 推理引擎的LLM組態設定是固定的。代理建置者無法變更這些設定。目前，代理建置者可選擇由Salesforce基礎架構託管的OpenAI LLM或Anthropic 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項指示中的「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與生成式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中使用。

我們推出了文件式畫布，作為文字轉指令碼介面。您不必撰寫程式碼，而是以結構化自然語言撰寫子代理邏輯。接著，Builder會解讀您的意圖，並在背景將其編譯為Agent Script。

• 您撰寫：「首先，檢查訂單是否已超過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來即時解決問題。

隨著Agent Script作為確定性層級架構中的第6層導入，您現在擁有完整的控制範圍，從第1層子代理的開放式創造力，到第6層Agent Script僵硬且由程式碼驅動的邏輯皆涵蓋在內。

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

最常見的錯誤，是認為「層級越高越好」，並以為現在所有事項都應使用指令碼完整控制代理。事實並非如此。代理架構與設計的真正訣竅，在於適度調整確定性，也就是套用剛剛好的控制力來確保安全，同時不犧牲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.防止子代理偏移

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

• Agent Script解決方案：使用@utils.transition將使用者鎖定在Emergency Protocol子代理中，直到問題解決，明確停用偏移的能力。

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

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

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

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

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

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

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