Emil Chetty：让支付智能体在客户授权的范围内行动

你是否厌倦了反复为编码智能体点击批准，或多次授予助手权限？Emil Chetty 说，行业承诺为用户减少复杂性，却常常交付了一串审批请求。结果是客户盯着流程，而不是让助手真正完成工作。

Chetty 负责 Wise 的数据与 AI 产品。他介绍了面向个人的 Wise 账户、面向企业的 Wise Business，以及供金融机构使用的 Wise Platform。其支付网络连接多个国家的本地银行和国内支付系统。

Chetty 说，Wise 上一年处理了 2430 亿美元的跨境交易，服务近 1900 万活跃客户，并持有 80 多张牌照。国家、货币和受监管实体各有不同要求；在前面加一个聊天机器人并不会让这些义务消失。

监管机构仍要求 Wise 知道客户授权了什么、控制资金流向并解释结果。Chetty 问，如何既让智能体拥有有用的自主权，又让金融机构对其行为负责？

设想一位小企业主要求智能体处理本周已批准的供应商付款、核对结果并报告例外情况。企业主希望任务完成，而不是逐一批准每次查询、读取文件和状态检查。

一长串审批提示让人变成了 API。Chetty 说，编码智能体已通过权限规则、分类器和沙箱减少类似摩擦。这些控制措施很重要，但金融交易提出了更具体的授权问题。

对于付款，问题不仅是某个行为看起来是否安全，而是客户是否授权按这些条款向这个收款人付款。评估和智能体运行框架仍然有用，却不能替代客户同意这项任务的证据。

Chetty 提议将客户意图转化为不可变的协议。可信软件准备具体方案，客户审核并确认权限范围，服务负责执行已确认的版本。智能体可以选择如何完成任务，但不能改变授权内容。

当执行路径变化但不影响约定的支付条款时，智能体可以重新规划。如果基本条款改变，服务就向客户提交修订方案并请其决定。客户批准任务，智能体选择步骤，可信软件执行协议。

在一个假设示例中，企业主 Sarah 让智能体处理供应商付款。智能体先取得有限的只读权限来收集上下文；可信软件从记录中确定供应商、银行信息和金额。准备工作本身并不授权转账。

Sarah 看到一份草稿，列出三家供应商、总计 775 美元的付款、费用额度以及智能体可以作出的决定。缺失或冲突的信息必须在确认前解决。示例幻灯片列出的上限为 780 美元，包含约定费用。

Chetty 将同一任务分为两个视图：供人阅读的承诺，以及服务可以校验的机器可读记录。Sarah 确认并验证某个具体版本；该版本成为不可变的授权任务，而不是由智能体推测她可能想要什么。

可信权限配置服务只授予已确认任务、Wise 批准的能力以及 Sarah 当前权利三者的交集。支付工作进程可以请求许可范围内的付款，对账工作进程则可以读取发票和结果。智能体可以调整计划，但不能扩大自身权限。

重试不应产生重复付款。Chetty 介绍了共享支付状态：崩溃或重启后，工作进程查询已有的支付任务，而不是创建第二笔付款。如果报价过期或发生变化，智能体可以准备替代方案，但必须请 Sarah 批准新条款。

Chetty 概述了用于配置智能体、检查不可变任务、控制模型访问以及注册并记录工具的网关。工作进程检查自己能使用哪些工具，再调用支付服务，始终受原有边界约束。他将其描述为 Wise 的思路和架构草图，并未证明每个细节都已投入生产。

假设发票中有提示注入，声称银行账户已变更，而智能体相信了它。这种判断无法修改已确认的任务。下游支付服务会拒绝未经批准的收款人，模型也不能重写协议或为自己扩大权限。

最终的证据链应能回答谁授权了任务、智能体能做什么、付款发生了什么、哪些行为可以停止以及谁负责。Chetty 最后的原则是：让客户授权任务，让智能体选择步骤，由服务执行协议。