BizAgentBench（原帖称 BizBench）：把"任务完成"和"过程合规"分开算的长程 Agent 业务基准 · 干货攻略

  • 链接: https://x.com/_akhaliq/status/2112249207969235093
  • 分类: x-tips
  • 来源: X @_akhaliq（AK，AI 资讯转发）
  • 作者: Jay
  • 更新: 2026-10-21
  • 论文: https://arxiv.org/abs/2610.20424
  • 仓库: ant-intl/BizAgentBench（https://github.com/ant-intl/BizAgentBench）
  • 数据集: https://huggingface.co/datasets/ant-intl/BizAgentBench

这是什么

原帖正文只有三行：项目名 "BizBench"、完整标题 "Unveiling Hidden Challenges in Deploying Long-Horizon Agents for Real-World Business"，以及一个论文链接（t.co 短链实际跳转到 https://huggingface.co/papers/2610.20424 ）。所以原帖本身不含任何数字，本篇所有数据都来自论文与官方仓库的核对，不是从推文或评论区二次加工。

这是一篇由北京大学 + 蚂蚁国际（Ant International）发表于 arXiv（cs.CE，v1 2026-10-14 / v2 2026-10-18）的论文，提出 BizAgentBench（v1 标题写作 BizBench）——一个基于某全球头部支付公司真实业务流程构建的长程 Agent 基准。

它要解决的痛点非常具体：现有长程 Agent 基准大多只判"最终任务有没有成功"，但真实业务里中间过程的违规同样是事故。论文给的例子是：客户账户有 60 美元、要求全程保留至少 20 美元现金储备，Agent 付了一笔 60 美元 retainer，余额归零——工具调用被接受了、任务最终也可能"完成"，但储备约束已经在过程中被破坏，后面再退款也补不回这次违约。只看终态的评测会把它算成成功。

于是这个基准把评测拆成三层（后面"上手步骤"里的 G/P/F）： - Goal (G)：请求的业务结果是否达成 + 允许的终态条件 - Process (P)：过程中必须持续满足的要求（授权、储备下限、持续担保覆盖等） - Protection (F)：受保护对象、账本完整性、禁止的副作用

Strict = G ∧ P ∧ F，全部通过才算成功。评分用确定性可执行检查跑在业务状态与执行历史上，不使用 LLM judge，也不比对某条"标准答案轨迹"——不同合规解法都能通过。

核验来源

全部取自一手官方出处：

  1. arXiv 摘要页（https://arxiv.org/abs/2610.20424 ，v2）：环境规模、Claude Opus 5 / GPT-6 Sol / Qwen3.8-27B 的分数、DeepSeek-V4.1-Flash 的平均工具调用数，均为原文表述。
  2. arXiv HTML 全文（https://arxiv.org/html/2610.20424v1 与 /v2 ）：引言中的构造逻辑、三次运行的稳定性、"40.0% 任务三次全对"、Qwen3.5-9B 的 187.2 次工具调用与错误占比等细节。
  3. 官方 GitHub 仓库 README（https://github.com/ant-intl/BizAgentBench ）：安装、配置、运行命令、指标定义、输出文件、许可证。这是"上手步骤"一节的唯一依据。
  4. Hugging Face 论文页与数据集页（ant-intl/BizAgentBench）：数据集与论文的挂载位置。

交叉检查只做了一次（用于确认主仓库确实存在、名称拼写），没有反复重试或换题。

关键数字与出处

指标 数值 官方出处
任务数 50 个多轮长程任务 arXiv 摘要 + 论文 §3.1
知识文档 789 份 arXiv 摘要 + §3.1
可发现业务能力 601 个；Agent 侧常驻工具 9 个，用户模拟器工具 10 个 §3.1
Claude Opus 5 Strict success 64.0% arXiv v2 摘要
GPT-6 Sol Strict success 61.3% arXiv v2 摘要 + v1/v2 引言
GPT-6 Sol 三次尝试全部成功的任务占比仅 40.0% v2 引言
Qwen3.8-27B Goal attainment 42.0% → Strict 32.7% arXiv v2 摘要
DeepSeek-V4.1-Flash 平均 191.3 次工具调用/次运行，比参考执行多约 70% arXiv v2 摘要
Qwen3.5-9B 平均 187.2 次工具调用，超过一半是错误；150 次运行无一达成全部任务目标 v2 引言
单次 episode 超时 5,400 秒 仓库 README
工具错误阈值 16 仓库 README

Goal 与 Strict 的落差是这篇论文最有说服力的地方：Qwen3.8-27B 目标达成率 42.0%，扣掉过程/保护违规后只剩 32.7%——大约五分之一的"成功"其实在途中违反了规则。论文还点名 DeepSeek-V4.1-Flash 有 4 次运行虽然达标且终态储备高于阈值，但中途击穿过阈值。只看终态的评测会把它们全部误判为成功。

上手步骤

仓库 README 给出的是一条完整的本地评测链路，MIT 许可（payment/runtime/ 与 tools/；内置的 tau2 第三方组件保留原 MIT 许可）。

1. 装环境

需要 Python 3.12，在仓库根目录执行：

python3.12 -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements.txt
cp configs/model.example.json configs/model.json

2. 配置两个角色（关键点）

这个基准需要同时配置两个模型：被测的 Agent，以及提供客户信息与审批的 用户模拟器。两者可以各自使用不同的模型、服务器和凭据。

编辑 configs/model.json 的 agent 与 user 两段，关键字段：

字段 含义
base_url API 基址，通常以 /v1 结尾，runner 会自动拼 /chat/completions
model 该端点接受的模型标识
api_key_env 存放该角色凭据的环境变量名
max_tokens 单次响应输出上限（不是上下文窗口，也不是累计 token 预算）
timeout_seconds 单次网络操作（含等待流式分片）的超时
extra_body 厂商特有参数，例如 reasoning 设置
response_model 厂商返回的模型标识与请求名不一致时填这里

端点必须同时支持 OpenAI 兼容的 Chat Completions、streaming、原生 tool calling（纯文本补全端点不够）。HTTPS 端点与 127.0.0.1/localhost 上的本地服务都支持。

凭据放环境变量（模型配置与运行输出已被 .gitignore 忽略）：

export AGENT_API_KEY='your-agent-key'
export USER_API_KEY='your-user-key'

本地无鉴权服务可把对应变量填非空占位符（如 local）。README 示例配置沿用了论文中 DeepSeek-V4.1-Flash 实验的每次响应输出上限：Agent 侧 max_tokens 为 262,144，用户模拟器侧为 393,216。用户模拟器默认模型是 DeepSeek-V4.1-Flash，官方 DeepSeek API 的模型标识是 deepseek-flash；换 provider 可能标识不同。

3. 先跑一个任务冒烟

python tools/evaluate.py \
  --config configs/model.json \
  --output runs/smoke \
  --numbers 1 \
  --workers 1

4. 跑全量 50 题

python tools/evaluate.py \
  --config configs/model.json \
  --output runs/model-run-1 \
  --workers 4
  • --numbers 按论文公布的任务编号取子集，例如 --numbers 1 2 3 4 5
  • --workers 取值 1–50，按两个端点的并发承受力调整
  • 每个输出目录必须是新的，除非使用 --resume

三次重复跑法（论文的稳定性统计就是这么做的）：

for run in 1 2 3; do
  python tools/evaluate.py \
    --config configs/model.json \
    --output "runs/repeat-${run}" \
    --workers 4
done

5. 断点续跑

python tools/evaluate.py --config configs/model.json \
  --output runs/model-run-1 --workers 4 --resume

续跑必须使用相同的模型配置、任务编号与代码/数据资产；已有 result.json 的用例会被跳过，未完成用例仅在请求哈希匹配时复用缓存响应并重建已有执行。

6. 读结果

汇总在 runs/model-run-1/summary.json，其中 paper_counts 是通过数，paper_rates 是 0–1 的比率：

python - <<'PY'
import json
from pathlib import Path

summary = json.loads(Path("runs/model-run-1/summary.json").read_text())
print(f"Finished: {summary['finished']}/{summary['planned']}")
print(f"Evaluated: {summary['evaluated']}")
for metric, rate in summary["paper_rates"].items():
    print(f"{metric}: {rate:.1%}" if rate is not None else f"{metric}: unavailable")
print("Run classifications:", summary["classifications"])
PY

单次运行目录里值得看的文件：result.json（任务得分、失败检查项、终止原因、工具计数、token 用量）、trajectory.json（完整对话与工具历史）、final_world.json（用于打分的终态与执行历史）、progress.json。中断或失败的 episode 会写成 trajectory_live.json / trajectory_partial.json，此时应结合 provider_retries.jsonl 区分是模型表现问题还是 provider/传输故障。

7. 离线自检

不调用任何模型 API 的本地测试：

python -m unittest discover -s tests -v

坑与适用边界

1. 名字有 v1/v2 两版，搜的时候两个都要试

原帖和 v1 论文标题写 BizBench，v2 标题、GitHub 仓库与 HF 数据集改名为 BizAgentBench。arXiv 的 abs 页现在默认展示 v2 摘要，但 HF papers 页（也就是原帖短链指向的页面）渲染的是 v1 HTML。两版核心数字（GPT-6 Sol 61.3%、40.0% 三次全成）一致，但引用时应注明版本。

2. 它是"单公司、抽象后"的基准，不是通用业务基准

流程抽象自一家支付与金融科技公司（跨境支付、外汇、资金服务），敏感业务规则已被改写（论文 §3.1 明确说明为保密做了抽象）。迁移到自己业务时，规则结构可借鉴，但不能用它的分数横评自己场景的模型。

3. 严格成功率的绝对值天然偏低

Opus 5 64.0%、GPT-6 Sol 61.3% 是在"全程合规"的判定口径下的数字，和只看终态的公开榜单（如 SWE-bench 类）不可直接比较。且任务只有 50 个、每题 3 次运行，样本不大，跨版本比较需谨慎。

4. 稳定性和成本是更值得看的指标

  • GPT-6 Sol 三次全过的任务只有 40.0%，比单次 61.3% 低一大截——真实上线要按"最差一次"而不是"平均一次"设期望。
  • DeepSeek-V4.1-Flash 平均 191.3 次工具调用/次运行，比参考执行多约 70%；Qwen3.5-9B 平均 187.2 次、且过半为错误，150 次运行无一全对。长程 Agent 的成本与幻觉工具调用，可能比成功率更早成为瓶颈。

5. 运行开销不小

单 episode 超时 5,400 秒，工具错误阈值 16（两个角色合计），且没有工具调用或对话步数上限。全量 50 题建议 --workers 4 起，先单题冒烟再放开；两个角色的端点都要能扛住长上下文 + 流式 + 原生 tool calling。

6. 评分口径要自己看 G/P/F，别只看一个数

Intermediate failure 指 not (P and F)，即过程或保护项失败；报告时应同时给出 Goal 与 Strict，否则就复制了论文批评的"只看终态"问题。

7. 常见报错

  • HTTP 401 / 缺环境变量 → 检查对应角色的 api_key_env
  • PROVIDER_MODEL_MISMATCH → 核对模型 ID，必要时用 response_model 覆盖
  • 工具调用报无效 → 确认服务端支持原生 tool calling
  • 输出被截断 → 看 output_limit_roles，在新一次运行里调大 max_tokens（不要原地续跑改配置）
  • 续跑被拒 → 必须与原始运行同配置、同任务编号、同代码/数据资产

不确定处

  • 论文完整榜单（全部参评模型的主表）未逐格核对：本篇只引用了 arXiv 摘要与引言中直接出现的数字（Opus 5、GPT-6 Sol、Qwen3.8-27B、Qwen3.5-9B、DeepSeek-V4.1-Flash），HTML 全文抓取在第 4 节被截断，未覆盖实验章节的完整表格。
  • 原帖配图（pic.twitter.com/yZcLYAvYUm）未单独取回核对；从 HTML 正文看对应的是论文 Figure 1 的构造示意图，但未做像素级确认。
  • 仓库 README 未列出的模型（其余参评模型的具体分数与成本）本篇不臆测。
  • "BizBench" 与 "BizAgentBench" 的改名时点以 arXiv v2（2026-10-18）与仓库当前命名为准，未查到官方单独的改名说明。

一句话结论

BizAgentBench 把长程 Agent 评测的判分标准从"最后办成了吗"改成"全程合规地办成了吗"——Qwen3.8-27B 目标 42.0% 掉到严格 32.7%、GPT-6 Sol 三次全过只有 40.0%、DeepSeek 平均 191 次工具调用，说明真要落地业务 Agent，过程合规、运行稳定性和调用开销比终点分数更要紧；基准本身 MIT 开源、50 题全开放，可以直接拿来压测自己的 Agent。