普通問答分數(shù)高不代表 Agent 能力好。我最近在整理類似 Agents on Rails 的 LLM Benchmark Project 時最大的感受是LLM Agent 的評測真正該看的不是模型能不能說出正確答案而是模型能不能在給定邊界和行動序列里把任務跑完。Agents on Rails 這個名字很直白rails 指的是軌道、邊界、約束benchmark 是在這條標準化軌道上做考試。如果你正在選型大模型、做工具調(diào)用型 Agent或者想給內(nèi)部系統(tǒng)建立一套回歸評測后面這套拆解方式可以直接幫你把任務集、執(zhí)行環(huán)境、判定規(guī)則和日志結(jié)構(gòu)串起來。我不打算先講榜單分數(shù)而是先解決一個更基礎(chǔ)的問題什么樣的基準測試才算真的在測 Agent。1. 為什么 Agent 評測不能直接拿普通問答分數(shù)湊合1.1 問答測的是“記得住”Agent 測的是“完得成”普通 LLM Benchmark 的典型題目是給一段知識或推理問題讓模型輸出答案。評測時比對答案正確性比如字母題、數(shù)學題、百科知識題。這類任務的核心是模型肚子里有沒有貨能不能把已經(jīng)訓練的推理能力調(diào)出來。Agent 任務不是這樣。它會更多出現(xiàn)“查一下三個平臺的價格取最低價并按固定 JSON 返回”這類需求。模型不是直接背答案而是要完成一連串動作從自然語言里拆出查詢條件。決定調(diào)用哪個工具。傳入正確的參數(shù)。拿到工具返回結(jié)果后再判斷下一步。最后按照指定格式輸出結(jié)論。如果評測只看最終文本是否包含想要的關(guān)鍵詞中間步驟錯了也發(fā)現(xiàn)不了。比如模型根本沒有調(diào)用查詢工具而是根據(jù)訓練記憶編了一個價格最終結(jié)果可能看起來像模像樣但實際任務根本沒完成。普通問答評測很難抓住這種問題因為它的判定對象是“一句話”不是“一個帶狀態(tài)變化的過程”。1.2 軌道約束是公平評測的前提自由對話式的 Agent 評測看起來很靈活但會讓不同模型之間的比較變得非常不靠譜。一個模型可能一直在解釋思路但不執(zhí)行另一個模型可能第一次就調(diào)用工具還有一個模型繞了五步其中兩步訪問了不應該訪問的數(shù)據(jù)。這些路徑差異會讓結(jié)果無法量化。按軌道化思路設(shè)計時需要先定義清楚這幾樣東西允許使用的工具名單。每輪任務的最大步數(shù)。輸入狀態(tài)和輸出狀態(tài)。什么情況下算成功。什么行為算越界。這么做的目的不是限制 Agent 的真實能力展示。任何一次可復現(xiàn)評測都需要把不可控變量收住讓模型只在同一個賽道里比賽。否則模型 A 在 2 步內(nèi)完成模型 B 在 12 步內(nèi)完成模型 B 的成功率也可能算 100%但成本和穩(wěn)定性已經(jīng)被拖垮。1.3 誰最需要這類評測第一類是做模型選型的人。他們要比較不同 LLM 在工具調(diào)用和任務執(zhí)行上的差距不能只看 MMLU、GPQA 這類問答榜。第二類是 Agent 應用開發(fā)者他們頻繁改 Prompt、換函數(shù)定義、調(diào)整工具返回格式需要一套回歸任務保證改動不破壞已有能力。第三類是偏研究的人想通過任務集觀察模型在規(guī)劃、糾錯、格式遵循上的邊界。我個人更建議先分清目的再選任務。如果只是做問答能力摸底普通 Benchmark 夠用如果想評價 Agent 能不能在邊界內(nèi)完成任務就必須走任務軌道化評測。2. 先拆任務把 Agent 能力切成可測量單元2.1 一項 Agent 任務包含多個能力點如果只統(tǒng)計最終成功率你很難回答一個問題模型到底是因為不會規(guī)劃而失敗還是因為不知道工具參數(shù)格式而失敗。所以設(shè)計評測任務時我會先把能力拆成四個單元能力單元代表行為失敗時常見表現(xiàn)指令理解從任務描述中提取目標、對象、約束參數(shù)缺失理解錯條件動作選擇判斷當前該調(diào)用什么工具不調(diào)用工具或選錯工具結(jié)果解釋理解工具返回內(nèi)容并決定下一步忽略關(guān)鍵字段重復調(diào)用同一工具收斂輸出在允許步數(shù)內(nèi)產(chǎn)生最終答案循環(huán)調(diào)用輸出格式不符合要求每個任務跑完之后不只記成功失敗還要記是哪個能力點先斷掉。比如任務日志里出現(xiàn)“agent 第 3 步嘗試調(diào)用 search但 action_input 缺少 query 字段”這屬于工具調(diào)用協(xié)議問題出現(xiàn)“agent 在最終輸出里寫了一整段分析沒有 required_fields”這屬于格式遵循問題。2.2 成功標準必須落到狀態(tài)變化上一份好的任務定義應該像驗收文檔不能只寫一句“回答正確”。下面是一個我會直接用的最小結(jié)構(gòu)字段含義是通用的不是某個項目官方格式{ task_id: order-logistics-001, goal: 根據(jù)訂單號查詢物流狀態(tài)判斷訂單是否已簽收, initial_state: { order_id: SO20250101 }, max_steps: 6, allowed_tools: [find_order, query_logistics], required_fields: [order_id, delivery_status, conclusion], expected: { delivery_status: signed, conclusion: yes }, validators: [conclusion_is_yes, status_matches_expected] }問題來了為什么成功標準不能只看conclusion因為模型可能跳過工具查詢直接根據(jù)訂單號猜結(jié)果。真實業(yè)務里這種輸出毫無價值。所以 Validator 里可以再加一條must_call_query_logistics確保任務確實走過了該走的路徑。2.3 任務難度要分檔不要把簡單任務和復雜任務混在一起算平均分。一個模型在 5 個簡單任務上拿滿分在 3 個長鏈路任務上全部失敗平均分可能仍然很體面但實際部署到復雜業(yè)務里會立刻暴露問題。我的經(jīng)驗是把任務集分成三檔L1單工具1 到 2 步可完成重點看指令理解和輸出格式。L2多工具需要根據(jù)中間結(jié)果決策3 到 6 步。L3長鏈路需要過濾噪聲、分階段匯總、處理數(shù)據(jù)缺失最多 8 到 12 步。每檔至少準備 20 到 30 條初期也可以先用 5 到 10 條快速驗證流程。任務數(shù)量不夠時不要急著上報準確率因為影響分數(shù)的隨機波動會被誤讀成模型能力差異。3. 搭評測軌道從任務樣例到統(tǒng)一流程3.1 把 Agent 交互改成狀態(tài)機自由聊天式評測的問題在于Agent 輸出什么都可以繼續(xù)。要搭軌道就應該把流程壓縮成一個循環(huán)讀取任務初始狀態(tài) - 把“當前狀態(tài) 可用工具 約束”發(fā)給 LLM - 模型返回動作 - 解析動作 - 如果動作是調(diào)用工具讓模擬器執(zhí)行并把結(jié)果追加到上下文 - 如果動作是最終答案進入結(jié)果校驗 - 如果超過 max_steps按失敗結(jié)束這個循環(huán)看起來簡單但能保證每個模型都處在同一個可比較環(huán)境里。模型不能跳出軌道因為評測環(huán)境只接受兩種輸出工具調(diào)用動作和最終答案。即便模型想自由發(fā)揮環(huán)境也會把它拉回任務軌道。3.2 模型輸出協(xié)議要固定很多 Agent 評測跑得不順是因為模型返回的格式太自由。有人返回一句話“我需要查詢訂單”有人返回 Markdown有人嘗試輸出一個代碼塊。評測程序接收這些內(nèi)容時解析成功率就會很低。穩(wěn)妥做法是強制要求模型按結(jié)構(gòu)化 JSON 返回。比如{ thought: 需要先根據(jù)訂單號查詢訂單信息, action: find_order, action_input: { order_id: SO20250101 } }如果結(jié)果已確定則{ thought: 物流狀態(tài)已經(jīng)是 signed可以結(jié)束, action: final, action_input: { order_id: SO20250101, delivery_status: signed, conclusion: yes } }評測端把 action 解析出來后才把 action_input 轉(zhuǎn)成工具調(diào)用。如果模型返回的不是合法 JSON或 action 不在允許列表內(nèi)直接記一條format_error。這類樣例會真實影響評測結(jié)果所以 Prompt 里必須給清晰示例不能只講規(guī)則。3.3 模擬器和真實工具分開做 Benchmark 時我不能讓你所有任務都直接調(diào)真實外部 API。原因很直接第三方接口可能變慢、限流、返回字段也可能變動最后失敗的是誰分不清是模型還是外部服務所以第一版優(yōu)先用模擬工具。模擬器不復雜就是預設(shè)好返回值和可變狀態(tài)。比如find_order模塊接收order_id返回一條固定訂單記錄query_logistics接收訂單號根據(jù)訂單狀態(tài)返回物流物流節(jié)點。模擬器會讓任務可重復也會讓排查鏈路變短不會出現(xiàn)“上一次能成功這一次外部接口漲價導致超時”這種問題。等核心評測穩(wěn)定以后再按需要增加真實工具測試但二者必須分開計分。否則把環(huán)境變量混在一起整個基準測試的可信度會下降。4. 跑批與指標怎么判斷模型變強還是變貴4.1 每條任務需要記錄哪些日志評測結(jié)構(gòu)要在結(jié)果里保留足夠信息否則后續(xù)無法復現(xiàn)。我通常給每個任務記錄這樣一批字段字段說明task_id任務編號model被測模型名稱temperature溫度參數(shù)run_id同一任務同一模型的多輪編號success是否通過校驗error_type錯誤分類如 timeout、format_errorstep_count實際執(zhí)行步數(shù)tool_used實際調(diào)用的工具列表total_tokens本次任務總 token 數(shù)cost_usd估算費用非必填latency_ms總耗時trace_path日志文件或 JSON 行文件路徑有這些數(shù)據(jù)后一個詭異的分數(shù)才能被拆開看。同樣是成功率 80%一個模型可能是格式錯誤占 20%另一個模型可能是工具調(diào)用后經(jīng)常拿錯結(jié)果這代表完全不同的整改方向。4.2 核心指標組別只設(shè)三個第一類是完成指標就是成功率。第二類是效率指標包括平均步數(shù)、工具調(diào)用次數(shù)、總耗時。第三類是成本指標包括輸入 token、輸出 token、估算費用。這三組指標要放在一起看不能只對比成功率。模型 A 成功率比模型 B 高 5%但平均多花 3 倍 token能否采用取決于你到底在做什么場景。如果是一個高頻低級操作成本權(quán)重就會很高如果是低頻高價值任務穩(wěn)定性比成本更重要。另一個容易被忽視的指標是“收斂失敗率”。把 max_steps 設(shè)為 6很多模型會在第 5 步才開始嘗試最終輸出最后一步格式出錯。這其實說明模型不擅長判斷“什么時候該結(jié)束”它不是知識不夠是不會停。4.3 對比前先跑小樣本我不建議一開始就把幾百條任務全量跑一遍。樣例少、識別度高時先用 5 條任務、3 個模型跑通整個鏈路。確認每個模型都能啟動、工具能返回、結(jié)果能落盤、日志能定位再開放批量。批量跑的時候要注意不要一上來開最大并發(fā)。先看 3 個并發(fā)會不會超時再看 10 個并發(fā)會不會被限流。如果模型供應商返回llm request timed out未必是模型本身慢有時候是因為你同一秒內(nèi)發(fā)了太多請求。4.4 不要只看一次輸出大模型本身有隨機性即使 temperature 設(shè)為 0某些服務端配置或采樣參數(shù)也可能讓結(jié)果不同。所以我會在固定任務集上讓同一模型重復 2 到 3 次記錄中位數(shù)和波動情況。如果一個任務第一次成功、第二次失敗、第三次成功那它不算穩(wěn)定通過。穩(wěn)定通過的定義應該是多次重復中絕大多數(shù)都滿足成功條件而且錯誤的類型集中在可控范圍內(nèi)。這樣選型時才不會被單次跑出來的好分數(shù)誤導。5. 環(huán)境隔離與可復現(xiàn)分數(shù)要能還原5.1 固定模型參數(shù)別讓隨機性背鍋評測環(huán)境必須記錄模型版本、Prompt 版本、工具定義版本和依賴版本。很多 Agent 項目失敗后沒法還原是因為改了代碼但沒改任務描述改了工具文檔但沒改 Prompt最后分數(shù)變化到底因為哪個環(huán)節(jié)無人知曉。針對 LLM 本身的隨機性重復實驗是最直接的應對。評測腳本可以自動在 task_id 后加-run1、-run2對同一任務執(zhí)行多次后再進入指標統(tǒng)計。種子參數(shù)不是所有供應商都支持不能默認它有效所以重復跑比強行依賴 seed 更通用。5.2 外部頁面和接口要做版本固化如果評測對象是瀏覽器操作型 Agent網(wǎng)頁結(jié)構(gòu)變化會讓結(jié)果非常不穩(wěn)定。之前跑得好好的任務某天頁面按鈕從idsubmit改成>