有 Skill 平均高 10.31 个点：蚂蚁用 18 道仓库任务评支付集成

有 Skill 平均高 10.31 个点：蚂蚁用 18 道仓库任务评支付集成

蚂蚁集团的 Alipay-PIBench（支付宝支付集成基准，用来评编码智能体能不能把支付产品接到已有业务仓库里），arXiv 提交日 2026 年 7 月 16 日（2607.14573）。作者 Shiyu Ying、Xuejie Cao、Yingfan Ma、Yuanhao Dong、Wenyu Chen、Bowen Song、Lin Zhu，单位是 Ant Group，通讯邮箱 lin.zhulin@antgroup.com。代码在 https://github.com/inclusionAI/PIBench 。许可证是 CC BY 4.0。

支付集成不是多写一次 API。智能体要选对产品，把密钥和签名留在服务端，接上前后端，核对应答，并且只在可信确认之后改本地订单。评测把这件事拆成功能闭环和风险加固两段，主指标是规则通过率 RPR。

九个产品，十八道题

一道题是一个产品加一种场景。九个产品各有 Basic 和 Advanced，一共 18 道。Basic 叫功能支付完成：目标支付宝产品还没接上，业务仓库可能已有别的支付，也可能完全没有。Advanced 叫风险加固：核心支付路径已经在，单独准备的快照上只考安全边界。两段是递进的受控任务，不是同一仓库上的前后两步。

智能体看到的是初始仓库和一段自然语言需求，交回改过的仓库。评分侧另有该场景的规则、从规则导出的确定性检查，以及需要语义判断的补充项。产品在任务元数据和指令里写明，接口依据支付宝开放平台文档。

表 1。初始支付一列，叉表示仓库里还没有支付，勾表示已有别的支付。Basic、Advanced 是规则条数。

Basic 通常要同时改支付配置、服务端下单与确认、本地业务状态，以及面向应用的入口。Advanced 在此之上考重复通知、重复确认、本地状态不一致、不安全退款、异步通知验签不足。

以 Laravel 健身房会员的 JSAPI Basic 为例。仓库已有套餐、下单和查询，以及支付宝小程序页，但停在待支付订单。指令要求补上小程序支付，而不是另起一套 API。合格实现必须在服务端创建交易，返回大小写敏感的 tradeNO 供小程序调起，并且只有服务端可信结果才能推进订单和会员履约。无效通知要拒绝，重复成功通知要幂等，客户端回调不能决定最终支付状态。

五种信号，集成和端到端权重为 2

每条规则落到静态分析、单测、集成测试、端到端或大模型辅助审查之一。

静态检查看 SDK 或 OpenAPI、凭证、支付入口、验签、字段绑定、状态或退款模型。安全题还看通知验签钩子、假成功旁路、幂等或终态保护、退款或查询、密钥管理。它只说明结构像不像，不证明跑得通。

单测只在该题有本地测试时使用。集成测试看应用能否启动、产品支付流、后端状态，以及和网关或确定性夹具的交互。安全题覆盖重复通知、重复请求、错误签名、错误金额、异常交易状态和退款边界。有的题用本地模拟支付宝网关，不是一律打真实沙箱。端到端看入口是否可达、后端是否被调用，以及成功、失败、取消、处理中等可见状态。

大模型辅助审查看产品映射、服务端签名与确认、状态机是否自洽、安全逻辑放在哪一侧、跨组件是否接上。安全题还看有没有处理指定风险，而不是只留快乐路径。论文引用 RuVerBench，承认智能体编码里的规则核查仍然有噪声。可执行检查仍是主信号，大模型审查是补充。

RPR 是被满足的规则占比。一次配置是某个模型加一种 Skill 条件：没有 alipay-payment-integration，或装上它。单题单次试验先按方法算通过率，再加权。静态、单测、大模型辅助的权重是 1，集成和端到端是 2。分母只加这道题实际用到的方法，所以不同题目的方法集合不同，RPR 仍在 0 到 1。没通过和评估器报错都记 0。评估器错误另外留作诊断。

重复试验先对同一道题取平均，再对项目—场景做宏平均，规则条数多的题不会占更大权重。正文没有写明每道题重复几次。

六个模型，装上 Skill 后再比

环境是 Claude Code 2.1.200。六个模型：Claude Opus 4.8、GLM-5.2、Kimi K2.7 Code、DeepSeek-V4-Pro、MiniMax M3、Qwen3.7-Max。论文给前五个标了官方文档，Qwen3.7-Max 不在这句名单里。每次试验用新的 Docker，文件、依赖缓存、服务状态和评估输出不带到下一次。模型、项目、场景、Skill 条件的组合里，任务和评分流程固定。

能力比较用的是装上 Skill 之后的结果。总平均 RPR：Claude Opus 4.8 为 91.37%，GLM-5.2 为 87.12%，Kimi K2.7 Code 为 82.18%，Qwen3.7-Max 为 75.78%，DeepSeek-V4-Pro 为 75.23%，MiniMax M3 为 68.58%。最高和最低差 22.79 个百分点。

达到 90% 的产品—场景格子：Opus 13/18，GLM 10，Kimi 6，Qwen 和 DeepSeek 各 2。Opus 在 Advanced 应用内支付上掉到 65.73%。MiniMax 从 Advanced 预授权的 46.54% 到 Basic 扫码支付的 98.00%。

应用内支付总平均最低，58.65%。只有 Opus 超过 65%，为 71.30%。GLM 62.71%，Qwen 55.39%，DeepSeek 51.12%。原应用是线上预约、线下结算，没有现成的线上支付流，智能体得自己加入口、后端状态和确认。预授权总平均 69.76%，单格从 42.96% 到 98.67%，拉开模型，而不是所有模型都低。

Basic 和 Advanced 不是同一条难度排序。Opus 两边是 92.58% 和 90.17%，GLM 是 87.05% 和 87.19%。Qwen 的 Basic 是 70.88%，低于 Advanced 的 80.67%。MiniMax 相反，Basic 70.20%，Advanced 66.97%。能把支付流搭起来，和能守住资金安全，是两件事。

Skill 不是每格都涨

对照只改一件事：编码智能体能不能读到 alipay-payment-integration。任务、仓库、评估器不变。108 个模型—产品—场景格子里，平均 RPR 高 10.31 个百分点。101 格为正，4 格为负，3 格视为不变。Basic 平均多 11.27 个点，Advanced 多 9.35 个点。每个模型的平均增益从 Opus 的 +6.81 到 Kimi 的 +15.51。

无 Skill 基线低于 40% 的格子平均涨 17.64 个点，基线在 80% 到 100% 的格子平均只涨 4.52 个点。文中点名：Kimi 的 Advanced 预授权从 31.43% 到 79.43%，加 47.99 个点；DeepSeek 的 Basic 条码从 58.33% 到 96.67%，加 38.33 个点。

下表只保留每个模型在该场景下九个产品的平均 RPR（%）。Δ 是百分点，不是相对变化。

3 个不变格都在 Opus 的 Basic：手机网站、订单码、扫码，Δ 为 0。4 个下降格都在 Advanced：Kimi 的手机网站 −3.7，DeepSeek 的电脑网站 −1.8，MiniMax 的手机网站 −2.0、预授权 −5.3。论文写下降集中在安全边界，而不是稳定变差；抽查轨迹后，把这些格子归到单次试验的运行中断或实现失败。分产品的其余格子在原文表 2，这里不逐格重排。

第二个效率指标是输出 token（千）除以 0 到 1 的平均 RPR。先对九个产品平均，再算有 Skill 相对无 Skill 的比。12 个模型—场景比都低于 1，范围 0.69 到 0.96，均值 0.81。单个产品仍有高于 1 的格子，所以效率提升不普遍。这个数只看输出 token 和规则完成度，不是集成耗时或费用。

结构写对了，流程仍可能断

有 Skill 条件下，方法内部的 RPR 先不加权，再对模型平均。Basic 的静态平均 92.79%，集成 73.16%，端到端 78.24%。Basic 应用内支付的静态是 83.0%，集成只有 38.6%。SDK、入口、字段和状态模型可以都在，支付流仍然没接上。

Advanced 的端到端平均 97.03%，大模型辅助只有 61.05%。Advanced 订单码的端到端是 100%，大模型辅助是 58.6%。测过的入口能走通，资金安全和状态一致仍可能没有证据。

反过来也有。Basic 预授权的大模型辅助是 96.4%，端到端是 39.3%。语义上看着像产品要求，应用侧流程仍失败。

这些方法覆盖的规则子集不同，不能拿来比哪个评估器更严。它们用来定位失败落在结构、执行还是支付领域。

限制

结果只覆盖文中的支付宝开放平台产品、18 道题和这六种编码智能体配置。部分集成测试用本地模拟网关或确定性夹具，不是统一的线上沙箱。大模型辅助审查有噪声，失败和评估器错误在 RPR 里都记 0。每题重复次数没有写明。Skill 带来的是配对条件下的正相关，下降格被归到个别试验失败，不是因果实验的全部对照。输出 token 比不能当成成本。论文把下一步放在更多模型、更多仓库和更长的可执行支付流程，没有声称这 10.31 个点可以外推到别的支付渠道。

蚂蚁，Shiyu Ying、Xuejie Cao、Yingfan Ma、Yuanhao Dong、Wenyu Chen、Bowen Song、Lin Zhu，Alipay-PIBench: A Realistic Payment Integration Benchmark for Coding Agents，2026-07-16，https://arxiv.org/abs/2607.14573