Agent評測的下半場：為什么需要一個「活的」Benchmark？

新智元報道

編輯：LRST

【新智元導讀】Claw-Eval-Live提出「活的」benchmark概念，通過信號采集與任務篩選，確保評測內容緊跟企業(yè)實際痛點，而非固定不變的題庫。評測不僅關注結果，還追蹤執(zhí)行過程，從數(shù)據(jù)調用到狀態(tài)變更，全面驗證Agent的真實能力。

今天的AI Agent看起來越來越像「能干活的數(shù)字員工」了：能調 API、查數(shù)據(jù)庫、寫郵件、改代碼、排日程、做報表。但真正麻煩的問題不是它「會不會說」，而是兩件更現(xiàn)實的事：它到底有沒有真的做成任務；以及我們拿來測它的那些任務，是不是還代表當下真實世界最重要的workflow。

Claw-Eval回答前者，Claw-Eval-Live回答后者。前者解決的是「怎么確認Agent真的做成了任務」，后者解決的是「benchmark里的題庫如何持續(xù)跟上現(xiàn)實需求」。這篇文章想講的，也正是這條連續(xù)升級的評測邏輯。某種意義上，這也是 Agent benchmark進入「下半場」的標志：不再只比較誰更會答題，而是比較誰更接近真實世界。

論文鏈接：https://arxiv.org/abs/2604.28139

論文鏈接：https://arxiv.org/pdf/2604.06132

你確定Agent真的做了？

在Claw-Eval之前，主流Agent評測的做法是：給Agent一個任務，看最終結果，判對錯。文件創(chuàng)建了？測試通過了？答案匹配了？那就算過。

聽起來合理，但對于 Agent 來說，這樣的評測有兩個致命問題。

第一，它只看結果，不看行動。模型交了一份漂亮報告，但它真的查了正確的數(shù)據(jù)源嗎？真的調了對的 API 嗎？還是只是「編」了一個看起來對的答案？近期研究已經(jīng)表明，前沿模型會主動尋找評測捷徑，繞過預期的執(zhí)行路徑直接滿足最終檢查。只看結果的評測，恰恰給了這種行為可乘之機。

第二，它很難反映真實部署要求。一個真正可部署的 Agent，不僅要能把活干完，還要在干活的同時避免不該做的事，并且能在API超時、服務報錯的環(huán)境里穩(wěn)定運行。換句話說，評測不能只看「能不能做出來」，還要看「是不是安全地做、穩(wěn)健地做」。Claw-Eval 還進一步把多模態(tài)和多輪對話也納入統(tǒng)一評測框架，但它最關鍵的貢獻，首先是把Agent評測從「只看答案」推進到「看行動」。

Claw-Eval

讓Agent的執(zhí)行過程變成可審計證據(jù)

Claw-Eval包含300道人工驗證任務，覆蓋通用服務編排、多模態(tài)感知與生成、多輪專業(yè)對話三大群組，共定義了2,159個可獨立驗證的評分細則。

它的核心思路可以概括成一句話：讓Agent 的執(zhí)行過程變成可審計證據(jù)。每次評測都在隔離環(huán)境中進行，分為 Setup、Execution、Judge 三個階段；在 Agent 運行時，容器里看不到評分腳本和參考答案。真正用于打分的，不只是最終輸出，而是三條獨立證據(jù)鏈：執(zhí)行軌跡、服務端審計日志、以及執(zhí)行后的環(huán)境快照。

在這個基礎上，Claw-Eval 再把完成度、安全性、魯棒性和跨模態(tài)任務統(tǒng)一納入同一套評測框架。

Claw-Eval 最關鍵的發(fā)現(xiàn)，其實非常直接：如果不看過程，Agent 評測會系統(tǒng)性「放水」。

團隊做了一個嚴格對照實驗：讓一個 vanilla LLM judge 拿到完整對話記錄和評分腳本源碼，只缺服務端審計日志和環(huán)境快照。結果是，它仍然漏掉了44%的安全違規(guī)和13%的魯棒性問題。這意味著，對 Agent 來說，「只看結果」的評測方式不是不夠精細，而是會系統(tǒng)性高估模型。

Claw-Eval當然還展示了更多東西，比如錯誤注入會顯著拉低可靠性（Pass^3最多暴跌24個百分點）、多模態(tài)和多輪對話能力并不存在統(tǒng)一冠軍。但對這篇文章來說，最重要的結論只有一個：Agent benchmark 不能只看答案，而要看行動。

但當「怎么看」終于被厘清之后，另一個更現(xiàn)實的問題也浮現(xiàn)出來了：即便評測足夠可信，如果benchmark測的工作流本身已經(jīng)慢慢偏離現(xiàn)實需求，那評得再準，也未必評在點子上。

這正是Claw-Eval-Live想接著解決的問題。

「評得準」還不夠

benchmark也會過時

從這里開始，問題不再只是「怎么評」，而是「評什么」。這也是Claw-Eval-Live真正切入的位置。

Claw-Eval解決了「評分是否可信」的問題。但它和幾乎所有現(xiàn)有benchmark一樣，有一個更根本的局限：

任務集合是固定的。

300 道任務，發(fā)布那天就定住了。不管外面的工具生態(tài)怎么變、企業(yè)工作流的重心怎么遷移、用戶最想讓 Agent 自動化的事情從日報寫作變成了跨系統(tǒng)對賬——benchmark 里的任務分布不會跟著動。

在傳統(tǒng) NLP 評測里這不是大問題，「翻譯一段話」、「回答一個問題」這類任務形態(tài)相對穩(wěn)定。但在 Agent 評測里，這個問題被急劇放大了。Agent 面對的不是抽象的語言任務，而是具體的工作流。而工作流一直在變——工具棧在迭代，企業(yè)痛點在遷移，某些自動化場景從無到有，另一些從核心變成邊緣。

一個 benchmark 可以在技術上保持完全可復現(xiàn)，但它測的任務組合，可能正在悄悄偏離用戶此刻最想讓 Agent 干的事情。

這種偏移不來自某道具體任務「過時」了，而來自任務混合比本身。半年前最熱的自動化需求和今天最熱的，很可能已經(jīng)不是同一組東西了。

這就是Claw-Eval-Live要解決的問題。

「活的」benchmark到底長什么樣？

聽到「live benchmark」，很多人的第一反應是：那不就每天都變，根本沒法比了嗎？

Claw-Eval-Live 的回答不是「讓benchmark一直變」，而是：

讓每一次release都成為當下真實世界的一張切片。

它的核心是兩層分離的設計：

信號層（Signal Layer）——每次構建新 release 時，不是團隊自己頭腦風暴「應該測什么」，而是從ClawHub Top-500熱門技能等公開workflow demand signals出發(fā)，觀察此刻哪些工作流更值得關注。這里要強調的是，這些信號不是自動出題器，更不是對真實需求的精確測量。它們只是一個公開、可檢查的需求先驗，用來幫助benchmark決定這一版release應該更關注哪些workflow。

發(fā)布層（Release Layer）——真正公開出來的 benchmark 依然是固定的、帶時間戳的 snapshot。任務定義、執(zhí)行環(huán)境、數(shù)據(jù)夾具、評分腳本全部鎖定。模型之間完全可以穩(wěn)定比較，學術上也完全可復現(xiàn)。

兩層之間通過一條五階段流水線連接：

1. 信號采集：抓取 ClawHub Top-500 的時間戳快照，每條信號帶來源和元數(shù)據(jù)

2. 模式聚類：將碎片化的技能名稱聚合成穩(wěn)定的工作流模式——區(qū)分的不是技能的表面名稱，而是背后的用戶目標、操作對象和執(zhí)行環(huán)境

3. 家族加權：根據(jù)上游信號強度確定各任務家族的目標權重，信號越強的工作流在 release 中占比越大

4. 種子擴展與篩選：將加權模式展開為可執(zhí)行的任務候選，試跑篩選后只保留可運行、可復現(xiàn)、且能產(chǎn)生有效分數(shù)差異的候選——從 178 個生成候選篩選到 157 個

5. 區(qū)分度優(yōu)化選取：用混合整數(shù)線性規(guī)劃（MILP）從 157 個候選中選出 105 道公開任務，同時優(yōu)化三個約束——發(fā)布規(guī)模、家族覆蓋、和榜單區(qū)分度

這里的 MILP 不是在機械追求「多樣性」，而是在把三件事顯式化：公開release要有多大、每個 family 至少要被覆蓋、以及這套題要能真正拉開模型差距。把這些原本模糊的策展判斷變成可審計的約束，是 Claw-Eval-Live 讓 release 構建本身也變得透明的方式。

當前公開 release 的規(guī)模：105道任務，22個任務家族，13個前沿模型。任務分為兩大執(zhí)行環(huán)境——87道服務驅動的業(yè)務工作流（涉及CRM、郵件、日歷、財務、工單等18個受控服務）和18道本地工作空間修復任務（終端操作、環(huán)境修復、配置調試）。

每道任務不只是一個 prompt，而是一個完整的可執(zhí)行評測單元：任務定義（task.yaml）、工具接口、數(shù)據(jù)夾具、以及專屬評分腳本（grader.py），缺一不可。評分沿用 Claw-Eval 的證據(jù)錨定原則——在整個 release 中，最常見的三類確定性證據(jù)包括：數(shù)據(jù)檢索（是否調用了正確的工具和數(shù)據(jù)源）、數(shù)據(jù)準確性（實體和數(shù)值是否與 ground-truth 一致）、行動驗證（必需的狀態(tài)變更是否真的發(fā)生）。只有當這些確定性檢查無法覆蓋的語義維度（如報告組織質量、摘要連貫性）時，才引入結構化 LLM judge。

所以，從項目演進上看，兩個工作是一脈相承的：

Claw-Eval解決「評分可信」——讓我們看清Agent到底做了什么。

Claw-Eval-Live解決的是「題庫跟上現(xiàn)實」——讓benchmark不再停留在一套固定題目上，而是持續(xù)對準當下最該測的workflow。

當benchmark真正貼近現(xiàn)實

我們看到了什么？

13個前沿模型在當前release上的結果足夠直接，也足夠冷峻。

整體天花板依然很低

沒有任何模型突破70%的通過率。榜首到末尾差距達22.9個百分點。真實工作流自動化，遠沒有到「可靠部署」的階段。

值得注意的是，通過率相近的模型，完成度可以差很遠。MiMo V2 Pro、Kimi K2.5、Gemini 3.1 Pro三個模型都是53.3%的通過率，但Overall Completion從76.9拉到74.0，這說明有些模型不是完全不會做，而是經(jīng)常「差一點做完」——問題不在語言能力，而在執(zhí)行閉環(huán)。

真正有沖擊力的發(fā)現(xiàn)：難的不是你以為的那些

如果只憑直覺，很多人會覺得最難的肯定是終端操作、環(huán)境修復這些需要硬核技術能力的任務。

Claw-Eval-Live 給出的結果恰恰相反。

從分組熱力圖看，Development / Terminal對強模型已經(jīng)接近天花板：Claude Opus 4.6、GPT-5.4和Claude Sonnet 4.6在這個切面上都達到100%，最弱模型也在72.2%以上。真正困難的，是HR / People、Management / Ops以及跨系統(tǒng)workflow這類業(yè)務任務。HR / People這一組里，沒有模型超過 22.2%，而且有多個模型直接是0。

進一步看細粒度family，結論更尖銳。HR的平均通過率只有6.8%；MGMT在公開pass規(guī)則下是all-fail；WORKFLOW的平均通過率也只有12.8%。相反，看上去「更技術」的workspace repair反而相對容易。整個benchmark分成兩種執(zhí)行面之后，這個差異更明顯：workspace這一側，所有模型都至少達到72.2%；而service-backed workflows這一側，沒有模型超過59.8%。

這意味著，當前 Agent 的主要瓶頸，已經(jīng)不是「會不會用 terminal」，而是「能不能在多個系統(tǒng)之間持續(xù)收集證據(jù)、正確關聯(lián)記錄，并完成必須的寫操作」。

論文中最能說明這個問題的，是幾個高區(qū)分度任務的表現(xiàn)模式。像電商月度對賬（ecommerce_monthly_reconcile）、客服首次響應時間審計（first_response_time_audit）和多文檔合并（multi_doc_merge），它們的共同特征是：必須從多個來源精確提取數(shù)據(jù)，任何一個工具調用的遺漏或實體鏈接的錯誤都會導致大幅扣分。

以論文附錄展示的代表性子矩陣里的HR_01_onboarding為例，多個模型都能寫出體面的入職文檔，但在公開通過閾值之下。問題不是文檔是否通順，而是它沒有真正把員工信息、必需的 tool call 和任務證據(jù)閉環(huán)補齊。它更像是在「說」一件事，而不是「做完」一件事。

這是Claw-Eval-Live最有價值的發(fā)現(xiàn)：今天Agent最難的地方，不是「修一個壞掉的東西」，而是「在多個系統(tǒng)之間，把一件業(yè)務真的做完」。

「說得好」不等于「做得到」

Claw-Eval-Live 的排名和通常的聊天/寫作 benchmark 排名并不一致，這恰恰是它的價值所在。

它不獎勵「最終回答寫得多流暢」，而是獎勵跨系統(tǒng)證據(jù)收集、正確的記錄關聯(lián)、行動閉環(huán)和執(zhí)行后狀態(tài)完整性。一個模型可以寫出極其流暢的總結，但如果它漏了必需的工具調用、遺漏了關鍵證據(jù)、或者工作空間狀態(tài)不對——在這里照樣拿不到分。這就是「can say」與「can do」的核心區(qū)別。

再多看一眼部署視角：成本同樣重要

如果從部署角度再看一眼榜單，估算API成本差異同樣巨大。這里強調「估算」：

論文按記錄的輸入輸出 token 用量和發(fā)布時provider list price計算，并不等于真實賬單。

Claude Opus 4.6準確率最高，但跑完整個 105 題 release 的估算API成本約31.6美元；GPT-5.4以約6.3美元拿到第二名，通過率只低2.9個百分點；GLM-5以約2.5美元達到與Claude Sonnet 4.6相同的61.9%通過率，估算成本約為Opus的7.8%，也就是約1/12.8。

對真正要部署 Agent 的團隊來說，總榜只是起點，更實際的決策維度是「具體workflow家族上的準確率 × 成本」。

從Claw-Eval到Claw-Eval-Live

到底推進了什么？

Claw-Eval把Agent評測從「只看結果」推進到「看過程」。它最關鍵的貢獻，是證明了如果沒有執(zhí)行軌跡、審計日志和環(huán)境快照，Agent benchmark會系統(tǒng)性高估模型。

Claw-Eval-Live則把Agent評測從「靜態(tài)題庫」推進到「與真實需求共同演化的任務快照」。

它揭示了：當benchmark真正對齊現(xiàn)實工作流后，最好的模型也只能通過三分之二的任務；直覺上很難的終端修復其實已經(jīng)接近解決，真正的瓶頸是跨系統(tǒng)的業(yè)務編排；HR、管理以及workflow類任務依然明顯偏難。

這兩步缺一不可。

沒有第一步，你可能會被一個「看起來很會做事」的 Agent 欺騙——它的報告寫得很好看，但它從來沒有真正查過那些數(shù)據(jù)。

沒有第二步，你可能會用一套逐漸脫離現(xiàn)實的任務集合，得出一個看似精確但不再 relevant 的結論——你的榜單很穩(wěn)定，但它在回答一個沒人再問的問題。

如果Agent真的要走向部署，benchmark就不能只產(chǎn)出一張榜單。它還應該回答兩件事：這個 Agent 有沒有真的完成任務；以及我們究竟在拿什么任務定義「會干活」。

Claw-Eval回答的是前一個問題：我們怎么知道Agent真的做成了任務。Claw-Eval-Live回答的則是后一個問題：我們究竟在拿什么任務定義「會干活」。前者為 Agent 評測打下了可信基礎；后者則把benchmark從一套靜態(tài)題庫，推進到與真實世界一起演化的任務快照。

對今天的Agent來說，這一步尤其關鍵。因為當能力開始接近部署邊界時，真正重要的不再只是「會不會做題」，而是benchmark測的，是否還是現(xiàn)實世界里最值得自動化的工作流。

如果說過去的大模型競爭更像能力展示的上半場，那么面向真實workflow的評測、驗證與部署，才是Agent benchmark的下半場真正開始的地方。

先把Agent評測做實，再讓benchmark跟上真實世界。