Salesforce Agent Fabric 推代理評估，自動攔截明年一月到位

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2026 年 10 月 27 日晚間 9 點（台北時間），Salesforce 在官方新聞室發布 Agent Fabric 的擴充更新：Agent Evals、API Evals，以及一組成本控制功能；官方帳號在九分鐘後跟著宣布。公告的標題承諾很直白：在影響客戶之前，自動擋下失控的成本與出錯的 AI 代理。把公告附的時程表拆開看，這句承諾要分兩段兌現：公告當天就能用的是人工出手的緊急停止開關、硬性預算上限與跨閘道政策；至於「自動」的那一半，兩項評估功能 2026 年 11 月才進入 beta，評估觸發的自動停止要等 2027 年 1 月的正式版。這篇依官方公告與產品文件，把三層時程、官方示範的攔截流程，以及幾個需要打折讀的宣稱分開整理。

掛在 Agent Fabric 上，與 Agentforce 是兩條產品線

先定位這次更新的主角。Agent Fabric 是 Salesforce 底下 MuleSoft 產品線的跨平台 AI 控制平面，用產品頁自己的說法，就是用單一控制台去註冊、管理、治理並觀察企業裡所有的代理與 MCP 端點。它與 Agentforce 是兩回事：Agentforce 是在 Salesforce 平台內建置與執行代理的產品，Agent Fabric 則不管代理建在哪個平台上，都收進同一份註冊表管理，兩者共用同一套定義代理如何處理互動、推理與行動的引擎。文中的 MCP 指的是讓 AI 應用連接外部工具與資料的開放協定，企業內的代理靠它去呼叫庫存、付款、行事曆或內部資料系統，因此 MCP 伺服器在治理清單上也是一級公民，同樣要被點名看管。可以把控制平面想成代理的戶政系統：先知道企業裡有哪些代理存在、誰擁有、連到哪些系統，後面的一切治理才有對象。

規模數字方面，Salesforce 自述 Agent Fabric 目前每天處理超過 12 億個請求，公告未附計算口徑。治理這個議題在 Salesforce 生態並不陌生，九月中的 Dreamforce 2026 場上，幾位 AI 巨頭才對代理時代該不該放慢腳步給出截然不同的答案。

既有能力裡，掃描器已能自動發現並註冊 Amazon、Google、Microsoft、Claude、Databricks、Kong 等生態系上運行的代理、MCP 伺服器與 API。這次新增的 Custom Agent Scanner 則讓企業自建掃描器，把自動發現延伸到內部環境、防火牆後方的系統，以及超出既有支援清單的第三方平台；掃到的資產直接進入 Agent Registry，不必逐一手動註冊。這項功能公告當天就是 beta，正式版同樣排在 2027 年 1 月。

時程表分三層：今天、十一月、明年一月

公告最值得細讀的是文末的 Availability 段，六個功能項各自標了不同時間點，拆成三層來看會清楚很多。

公告當天正式提供的有三組：既有的人工版 Agent Kill Switch（緊急停止開關）、FinOps Dashboard 與 Model Wallet 加上 Cost Optimization Policies 這組成本控制，以及 Open Policies for Federated API Gateways，後者能在 Azure、Apigee、Kong 三家其他廠商的閘道上統一套用政策，例如 IP 允許清單或速率限制，一次設定套用到全部。對同時經營多套閘道的企業來說，這代表政策不必再逐套重設；而公告引用的統計裡，96% 的企業在多於一個平台上跑代理，跨平台正是這條產品線賭注的核心。

2026 年 11 月進入 beta 的是兩項評估功能：Agent Evals 與 API Evals。2027 年 1 月則是另一個關口，兩項評估功能的正式版、評估觸發的 Triggered-Agent Kill Switch，以及 Custom Agent Scanner 的正式版都排在這個月。

這就是標題承諾與時程表之間的縫隙：一條「評估發現品質下滑，自動把代理停掉」的完整鏈路，需要 Agent Evals 加上 Triggered 版的停止開關，兩者都要等到 2027 年 1 月才正式提供。換句話說，公告當天企業能做的是由人出手的停止與預算防線，自動攔截的那一半還在路上。兩種停止開關的差別在實務上不小：人工版的意思是有人盯著監控、判斷、然後伸手關掉，前提是問題先被看見；觸發版則把「品質低於門檻」這個判斷交給排程測試，命中就啟動預設的處置。前者考驗的是監控與值班安排，後者考驗的是門檻與處置政策事先設得多周全。公告頁尾其實自己寫明了這一點，那段免責聲明說：本文可能提及仍在開發、尚未發布的服務或功能，客戶的採購決策應以完全發布且可用的功能為準。

Pin

官方示範的攔截流程：偵測、隔離、重評、回到線上

Agent Evals 依公告定義做兩件事：部署前自動產生測試，上線後依事先定義的品質門檻，在正式運作期間持續評估代理、語言模型與 MCP 伺服器；結果低於門檻時觸發預先定義的介入措施，包括 Agent Kill Switch，若團隊政策要求人工同意，就先取得同意再動作。產品頁另外註明 MCP 伺服器與 LLM 的評估是後續推出，也就是說首波上線時的評估對象以代理本身為主。API Evals 則從 API 規格自動產生功能與效能測試，在破壞相容性的變更進入正式環境前先抓到，官方把代理依賴的介面變更明確點名為失敗來源之一。實際場景不難想像：上游服務把欄位改名、回應格式換了一套、或回應速度突然變慢，代理就算選對工具也照樣拿到錯的或遲來的資料，使用者端看到的症狀，最後往往讓人直覺怪罪模型。品質門檻本身則需要事先定義，系統能替你產測試、跑排程、觸發介入，但「多準確才算合格」「哪種錯誤必須立刻隔離」這些標準，仍然是每個組織要自己回答的問題。

公告用一個零售情境示範整套流程怎麼走，四個步驟都寫明在頁面上。情境是零售商為了省錢，把訂單客服代理換到較便宜的模型；換完之後，Agent Evals 的排程測試偵測到代理對延遲訂單給出錯誤資訊。接著系統標記品質問題，並依照這家公司「保留人工判斷」的設定，先徵得同意才隔離代理；隔離期間團隊修改代理處理延遲訂單的指示，再用新指示在便宜的模型上重新評估，確認表現符合要求後才讓代理回到正式服務。

Pin

這段是官方提出的示例，不是已公開證實的客戶案例，引用時值得記住兩件事：其一，流程裡的自動偵測與自動標記依賴 Agent Evals，最快要到 11 月的 beta 才摸得到，完整上線要看明年 1 月的正式版；其二，人工同意被放在隔離之前，這個位置是客戶政策決定的，不是系統固定行為。想在官方功能之外先自己動手稽核代理的團隊，開源圈已經有代理稽核工具可以把關，不必等 11 月的 beta。

成本控制今天就能用，擋的是請求不是事後帳單

成本控制這組是公告當天正式提供的部分，也是這波更新裡企業現在就能實際碰到的功能。FinOps Dashboard 把 AI 支出收進單一檢視，Model Wallet 則給預算負責人硬性上限，公告的說法是在成本超出預算之前就停止請求。產品頁的 FAQ 補了幾個實作細節：預算可以逐代理、逐實例或逐事業單位設定，支出即時累計，額度用罄前就介入，預測功能會提前數天標示預計超支。支出數字的計價方式也寫得明白：流量經過代理層時，每個請求依企業實際議定的費率計價，型號、消耗的 token 與供應商費率被記在同一筆，頁面上的說法是儀表板上的數字就是發票上的數字；未經過代理層的模型，則回報可驗證的 token 量與呼叫次數。

硬上限的另一面也值得想清楚：被擋下的是新的請求，若額度見底時客服代理正在服務使用者，先感受到的會是使用者，不是帳單。這層風險公告沒有展開，企業安排預算時最好先區分測試與正式服務的額度。

Cost Optimization Policies 宣稱最多可減少 75% 的 token 用量，token 是模型處理內容的計量單位，輸入越長、輸出越多、代理反覆呼叫，費用就越高。官方在公告裡自己標註了但書：這個數字基於測試情境，是特定情境下的最高值。手法有三種：語意快取（重用相近請求的結果）、內容壓縮與回應修剪。FAQ 另載明最佳化政策在閘道器上執行，不必修改 MCP 伺服器或代理的程式碼，要不要套用由企業自己決定。快取與修剪對任務的影響因情境而異：語意快取重用相近請求的結果，若配送狀態這類時效資料停在快取裡沒有更新，使用者拿到的就是過期答案；修剪省略的內容，在訂單條件或合約條款這類文字裡可能正是決策所需的那一句。省下的 token 與保留的必要細節之間怎麼取捨，決定權同樣在企業手上，量測方式官方沒有提供；合理的做法是先固定一批測試題與評分標準，分別記錄啟用前後的用量與正確率，再對照發票驗證節省是否真的成立。

三個數字與四段見證，各有各的讀法

公告開頭引用了三個規模數字，出處性質各不相同。「少於半數有代理的組織會在實際流量上評估代理」這句，公告連到 LangChain 的 State of Agent Engineering 報告；「96% 的企業在多於一個平台上運行代理」這句，連到的頁面是 The Atlantic 上標示為 Salesforce 贊助的內容，也就是 Salesforce 出資製作的素材；至於每天 12 億個請求，則是 Salesforce 自己的說法，未附統計方法。三個數字都如實反映了代理治理的痛點，但引用時知道各自的出處性質，會更準確。

四家客戶的引述同樣是公告安排的見證。ASICS Digital 數位商務工程總監 Poonam Deshpande 表明正在參與 Agent Evals 的 beta 合作，引述裡把這套功能的價值講在「不停在告訴你出錯」，而在品質下滑時自動通知負責人或把代理下線；GE Appliances 的 Adam Jones 那句「看得到我們的代理、知道誰建的、出事能關掉」把治理需求講得最直白；Capita 的 AI 工程總監 Tiina Stephens 把重點放在「對著明確的業務與服務成果驗證代理表現」，Newell Brands 全球客服副總裁 Steve Sigrist 則強調每個品牌下的每個代理都要看得到、被治理、可問責，兩段引述都把信心建立在流程上，而非模型能力本身。負責這條產品線的 Andrew Comstock（MuleSoft 與 Agent Fabric 資深副總裁暨總經理）的說法是：企業擴張代理的速度，取決於能多快讓代理保持準確並控制在預算內，而「發現問題」與「解決問題」今天是兩份工作，Agent Fabric 要把它們放進同一個地方。

把「行動之前先過人工這一關」當成治理設計的廠商不只 Salesforce。OpenAI 針對企業資料分析的 ChatGPT Data agent 同樣把連線核定與行動同意畫進治理邊界，兩家做法細節不同，方向是同一個：代理可以建議，關鍵動作留給人。

現在能做什麼，還不知道什麼

公告落地後，企業端現在能做的事相當有限但具體：產品頁提供 30 天免費試用，標明免信用卡、免安裝；更實際的第一步是把「哪些代理在跑、誰擁有、超支或出錯時誰有權限處置」這份清單盤出來，因為無論評估還是預算功能，前提都是先看得到資產。

不知道的部分也一樣具體：兩項評估功能的 beta 只承諾到 2026 年 11 月，沒有確切日期；各功能會包進哪些方案、既有 Agent Fabric 客戶要不要加購，產品頁只留下一句「聯絡你的客戶團隊」，洽詢時值得直接把這份 availability 清單帶著對；正式版只承諾 2027 年 1 月；各功能歸屬哪些方案版本與定價，公告與產品頁都沒有揭露；台灣區的銷售條件與資料駐留細節同樣未載明；75% 的節省幅度能否在自己的環境重現，官方已經先用「測試情境」四個字劃清了界線。

回查的節點也清楚：11 月看 beta 開放與首批使用心得，特別是自動產生的測試題品質與 MCP、LLM 評估是否跟著首波推出；2027 年 1 月看正式版與 Triggered-Agent Kill Switch 是否如期，這兩個時間點都過了之後，這份公告才算真正兌現。把這份公告當路線圖讀，比當功能清單讀更有價值，它真正畫出的是評估、預算、介入這三件事會在哪個時間點被接上同一條線。