SaaS-Bench：浙大阿里 Steering Computer-Use Agent 真实系统评测（3.8% 通过率暴露范式天花板）¶
📊 Level ⭐⭐⭐⭐ | 10.4KB
摘要¶
浙大阿里 Steering 团队 + UniPat AI 推出 SaaS-Bench：23 个真实开源 SaaS 系统（Docker 部署，保留完整前后端+数据库+业务约束）+ 106 个跨应用长程任务。最强模型 Claude Opus 4.7 检查点分数 43.9%，端到端完全通过率仅 3.8%（4/106 任务）。Kimi K2.5、Gemini 3.1 Pro 0% 通过。
不是靠模型变大或加工程模块能解决的，指向当前 CUA 范式的天花板：长程任务中模型缺少对全局状态的持续感知，缺少操作后闭环验证机制，缺少从错误中恢复的能力。
Benchmark 核心设计¶
- 23 个真系统、6 大领域：研发（OpenProject/Code-Server/Metabase）、财务（Twenty CRM/BigCapital/HRMS）、医疗（OpenEMR/OpnForm）、协作（SiYuan/Mattermost/ownCloud）、农业（FarmOS/Grocy）、媒体（PhotoPrism/MediaCMS/BookLore）
- 106 个任务分布：93.4% 跨 ≥2 个应用，三应用任务占 53 个；97.3% 任务 > 100 步，最长 300+ 步
- 两个评估指标：Resolved Score（严苛）+ Checkpoint Score（宽松）。两者的巨大落差是核心信号
- 任务构建：LLM 生成 + 专家把关，四阶段质量保证
榜单：全军覆没¶
最强模型 Claude Opus 4.7 检查点分数 43.9%，端到端完全通过率仅 3.8%（4/106 任务）。Kimi K2.5、Gemini 3.1 Pro 0% 通过。
含义：Agent 可以推进部分中间环节，但几乎没有能力把完整长程工作流走完。
Pass@k：多跑几次能救吗？¶
- pass@3 相比 pass@1 整体提升约 8pp
- 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：做完不检查，自以为对了 Claude Opus 4.6 在 Step 124 识别日期错误（2026-03-19 vs 03-20），执行修改但没回页面复查。Step 210 提交时汇报「已修复」，页面实际日期仍是 03-19。意图层成功 ≠ 状态层成功。当前 CUA 框架缺少严谨的反思闭环。
失败 4：同一张考卷，成绩忽高忽低 Claude Sonnet 4.6 同一任务三次独立运行：分数 0.00 → 0.68。路径依赖让长程执行变成赌博。
范式天花板：不是工程问题¶
四种失败模式指向同一底层事实： - 缺少对持久状态的有效推理能力 - 缺少操作后的闭环验证机制 - 缺少从错误中恢复的能力
这不是技术债，而是当前 Agent 范式在长程任务上的天花板 —— 模型缺少对全局状态的持续感知，无法像人一样"心里有数"。
延伸洞察：SaaS 形态的保质期¶
今天的 SaaS 是给人设计的（菜单/按钮/表单）。当 Agent 成为主要用户，这些界面就变成累赘。
未来不是让 Agent 学会操作人类的软件，而是软件本身要为 Agent 重新设计。SaaS-Bench 揭示的不只是 Agent 短板，也是当前软件形态的保质期 —— 面向人类的 SaaS 可能都要为 Agent 重做一遍。
工程对照¶
| 失败模式 | 现有缓解 | SaaS-Bench 暴露的差距 |
|---|---|---|
| 任务长做不对 | 长上下文/CoT 压缩 | 通过率随步长不可逆下降 |
| 一步错步步错 | 异常回滚/事务 | 错误节点权重损失是几何级数 |
| 做完不检查 | Self-critique 提示 | 意图层 ≠ 状态层，缺少验证闭环 |
| 路径依赖 | 多次采样/投票 | pass@3 提升 8pp 但仍不可控 |
深度分析¶
1. 检查点分数 vs 端到端通过率：全局状态的感知缺失
43.9% 检查点分数 vs 3.8% 端到端通过率的巨大落差，是 SaaS-Bench 最核心的信号。 即使每个检查点 95% 通过率，12 个检查点的全部通过概率也只有 54%，而 SaaS-Bench 平均检查点数远超 12——呈指数下降的复合失败率让长程任务几乎不可能完整通过。当前 CUA 框架在设计时没有内置"对全局状态持续感知"的机制，这是结构性缺陷而非模型能力问题。
2. 路径依赖：Agent 执行的"分叉点"陷阱
Claude Sonnet 4.6 同一任务三次独立运行，分数范围 0.00 → 0.68，这说明即使初始状态完全相同，决策点的微小差异就足以让轨迹完全分叉。 这不是环境随机性，而是路径依赖。应用到工程实践：在构建 agentic pipeline 时，应当将"关键决策节点的一致性"作为优先目标，而不是假设模型在相同输入下有行为一致性。
3. 意图层成功 ≠ 状态层成功：反思闭环的架构性缺失
Claude Opus 4.6 在 Step 124 识别并修复了日期错误，但到 Step 210 提交时，页面实际日期仍是错误的。 Agent 在意图层认为修复成功，但持久化状态层仍然错误。当前 CUA 框架缺少"严谨的反思闭环"——Agent 是不会检查自己作业的学生。这一缺陷指向当前范式在架构层面缺少状态验证层。
4. SaaS 为 Agent 重设计：界面形态的保质期
今天的 SaaS 界面（菜单、按钮、表单）是给人设计的，不是给 Agent 设计的。 当 Agent 成为主要用户，这些界面就变成了累赘。这揭示的不只是 Agent 的短板，也是当前软件形态的保质期——面向人类的 SaaS 可能都要为 Agent 重做一遍。这意味着未来软件形态演进的方向是"面向 API/Agent 的界面设计"，而非继续优化人类用户体验。
5. 多尝试能部分缓解但不能解决 pass@k 的根本问题
pass@3 相比 pass@1 整体提升约 8pp，Sonnet 4.6 多模态任务提升 18.2pp。 这说明增加尝试次数有帮助，但提升幅度有限且不稳定。路径依赖意味着单次失败可能引发后续所有步骤的连锁错误，因此多次采样的工程收益存在上界。
实践启示¶
- 为 Agent 设计状态验证层：在 agentic pipeline 的每个关键步骤后，强制插入"状态回读"验证，而不是依赖 Agent 的自我报告。
- 避免长程单线路径设计：将长程任务拆分为可独立验证的短阶段，每阶段设置明确的成功标准，防止错误级联。
- 界面形态演进纳入路线图：当规划面向 Agent 的 SaaS 集成时，需要同时考虑软件界面是否适合 Agent 操作——这可能是未来 SaaS 竞争力的核心维度。
- 评估模型的长程稳定性：在选型评测中，除了 pass@1 分数，还应纳入 pass@3 方差和最长可通过轨迹长度，作为稳定性的代理指标。
- 关注 path-dependence 的决策点：通过在关键分支点引入确定性规则或人工确认机制，抑制微小差异导致的全链路分叉。
链接¶
- Blog：https://unipat.ai/blog/SaaS-Bench
- GitHub：https://github.com/UniPat-AI/SaaS-Bench
- 论文：https://arxiv.org/abs/2605.15777
→ 原文存档
关联¶
- 相关概念: Harness Engineering