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

本文来自微信公众号： 鑫卉正在理解 ，作者：鑫卉自主型AI出现之前，我和研发同事遇到过的比较典型的责任归属压力场景： 业务预期需要的一个能力上线了，但是上线后发现了问题，被业务方挑战说损失了多少投入的广告费及转化收入。然后做复盘，做核心归因，接下来继续优化验收流程，优化监测效率和手段。 这个场景下，是可以找到一个核心的“谁的问题”的，至少代码可以找到，人可以决策回滚、还是迭代一个优化。 自主型AI出现之后，它可以作为智能支付代理，也可以应用解决以上场景风险。这时，同场景下的中间任何环节代理出错，会变成：哪个代理错了，谁管理的代理？ 当支付由自主代理发起时，确定责任归属变得显著复杂。 最近分析的一份IFM说明里重点点名的问题就是这个问题，学术上的语言叫"授权可追溯性失败"（Authorization traceability failures）。 自主型AI出现之前，常规的规避风险手段是监测。 我们会做很多技术指标、产品运营指标去观测，会建立稳定的保障机制，例如，上线前的验收流程约束；设计多长时间内失败多少笔的预警能力，严重会立马人工介入；高峰期期严控上线机制…… 但当决策主体从"人"变成"代理"，传统的监测框架就失效了。 在传统的产品中，同产品同用户行为路径下，支付结果（延迟结果）是二元的，要么成功、失败。支付代理的情况下，会因为上下文依赖，概率性导致不确定，这笔最终是导向成功还是失败。 在传统产品中，出现问题，问题被响应的速度越快越好，第一时间就发现。代理支付下，比如指令就是要代理等待一个价格更合适的时机，这个时间的出现节点，才真正决定问题响应速度。 更直接的一个对比是，在传统产品中，不行就回滚，版本是明确定义的，动作是彻底的。但是支付代理的情况下，代理的决策本身是连续的、状态以来的，很难界定“上一个版本”，往哪回滚也是问题。 那代理时代需要的新监测维度是怎样的。 这份IFM说明给了对应的框架，把支付架构分成了三层，分别是意图层，授权层、结算层。代理时代需要的新监测维度是怎样的，这个问题也可参考这个框架。 报告本身要显得很专业，直接套用的话不好理解，接下来我把理解的，翻译成我能输出的通俗表达。 第一层：意图层 这一层是说AI代理到底能多“懂我”。 假设我给代理说：你是一个采购代理，你要在7天内，自行预测在价格最低的情况下下单支付。我的真实意图其实更偏向价格最低，时间是其次。 如果AI代理理解成重点是更偏时间更快，最终下单支付10次支付里，代理按照时间更快走了6次。这就会不符合我的预期。此时，也发现我的目标设定就不合理，没有明确说更偏重什么。 这里还涉及我有几个代理，比如我有一个采购视角价格最优的代理，还有一个是财务同事视角价格符合预算的代理，这两个代理要是冲突了，也会出错。 针对意图层，对照以上至少可以监测的维度包含：目标偏离程度、边界约束触达率、多代理冲

本文作者：虎嗅APP