SaaS-Bench, 一份新的研究

判斷 Agent 靠譜與否，核心指標(biāo)只有一個：是不是真干完活了

行業(yè)的做法大抵是：給 Agent 配臺虛擬機，里面里裝點程序或者仿真網(wǎng)頁，給他的操作打分。在這種邏輯下，誕生了如評估電腦技能的OSWorld，評估客服工作流的 Tau2 等 bench

在 GPT-5.5 發(fā)布的時候，也是引用了這些個榜單

每當(dāng)模型發(fā)布的時候，這些曲線就會被拿出來展示，但這里卻有一個心照不宣的漏洞：用模擬器評測，測的是【動作】，而不是【結(jié)果】

Benchmark 最主要的功能，是掃描現(xiàn)有模型的問題。而在 Computer Using 這個場景下，最大的挑戰(zhàn)就是面試形選手太多：很多 Agent 非常善于表演，能完成如復(fù)制文件之類的簡單動作，再給出非常漂亮的結(jié)案報告

但如果放在真實的辦公場景，我們更在乎的是那些跨軟件、動輒上百步的長任務(wù)，最終是不是完成了

為了解決這個問題，我那些個在 UniPat 實驗室整活的朋友，整了個新玩意兒：SaaS-Bench，來給 Agent 操作電腦這事兒，治治嘴硬

他們把一堆非常知名的、開源的 SaaS 工具，比如 Mattermost、OnlyOffice、ownCloud 打包進了一個 Docker，用真實的的辦公環(huán)境，看看這些 Agent 怎么操作，以及操作完成后數(shù)據(jù)庫有沒有變化

作為測試結(jié)果，Opus 和 GPT 確實斷檔領(lǐng)先。但在這種真實的校驗下，強如榜首也只拿了不到一半的分?jǐn)?shù)

（另：這里 DeepSeek/GLM/MiniMax 不支持多模態(tài)，所以評分受影響）

所謂「真實」，必須能檢測

之前測 GUI 能力的時候，通常是搭建一個靜態(tài)網(wǎng)頁的環(huán)境，看 Agent 能不能正確的點擊按鈕。測 bench，大抵就像是考駕照：看你會不會側(cè)方位停車、會不會壓線等等

但實際上路是另一回事兒。咱正常辦公是業(yè)務(wù)導(dǎo)向的，環(huán)境也是較為復(fù)雜的，比如有的時候 Agent 的點擊雖然成功了，甚至網(wǎng)頁也跳轉(zhuǎn)了，但后臺可能沒收到響應(yīng)...因為你可能點了假鏈接，比如...下面這種

真實的電腦環(huán)境，總是有很詭異的問題

作為第一性原理，我們不妨換個思路：Agent 的嘴會騙人，但數(shù)據(jù)庫不會，只需要檢測數(shù)據(jù)庫里的變化就行了，按著這個思路，就有了 SaaS-Bench

Task Input → Agent → SaaS Apps（Docker）→ Browser-Use → Verify（State-Check）→ Score，走完這條鏈才算數(shù)

然后呢，UniPat 的朋友把 23 個開源 SaaS，都丟進了 Docker 來跑，測試項目覆蓋軟件研發(fā)、業(yè)務(wù)財務(wù)、醫(yī)療管理、團隊協(xié)作、農(nóng)業(yè)供應(yīng)鏈、獨立媒體六個領(lǐng)域。然后每個業(yè)務(wù)場景里都是用了真實的業(yè)務(wù)數(shù)據(jù)，大概就像下圖所示：

六個領(lǐng)域二十三個 App，環(huán)狀圖里大概率有你們公司在用的那幾個

值得一提的事，在全部的 106 個任務(wù)里，93.4% 跨兩個以上 App，三 App 協(xié)作的占一半（53 個）。純文本任務(wù) 74 個，涉及多模態(tài)理解的 32 個。

這就很符合我們常見的工作習(xí)慣了，總是跨著軟件來反復(fù)復(fù)制粘貼....哈哈哈哈，然后之前的各種 GUI bench 中，基本測試的都是 50 步以內(nèi)的單 App 任務(wù)

就以醫(yī)療管理為例，醫(yī)生先要在 OpenEMR 里寫 SOAP 病歷，再到 OpnForm 填上報字段，最后到 OnlyOffice 出正式文檔，三個系統(tǒng)之間切來切去，就像下圖所示

OpenEMR 寫 SOAP 病歷 → OpnForm 填上報字段 → OnlyOffice 出正式文檔

之前的 bench 里測的基本上是 50步以內(nèi)的單 App 任務(wù)，而 SaaS-Bench 則基本都是 100 步以上的長程任務(wù)，但凡中間出現(xiàn)糊弄，最終數(shù)據(jù)庫校驗就過不去

至于這些任務(wù)是怎么來的？也是有 Human 在 Loop 的，是先由大模型結(jié)合職業(yè)角色和 task seed 生成初步的數(shù)據(jù)，再由專家人工篩選、實際執(zhí)行、對齊驗證器，以保證所有的任務(wù)具有代表性和可驗證性

大概就是這么四個階段

還得說一下，在這個 Bench 里「操作對不對」這件事兒是通過「查數(shù)據(jù)庫」來檢測的，背后有一個驗證器：每個任務(wù)都有一個 verify.py 文件，在跑任務(wù)的時候會自己調(diào) SQL 查數(shù)據(jù)庫、調(diào) API 拉狀態(tài)。每當(dāng)任務(wù)有結(jié)果了，verifier 就會直接去查數(shù)據(jù)庫里的字段對不對，避免出現(xiàn)下面這種情況

hhhhh

SaaS-Bench 榜單

【注意】DeepSeek/GLM/MiniMax 是單模態(tài)

說一下榜單的測試成績吧，模型測試其實分為大類：文本任務(wù)和多模態(tài)任務(wù)，兩者都通過 Browser-Use 在瀏覽器里操作 SaaS 界面，區(qū)別在于：多模態(tài)模型喂的是截圖+無障礙樹；不支持多模態(tài)的模型喂的就只有無障礙樹，頁面所有可交互元素被提取成結(jié)構(gòu)化文本，模型讀文字、輸出「點第幾號元素」

對于多模態(tài)的模型，沒啥懸念的 Opus 4.7 拿了第一，checkpoint 分 43.9%，resolved 分 3.8%。GPT-5.5 High 幾乎打平，checkpoint 43.8% 但 resolved 只有 1.9%

這里說一下，resolved 指的是完美完成了任務(wù)，checkpoint 則是給過程分；很顯然，即便是強如 Opus，在真實操作辦公軟件這事兒上，其實跟弱智也差不多，很符合體感

在支持多模態(tài)的國產(chǎn)模型里，K2.6 是顯著最強的，很符合認知：/

對于不支持多模態(tài)的 DeepSeek/GLM/MiniMax 這三款模型，只看 text-only 任務(wù)的話，最新發(fā)布的 DeepSeek V4 是強于 GLM 和 MiniMax 的，符合「越新越強」的刻板印象

然后...我發(fā)現(xiàn)了兩個有趣的現(xiàn)象：其一、幾乎所有多模態(tài)模型，在理論上更難的多模態(tài)領(lǐng)域里，分都會更高；其二、支持多模態(tài)模型，即便是在 text-only 的 Computer-Use 任務(wù)里，也更強

對于第二個點，考慮到在 text-only 下，單模態(tài)模型靠的是無障礙樹，而多模態(tài)模型多了個截圖，這意味著...即便是 Agent，圖文并茂也是更利于模型/Agent 進行信息理解

任務(wù)越長，成功率越低

越長的任務(wù)，就越容易出問題，這個還是很容易理解的。作為數(shù)據(jù)，可以查看上面的圖：

• 單 App 的任務(wù)平均分 53%，而跨 4 個 App 任務(wù)的成功率就掉到 20% 左右

• 操作部署在 50 步以內(nèi)的任務(wù)，平均成功率有 50%+，但到了 400 步就在 20% 左右

• 驗證點 6 個以內(nèi)能拿 65% 的分?jǐn)?shù)，18 個以上則掉到 27%

總而言之：任務(wù)越復(fù)雜，分越低。當(dāng)然，從數(shù)學(xué)上來看也合理，即便每個 checkpoint 通過率高達 95%，12 連抽也就只剩 54%

97.3% 的任務(wù)超 100 步，最長 300+。真實辦公流程就是這么長

步數(shù)越長，任何一步出錯的概率越高，后面恢復(fù)的機會越少，把任務(wù)切成 early / mid / late 三段看，所有模型都是同一個走勢：前段拿分，后段掉分

所有模型一路向下，沒有例外

同時的，單步驟錯誤率并非一成不變，當(dāng)前序步驟發(fā)生錯誤了，可能后續(xù)好多步的成功率都會受到影響，并且難以自檢，比如下面這個：

第七步小石頭一磕，后面九分跟著倒

在這個任務(wù)里，是要創(chuàng)建一個公司客戶 Arcturus Digital，Agent 填了聯(lián)系人姓名加公司名，卻觸發(fā)了個人客戶的邏輯路徑，實際創(chuàng)建出一個叫 Elena Vasquez 的人。作為影響，后續(xù)的開發(fā)票、記付款、對賬等流程，都因為全部掛在錯誤實體下而產(chǎn)生錯誤

可見，前面只是一個小的錯誤，在后續(xù)環(huán)境下都能產(chǎn)生不小的損失

數(shù)據(jù)庫，專治嘴硬

大模型總是帶著點「先忽悠，大不了道歉」的惡習(xí)，而通過數(shù)據(jù)庫去校驗實乃創(chuàng)舉。之前如果讓 Agent 去自檢，他總是說「放心吧，餐廳 100% 定好了」但如果拿數(shù)據(jù)庫去校驗，就很容易發(fā)現(xiàn)大模型在此處出現(xiàn)的問題：很多 Agent 自評是純幻覺的

如果你只看 Agent 給你的匯報結(jié)果，很多時候你會被騙的心服口服，這時候你需要真的讓賽博勇哥過來，讓你的 Agent 360 度轉(zhuǎn)一圈，看看數(shù)據(jù)

比如 Opus 4.6 在一個任務(wù)里發(fā)現(xiàn)日期填錯了，它會說「我現(xiàn)在就去修改，一定搞好」，并匯報「賬單日期 2026-03-20，已修復(fù)」。此刻如果通過 API 看一下，可能后臺里還是：賬單日期 03-19

意圖說成了，狀態(tài)說沒成，兩邊各覺得自己沒錯

Agent 在意圖層面認為成功了，反思機制是「我會改」，但不一定會改成功，這點相信大家一定深有體會，而 verifier 這玩意兒也正好拿來看看 Agent 到底能怎么糊弄

從榜單，到訓(xùn)練數(shù)據(jù)

對于 Computer-Use Agent 整塊，在過去兩年都在面臨一個事情：CUA 訓(xùn)練數(shù)據(jù)嚴(yán)重不足，WebSTAR、GUI-360、Video2GUI 這些近期論文，開篇都點同一個判斷：scarcity of high-quality trajectory data

CUA 訓(xùn)練數(shù)據(jù)大頭來自人工標(biāo)注，貴且不可擴展，而另一部份則來自簡化環(huán)境下的合成數(shù)據(jù)，便宜但不真

SaaS-Bench 更有價值的地方在于它的環(huán)境，能夠穩(wěn)定的產(chǎn)出長程、跨 App、帶真實后段校驗的運行軌跡

對于想要攻克辦公環(huán)境的 Agent 來說，這套環(huán)境是非常有價值的

總結(jié)

如果我們真的希望 Agent 能夠進入千行百業(yè)，那么就應(yīng)該更好的評估 Agent 的行為，確保無論它在做任何事情的時候，不是在糊弄

對于 Agent 的評估來說，我們不能只看他的結(jié)案報告寫的多漂亮，排版多精美，更需要的是看看 Agent 是不是真的干完活了

SaaS-Bench 的意義，恰就在于給出了一套「測謊」的方法，以及一套「生成數(shù)據(jù)」的環(huán)境，或者說...給未來 Agent 打績效的憑證...

趨勢已經(jīng)是這樣了，擁抱吧

Blog：unipat.ai/blog/SaaS-Bench

GitHub：github.com/UniPat-AI/SaaS-Bench

論文：arxiv.org/abs/2605.15777