LangSmith 如何查 AI 程式代理成本？從執行軌跡到模型路由
LangChain 分享程式代理的成本治理方法。本文說明 LangSmith 執行軌跡、LLM Gateway 與模型路由如何分工，以及為什麼降低 token 費用仍要一起看成功率和重試成本。
LangSmith 是 LangChain 的代理觀測與評估平台，能把模型呼叫、工具操作、子代理和重試整理成執行軌跡。對使用 AI 寫程式的團隊而言，這些紀錄可以幫助回答：費用花在哪裡，以及哪些工作反覆失敗。
LangChain 共同創辦人 Harrison Chase 近日在 X 分享，團隊使用觀測、閘道和模型路由來控制程式代理成本。這是一組互相配合的方法；單看某個模型的單價，往往看不見代理整段工作的浪費。
執行軌跡如何找到重複花費
執行軌跡是一次任務的操作紀錄，從使用者要求開始，連接到模型輸出、工具呼叫與結果。官方說明 提到，LangSmith 能整理不同程式代理的紀錄，包括模型輸入輸出、token、成本、時間與子代理。
文章中的案例很具體：主代理把子代理指向使用舊分頁方式的程式，導致它持續做錯。使用者不斷重述需求，卻沒有處理錯誤的背景來源。看見交接紀錄後，團隊才知道應修正哪一段指引。
成本問題因此可以分成兩類：單次呼叫太貴，以及流程讓相同工作反覆發生。後者即使換成便宜模型，仍可能浪費大量時間。
LLM Gateway 把使用規則放在同一入口
LLM Gateway 是模型閘道，讓不同應用透過共同入口呼叫模型。依LangSmith 文件，它提供集中管理模型存取與使用量的方式。
觀測平台告訴團隊已經發生什麼，閘道則提供執行規則的位置。團隊可以依實際支援功能與設定，管理可用模型、憑證和用量。這些規則要連到正在使用的工作流程，才能影響真實費用。
導入時也要確認哪些呼叫經過閘道。如果部分工具直接使用各自的金鑰，統計就可能少一塊。完整的呼叫清單，比單一儀表板上的總數更能避免誤判。
模型路由，依任務選擇模型
模型路由是根據任務特性選擇模型。例如先由較省資源的模型處理清楚的小修改，遇到複雜除錯或失敗重試，再轉交能力較強的模型。
LangChain 的路由實作文章 將選擇邏輯放在代理的執行框架。執行框架負責安排工具、上下文和模型呼叫，因此能依工作狀態改變選擇。
| 方法 | 主要回答的問題 | 實際要觀察的資料 |
|---|---|---|
| 執行軌跡 | 為什麼花了這麼多 | 重試、工具失敗、子代理交接 |
| 模型閘道 | 哪些使用符合規則 | 呼叫來源、用量與設定 |
| 模型路由 | 這個步驟用哪個模型 | 任務難度、結果品質與升級條件 |
路由策略需要評估資料支持。便宜模型若經常失敗，再由昂貴模型重做，總成本可能反而增加。
小團隊可以先算每個成功任務的成本
每個成功任務的成本，是把成功和失敗嘗試都算進去，再除以達標任務數。這比只看平均單次呼叫費用，更接近產品真正付出的代價。
可以先記錄同一類任務的成功率、總費用、完成時間與人工修正時間，再比較加入路由前後的變化。不要同時改提示詞、工具與模型，否則很難知道改善來自哪裡。
我的判斷是，先觀測再改路由通常更合理。找到代理最常卡住的地方，可能只需修正文件或工具回傳；等流程穩定後，才有可靠資料判斷哪些步驟適合換模型。
常見問題
換便宜模型一定能省錢嗎？
要把重試和人工修正一起計算。能完成任務的總成本，比模型單價更有參考價值。
執行軌跡可以公開分享嗎？
紀錄可能包含程式、客戶資料與金鑰相關資訊。分享前應檢查內容與遮蔽設定，限制在需要的範圍。
這套方法保證降低多少費用？
作者的分享沒有提供適用所有團隊的固定降幅。每個團隊都需要用自己的任務與量測期間驗證。
結語：讓成本連到實際完成的工作
LangSmith、閘道與路由各自處理不同問題。把費用連回執行過程與成功結果，團隊才知道該修工具、改流程，或調整模型，而能逐步建立可維護的成本控制方式。
