新智元報道

【新智元導讀】許多實習生能輕松完成的任務，有時對于AI來說卻是一場嚴酷大考。人類距離真正可用的Agent，還有多遠？一份全新SaaS-Bench實戰考卷，已經給出了答案。

Computer-Use Agent的「奇點」沒有來，現實的冷水先潑下來了。

過去一年，各家GUI Agent爭先恐后地宣稱能替人類干活。Benchmark成績一路飆升，投資人興奮，媒體狂歡，「全自動辦公」似乎就在眼前。

但UniPatAI剛剛用一組數據證明：這一切，都建立在沙子上！

Leaderboard

23個真系統，106個任務

一場殘酷的實戰考試

現有的Agent評測，說白了就是：仿真環境、簡單任務、最多幾十步搞定。

跟真實工作完全是兩回事。

真實辦公長什么樣？一個醫療管理員寫完SOAP病歷→填病例上報→生成正式文檔。一個財務收到報銷申請→審批→打款→記賬。

跨好幾個系統，步驟動輒幾百步。

SaaS-Bench的思路很暴力：直接把真系統搬進Docker，讓Agent在真實的前后端邏輯、數據庫狀態和業務約束中干活。

SaaS-Bench任務——真實工作場景任務

SaaS-Bench精心挑選了23個開源SaaS（Software-as-a-Service）系統，全部通過Docker本地部署，保留了完整的前后端邏輯、數據庫狀態和業務約束。覆蓋六個專業領域：

• 軟件研發：OpenProject、Baserow、Code-Server、Metabase

• 業務財務：Twenty CRM、BigCapital、HRMS、Pretix

• 醫療管理：OpenEMR、OpnForm、OnlyOffice

• 團隊協作：SiYuan、Roundcube、Mattermost、ownCloud

• 農業供應鏈：FarmOS、Grocy、Recipya、E-Label

• 獨立媒體：PhotoPrism、MediaCMS、BookLore、Watcharr

更重要的是，這些系統不是「空殼網頁」：每個軟件里都填充了真實業務的數據，包括用戶、項目、訂單、文件等實體記錄。

Agent進入的不是一個空白的測試頁面，而是一個有歷史數據、有干擾項、有跨系統關聯的真實工作環境。

任務模態、領域、app三層分布

106個任務中，93.4%跨越至少兩個應用，三應用任務占了一半（53個）。

純文本任務74個，涉及多模態理解的32個。以Claude Opus 4.6的執行軌跡估算，97.3%的文本任務操作步數超過100步，最長軌跡達300+步。

任務難度分析 ——大多數任務是 Cross-App + Long-Horizon 的

這些任務是怎么來的？

如何評估Agent的操作能力？

SaaS-Bench 采用「LLM生成 + 專家把關」的方式完成任務構建：

• 先由LLM圍繞六大專業領域和具體職業角色生成任務，明確任務目標、跨應用依賴和驗證要求，并通過多輪修改減少歧義和漏洞。

• 隨后，專家會對任務進行人工篩選和真實執行檢查，重點判斷任務是否專業、自然、可完成、可驗證。對于堆砌步驟、邏輯混亂或驗證不準的任務，會被修改或剔除，最終確保每個任務都能真實運行，并能被驗證器準確評估。

任務構建流程圖——四個階段保證任務質量

SaaS-Bench允許Agent使用Browser-Use在SaaS環境中操作計算機，并給出了兩個指標：

• Resolved Score（完全通過分數，嚴苛）：全部檢查點通過才算1，否則為0

• Checkpoint Score（檢查點分數，寬松）：按權重計算部分檢查點完成比例

Agent → Browser-Use → 執行 → 驗證 → 打分總覽圖

后面的結果會表明——這兩個數字之間的巨大落差，恰好暴露了Agent最核心的問題。

榜單出爐：全軍覆沒

來看這組數字 ——

主要結果（DeepSeek V4 、M2.7和GLM5.1為單模態模型，僅測評Text-OnlyDomain）

最強的Claude Opus 4.7，檢查點分數43.9%，端到端完全通過分數只有3.8%——106個任務，只完整通過了4個。Kimi K2.5和Gemini 3.1 Pro？完全通過分數為零。一個任務都沒走完。

這組數字的含義極其殘酷：Agent可以推進工作的部分中間環節，但幾乎沒有能力將一個完整的長程工作流走完。

多跑幾次能救嗎？

四個模型的Pass@k結果

把每個模型在同一任務上獨立跑3次，對一次就算通過。pass@3相比pass@1整體提升約8個百分點。

Sonnet 4.6在多模態任務上從33.9%跳到52.1%（+18.2pp）——它并非完全不行，而是執行極不穩定。

這不是環境隨機性。每次運行的初始狀態完全相同。這是路徑依賴——模型在某個決策點的微小差異，導致后續軌跡完全分叉。

多跑幾次有幫助，但遠不是解決方案。

越復雜，分越低

三個結構維度全部單調遞減：

分數 vs 應用數 / 分數 vs 步長 / 分數 vs 檢查點個數

• 跨應用數1→4：平均分從53%降至20%

• 操作步長增加：任務軌跡越長，得分顯著越低

• 檢查點個數≤6 vs ≥18：平均分從65%降至27%

「跨應用+軌跡長+細粒度驗證」的任務得分最低——這恰恰是真實工作流最常見的形態。

四種結構性失敗：Agent到底在哪翻車

SaaS-Bench真正的價值不在于分數本身，而在于暴露了Agent在真實環境中的四種致命缺陷。

失敗1：任務越長，越做不對

即使每個檢查點通過率高達95%，12個檢查點的全部通過概率也只有54%。而SaaS-Bench的平均檢查點數遠超12。

所有模型都呈現同一個模式：通過率隨任務推進呈下降趨勢，沒有一個模型能在后半段維持住前期表現。

模型隨著任務執行，做對的越來越少

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

失敗2：一步錯，步步錯

一個典型案例：任務要求創建一個公司客戶「Arcturus Digital」。Agent同時填了聯系人姓名和公司名，觸發了個人客戶邏輯，實際創建的是個人客戶Elena Vasquez。

此后的10張發票、付款記錄、賬戶對賬，全部掛在錯誤實體下。核心檢查點權重僅3%，但導致了下游30%的權重損失。

上游任務導致下游失敗鏈示意圖

一個3%的錯誤節點，造成30%的分數損失。

失敗3：做完不檢查，自以為對了

Claude Opus 4.6在Step 124識別出日期錯誤（2026-03-19 vs. 2026-03-20），執行了修改，但沒有回到頁面復查，直接推進后續子任務。

Step 210提交時，匯報寫的是「賬單日期2026-03-20，已修復」——頁面上實際日期仍是03-19。

Agent 在意圖層面認為成功，Verifier 在狀態層面發現失敗

Agent在意圖層面認為成功，驗證器在狀態層面發現失敗。兩者之間的斷層是系統性的。

當前CUA框架缺少「嚴謹的反思閉環」 —— Agent是個不會檢查自己作業的學生。

失敗4：同一張考卷，成績忽高忽低

Claude Sonnet 4.6在同一任務的三次獨立運行中，分數范圍從 0.00 到 0.68。

這不是環境隨機性造成的 —— 每次運行的初始狀態完全相同 —— 而是路徑依賴：模型在某個決策點的微小差異，會導致后續執行軌跡完全分叉，這讓Agent在長程任務中的執行變成了賭博。

Claude Sonnet 4.6在同一任務的三次運行

這意味著什么

SaaS-Bench撕碎了一個幻覺：Agent的Benchmark成績和真實工作能力之間，存在巨大的鴻溝。

四種結構性失敗模式——越往后越做不對、一步錯步步錯、做完不檢查、次次分數不一樣——指向同一個底層事實：當前Agent缺少對持久狀態的有效推理能力，缺少操作后的閉環驗證機制，缺少從錯誤中恢復的能力。

這些不是靠模型變大、或者加幾個工程模塊就能解決的問題。它們指向的是當前Agent范式更深層的局限：在長程任務中，模型缺少對全局狀態的持續感知，無法像人一樣「心里有數」。這不只是技術債，而是當前范式的天花板。

Computer-Use Agent想要真正替人干活？路還很遠。SaaS-Bench把地圖攤開了——接下來就看各家怎么走了。

但這也引向了一個正在逐漸形成的共識：今天的SaaS是給人設計的——菜單、按鈕、表單，都在服務人類的眼睛和手指。但當Agent成為主要用戶，這些界面就變成了累贅。

未來不是讓Agent學會操作人類的軟件，而是軟件本身要為Agent重新設計。

SaaS-Bench揭示的不只是Agent的短板，也是當前軟件形態的保質期——面向人類的SaaS，可能都要為Agent重做一遍。

·Blog：https://unipat.ai/blog/SaaS-Bench

·GitHub：https://github.com/UniPat-AI/SaaS-Bench

·論文：https://arxiv.org/abs/2605.15777

UniPat AI

UniPat AI致力于構建面向真實場景的AI訓練、評測與應用新范式，推動Agent能力在千行百業中規模化落地，創造切實的經濟與社會價值。

官網鏈接：https://unipat.ai