AI代理應該呼叫模型

MLAT論文描述了一個生產環境試點：代理將XGBoost定價模型作為工具呼叫，在留出資料上達到R^2 = 0.807，平均絕對誤差為3688 USD，並將提案產生時間從數小時縮短到10分鐘以內。¹

真正有用的不是那個特定的定價模型，而是邊界本身：當任務需要分數、預測、價格、風險估計、排序、分類器或偵測器時，代理應該呼叫為該工作訓練的模型，而不是用流暢文字臨場編出統計答案。

訓練完成的模型應該放進代理工具登錄表。LLM可以判斷何時呼叫它、解釋結果、詢問缺少的輸入，並處理例外狀況。擬合後的模型則應產生數值估計、信心訊號、帶版本資訊的輸出，以及可追溯的證據記錄。

摘要

LLM代理擅長編排。統計與機器學習模型通常更擅長有明確邊界的預測。Machine Learning as a Tool模式將擬合完成的ML模型視為代理工作流程中的可呼叫工具，與搜尋、資料庫、API和其他工具並列。¹

這個模式給團隊一條清楚的運作規則：由代理協調工作，但讓專門模型負責專門推論。結果應包含模型版本、輸入結構描述、輸出結構描述、校準說明，以及可追蹤的呼叫紀錄。少了這條邊界，LLM可能聽起來很篤定，卻在暗中用猜測取代模型。

重點整理

• 給代理建置者：將訓練完成的模型公開為具型別的工具，並定義結構描述、版本與失敗模式。
• 給ML團隊：把代理視為呼叫端，而不是模型評估、持久化或登錄紀律的替代品。
• 給產品團隊：顯示某個數字究竟來自模型呼叫、規則、資料庫，還是LLM解釋。
• 給安全團隊：將代理金鑰需要風險預算中的範圍化權限邏輯套用到模型工具。
• 給審查者：在信任答案之前，要求看到模型呼叫、模型版本、輸入、輸出與信心界限。

為什麼代理應該呼叫模型，而不是模仿模型？

LLM可以討論價格。定價模型可以根據學到的特徵估算價格。LLM可以摘要風險。風險模型可以用經測試的特徵集計算風險分數。LLM可以描述流失。流失模型可以回傳與訓練流程相連的機率。

這些是不同工作。

代理工具已經讓這種切分成為可能。OpenAI的Agents SDK文件說明了具備JSON Schema參數、工具呼叫處理器，以及結構化工具輸出的函式工具。²Anthropic的工具使用文件描述Claude如何以JSON Schema輸入呼叫用戶端工具與外部函式。³代理可以透過同一種工具模式請求模型預測，就像它用來搜尋、更新行事曆、執行shell命令或查詢資料庫一樣。

核心失敗模式出現在團隊跳過這條切分時。他們向LLM要求估計，因為LLM能產生一個估計。答案很快出現，文字看起來也合理。介面卻沒有任何明顯線索，說明那個數字是來自模式補全，而不是擬合完成的估計器。

這是一份薄弱的契約。使用者不知道結果由什麼產生。審查者無法檢查模型版本或輸入特徵。操作人員無法重播呼叫。產品也無法解釋答案為何改變。

證據關口在這裡同樣適用：信心不是證據。模型呼叫可以產生證據；文字猜測通常不行。

MLAT模式新增了什麼？

MLAT代表Machine Learning as a Tool。該論文將訓練完成的ML模型定位為一等工具，讓LLM代理在對話需要量化估計時呼叫。¹

論文中的試點系統PitchCraft使用兩個代理。研究代理透過平行工具呼叫蒐集潛在客戶脈絡。草稿代理呼叫XGBoost定價模型，接著透過結構化輸出撰寫提案。¹ML模型負責定價，LLM負責脈絡、組裝與解釋。

這種切分很重要，因為它避開了兩種糟糕設計：

代理依然重要。它可以判斷定價輸入是否不完整，可以向使用者詢問缺少的欄位，也可以在呼叫模型前先呼叫搜尋或CRM工具。它還可以說明估計來自模型，而不是來自自身權威。

這才是正確分工：LLM負責編排；擬合模型負責預測。

模型工具應該回傳什麼？

模型工具不該只回傳一個裸露數字。嚴謹的模型工具應該回傳一個證據物件。

這種輸出形狀讓模型工具能與代理執行追蹤就是執行環境契約相容。如果代理呼叫定價模型，追蹤中就應顯示模型呼叫。如果代理跳過模型卻仍寫出數字，追蹤也應讓這個缺席一目了然。

同樣邏輯也支援審查封包才是新的最終答案。只帶價格的最終答案很薄弱。帶有模型呼叫紀錄、模型版本、特徵快照與信心說明的最終答案，才給審查者可檢查的材料。

模型登錄表放在哪裡？

工具包裝不會取代MLOps。它會把MLOps暴露給代理執行環境。

MLflow的模型登錄表文件描述了模型的譜系、版本、別名、後設資料標籤與生命週期資訊。⁴這個登錄層很重要，因為只有平台本身追蹤版本，代理工作流程才有模型版本可引用。

Scikit-learn的模型持久化文件則從服務端提出相關觀點：持久化選擇帶有安全性與可攜性取捨，ONNX可以在沒有Python環境的情況下服務模型，而以pickle為基礎的路徑則需要信任來源。⁵模型工具不該只因代理要求預測，就把不安全的模型成品偷渡進代理。

最低限度的運作堆疊如下：

團隊經常把這些層全部壓成一個名為predict的端點。這種捷徑在示範中可行；一旦代理開始把預測串進客戶email、銷售提案、核保備註、基礎設施規劃或醫療分流草稿，就會失效。

產品需要的是模型契約，不是魔法端點。

產品應該如何呈現模型輸出？

UI應告訴使用者：某個答案何時來自模型工具。

糟糕的介面文案會隱藏來源：

更好的文案會說明產生路徑：

這個區分保障使用者尊嚴。使用者不該被迫猜測某個數字是來自經測試的模型、模型卡、商業規則，還是語言模型補全。代理式設計就是控制介面設計主張，代理產品需要提供監督與控制介面。模型來源就是其中之一。

模型卡也能在文件層處理同一個問題。Model Cards論文提出以結構化方式報告模型特性、預期用途、指標與評估脈絡。⁶代理介面可以在執行環境中借用這個想法：每個模型答案都應帶有足夠脈絡，讓使用者或審查者理解模型提出的是哪一類主張。

代理應該拒絕什麼？

具備模型意識的代理應拒絕幾種誘人的捷徑。

當模型工具無法使用時，它應拒絕捏造模型輸出。它可以說定價模型失敗，也可以詢問使用者是否需要粗略的人工標記估計；但不應默默取代模型。

它應拒絕在沒有證據時擴大模型領域。以中型市場SaaS資料訓練的流失模型，不會因為提示語客氣，就變成通用的企業健康神諭。

它應拒絕隱藏不確定性。如果模型回傳區間，除非產品有明確顯示規則，答案不應把它壓成單一且自信的數字。

它應拒絕用缺漏或捏造的特徵呼叫模型工具。代理可以蒐集輸入、追問問題，或將欄位標記為未知；不該用方便的虛構內容填滿特徵向量。

它應拒絕把模型權威當成行動權限。模型可以估計詐欺風險，但這不代表代理可以凍結帳戶。行動仍需要代理金鑰需要風險預算中的範圍化金鑰紀律。

決策規則

建置代理工作流程時，請使用這條規則：

這條規則讓LLM擁有有價值的工作，同時不讓它冒充每個其他系統。它可以協調工作流程、解釋輸出、起草訊息，並提出更好的問題。它不能只靠流暢語氣就變成定價模型、風險模型、詐欺模型、排序模型或政策引擎。

最好的代理產品不會要求一個模型假裝成整間公司。它們會建置一個工具介面，讓每個系統做自己能證明可勝任的工作。

FAQ

這只適用於傳統機器學習模型嗎？

不是。同一模式適用於任何專門估計器或評分器：梯度提升模型、分類器、排序系統、預測模型、規則引擎、檢索評分器，以及特定領域偵測器。重點不是演算法，而是圍繞輸出的契約。

為什麼不讓LLM直接估計？

有時候，粗略的定性估計已經足夠。產品應清楚說明這一點。當使用者需要價格、風險分數、預測或資格決策時，答案應來自經測試的模型或規則路徑，並帶有可追蹤的輸入與限制。

模型工具會讓答案自動正確嗎？

不會。模型工具仍可能過時、有偏誤、校準不良、被誤用，或超出有效領域。模型工具改善的是可檢查性，並不免除評估、監控與人工審查。

最低可行的模型工具契約是什麼？

從輸入結構描述、輸出結構描述、模型版本、預測、信心或但書、錯誤形狀、逾時與追蹤ID開始。若模型影響金錢、存取、安全或面向客戶的決策，再加入特徵名稱、登錄表連結、模型卡參考與校準說明。

這會如何改變代理UX？

介面應標示重要輸出的來源。使用者應看得出答案是來自模型呼叫、擷取的文件、商業規則、人工核准，還是LLM綜合。這種來源資訊會改變答案值得信任的程度。

參考資料