Claw-Eval-Live：Agent Benchmark 正在從答案評分轉向執行證據
這篇 Threads 介紹 arXiv 論文 Claw-Eval-Live: A Live Agent Benchmark for Evolving Real-World Workflows。表面上它是一個新的 workflow agent benchmark：105 個任務、17 個 families、13 個 frontier models，第一名 Claude Opus 4.6 也只過 66.7%，沒有模型超過 70%。但更值得記下的不是分數，而是它把 agent benchmark 的核心從「最後回答像不像」推向「可驗證的執行證據」。
原文作者的觀察很準：如果只看 66.7% 這個數字，會很容易得到一個太快的結論——模型還不夠強，題目再做難一點就好。但 Claw-Eval-Live 真正改寫的是 benchmark 到底在驗什麼。
Claw-Eval-Live 的設計重點
這篇 paper 要解的是兩個老問題。
第一，很多 agent benchmark 在發表那天就把題庫凍住。任務集固定後，外部工作流需求繼續變，工具棧繼續變，企業瓶頸也繼續變，但 benchmark 的任務組合不再反映市場。
第二，很多 benchmark 主要評 final response。這會造成一個嚴重盲點：模型最後講得很像做完了，但它到底有沒有真的查資料、改狀態、寫檔案、呼叫服務、留下可稽核的行動證據，不一定看得出來。
Claw-Eval-Live 把 benchmark 拆成兩層：
- signal layer：會隨公開 workflow demand signals 更新。這版使用 ClawHub Top-500 skills 作為需求訊號來源。
- release snapshot：每一季固定成可重跑、可比較的時間戳版本。
也就是說，它不是每次都亂變，而是把「活的市場需求」和「可重現的評測快照」分開。這個設計很重要：benchmark 可以跟著需求更新，但每個 release 仍然能被重跑與追溯。
Evidence contract：真正關鍵的轉向
Claw-Eval-Live 的更大價值在 grading。它不只看最後答案，而是讀：
- execution traces
- audit logs
- service state
- post-run workspace artifacts
能用 deterministic checks 的地方就先用 deterministic checks；只有真正涉及語意判斷的部分，才交給 structured LLM judging。論文甚至明講，judge model 用 GPT-5.4，但它不是把 judge 當成人類裁判，而是把 judge 限縮在 deterministic evidence 無法覆蓋的語意維度，並把 task prompt、agent trace、observable actions、rubric 一起交給 judge。
這其實是在重寫 agent benchmark 的 evidence contract：
不是問「這個回答看起來有沒有完成」，而是問「這個 agent 有沒有真的做、做的過程能不能回讀、失敗時能不能追責」。
結果透露的能力斷層
論文公開 leaderboard：
- Claude Opus 4.6：66.7% pass rate，overall 83.6
- GPT-5.4：63.8%，overall 81.7
- Claude Sonnet 4.6：61.9%，overall 79.9
- GLM-5：61.9%，overall 78.1
看起來大家都還沒到可靠自動化。更有意思的是，失敗不是平均分布。
Development / Terminal 類任務對強模型已經接近天花板：Claude Opus 4.6、GPT-5.4、Claude Sonnet 4.6 在這個 grouped slice 都達到 100%。但 HR / People 非常難，沒有模型超過 22.2%，一些模型甚至是 0%。MGMT 在 public pass rule 下全 fail，WORKFLOW 平均也只有 12.8%。
服務型 business workflows 比本地 workspace repair 難很多。workspace slice 所有模型至少 72.2%，但 service-backed workflows 沒有模型超過 59.8%。這代表當前 agent 的瓶頸不是「會不會用 terminal」，而是能不能跨多個服務維持狀態、抓對證據、連對 entity、執行必要 writes，並讓結果可稽核。
對 BigIntTech / Hermes 的啟發
這篇對我們有兩個直接啟發。
第一，評估 agent 不應該只看 final answer。Hermes、Forge、Archivist 這類 agent 如果要變成可靠的營運工具，評測與驗收要看工具呼叫紀錄、檔案 diff、API 狀態、DB 狀態、外部 side effect、post-run artifacts，而不是只看最後一段回報。
第二，workflow benchmark 應該跟真實需求綁定。若我們要建立自己的 internal benchmark，不該只手寫一批靜態題目，而應該從實際任務來源抽樣：Allen 丟的 Threads / KB 上架、月結收據、GitLab MR review、工多多 issue、行事曆同步、Google Sheet 對帳。這些才是真正會反覆發生、且能驗證 agent 是否有商業價值的 workflow。
我的判斷
這篇 paper 的核心不是「Claude Opus 4.6 第一」或「GPT-5.4 CP 值高」。真正重要的是：agent 評測正在從 answer evaluation 走向 action-grounded evaluation。
下一階段的 agent moat 可能不只是模型能力，而是整套可稽核執行基礎設施：trace、audit log、service state、workspace artifact、deterministic grader、semantic judge 的邊界設計。能把這些做好的人，才有資格說 agent 真的能接業務流程。
原始來源： https://www.threads.com/@james.leo.lai/post/DX5dQwuj8cS