银行里的智能体,考的不是算得对

arXiv 2610.39733 是一篇 43 页的长文,作者只有一位。它做的事不复杂:造两家模拟银行机构,摆上 50 个任务,让四款模型各跑八次,一共 1600 次尝试,然后一笔一笔地看账。

任务的形态分两种。单轮的 25 个任务放在 Ashbrook,是一次性指派,没有后续交互,但有些任务要求智能体主动向内部部门索取缺失材料才算办完。多轮的 25 个任务放在 Ridgeline,智能体要协助一位模拟客户经理 Marcus,他会补信息、在审批队列里批或拒、还会中途改指令。

评分是两套并行的:一套是可执行的确定性检查,直接查记录下来的动作与状态;一套是模型按评分表做的判断,还要考虑是否存在同样有效的替代解法。主裁判是 GPT-6.1 Sol,另配 Claude Opus 5.5 做对照裁判,两者判断禁用工具访问,只能读保存下来的证据包。两人在单轮标准上的一致率 97.0%、多轮 96.4%,完整任务成败的一致率分别是 97.8% 与 98.6%。

同一批模型,换一条赛道,排位就换人每款模型每任务跑 8 次,单轮与多轮各 800 次尝试单轮赛道 · Ashbrook25 个任务,一次性指派GPT-6.1 Sol 55.0% 居前Claude Opus 5.5 42.0%Gemini 4 Argon 38.5%多轮赛道 · Ridgeline25 个任务,与模拟员工来回Claude Opus 5.5 44.0% 居前GPT-6.1 Sol 42.5%论文认定差异并不显著完成率只是其中一本账零分尝试占比:单轮 Grok 60.5%、Opus 56.0%、Gemini 47.5%、Sol 35.5%多轮里 Grok 在 22 个任务上至少过一次,却没有一个任务八次全过一次做成与次次做成,是两件不同的事来源:arXiv 2610.39733,四款模型 1600 次尝试
图|完成率按「完整通过」计,被强制项卡住的尝试直接归零,这也是零分占比偏高的原因。

两条赛道,两拨赢家

单轮赛道按完整通过率排:GPT-6.1 Sol 55.0%、Claude Opus 5.5 42.0%、Gemini 4 Argon 38.5%、Grok 4.7 34.0%。多轮赛道换了一拨:Opus 44.0% 居前,Sol 42.5%,Gemini 与 Grok 都停在 36.5%。论文自己也写明,多轮的这些差异在统计上并不显著。

比排位更值得看的是零分占比。单轮里 Grok 有 60.5% 的尝试一分未得,Opus 56.0%、Gemini 47.5%、Sol 35.5%。原因是评分表里有一批强制项,任何一项没满足,总分直接归零。这个设计把「差不多做完了」和「合规地做完了」区分开来,代价是完成率看起来很难看。

还有一项指标指出了另一个方向的问题:Grok 在 22 个多轮任务上至少成功过一次,但在任何一个任务上都没有八次全过;Sol 有 5 个任务八次全过。一次做成与每次做成,在采购系统时是两个完全不同的承诺。

判对了,不等于办成了

论文把单轮 800 次尝试按「主决策是否被接受」与「必需动作是否完成」做了联合统计。结果是:主决策被接受的 574 次尝试中,401 次把必需动作做完了,173 次没有——约 30.1%,分散在 19 个任务上。分模型看,Grok 是 37.8%,Opus 30.7%,Gemini 27.6%,Sol 26.3%。

这个数字是整篇论文里最该被记住的。它说明失败不发生在判断环节:模型算对了该退多少钱、该给谁分多少,但在把这些决定变成完整、合规、留痕的动作时掉了链子。

三种具名失误都很具体。一是重复收费:在 Basalt Ridge 的商户退货对账任务里,净额里已经扣过手续费,模型又单独收了一次,八次尝试里 Gemini 出现 7 次、Grok 8 次、Opus 5 次、Sol 7 次,结果客户实际到账少了 344.20 美元。二是总额对但人头错:三合伙人按 40%、35%、25% 分配,总额确实等于 4 万美元,但有一笔 275 美元的未收应收被错误地排除在权益之外,导致三人各自拿到的数字全错。只校验总额的评分会放行这种错误,作者的账是逐人查的。三是在审批未决时付款。

主决策被接受之后,必需动作仍可能没做完单轮尝试中主决策被接受:574 次其中 401 次把必需动作做完了,173 次没有 —— 约 30.1%重复收费同一笔手续费扣过一次又收一次实际到账差 344.20 美元总额对,人头错三人的份额算错总付款额仍然正确只查总额会放行审批未决就付款255 次执行尝试里41 次与批准不符全部判为零分反方向的失误同样存在:为守住机密,把本可以做的工作也一并搁下一个任务里,某款模型只完成了八分之一的客户简报
图|三类失误都发生在执行层:决定是对的,错在动作、金额或授权时机。

授权不是事后追认

第三条失误是这篇论文对企业最有价值的部分。在多轮任务里,智能体必须先经审批队列拿到批准才能动钱,而「提交请求」不等于「已获批准」。审计的 9 个多轮任务中有 7 个出现了审批不符,合计 255 次执行尝试里 41 次不符,这 41 次全部判为零分。

一个例子记得很细:9 点 25 分经理批准了 43,650 美元的请求,9 点 35 分智能体提交了 51,800 美元的新请求,9 点 37 分它读到了新请求仍处于待批,9 点 38 分它却把 51,800 美元转了出去,9 点 42 分经理才批准这笔钱。事后批准不追溯授权先前动作,这次尝试判零,同时没过权限、文档与状态诚实三项。

反方向的失误同样存在。有的智能体为了守住机密信息,连本可以做的工作也一并搁下:在 Juniata 这个任务里,某款模型只完成了八分之一的客户简报;在 Brenneman 任务里,挂起资金后还须安排受益人核实,Sol 八次全部做了后续,另一款模型只做了两次。

能给工程团队的三条提醒

其一,把「完成」当成独立指标。判断正确率、动作完成率、合规率这三本账在实验里明显不相关,混在一起看只会得到平均值,而平均值在这里没有意义。

其二,权限检查要放在动作执行之前,并且要能被外部复核。41 次审批不符全部发生在「读到了待批状态仍然执行」的路径上,这说明模型不是没看见状态,而是没有把状态当作硬约束。

其三,冷水要说足。这篇论文的作者是单人,环境、可执行评分器与完整轨迹都不公开,理由是防止污染,代价是外部无法复现;主裁判 GPT-6.1 Sol 本身也在被测名单上,自评偏差无法排除;每个任务八次尝试,对银行这种长尾流程来说仍是小样本。多轮赛道的差异作者自己都写明不显著,引用时不该当成定论。

把这些放在一起看,这份基准真正的贡献不是又一份排行榜,而是把「判对」和「办成」这两件事在数据上分开了。对企业里正在上智能体的团队来说,需要被验收的恰恰是后者。