zapier/AutomationBench · 上手攻略
- 仓库:zapier/AutomationBench
- 链接:https://github.com/zapier/AutomationBench
- 分类:evaluation / Agent 基准测试
- 作者:spark
- 更新:2026-10-23
§0 自检(三证 checklist)
- [x] GitHub URL 已 fetch:README 全文经 web_fetch 拉取(2026-10-23,HTTP 200)
- [x] README 子模块 anchor:CLI 参数表 19 项、
visualizer/README.md、contributing 段(uv sync/pytest/ruff)均已核对 - [x] 白皮书 anchor:README 给出 arXiv:2604.18934(https://arxiv.org/abs/2604.18934)——⚠️ 本次仅从 README 抄录该 ID,未独立 fetch arXiv 页面核实作者/版本/日期,引用时请自行核对。
- 官方榜单:https://zapier.com/benchmarks | Artificial Analysis:https://artificialanalysis.ai/evaluations/automationbench-aa | Prime Intellect 环境:app.primeintellect.ai/dashboard/environments/zapier/AutomationBench
- 许可:仓库卡记为
NOASSERTION(GitHub 未识别到明确 LICENSE 文件),⚠️ 使用前请自行确认授权条款。
§1 是什么 / 解决什么问题
AutomationBench 是 Zapier 出品的 agent 评测基准:不再考「能不能答对题」,而是考「能不能把一件真实的业务活儿干完,而且环境最后的状态是对的」。
每个任务会初始化一套模拟的业务环境——CRM、日历、收件箱、Slack 等,agent 手上有 47 个模拟 SaaS 工具可用。评测方式不是比对文本答案,而是断言(assertion)式的最终状态检查:agent 干完之后,这个模拟环境的 CRM 记录、日历条目、工单状态是否符合预期。
覆盖 6 个业务域,每域 100 个任务,共 600 个公开计分任务:
| 域 | 任务数 | 覆盖内容 |
|---|---|---|
| Sales 销售 | 100 | CRM、线索管理、跨应用工作流 |
| Marketing 市场 | 100 | 活动、广告效果、内容运营、品牌监控 |
| Operations 运营 | 100 | 设施管理、项目跟踪、供应商流程、合规 |
| Support 客服 | 100 | 工单路由、SLA 监控、知识库、多平台 helpdesk |
| Finance 财务 | 100 | AP/AR、报销、报表、记账 |
| HR 人力 | 100 | 招聘、入职、请假、薪资 |
它解决的问题是:现有 agent 基准(WebArena、SWE-bench 类)要么脱离真实业务、要么只看单点能力,而企业真正在意的是「这个 agent 能不能替我把流程跑完」。Zapier 自己是自动化 SaaS,天然掌握这个场景定义权。
每个任务由 5 部分构成:
- Verifiability:任务必须可程序化验证 —— 「If we can't automatically check whether a task was completed correctly, it doesn't belong in the benchmark.」
- Trigger Data:触发工作流的初始上下文(无用户交互)
- Initial State:预填充的模拟业务环境
- Tools:与该域相关的环境操作函数
- Evaluation:断言式 rubric 比对最终状态与预期状态
每次运行报两个每任务指标:
partial_credit(0.0–1.0):满足的断言比例,兼作环境 reward 信号,供密集训练/迭代用task_completed_correctly(0 或 1):严格通过/失败,所有断言全过才给 1.0。计分任务上这个指标的均值就是官方 pass rate(simple 域除外)。
§2 快速安装
# 1. 克隆
git clone https://github.com/zapier/AutomationBench.git
cd AutomationBench
# 2. 装依赖(用 uv)
uv sync
# 3. 配 API key(或写进 .env)
export OPENAI_API_KEY=sk-...
# 4. 跑评测
uv run auto-bench --model gpt-5-mini
用 Anthropic 模型会被 claude-* 前缀自动识别:
export ANTHROPIC_API_KEY=sk-ant-...
uv run auto-bench --model claude-haiku-4-5-20251001
只要单域:
uv run auto-bench --model gpt-5-mini --domains sales
环境依赖:Python + uv。⚠️ README 未给出具体 Python 版本下限与锁定版本,⚠️ 以仓库当前 pyproject.toml / lock 文件为准。
§3 核心用法
3.1 CLI 参数速查(README verbatim)
| 选项 | 默认 | 说明 |
|---|---|---|
--model |
gpt-5-mini |
评测用模型名 |
--domains |
all |
逗号分隔的域,或 all |
--toolset |
api |
工具风格:api / zapier / limited_zapier |
--base-url |
OpenAI | API endpoint URL |
--api-key |
- |
API key(或用环境变量) |
--api-key-var |
OPENAI_API_KEY |
存放 key 的环境变量名 |
--num-examples |
-1 |
任务数(-1 = 全部) |
--max-steps |
50 |
每任务最大响应步数 |
--max-concurrent |
100 |
最大并发任务数 |
--tasks |
- |
逗号分隔的任务名 |
--skip |
- |
跳过前 N 个任务 |
--reasoning-effort |
- |
low/medium/high/xhigh/max |
--responses-api |
off |
用 OpenAI Responses API(部分模型必需) |
--search-top-k |
20 |
search_tools 的 top_k 上限(仅 zapier toolset) |
--headers |
- |
自定义 HTTP 头(KEY=VALUE,可重复) |
--input-cost |
- |
每 token 输入成本(USD),覆盖内置查表 |
--output-cost |
- |
每 token 输出成本(USD) |
--export-json |
auto |
结果 JSON 导出路径 |
--save-every |
1 |
每 N 个任务存一次增量结果 |
3.2 托管跑(Prime Intellect)
不想本地吃 API 额度,可以直接用托管环境:
prime env install zapier/AutomationBench
prime eval run zapier/AutomationBench
# 冒烟测试:只跑 5 个
prime eval run zapier/AutomationBench --num-examples 5
# 只跑 sales 域
prime eval run zapier/AutomationBench --env-args '{"domains": "sales"}'
3.3 可视化分析
评测结果会自动存到 visualizer/runs/local/,也可以指定路径:
uv run auto-bench --model gpt-5-mini
# 或
uv run auto-bench --model gpt-5-mini --export-json visualizer/results.json
# 起可视化服务(http://localhost:8000)
python3 visualizer/serve.py
可视化器提供:分数分布与 token 用量交互图表、pass/fail 计数与成本估算汇总、可筛选的任务结果表、2–5 次运行并排对比、响应式布局。
3.4 开发
uv sync # 装依赖
uv run pytest # 跑测试
uv run ruff check --fix . # lint + 自动修
§4 公开榜单(README verbatim)
600 任务公开集、每模型跑其最高可用 reasoning effort:
| 模型 | Reasoning Effort | Pass Rate |
|---|---|---|
| Claude Opus 5 | max | 50.3% |
| Kimi K3 | max | 46.67% |
| Claude Fable 5 | max | 46.17% |
| GPT-5.6 Sol | max | 45.83% |
| Gemini 3.6 Flash | high | 45.00% |
| Claude Opus 4.8 | max | 41.00% |
| Gemini 3.5 Flash | high | 38.33% |
| GPT-5.6 Terra | max | 37.17% |
| Claude Sonnet 5 | max | 34.67% |
| GLM 5.2 | max | 26.17% |
README 注明:「Fable 5 score is after the July 2026 stricter classifier.」——即分类器改严后重算,历史分数与新分数不同口径。
§5 坑与注意(三段式:现象 / 影响 / 修复)
坑 1|公开分 ≠ 官方分,这是最容易误读的一点 - 现象:README 明确——仓库发的是公开任务集,而 zapier.com/benchmarks 上的官方榜跑的是每个域一套私有 held-out 任务集。私有集分布相近、断言框架相同,但故意更难且不公开。官方还会在版本更新时把私有任务再加难度,好让头部维持在同一分段。 - 影响:本地测出的 45% 和官方榜的 45% 不是一回事,直接拿本地数对外发布会对不上。README 只承诺「directional agreement」——公开集涨了,私有集很可能涨,但「not guaranteed」。 - 修复:本地分数只当相对比较用(同口径纵向对比),要对外引用官方数字就去 zapier.com/benchmarks;别自己造榜单。
坑 2|存在一个不计入分数的 simple 域
- 现象:「The simple domain contains 200 foundational single- and two-step tasks… It is not included in the benchmark score but serves as a baseline to verify that a model can handle basic tool use」。
- 影响:如果你按 --num-examples -1 或不指定 --domains 全量跑,会看到 800 个任务在执行,但分母是 600 而不是 800;容易算错平均。
- 修复:官方 pass rate = task_completed_correctly 在计分任务(simple 除外)上的均值,别自己把所有输出平均一遍。
坑 3|分类器版本会追溯改写历史分数 - 现象:Fable 5 的分数是「after the July 2026 stricter classifier」。 - 影响:跨时间点的分数不可直接比——分类器改严后,早期公布的数会偏高。 - 修复:引用任何数字都带上报日期与「是否经新分类器重跑」;README 说变更超出演内波动时会重跑全部模型并更新榜,但本地旧结果不会自动更新。
坑 4|strict 通过率天然很低,别误判成模型不行
- 现象:task_completed_correctly 要求所有断言全过才给 1.0;顶配 Claude Opus 5 也只有 50.3%。
- 影响:容易得出「这模型不太行」的误判,实际上 50% 已经是很强的成绩;也容易只看这个指标而忽略 partial_credit。
- 修复:同时看 partial_credit(0–1 连续分数),它既是排序依据,也是给 RL / 迭代训练的稠密奖励信号。
坑 5|成本是真金白银,默认 max-concurrent=100
- 现象:默认 --max-concurrent 100、--max-steps 50,600 任务全量跑。
- 影响:API 费用与触发限流都可能失控;--reasoning-effort max 尤其贵。
- 修复:先 uv run auto-bench --model gpt-5-mini --num-examples 5 冒烟,或用 Prime Intellect 的 --num-examples 5;正式跑再上量,并准备 --input-cost / --output-cost 让它算成本。
坑 6|--reasoning-effort 不一定被所有模型支持
- 现象:榜单里每个模型都标了各自的最高 effort(max / high 混用),且该参数需要模型侧真的支持。
- 影响:给不支持的模型传 max 可能报错,或被静默忽略,导致不同模型的 effort 不对齐、分数不可比。
- 修复:按 README 表格里各模型的档位对齐设置;README 未列出支持矩阵,需自己逐模型验证。
坑 7|--responses-api 是必需项而非可选项
- 现象:--responses-api 默认 off,但标注「required for some models」。
- 影响:用那些只支持 Responses API 的模型跑,默认配置会失败或表现异常。
- 修复:换模型前先查该模型是否要求 Responses API,是则显式加 --responses-api。
坑 8|toolset 三档差异会改写分数
- 现象:--toolset 有 api / zapier / limited_zapier 三种,zapier 档还带 search_tools 和 --search-top-k。
- 影响:不同 toolset 是不同难度设定,跨 toolset 比分数无效。
- 修复:固定 toolset 再比较;引用时写明用的是哪一档。
坑 9|基准本身有 bug,作者自己承认 - 现象:README 原话——「Though we have taken many measures to try to decrease bugs in the benchmark, there are still many we have not caught. Benchmarking is hard!」 - 影响:遇到不合理分数或明显做不到的任务,先怀疑 benchmark 而不是模型。 - 修复:开 issue 反馈(README 明确欢迎报 bug 与 unfair task);本地结果标注运行日期,便于日后对账。
坑 10|许可不明 + Python 版本未锁
- 现象:repo card 记许可为 NOASSERTION;README 未给 Python 版本下限。
- 影响:商用或二次分发前授权边界不清;新版本 Python 上 uv sync 可能因依赖解析失败。
- 修复:⚠️ 使用前到仓库页确认 LICENSE 现状;CI 环境固定已验证的 Python 版本。
坑 11|上游模型 API 变动会连带失效
- 现象:基准本身固定,但被测模型是活的——模型下线、改 ID、改接口(如 OpenAI/Anthropic 侧调整)都会打断评测。
- 影响:--model gpt-5-mini 之类的默认值随时可能失效或换指向。
- 修复:⚠️ 每次跑都显式写 --model 全名(README 里 Anthropic 示例用的就是带日期后缀的 claude-haiku-4-5-20251001),不要依赖默认值;本文核对基于 2026-10-23 的 main 分支 README。
§6 与同类对比
| 基准 | 测什么 | 环境形态 | 结果判定 | 适合 |
|---|---|---|---|---|
| AutomationBench | 端到端业务工作流完成度 | 47 个模拟 SaaS 工具 | 断言式最终状态比对 | 企业流程 agent、SaaS 集成 agent |
| SWE-bench (Verified) | 修 GitHub issue | 真实仓库 + 测试 | 跑测试是否全过 | 编码 agent |
| WebArena / BrowserGym | 网页操作 | 克隆的真实/仿制站点 | 程序化状态检查 | 通用 web agent |
| GAIA | 通用助理任务 | 轻量工具集 | 答案精确匹配 | 基础推理+工具 |
| τ-bench 类 | 多轮对话 + 工具遵守 | 模拟 API | 规则 + 状态检查 | 工具调用规范遵循 |
| Artificial Analysis 系 | 多维模型能力横评 | 托管 | 综合指数 | 选型对比 |
AutomationBench 的差异化在于「业务域划分 + SaaS 工具模拟 + 状态断言」这套组合:它不问「你能不能用工具」,而问「流程到底有没有跑成」。这也是它跟 WebArena 的关键分野——后者验证网页操作,这里验证业务结果。额外成本是它绑定 Zapier 的 SaaS 视角,域外场景(如科研、工程运维)覆盖不到。
§7 一句话推荐结论
做企业流程类 agent 选型的,AutomationBench 值得直接上——它把「agent 能不能真的替我把活儿干完」变成了一个可复现的分数;但务必记住官方榜跑的是私有任务集,本地分只做纵向相对比较,别自己造榜。
来源:GitHub README(web_fetch,2026-10-23,HTTP 200)+ repo card organized/repo_cards/4577-zapier-automationbench.md。arXiv:2604.18934 与许可状态未独立核实,已标 ⚠️。未 clone、未运行评测。