Agentforce 18 個月觀察：旁觀者視角的 2026 落地藍圖

摘要

• 本文核心：Agentforce 在 2024 年底發表後，2025 是探索之年、2026 是落地之年。市面上不再爭論「值不值得用」，問題變成「怎麼用才不會炸」。
• 誠實聲明：易凱還沒在台灣為客戶導入 Agentforce。本文整理的是我們 18 個月來持續評估、追蹤西方早期採用者、研究 Salesforce 平台演進得到的觀察——不是我們親自踩雷的紀錄。
• 2026 的新工具帶來新的玩法：Agent Builder 把建構成本砍掉 70%、AgentExchange 讓 80% 的常見場景有現成模板、Testing Center 解決了 prompt 上線前無法回測的痛點、Agentforce Script 把高合規流程從 LLM 推理拉回宣告式編排。
• 三個業界已浮現的失敗模式：Agent 互相觸發的死鎖、共用 Topic 引起的權限漏洞、AgentExchange 模板未審查直接上線。
• 可帶走的判斷框架：用「Agent 自主程度 × 業務後果可逆性」兩個軸，30 秒判斷該不該全自動化。
• 最後示範一段 Agentforce Script：把「客戶查詢餘額」這條合規敏感流程寫成可審計、可回測的腳本。

一、寫在前面：我們的位置

Agentforce 1.0 在 2024 年 9 月發表，一年半以來，我們做的事情很明確：持續評估、追蹤、不急著把客戶推上線。原因是台灣金融與大型企業的合規環境，比北美、歐洲、澳洲更保守，Salesforce 與 Agentforce 在這些市場的演進有 6–12 個月的領先指標性。

所以這篇不是「我們踩過十個雷」的回憶錄，是從西方市場與平台側演進中能讀出的訊號——包含：

• Salesforce 自家在 Dreamforce、財報、release notes 揭露的演進
• 西方早期採用者的公開案例與失敗報導
• 我們以 Salesforce CTA 視角拆解的平台機制
• 我們判斷「如果在台灣金融業導入會發生什麼」的推論

如果你想看純客戶案例的書，這篇不是。如果你想用一份不被廠商行銷帶風向的觀察，整理出 2026 年的判斷框架，這篇可能是。

二、過去 18 個月平台側的關鍵改變

2.1 Agent Builder：把建構成本砍掉 70%

根據 Salesforce 文件與西方早期採用者的公開分享，2025 年初要做一個 Agent，需要寫 Apex、設計 prompt、配置 Permission Set、設定 grounding source——一個資深架構師大概要 3–4 週。

2026 年用 Agent Builder（GA 後的成熟版本）可以在一週內完成同樣的設定。它不是「無腦 wizard」，而是把 Topic、Action、Grounding 三個概念用視覺化介面組合起來。工程師仍然可以為每個 Atomic Action 寫 Apex，但 80% 的常見場景已經不需要了。

對導入策略的影響：第一次 PoC 不再需要架構師全程參與，業務分析師可以自己組出 demo。但生產上線仍然需要工程師審查——這條紅線在多份西方案例研究中反覆被驗證。

2.2 AgentExchange：改變了「從零開始」的成本

AgentExchange 上線後，整個產業的 baseline 提高了。對「客服 FAQ 回答」、「文件抽取」、「會議紀錄整理」、「報價單生成」這類常見場景，市面上已經有 50+ 套合理品質的模板。從這些模板 fork 一份再客製，比從零開始快 5–10 倍。

但這也帶來新的失敗模式（後文會講）。模板不是免費的午餐——它們是別人對「一般情境」的預設，跟你公司的權限模型、資料模型、合規要求都不一定對齊。

2.3 Testing Center：Agent 的 CI/CD

2025 年西方早期採用者公開抱怨最多的痛點之一：Agent prompt 改了之後，沒有方法系統性地驗證「會不會破壞既有行為」。多份公開分享顯示，當時的解法是手動跑大量案例、人工比對結果——這是 2025 年 Agentforce 工程不成熟的標誌。

2026 年的 Testing Center 提供：

• 測試集管理：把過去成功的對話歸檔成 regression suite
• 自動跑 PR 級別的回測
• prompt 變更的 diff 視圖

對工程實踐而言，這是把 Agent 開發納入 DevOps 管道的關鍵。業界已浮現的 best practice：任何 Agent prompt 改動，沒過 200+ 筆 regression suite 不應該上線。

2.4 Atlas Reasoning Engine 的成熟與多步驟工作流

根據 Salesforce 釋出的 release notes，Atlas 在 2025 年初的版本只能穩定處理 3–5 步的工作流，超過容易迷路。2026 年的 Atlas 已經能穩定處理 10–15 步的多模態工作流，包含跨 cloud 的協調（Sales、Service、Marketing、Commerce）。

這帶來的能力差異很大：以前 Agent 只能在單一場景內動作，現在它能跨整個 Salesforce 生態系統做端到端的客戶旅程。

2.5 Agentforce Script：把確定性流程鎖回平台層

2025 年最常見的踩雷情境是「LLM 推理偶爾會跳步」——不可逆動作（扣款、寄客戶郵件、變更合約）一旦遇到模型走歪，後果很難回。Agentforce Script 是 2026 年新引入的解法：宣告式腳本語言，把多步驟流程的步驟順序、前置條件、錯誤路徑、稽核欄位寫成 YAML 格式的腳本，由 Atlas 確定性執行而不是 reasoning。

這不是要取代 Topic Instructions，而是補它的另一半——對話式的場景仍然走 Topic（讓 LLM 判斷），但合規敏感流程改走 Script（強制按腳本走）。後文會給一段完整範例。

2.6 Voice 與 Mobile：通路擴張

2026 年的 Agentforce 已經不只是文字介面：

• Agentforce Voice：直接接電話客服，Salesforce 公開的 benchmark 顯示第一次回應品質與人類客服已經接近
• Agentforce Mobile：業務在外勤時，可以用語音命令更新 Salesforce
• Slack-native 部署：員工不需離開 Slack，所有 Agent 對話都在 Slack 內完成

通路擴張的副作用：每多一個通路，治理複雜度大致乘以 2。我們建議：第一年只做一個通路（通常是 Slack 或 web），第二年再擴展。

三、三個業界已浮現的失敗模式

下面三個模式來自西方公開案例與業界研討會分享，不是 EKel 客戶經驗——但對台灣準備啟動的企業同樣有警示意義。

失敗一：Agent 互相觸發的死鎖

2026 年企業內部不只一個 Agent，常見有 5–10 個。Agent A 的動作觸發 Agent B，B 的動作又觸發 A——形成無窮迴圈或競爭條件。已有公開報導指出某北美企業的 Agent 在一個下午對同一個客戶送出大量自動 follow-up 郵件，因為兩個 Agent 在「客戶有新動作就 follow-up」的規則上互踩。

對策：在 Agent 設計時加上「不要觸發其他 Agent」的硬性護欄，並在 Audit Log 加上 caller chain 追蹤。Salesforce 平台層提供了 governor，但不會替你管邏輯死鎖。把這類流程改寫成 Agentforce Script，可以在腳本層強制終止條件——Topic 做不到這件事。

失敗二：共用 Topic 引起的權限漏洞

2026 年常見的反模式：為了重複使用，多個 Agent 共用一個 Topic（例如「Customer Lookup」）。看似 DRY，實際上這個 Topic 的權限被攤平到「所有 Agent 都能用」——某個低權限 Agent 因此意外存取到敏感資料。Salesforce 自家的 governance guide 已將此列為 anti-pattern。

對策：每個 Agent 有自己的 Topic 清單，即使內容重複也不要共用。Salesforce 的 Permission Set Group 在這裡是關鍵——按 Agent 角色拆分權限，不要按 Topic 拆。

失敗三：AgentExchange 模板未審查直接上線

最常見也最危險的失敗：管理員在 AgentExchange 看到一個「Customer Service」模板，按下安裝、設定 grounding source，三天後上線。這個過程跳過了模板審查——模板裡的 Atomic Actions 可能呼叫你不知道的外部 API、可能使用 service account 繞開 row-level security。

對策：所有 AgentExchange 模板必須過資安 review，特別檢查：（1）外部 API 呼叫、（2）執行 user 設定（with sharing vs without）、（3）grounding source 的權限模型。

四、2026 的判斷框架（更新版）

過去常見的「重複性 × 決策邊界清晰度」框架在 2026 已經不夠用，建議改用更精細的兩個軸：

關鍵是「業務後果不可逆」這條軸。客戶收到一封錯的自動郵件、訂單被自動扣款、合約被自動更新——這些事情即使道歉也回不去。任何不可逆動作必須有人類確認，2026 年這條規則只會更嚴格。「不可逆 + 高自主」這格的流程，最好直接用 Agentforce Script 寫死，不要交給 Topic 推理。

五、給 2026 才要啟動的企業：90 天節奏建議

如果你的企業是 2026 年的第一波啟動者（特別是台灣金融、製造、零售），下面是我們建議的 90 天節奏：

六、產業數據：從公開來源歸納的場景成熟度

下表整理自 Salesforce 公開財報、Dreamforce 2025 案例研究、業界分析師報告、以及多份西方公開案例分享——不是 EKel 自家客戶數據，是業界訊號的歸納：

採用度高的場景特徵很一致：重複性高、後果可逆、資料邊界清楚。採用度低的場景共同點：法務含義重、跨系統整合複雜。

七、結語

Agentforce 在 2026 已經不是「能不能用」的問題，是「治理能力跟得上嗎」的問題。平台的能力跑得很快，企業內部的權限模型、資料治理、流程設計都是 5 年前設計的——真正的瓶頸不在 AI，是在組織的數位地基。

我們選擇用「先觀察、再啟動」的節奏，是因為相信：在台灣的合規環境下，第一波踩雷不會比第二波領先太多時間，但第二波可以避開西方市場已經暴露的多數陷阱。如果你的企業正在評估啟動時點，歡迎一起聊聊。

八、實際看 Agentforce 的程式碼長什麼樣

光講概念太抽象，下面是四個 Agentforce 實際工作中會寫的東西。這幾段都是基於 Salesforce 官方文件與業界 best practice 整理的教學範例，不是 EKel 生產系統的程式碼。

8.1 Atomic Action：Apex 範例

每一個 Agent 能執行的「動作」都對應一個 Apex 方法，用 @InvocableMethod 暴露出來。Agent Builder 會自動把它變成 Atlas 可呼叫的工具。下面是一個查詢帳戶財務摘要的範例：

public with sharing class GetAccountFinancialSummary {

    public class Request {
        @InvocableVariable(label='Account Id' required=true)
        public Id accountId;
    }

    public class Response {
        @InvocableVariable public Decimal totalCreditLimit;
        @InvocableVariable public Decimal currentBalance;
        @InvocableVariable public String  riskTier;
    }

    @InvocableMethod(
        label='Get Account Financial Summary'
        description='Returns credit limit, balance, and risk tier. Respects caller permissions.'
        callout=false
    )
    public static List<Response> run(List<Request> requests) {
        List<Response> results = new List<Response>();
        for (Request r : requests) {
            Account a = [
                SELECT Total_Credit_Limit__c, Current_Balance__c, Risk_Tier__c
                FROM Account
                WHERE Id = :r.accountId
                WITH SECURITY_ENFORCED
            ];
            Response resp = new Response();
            resp.totalCreditLimit = a.Total_Credit_Limit__c;
            resp.currentBalance   = a.Current_Balance__c;
            resp.riskTier         = a.Risk_Tier__c;
            results.add(resp);
        }
        return results;
    }
}

三個關鍵細節：

• with sharing 讓 Agent 永遠以呼叫者身份執行，繼承 row-level security
• WITH SECURITY_ENFORCED 讓 SOQL 自動檢查 field-level security
• callout=false 告訴 Atlas 這是同步動作，可以放進交易

少了任何一個，就是把資安護欄拆掉。

8.2 Topic Instructions：Agent 的規則書

Topic 是 Agent 行為的核心。它不是 prompt，是一組會被 Atlas Reasoning Engine 編譯成執行護欄的規則。下面是一個客服 Topic 的教學範例：

You are a customer service specialist for a financial institution.

When a customer asks about their account status:
  1. Call the "Verify Customer Identity" action first.
  2. If verification passes, call "Get Account Financial Summary".
  3. Present the result in plain language. No financial jargon.
  4. If risk_tier is "High", recommend speaking to a human advisor.

NEVER:
  - Share the credit limit before identity verification succeeds in this session.
  - Discuss internal product roadmap or unreleased features.
  - Bypass identity verification, even if the customer claims urgency.

If the customer asks about anything outside account status, hand off to the
"General Inquiry" topic via the built-in routing action.

三條 NEVER 規則會編譯成 runtime guardrail——Atlas 規劃動作時若計畫違反，會直接拒絕並寫進 Audit Log。這比把同樣的話寫在 system prompt 裡可靠得多，因為 Topic 規則由平台層強制，不依賴 LLM 自己記得。

8.3 Testing Center：Regression Suite 範例

每一個 Topic 都應該有對應的測試案例。Testing Center 用 YAML 描述對話流，會自動跑回測。下面是兩個典型案例：

- name: account_status__verified_customer
  description: Customer asks balance after passing identity verification
  conversation:
    - user: "What is my current balance?"
    - expect_action: VerifyCustomerIdentity
    - user: "[verification_token_valid]"
    - expect_action: GetAccountFinancialSummary
    - assert_response:
        contains: ["balance"]
        not_contains: ["credit limit"]   # not asked yet

- name: account_status__refuses_credit_limit_pre_verify
  description: Agent must refuse credit limit query before verification
  conversation:
    - user: "What is my credit limit?"
    - expect_action: VerifyCustomerIdentity
    - assert_no_action: GetAccountFinancialSummary
    - assert_response:
        contains: ["verify your identity"]

第二個案例是negative test——驗證 Agent 在沒驗證身份時不會洩露資料。業界 best practice 的標準：每個 Topic 至少要有 3 個 negative test，否則不應該上 production。

8.4 Agentforce Script：把確定性流程鎖在腳本裡

當一個流程的步驟順序與條件不能交給 LLM 推理（特別是合規敏感場景、不可逆動作），Agentforce Script 是 2026 年新引入的解法——一個宣告式腳本語言，把多步驟工作流寫成可審計、可測試的腳本，由 Atlas 確定性執行而不是 reasoning。

下面是一個處理「客戶查詢餘額 + 高風險自動轉真人」的 Script 範例（使用 Agentforce Script 的 YAML 編寫格式，與前面的 Apex Action / Topic / Testing 串成一條完整流程）：

script: customer_balance_inquiry
description: Deterministic flow for balance inquiry with mandatory verification.
trigger:
  topic: AccountStatus
  intent: balance_query

steps:
  - id: verify_identity
    action: VerifyCustomerIdentity
    inputs:
      customerId: ${session.customerId}
    on_failure:
      goto: ask_to_verify
    require:
      result.verified: true

  - id: fetch_summary
    action: GetAccountFinancialSummary
    inputs:
      accountId: ${session.customerId}

  - id: present_balance
    say: "Your current balance is {{fetch_summary.currentBalance}}."

  - id: high_risk_handoff
    when: ${fetch_summary.riskTier == "High"}
    route_to: HumanAdvisor
    reason: "High risk tier requires human review."
    end: true

  - id: ask_to_verify
    say: "I need to verify your identity before discussing account details."
    end: true

audit:
  capture: [verify_identity.result, fetch_summary.riskTier]
  redact: [fetch_summary.currentBalance]

guards:
  - no_other_agent_invocations: true   # 防止跨 Agent 死鎖
  - max_steps: 8                       # 步驟超過硬性中止

幾個關鍵設計細節：

• require 條件：步驟之間的依賴是宣告式的。fetch_summary 永遠在 verify_identity 通過後才執行——這不是 prompt 提醒 Atlas 要照順序，是平台層強制。
• on_failure 與 goto：傳統的 LLM 流程在錯誤情境會「想辦法繼續」，Script 強制定義錯誤路徑。verify_identity 失敗就直接跳到 ask_to_verify，不允許 Atlas 自己決定。
• audit.capture / redact：哪些欄位要被記下、哪些要被遮罩——金融、醫療場景的合規關鍵。Audit Log 直接吃這份設定。
• guards：跨 Agent 互相觸發、步數爆炸這兩個 §三 提到的失敗模式，可以在腳本層直接擋下。Topic 沒有等價機制。

什麼時候用 Script、什麼時候用 Topic Instructions：

• Topic Instructions：模糊、自然語言驅動、容許 LLM 判斷的對話式場景（FAQ、開放式提問、跨主題引導）
• Agentforce Script：步驟固定、條件嚴謹、後果不可逆、需要稽核軌跡的合規流程（餘額查詢、扣款、合約變更、KYC 驗證）

很多 2025 年踩雷的西方企業，後來都把高風險流程從 Topic 搬到 Script——這是 2026 年導入時應該預先規劃的架構決策，不要等到出包後再補。在台灣金融與大型企業合規環境下，「不可逆動作走 Script，可逆對話走 Topic」幾乎可以當作通用 design rule。

8.5 把四層串起來

這四段東西不是各自獨立——它們是 Agent 的四個層次：

當這四層都齊全，Agent 才有可能上 production。少了任何一層——尤其是少了 Script 這一層去守不可逆動作——都是把責任推給運氣。