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