结果对不算数，过程合规才算：BizAgentBench 拷问真实业务里的长程智能体
你有没有遇到过这种场景：让一个 Agent 帮忙处理一笔转账，最后钱确实到账了，但你翻日志一看——它在没拿到授权的时候就把请求发出去了，中途还把备用金账户掏空过一次，只是后来又补回来了。
钱对了，账平了，但合规上这单就是事故。
现在主流的 Agent 评测，恰恰只看"钱到没到"。这篇来自北京大学和蚂蚁国际的论文 BizAgentBench（arXiv:2610.20424）就是冲着这个盲区来的：它把一家全球支付公司的真实业务流搬进可执行环境，50 个长程任务，不光看你最终有没有办成事，还全程盯着你每一步有没有违规。
结果挺扎心的：最强的 Claude Opus 5 严格成功率也只有 64.0 个百分点，GPT-6 Sol 61.3 个百分点。而 Qwen3.5-9B 跑了 150 次，一次都没能全部达标。
核心摘要
这篇论文解决的是一个评测上的结构性盲区：现有长程 Agent 基准大多只查最终状态，过程中踩了红线照样算成功。在支付这类高风险场景里，这是要出事的——未授权转账哪怕后来把钱退回去了，合规违规也已经成立。BizAgentBench 的做法是搭一个可执行环境，塞进 789 份知识文档和 601 个可发现的业务工具，用确定性检查同时核验目标达成（G）、过程合规（P）和副作用保护（F）。实验发现结果导向的评测会系统性高估能力：Qwen3.8-27B 目标达成率 42.0 个百分点，严格成功率直接掉到 32.7 个百分点。我的判断：这不是一个刷榜用的基准，更像一面照妖镜，专门照"看起来完成了"的虚假成功。做业务 Agent 落地的团队值得认真读。
论文信息
- 标题：BizAgentBench: Unveiling Hidden Challenges in Deploying Long-Horizon Agents for Real-World Business（arXiv 摘要页 v1 标题为 BizBench，v2 正文已更名 BizAgentBench）
- 作者：Enhan Zhao、Yongqi Tong、Xuejun Yu、Hang Wang、Pan Wang、Yichao Wang、Di He、Jianshe Li、Wei Wu（通讯作者）
- 机构：北京大学、蚂蚁国际（Ant International）
- 时间：2026 年 10 月 14 日
- 链接：https://arxiv.org/abs/2610.20424
问题动机：只看终点的评测，漏掉了什么
客服系统的演进路线其实很清晰：FAQ 匹配 → 端到端任务型对话 → LLM 驱动的自主 Agent。到了 Agent 这一代，事情起了质的变化——它不再只是"说话"，而是会真实改变业务状态：扣款、占用额度、做出承诺，这些动作都会反过来约束后续的决策空间。
这就带来两个老基准测不到的新问题。
第一，过程中的违规不能靠结果洗白。 论文举的例子很直白：账户里有 60 美元，业务要求全程至少保留 20 美元。Agent 一上来就把 60 美元全付出去当了定金——工具接受了这笔支付，余额归零，约束瞬间被击穿。后面就算有退款把期末余额补回 20 以上，违规也已经发生过了。只看最终状态的评测，会把这种执行判定为成功。
第二，规则本身是混乱的。 真实业务里，指导文档散落在政策手册、FAQ、运营公告里，由不同团队维护、不同时间更新。过期指引和现行政策共存，看着冲突的两条规则可能只是适用范围不同——不同辖区、不同产品、不同生效期。检索到相关文档远远不够，Agent 得判断哪条规则是权威的、现行的、适用于手头这单业务的。
我之前做业务系统的时候也碰到过类似情况：线上挂着三个版本的操作手册，新人照着过期的那个操作，出了事才发现。这篇论文把这个痛点原样搬进了基准里，说实话挺狠的。
方法核心：怎么把"过程合规"变成可检查的
基准总览
图 1：BizAgentBench 的构建流水线。左列从业务数据中提取 SOP 并搭建可执行环境（文档、记录、工具三方对齐）；中间列通过后果依赖（consequential dependencies）把多个工作流串成任务，每个任务由目标、初始状态、信息源、客户场景四要素组成；上方是独立的验收标准——成功 = 目标 G ∧ 过程 P ∧ 保护 F；右列是参考执行的回放验证与专家标注，最终产出可执行环境、任务、独立评估器这套基准资产。
整个环境基于一家全球支付金融科技公司的真实工作流重建（敏感细节做了脱敏重写，但保留了决策逻辑和依赖关系）。冻结版本包含 50 个任务、789 份知识文档；Agent 手上有 9 个常驻工具，通过它们发现和调用 601 个业务能力；用户模拟器另有 10 个工具。每次运行都从独立的数据库副本开始。
| 环境要素 | 数量 |
|---|---|
| 任务 | 50 |
| 知识文档 | 789 份（正文共 598,827 token） |
| 常驻 Agent 工具 | 9 |
| 可发现业务能力 | 601 |
| 用户模拟器工具 | 10 |
| 可查询数据库集合 | 398（记录 2,994 条） |
表：BizAgentBench 任务与环境规模（原文 Table 6）。
来自真实业务的三个构建洞察
这部分是我觉得全文最值钱的地方，因为它们直接决定了这个基准和普通 toy benchmark 的区别。
过期与冲突的指引。 基准刻意在文档库里同时放了现行和历史版本的规则，都标明了适用范围和生效期。比如一张过期的保险保单，可能仍然覆盖发生在过去的某个事故——选哪条规则本身就是任务的一部分。
授权与执行有效性。 笼统的同意不能替代对具体操作的批准。批准必须覆盖实际操作及其条款、来自有权的批准人、且先于执行。还有一些要求是全程持续成立的，比如最低储备金。工具接受了操作不代表操作合规——这个区分很关键。
延迟信息与时效决策。 审核、退款、结算可能在另一个义务的截止之后才完成。论文里配送案例（附录 C.2）很典型：优先配送的预订窗口在仓库确认结果返回之前就关闭了。等确认，第一个配送截止就注定错过。等待本身有代价，这在静态基准里是建模不出来的。
评估公式：三件事同时成立才算成功
设执行历史为 \(\tau = (s_0, e_1, s_1, \ldots, e_T, s_T)\)，任务 \(i\) 成功当且仅当：
其中 \(G_i\) 查目标达成与允许的终止条件，\(P_i\) 查执行过程的要求（比如授权先于操作、连续约束在每次状态变更时都成立），\(F_i\) 查受保护对象和禁止的副作用。
几个设计细节值得注意。检查全部基于业务状态、账本、回执、事件历史，不用 LLM 当裁判，完全确定性。评估器不会把执行和 Golden trace 做轨迹匹配——不同的合法动作序列都能过，它只查业务条件本身。它还区分"执行了"和"提议了/批准了/被拒了"，防止 Agent 拿一个被拦截的非法请求当无事发生。
每个任务都有一条经过回放验证的 Golden trace（证明目标与约束联合可满足），并且用合法替代执行和针对性违规 trace 测试过评估器：该放的放，该抓的抓。比如临时击穿储备金的红线，哪怕后来余额恢复了，也必须判失败。五名研究员加一支业务专家团队做了终审，只有通过双重检验的任务才进基准。
一个完整任务长什么样
图 4：任务 Q03——客户要求核对 Acacia 九月收据并完成 Durian Trading 的开户申请。(a) 从真实业务提炼的 SOP 依赖图：两条规则适用性判断（识别已被取代的买家指令、选在审核时点有效的证据）与对账、放款、机构审批串联；关闭档案会解锁 60 美元储备金，但会冻结其中的分配结果。(b) Agent 的执行轨迹：需要在 789 份文档里找到真正适用的三份，发现六个相关工具，向用户模拟器索取客户私有信息并拿到逐笔批准，在 t=19 的截止前完成审核。关键中间步骤：先完成对账再冻结档案；费用上限从 50 提到 60 美元需要客户明确批准新条款。
这个任务里藏着一个很刁的放款决策。三条路径动用的是同一笔 60 美元储备金，50 美元审核费另计：
| 放款路径 | 净到账 | 手续费 | 延迟 |
|---|---|---|---|
| A：标准 | 60 美元 | 0 | 10 分钟 |
| B：同周期 | 50 美元 | 10 美元 | 即时 |
| C：减额 | 49.99 美元 | 10.01 美元 | 即时 |
表 5：同一笔 60 美元储备金的三条放款路径。
Golden trace 里客户明确把总费用上限从 50 提到 60 美元并批准了 B 路径，t=8 放款，t=18 审核通过，赶在 t=19 的截止前。选 A 的话资金 t=18 才到账，加上 10 分钟审核就超期；选 C 差一美分付不起审核费。你看，这不是"会不会调工具"的问题，是真金白银的取舍——等待有成本，加急有价格，而客户不允许追加充值或从无关账户转账。
实验结果：虚假成功被当场抓包
主表：目标达成和严格成功之间有条沟
| 模型 | Goal G | Process P | Protection F | 中间失败 IF | 严格成功 G∧P∧F |
|---|---|---|---|---|---|
| Claude Opus 5 | 64.0 | 96.0 | 98.0 | 4.0 | 64.0 |
| GPT-6 Sol | 64.7 | 94.7 | 100.0 | 5.3 | 61.3 |
| GLM-5.3-Flash | 48.0 | 79.3 | 87.3 | 29.3 | 43.3 |
| DeepSeek-V4.1-Flash | 46.7 | 92.0 | 96.7 | 9.3 | 43.3 |
| DeepSeek-V4-Pro | 41.3 | 85.3 | 88.7 | 24.7 | 39.3 |
| Muse Spark 1.3 | 38.0 | 94.0 | 98.0 | 6.0 | 38.0 |
| Qwen3.8-27B | 42.0 | 74.0 | 93.3 | 28.0 | 32.7 |
| DeepSeek-V4-Flash | 7.3 | 53.3 | 95.3 | 47.3 | 5.3 |
| Qwen3.5-397B-A17B | 1.3 | 46.7 | 93.3 | 56.7 | 0.7 |
| Qwen3.5-9B | 0.0 | 18.7 | 89.3 | 83.3 | 0.0 |
表 1：各模型在 50 个任务上的目标、过程、保护通过率与严格成功率（%）。Claude Opus 5 与 Muse Spark 1.3 每任务跑 1 次，其余跑 3 次取平均。
几个观察。头部模型的瓶颈在目标达成上——Opus 5 的过程合规已经做到 96.0 个百分点，卡住它的是 G 只有 64.0 个百分点。而越弱的模型，中间违规越频繁：所有模型的过程通过率都低于保护通过率（P 在 18.7–96.0 之间，F 在 87.3–100.0 之间），说明"全程守住约束"比"别碰禁区"难得多。
最刺眼的对比是 Qwen3.8-27B：只看目标达成是 42.0 个百分点，加上过程检查掉到 32.7 个百分点。近四成的"成功"是靠违规换来的。 这就是只看终点的评测会告诉你的谎话。
可靠性：跑三次和跑一次，是两回事
图 2：(a) pass^k 可靠性——k 次运行全部成功的任务比例随 k 增大快速衰减；(b) 各模型的平均资源消耗（助手轮次、阅读文档数、工具调用数）。
pass^k 的衰减曲线让我有点皱眉。GPT-6 Sol 在 k=3 时只剩 40.0 个百分点，DeepSeek-V4.1-Flash 26.0 个百分点，GLM-5.3-Flash 22.0 个百分点，Qwen3.8-27B 只剩 10.0 个百分点，DeepSeek-V4-Flash 和两个 Qwen3.5 直接归零。单次成功率掩盖了方差——这对真实部署是个很现实的警告：你不能指望一个三次里只对一次的 Agent 去碰支付业务。
右表还有个反直觉的点：调用多不代表进展多。DeepSeek-V4.1-Flash 平均每次运行 191.3 次工具调用，是 Golden trace（111.8 次）的 1.71 倍；GLM-5.3-Flash 只用 118.3 次调用、读 9.4 份文档就拿到了同样的严格成功率，而前者读了 20.1 份。Qwen3.5-397B-A17B 更夸张，216.4 次调用只换来 150 次运行里的 1 次成功。
消融：信息获取才是大头
| 信息条件 | 严格成功率（%） |
|---|---|
| 默认（自己检索+多轮问客户） | 43.3 |
| + Gold-doc（直接给适用文档） | 50.0 |
| + 客户信息全披露（开场白直接给全） | 70.0 |
表 2：DeepSeek-V4.1-Flash 在三种信息条件下的严格成功率。
看到这组数我愣了一下。把检索环节直接免掉（Gold-doc），只涨 6.7 个点；但把客户私有信息在开场白里全给齐，直接冲到 70.0 个百分点。说明真正的难点不在找文档，而在向客户问对问题、并把这些约束条款一路记住。这是很业务的一个发现——规则摆在那儿不难查，难的是客户自己都没主动说的那些约束。当然，即便信息全给，还有 30.0 个百分点的任务做不下来，规划和合规执行本身的硬骨头还在。
预算敏感性：冗余调用的代价可以量化
| 工具调用上限 | 严格成功率（%） |
|---|---|
| 1.2 倍 Golden 调用数 | 0.7 |
| 1.5 倍 | 6.7 |
| 2.0 倍 | 26.7 |
| 不限 | 43.3 |
表 3：按 Golden trace 调用数做回溯性截断后的严格成功率。
哪怕给到两倍于参考执行的调用预算，也有一半多本来能成功的运行被掐死。这个实验设计得挺聪明，把"Agent 的信息搜索和反复确认到底浪费了多少"直接换算成了成功率损失。
轨迹分析：长轨迹 ≠ 有效进展
| 模型 | 工具调用 | 重复数据库读 | 工具报错 | 达成目标但违规 |
|---|---|---|---|---|
| DeepSeek-V4.1-Flash | 191.3 | 16.4 | 2.0 | 5/150 |
| Qwen3.8-27B | 129.2 | 7.8 | 4.2 | 14/150 |
| DeepSeek-V4-Flash | 168.0 | 23.7 | 8.2 | 3/150 |
| Qwen3.5-9B | 187.2 | 16.5 | 101.6 | 0/150 |
表 4：强弱模型的执行轨迹统计（每次运行均值）。
Qwen3.5-9B 每次运行收到 101.6 条工具报错，其中 71% 是因为它试图查不公开的资源；它只读了 6.4 份不同文档（对照组 20.1 份）。这已经不是规划问题，是连环境的边界都没摸清。而 DeepSeek-V4.1-Flash 有 5 次运行达成了目标但违规：4 次是中途击穿现金储备下限后又补回来，1 次是没拿到批准就先执行被拒。附录 D.3 里那个 Q18 案例特别典型——账户从 60 美元直接付空，靠后续退款和调整把期末余额做回 28.66 美元，目标和期末储备检查全过，只有翻执行历史才能抓到这个窟窿。
这些案例就是这篇论文存在的意义：只看 G，这些运行全是"成功"。
模拟器鲁棒性
图 3：固定 Qwen3.8-27B 作为任务 Agent，换四个不同模型当用户模拟器，严格成功率在 30.7–36.0 之间，与默认设置的偏差最大 3.3 个百分点——评测结果对模拟器选型不敏感。
做带用户模拟器的基准，绕不开"测的是 Agent 还是模拟器"的质疑。作者做了两件事回应：一是修订提示词明确了客户动作的次序和交还控制权的时机，协议违规从 50 个任务里的 4 个降到 0；二是换模拟器模型重跑，分数波动很小。这个验证做得比多数同类工作扎实。
我的判断
亮点是真的亮。 这个基准最硬的贡献不是又搭了一个环境，而是把"过程合规"从一句口号变成了确定性可检的条件——G∧P∧F 的拆解、连续约束在每次状态变更时的核验、用针对性违规 trace 反向测试评估器，这套东西在 τ-bench 家族和各类企业基准里都没做到这个深度。149 次违规成功的抓包案例（比如 Q18 那种期末账面干净、中途击穿的），直接证明了结果导向评测的系统性高估，这个证据本身就值回票价。
但也有几个问题值得追问。 一是规模：50 个任务，统计噪声不可忽略，Opus 5 和 GPT-6 Sol 之间 2.7 个点的差距很难说有多稳。二是 Golden trace 平均 111.8 次调用、任务间方差巨大（51–282），任务难度可能严重不均，报告里没有按难度分层的分析。三是评估全部依赖人工构建的确定性检查，覆盖度取决于作者能想到多少违规模式——未知的违规类型照样会漏。说实话这块作者自己也没法完全解决，这是所有规则式评估器的天花板。
对工程的启发很直接。 如果你在做业务 Agent，这篇论文给了三个可以立刻抄的作业：
- 把连续约束做成事中检查，而不是事后审计。 储备金、授权、额度这类要求，必须在每次状态变更时核验，不能等终态对账。论文里那些被拦截的"先执行后批准"尝试（工具返回 CUSTOMER_APPROVAL_REQUIRED、无副作用）也提示：工具层的硬性前置校验比指望模型自觉靠谱得多。
- 投资"问客户"的能力，回报比"查文档"高。 消融实验里客户信息全披露涨了 26.7 个点，Gold-doc 只涨 6.7 个点。主动追问约束、并把条款在整个工作流里保真传递，是眼下最值得做的能力。
- 警惕用调用量当工作量。 191 次调用 vs 112 次参考调用、一半以上是数据库查询和文档阅读，其中还有 16 次是完全相同的重复读——做成本预算和效率优化时，先把冗余读和无效导航清掉。
收尾
BizAgentBench 与其说是一个新榜单，不如说是一次评测观念的纠偏：在高风险业务里，"怎么做到的"和"做没做到"同等重要。64.0 个百分点的头部模型严格成功率、跑三次只剩 40.0 个百分点的可靠性，这两个数摆在一起，基本就是在说——今天的 Agent 离真正接管支付级业务，还差得很远。
接下来的悬念是：这些过程检查能不能从人工构建走向自动合成？50 个任务撑不起训练信号，但如果 G/P/F 这套检查器能规模化生成，它就不只是评测工具，还会是 RL 的奖励来源。这可能是这个基准更长远的价值。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我