关于ZAKER Skills 合作
虎嗅APP 10分钟前

当 AI 支付代理出错时,谁背锅?- 代理时代需要的新监测维度

本文来自微信公众号: 鑫卉正在理解 ,作者:鑫卉

自主型 AI 出现之前,我和研发同事遇到过的比较典型的责任归属压力场景:

业务预期需要的一个能力上线了,但是上线后发现了问题,被业务方挑战说损失了多少投入的广告费及转化收入。然后做复盘,做核心归因,接下来继续优化验收流程,优化监测效率和手段。

这个场景下,是可以找到一个核心的 " 谁的问题 " 的,至少代码可以找到,人可以决策回滚、还是迭代一个优化。

自主型 AI 出现之后,它可以作为智能支付代理,也可以应用解决以上场景风险。这时,同场景下的中间任何环节代理出错,会变成:哪个代理错了,谁管理的代理?

当支付由自主代理发起时,确定责任归属变得显著复杂。

最近分析的一份 IFM 说明里重点点名的问题就是这个问题,学术上的语言叫 " 授权可追溯性失败 "(Authorization traceability failures)。

自主型 AI 出现之前,常规的规避风险手段是监测。

我们会做很多技术指标、产品运营指标去观测,会建立稳定的保障机制,例如,上线前的验收流程约束;设计多长时间内失败多少笔的预警能力,严重会立马人工介入;高峰期期严控上线机制……

但当决策主体从 " 人 " 变成 " 代理 ",传统的监测框架就失效了。

在传统的产品中,同产品同用户行为路径下,支付结果(延迟结果)是二元的,要么成功、失败。支付代理的情况下,会因为上下文依赖,概率性导致不确定,这笔最终是导向成功还是失败。

在传统产品中,出现问题,问题被响应的速度越快越好,第一时间就发现。代理支付下,比如指令就是要代理等待一个价格更合适的时机,这个时间的出现节点,才真正决定问题响应速度。

更直接的一个对比是,在传统产品中,不行就回滚,版本是明确定义的,动作是彻底的。但是支付代理的情况下,代理的决策本身是连续的、状态以来的,很难界定 " 上一个版本 ",往哪回滚也是问题。

那代理时代需要的新监测维度是怎样的。

这份 IFM 说明给了对应的框架,把支付架构分成了三层,分别是意图层,授权层、结算层。代理时代需要的新监测维度是怎样的,这个问题也可参考这个框架。

报告本身要显得很专业,直接套用的话不好理解,接下来我把理解的,翻译成我能输出的通俗表达。

第一层:意图层

这一层是说 AI 代理到底能多 " 懂我 "。

假设我给代理说:你是一个采购代理,你要在 7 天内,自行预测在价格最低的情况下下单支付。我的真实意图其实更偏向价格最低,时间是其次。

如果 AI 代理理解成重点是更偏时间更快,最终下单支付 10 次支付里,代理按照时间更快走了 6 次。这就会不符合我的预期。此时,也发现我的目标设定就不合理,没有明确说更偏重什么。

这里还涉及我有几个代理,比如我有一个采购视角价格最优的代理,还有一个是财务同事视角价格符合预算的代理,这两个代理要是冲突了,也会出错。

针对意图层,对照以上至少可以监测的维度包含:目标偏离程度、边界约束触达率、多代理冲突监测。

第二层:授权层

这一层是说 AI 能做什么,什么时候能做。

还是第一层意图层的假设下,真下单错了,找到下单的支付代理了,需要确认下,这个代理确实被授权了吗,还是代理按照自主意志执行的。如果我存在明确的指令,比如有日志记录,支付代理在 2026 年 7 月 12 日下午 3 点请求是否做授权,1 分钟后我做了授权确认,那追溯到这个日志,代表代理是在授权下执行的。如果没有,一个没有授权的代理可以操作支付这么重要的涉及钱的行为,那性质就不一样了。

为了安全,设计支付代理可能需要不止一次请求授权,有前置授权了情况下,这次授权也可以对比下历史情况,比如以前是追求价格更低,大部分都低于 4 元,这次授权允许在 400 元上限内下单。相差 10 倍,是个可能授权异常的信号。

这种异常为了安全支付,就需要人工介入,如果频繁人工介入判断,那只能代理就不智能了,失去了代理的意义;如果判断次数过少,容易过度信赖代理,只能事后发现风险。

基于以上,可以至少做的监测维度包含:授权链的完整性(要有明确的授权责任可追溯)、异常授权情况(是否有异常情况)、人机交接频率(要设定一个适配具体场景诉求的频率)。

第三层:结算层

这一层是说 AI 做到了吗?做对了吗?

在传统支付里,你支付了,是说你输入了支付密码这种最终决策动作。支付成功了,支付者可以从两个地方感受到。一个是完成了最终决策动作后收到了明确的结果通知,告诉你支付成功。一个是你没收到结果,而是被提示以银行通知为准,此时你去银行账户看到确实出去了一笔钱,你也会认为支付成功了。

这一层里,结算这个词在本文的场景下就简化理解成资金支付了吗,是从预设的付钱账户到了收钱账户吗。在这一层要监测的内容,就是这两问题对应的内容。

当支付代理完成输入支付密码这种动作,可能是不符合预期的支付成功。

比如你要买的是商品 A,发现对商品 B 下单了。那就是说这笔交易最开是授权时,你明确了是买商品 A,但是支付代理在自主处理环节就改成了商品 B,导致交易从授权到最终支付的记录是不一致的。说明支付绕过了一些东西。

再比如,购买的确实是商品 A,但预期你授权的是从银行 A 的甲账户出钱,发现支付成功了,这个账户并没有出现。人工介入检查发现是从 B 账户出的钱。

再再比如,还是购买的确实是商品 A,但你要求只可以从供应商 1、2、3 中购买,也就是资金流向如果有只能去这三个,但是发现资金去了一个不在预期内的供应商 4。

这一层可以做的监测是什么?可以监测交易在不同的系统的记录是否一致,不一致就导致预期买 A 换成买 B 了还不知道;可以监测资金流动是否异常,出钱账户符合预期吗,收款方符合预期吗,避免代理自主 " 优化 " 引入了新风险。

个人觉得这个框架不一定是最准确答案,但是至少给了一个与现状支付基础设施架构划分层一致的参考。

以前是监测交易结果,代理时代需要监测维度本质是监测 " 代理怎么想的 " ——监测代理理解对了吗,请求授权了吗,授权后自行改了吗,还没执行在等什么……

随着支付代理的应用,及规则、政策的制定和发布,支付监测的维度更有参考依据,但我目前的认知是监测框架应该不会有大变化,有迭代会继续更新。

关于提及的 IFM 的说明,为了更完整的呈现,会单独一篇解读。