Claude通過(guò)率不到4%,SaaS-Bench撕碎Computer-Use 全自動(dòng)辦公幻想

機(jī)器之心發(fā)布

想象一個(gè)真實(shí)的工作日：項(xiàng)目經(jīng)理要更新項(xiàng)目狀態(tài)，財(cái)務(wù)人員要整理客戶賬單，醫(yī)療管理員要核對(duì)預(yù)約和保險(xiǎn)信息。

這些并不是高級(jí)專(zhuān)家任務(wù)，很多時(shí)候，一個(gè)認(rèn)真一點(diǎn)的實(shí)習(xí)生照著流程也能完成。

但對(duì)今天的 AI Agent 來(lái)說(shuō)，這些 “日常工作” 卻遠(yuǎn)沒(méi)有看起來(lái)那么簡(jiǎn)單。

它需要理解業(yè)務(wù)目標(biāo)、跨應(yīng)用查找信息、保持狀態(tài)一致，還要在幾十甚至上百步操作后，把所有細(xì)節(jié)正確落到系統(tǒng)里。

這也是SaaS-Bench想揭示的現(xiàn)實(shí)：Agent 不只是要會(huì)點(diǎn)按鈕、填表格，更要能完成真實(shí)辦公室里的長(zhǎng)流程工作。

如果連實(shí)習(xí)生日常能做的任務(wù)都無(wú)法穩(wěn)定完成，那我們就需要重新審視：距離真正可用的 Agent，還有多遠(yuǎn)。

• Blog 鏈接：https://unipat.ai/blog/SaaS-Bench
• GitHub 鏈接：https://github.com/UniPat-AI/SaaS-Bench
• 論文鏈接：https://arxiv.org/abs/2605.15777

Computer-Use Agent 的「奇點(diǎn)」沒(méi)有來(lái)，現(xiàn)實(shí)的冷水先潑下來(lái)了。

過(guò)去一年，各家 GUI Agent 爭(zhēng)先恐后地宣稱(chēng)能替人類(lèi)干活。Benchmark 成績(jī)一路飆升，投資人興奮，媒體狂歡，「全自動(dòng)辦公」似乎就在眼前。

但 UniPat AI 剛剛用一組數(shù)據(jù)證明：這一切，都建立在沙子上！

Leaderboard

23 個(gè)真系統(tǒng)，106 個(gè)任務(wù)，一場(chǎng)殘酷的實(shí)戰(zhàn)考試

現(xiàn)有的 Agent 評(píng)測(cè)，說(shuō)白了就是：仿真環(huán)境、簡(jiǎn)單任務(wù)、最多幾十步搞定。

跟真實(shí)工作完全是兩回事。

真實(shí)辦公長(zhǎng)什么樣？一個(gè)醫(yī)療管理員寫(xiě)完 SOAP 病歷→填病例上報(bào)→生成正式文檔。一個(gè)財(cái)務(wù)收到報(bào)銷(xiāo)申請(qǐng)→審批→打款→記賬。跨好幾個(gè)系統(tǒng)，步驟動(dòng)輒幾百步。

SaaS-Bench 的思路很暴力：直接把真系統(tǒng)搬進(jìn) Docker，讓 Agent 在真實(shí)的前后端邏輯、數(shù)據(jù)庫(kù)狀態(tài)和業(yè)務(wù)約束中干活。

SaaS-Bench 任務(wù) —— 真實(shí)工作場(chǎng)景任務(wù)

SaaS-Bench 精心挑選了 23 個(gè)開(kāi)源 SaaS (Software-as-a-Service) 系統(tǒng)，全部通過(guò) Docker 本地部署，保留了完整的前后端邏輯、數(shù)據(jù)庫(kù)狀態(tài)和業(yè)務(wù)約束。覆蓋六個(gè)專(zhuān)業(yè)領(lǐng)域：

• 軟件研發(fā)：OpenProject、Baserow、Code-Server、Metabase
• 業(yè)務(wù)財(cái)務(wù)：Twenty CRM、BigCapital、HRMS、Pretix
• 醫(yī)療管理：OpenEMR、OpnForm、OnlyOffice
• 團(tuán)隊(duì)協(xié)作：SiYuan、Roundcube、Mattermost、ownCloud
• 農(nóng)業(yè)供應(yīng)鏈：FarmOS、Grocy、Recipya、E-Label
• 獨(dú)立媒體：PhotoPrism、MediaCMS、BookLore、Watcharr

更重要的是，這些系統(tǒng)不是 “空殼網(wǎng)頁(yè)”：每個(gè)軟件里都填充了真實(shí)業(yè)務(wù)的數(shù)據(jù)，包括用戶、項(xiàng)目、訂單、文件等實(shí)體記錄。Agent 進(jìn)入的不是一個(gè)空白的測(cè)試頁(yè)面，而是一個(gè)有歷史數(shù)據(jù)、有干擾項(xiàng)、有跨系統(tǒng)關(guān)聯(lián)的真實(shí)工作環(huán)境。

任務(wù)模態(tài)、領(lǐng)域、app 三層分布

106 個(gè)任務(wù)中，93.4% 跨越至少兩個(gè)應(yīng)用，三應(yīng)用任務(wù)占了一半（53 個(gè)）。純文本任務(wù) 74 個(gè)，涉及多模態(tài)理解的 32 個(gè)。以 Claude Opus 4.6 的執(zhí)行軌跡估算，97.3% 的文本任務(wù)操作步數(shù)超過(guò) 100 步，最長(zhǎng)軌跡達(dá) 300+ 步。

任務(wù)難度分析 —— 大多數(shù)任務(wù)是 Cross-App + Long-Horizon 的

這些任務(wù)是怎么來(lái)的？如何評(píng)估 Agent 的操作能力？

SaaS-Bench 采用“LLM 生成 + 專(zhuān)家把關(guān)”的方式完成任務(wù)構(gòu)建：

• 先由 LLM 圍繞六大專(zhuān)業(yè)領(lǐng)域和具體職業(yè)角色生成任務(wù)，明確任務(wù)目標(biāo)、跨應(yīng)用依賴(lài)和驗(yàn)證要求，并通過(guò)多輪修改減少歧義和漏洞。
• 隨后，專(zhuān)家會(huì)對(duì)任務(wù)進(jìn)行人工篩選和真實(shí)執(zhí)行檢查，重點(diǎn)判斷任務(wù)是否專(zhuān)業(yè)、自然、可完成、可驗(yàn)證。對(duì)于堆砌步驟、邏輯混亂或驗(yàn)證不準(zhǔn)的任務(wù)，會(huì)被修改或剔除，最終確保每個(gè)任務(wù)都能真實(shí)運(yùn)行，并能被驗(yàn)證器準(zhǔn)確評(píng)估。

任務(wù)構(gòu)建流程圖 —— 四個(gè)階段保證任務(wù)質(zhì)量

SaaS-Bench 允許 Agent 使用 Browser-Use 在 SaaS 環(huán)境中操作計(jì)算機(jī)，并給出了兩個(gè)指標(biāo)：

• Resolved Score（完全通過(guò)分?jǐn)?shù)，嚴(yán)苛）：全部檢查點(diǎn)通過(guò)才算 1，否則為 0
• Checkpoint Score（檢查點(diǎn)分?jǐn)?shù)，寬松）：按權(quán)重計(jì)算部分檢查點(diǎn)完成比例

Agent → Browser-Use → 執(zhí)行 → 驗(yàn)證 → 打分總覽圖

后面的結(jié)果會(huì)表明 —— 這兩個(gè)數(shù)字之間的巨大落差，恰好暴露了 Agent 最核心的問(wèn)題。

榜單出爐：全軍覆沒(méi)

來(lái)看這組數(shù)字 ——

主要結(jié)果 (DeepSeek V4 、M2.7 和 GLM5.1 為單模態(tài)模型，僅測(cè)評(píng) Text-Only Domain)

最強(qiáng)的 Claude Opus 4.7，檢查點(diǎn)分?jǐn)?shù) 43.9%，端到端完全通過(guò)分?jǐn)?shù)只有 3.8%——106 個(gè)任務(wù)，只完整通過(guò)了 4 個(gè)。Kimi K2.5 和 Gemini 3.1 Pro？完全通過(guò)分?jǐn)?shù)為零。一個(gè)任務(wù)都沒(méi)走完。

這組數(shù)字的含義極其殘酷：Agent 可以推進(jìn)工作的部分中間環(huán)節(jié)，但幾乎沒(méi)有能力將一個(gè)完整的長(zhǎng)程工作流走完。

多跑幾次能救嗎？

四個(gè)模型的 Pass@k 結(jié)果

把每個(gè)模型在同一任務(wù)上獨(dú)立跑 3 次，對(duì)一次就算通過(guò)。pass@3 相比 pass@1 整體提升約 8 個(gè)百分點(diǎn)。

Sonnet 4.6 在多模態(tài)任務(wù)上從 33.9% 跳到 52.1%（+18.2pp）—— 它并非完全不行，而是執(zhí)行極不穩(wěn)定

這不是環(huán)境隨機(jī)性。每次運(yùn)行的初始狀態(tài)完全相同。這是路徑依賴(lài) —— 模型在某個(gè)決策點(diǎn)的微小差異，導(dǎo)致后續(xù)軌跡完全分叉。

多跑幾次有幫助，但遠(yuǎn)不是解決方案。

越復(fù)雜，分越低

三個(gè)結(jié)構(gòu)維度全部單調(diào)遞減：

分?jǐn)?shù) vs 應(yīng)用數(shù) / 分?jǐn)?shù) vs 步長(zhǎng) / 分?jǐn)?shù) vs 檢查點(diǎn)個(gè)數(shù)

• 跨應(yīng)用數(shù)1→4：平均分從 53% 降至 20%
• 操作步長(zhǎng)增加：任務(wù)軌跡越長(zhǎng)，得分顯著越低
• 檢查點(diǎn)個(gè)數(shù)≤6 vs ≥18：平均分從 65% 降至 27%

「跨應(yīng)用 + 軌跡長(zhǎng) + 細(xì)粒度驗(yàn)證」的任務(wù)得分最低 ——這恰恰是真實(shí)工作流最常見(jiàn)的形態(tài)。

四種結(jié)構(gòu)性失敗：Agent 到底在哪翻車(chē)

SaaS-Bench 真正的價(jià)值不在于分?jǐn)?shù)本身，而在于暴露了 Agent 在真實(shí)環(huán)境中的四種致命缺陷。

失敗 1：任務(wù)越長(zhǎng)，越做不對(duì)

即使每個(gè)檢查點(diǎn)通過(guò)率高達(dá) 95%，12 個(gè)檢查點(diǎn)的全部通過(guò)概率也只有 54%。而 SaaS-Bench 的平均檢查點(diǎn)數(shù)遠(yuǎn)超 12。

所有模型都呈現(xiàn)同一個(gè)模式：通過(guò)率隨任務(wù)推進(jìn)呈下降趨勢(shì)，沒(méi)有一個(gè)模型能在后半段維持住前期表現(xiàn)。

模型隨著任務(wù)執(zhí)行，做對(duì)的越來(lái)越少

這是一條不可逆的下降曲線。越往后走，越不可能走完。

失敗 2：一步錯(cuò)，步步錯(cuò)

一個(gè)典型案例：任務(wù)要求創(chuàng)建一個(gè)公司客戶「Arcturus Digital」。Agent 同時(shí)填了聯(lián)系人姓名和公司名，觸發(fā)了個(gè)人客戶邏輯，實(shí)際創(chuàng)建的是個(gè)人客戶 Elena Vasquez。

此后的 10 張發(fā)票、付款記錄、賬戶對(duì)賬，全部掛在錯(cuò)誤實(shí)體下。核心檢查點(diǎn)權(quán)重僅 3%，但導(dǎo)致了下游 30% 的權(quán)重?fù)p失。

上游任務(wù)導(dǎo)致下游失敗鏈?zhǔn)疽鈭D

一個(gè) 3% 的錯(cuò)誤節(jié)點(diǎn)，造成 30% 的分?jǐn)?shù)損失。

失敗 3：做完不檢查，自以為對(duì)了

Claude Opus 4.6 在 Step 124 識(shí)別出日期錯(cuò)誤（2026-03-19 vs. 2026-03-20），執(zhí)行了修改，但沒(méi)有回到頁(yè)面復(fù)查，直接推進(jìn)后續(xù)子任務(wù)。Step 210 提交時(shí)，匯報(bào)寫(xiě)的是「賬單日期 2026-03-20，已修復(fù)」—— 頁(yè)面上實(shí)際日期仍是 03-19。

Agent 在意圖層面認(rèn)為成功，Verifier 在狀態(tài)層面發(fā)現(xiàn)失敗

Agent 在意圖層面認(rèn)為成功，驗(yàn)證器在狀態(tài)層面發(fā)現(xiàn)失敗。兩者之間的斷層是系統(tǒng)性的。 當(dāng)前 CUA 框架缺少「嚴(yán)謹(jǐn)?shù)姆此奸]環(huán)」 —— Agent 是個(gè)不會(huì)檢查自己作業(yè)的學(xué)生。

失敗 4：同一張考卷，成績(jī)忽高忽低

Claude Sonnet 4.6 在同一任務(wù)的三次獨(dú)立運(yùn)行中，分?jǐn)?shù)范圍從 0.00 到 0.68。這不是環(huán)境隨機(jī)性造成的 —— 每次運(yùn)行的初始狀態(tài)完全相同 —— 而是路徑依賴(lài)：模型在某個(gè)決策點(diǎn)的微小差異，會(huì)導(dǎo)致后續(xù)執(zhí)行軌跡完全分叉，這讓 Agent 在長(zhǎng)程任務(wù)中的執(zhí)行變成了賭博。

Claude Sonnet 4.6 在同一任務(wù)的三次運(yùn)行

這意味著什么

SaaS-Bench 撕碎了一個(gè)幻覺(jué)：Agent 的 Benchmark 成績(jī)和真實(shí)工作能力之間，存在巨大的鴻溝。

四種結(jié)構(gòu)性失敗模式 —— 越往后越做不對(duì)、一步錯(cuò)步步錯(cuò)、做完不檢查、次次分?jǐn)?shù)不一樣 —— 指向同一個(gè)底層事實(shí)：當(dāng)前 Agent 缺少對(duì)持久狀態(tài)的有效推理能力，缺少操作后的閉環(huán)驗(yàn)證機(jī)制，缺少?gòu)腻e(cuò)誤中恢復(fù)的能力。

這些不是靠模型變大、或者加幾個(gè)工程模塊就能解決的問(wèn)題。 它們指向的是當(dāng)前 Agent 范式更深層的局限：在長(zhǎng)程任務(wù)中，模型缺少對(duì)全局狀態(tài)的持續(xù)感知，無(wú)法像人一樣 "心里有數(shù)"。這不只是技術(shù)債，而是當(dāng)前范式的天花板。

Computer-Use Agent 想要真正替人干活？路還很遠(yuǎn)。SaaS-Bench 把地圖攤開(kāi)了 —— 接下來(lái)就看各家怎么走了。

但這也引向了一個(gè)正在逐漸形成的共識(shí)：今天的 SaaS 是給人設(shè)計(jì)的 —— 菜單、按鈕、表單，都在服務(wù)人類(lèi)的眼睛和手指。但當(dāng) Agent 成為主要用戶，這些界面就變成了累贅。未來(lái)不是讓 Agent 學(xué)會(huì)操作人類(lèi)的軟件，而是軟件本身要為 Agent 重新設(shè)計(jì)。SaaS-Bench 揭示的不只是 Agent 的短板，也是當(dāng)前軟件形態(tài)的保質(zhì)期 —— 面向人類(lèi)的 SaaS，可能都要為 Agent 重做一遍。

UniPat AI

UniPat AI 致力于構(gòu)建面向真實(shí)場(chǎng)景的 AI 訓(xùn)練、評(píng)測(cè)與應(yīng)用新范式，推動(dòng) Agent 能力在千行百業(yè)中規(guī)模化落地，創(chuàng)造切實(shí)的經(jīng)濟(jì)與社會(huì)價(jià)值。

• 官網(wǎng)鏈接：https://unipat.ai