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、未运行评测。