---
source_url: "https://mp.weixin.qq.com/s/KzPHgTF7j3XzWDZSh_jJPw"
ingested: 2026-06-26
sha256: 98e71c5253878791
---
sha256: c7a87ac847336839
---
title: "SaaS-Bench：浙大阿里 Steering 真实SaaS系统Computer-Use Agent评测"
type: raw-article
source_type: wechat-mp
source: https://mp.weixin.qq.com/s/KzPHgTF7j3XzWDZSh_jJPw
author: 数据派THU（转载自机器之心）
publisher: 数据派THU / 清华大数据研究中心
ingested: 2026-06-10
created: 2026-06-10
confidence: 8
value: 8
stars: 4
tags: [benchmark, computer-use, gui-agent, saas-bench, unipat, long-horizon, eval, agent-failure, zhejiang-university, alibaba]
description: 浙大阿里 Steering/UniPat AI 提出 SaaS-Bench：23 个真实开源 SaaS 系统 Docker 化、106 个跨应用长程任务，Claude Opus 4.7 完全通过率仅 3.8%，揭示 Computer-Use Agent 四种结构性失败
sha256: 44f2a6dad3160e646f1246d1b7371f9477287794536ae0cf1c7647c02aa9a38c
---

# SaaS-Bench：浙大阿里 Steering 真实SaaS系统Computer-Use Agent评测

> 来源：机器之心 / 转载于 数据派THU（清华大数据研究中心），2026-06-08
> Blog：https://unipat.ai/blog/SaaS-Bench
> GitHub：https://github.com/UniPat-AI/SaaS-Bench
> 论文：https://arxiv.org/abs/2605.15777

## 核心痛点

现有的 Agent 评测：仿真环境、简单任务、最多几十步搞定。跟真实工作完全是两回事。

真实办公：医疗管理员写完 SOAP 病历→填病例上报→生成正式文档；财务收到报销申请→审批→打款→记账。跨好几个系统，步骤动辄几百步。

SaaS-Bench 思路：直接把真系统搬进 Docker，让 Agent 在真实的前后端逻辑、数据库状态和业务约束中干活。

## Benchmark 设计

**23 个真实开源 SaaS 系统**（全部 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 进入的不是空白的测试页面，而是有历史数据、有干扰项、有跨系统关联的真实工作环境。

## 106 个任务分布

- 93.4% 跨越至少两个应用
- 三应用任务占了一半（53 个）
- 纯文本任务 74 个，多模态 32 个
- 以 Claude Opus 4.6 执行轨迹估算：97.3% 文本任务操作步数 > 100 步，最长轨迹 300+ 步
- 任务构建流程：LLM 生成 + 专家把关，四阶段质量保证

## 两个评估指标

- **Resolved Score（严苛）**：全部检查点通过才算 1，否则为 0
- **Checkpoint Score（宽松）**：按权重计算部分检查点完成比例

→ 这两个数字之间的巨大落差，暴露了 Agent 最核心的问题。

## 榜单：全军覆没

| 模型 | 检查点分数 | 端到端通过率 | 完整通过任务数 |
|------|------------|--------------|----------------|
| Claude Opus 4.7（最强） | 43.9% | **3.8%** | 4/106 |
| Kimi K2.5 | - | 0% | 0 |
| Gemini 3.1 Pro | - | 0% | 0 |

DeepSeek V4、M2.7、GLM5.1 为单模态模型，仅测评 Text-Only Domain。

含义：Agent 可以推进工作的部分中间环节，但几乎没有能力将一个完整的长程工作流走完。

## Pass@k：多跑几次能救吗？

每个模型在同一任务上独立跑 3 次，对一次就算通过。pass@3 相比 pass@1 整体提升约 8 个百分点。

Sonnet 4.6 在多模态任务上从 33.9% 跳到 52.1%（+18.2pp）—— 它并非完全不行，而是执行极不稳定。

这不是环境随机性（每次运行初始状态完全相同），而是**路径依赖** —— 模型在某个决策点的微小差异，导致后续轨迹完全分叉。

## 三种结构维度全部单调递减

- 跨应用数 1→4：平均分从 53% 降至 20%
- 操作步长增加：任务轨迹越长，得分显著越低
- 检查点个数 ≤6 vs ≥18：平均分从 65% 降至 27%

「跨应用 + 轨迹长 + 细粒度验证」的任务得分最低 —— 真实工作流最常见形态。

## 四种结构性失败

**失败 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 在意图层面认为成功，验证器在状态层面发现失败。当前 CUA 框架缺少「严谨的反思闭环」 —— Agent 是个不会检查自己作业的学生。

**失败 4：同一张考卷，成绩忽高忽低**
Claude Sonnet 4.6 在同一任务的三次独立运行中，分数范围 0.00 到 0.68。路径依赖导致长程任务执行变成赌博。

## 结论：当前范式的天花板

四种失败模式指向同一个底层事实：当前 Agent 缺少对持久状态的有效推理能力，缺少操作后的闭环验证机制，缺少从错误中恢复的能力。

这些不是靠模型变大、或加几个工程模块就能解决的。它们指向当前 Agent 范式更深层的局限：在长程任务中，模型缺少对全局状态的持续感知，无法像人一样"心里有数"。这不只是技术债，而是当前范式的天花板。

## 延伸洞察：SaaS 形态的保质期

正在逐渐形成的共识：今天的 SaaS 是给人设计的 —— 菜单、按钮、表单，都在服务人类的眼睛和手指。但当 Agent 成为主要用户，这些界面就变成了累赘。

未来不是让 Agent 学会操作人类的软件，而是软件本身要为 Agent 重新设计。SaaS-Bench 揭示的不只是 Agent 的短板，也是当前软件形态的保质期 —— 面向人类的 SaaS，可能都要为 Agent 重做一遍。

## UniPat AI

UniPat AI 致力于构建面向真实场景的 AI 训练、评测与应用新范式，推动 Agent 能力在千行百业中规模化落地。

官网：https://unipat.ai