用户让AI“帮我买杯咖啡”，从提出需求到下单、确认支付，可能几分钟就结束了。
但如果换成一句“每天上午10点帮我买杯咖啡”，事情就复杂了一些。
支付宝阿宝最近上线的“异步任务”提供了一个很直观的例子。用户可以提前建立“咖啡闹钟”“打车闹钟”，设置执行时间和周期。到了指定时间，阿宝再发起服务，根据当时的商品、行程和价格进入后续交易流程。
今天建立任务，明天才真正执行，任务已经跨出了当前这轮交互。
异步Agent并不只是定时执行。任务可以脱离当前会话继续运行，在未来返回结果或者恢复执行。
查资料、生成内容这类任务，即使今天没有完成，明天继续往下做通常也不会产生资金后果。
支付没有这么简单。
昨天留下的是一个任务，今天真正执行时，商品、价格、用户需求和资金权限都可能已经变了。如果付款过程中发生网络中断，Agent甚至可能不知道上一笔钱究竟有没有付出去。
异步Agent把一个原本集中在较短时间里的交易过程，放进了一条可以等待、恢复甚至重试的任务流。
异步Agent，让任务不必在当前对话里结束
最常见的Agent任务通常从用户的一句话开始。
“帮我订张票。”
“给我叫辆车。”
“买杯咖啡。”
Agent理解需求、调用相应服务、获得结果，这一轮任务很快结束。即使中间调用多个工具，对用户来说，它们仍然发生在一次相对连续的交互里。
异步任务不必在这一轮交互里结束。
用户可以先建立任务，Agent保存已经获得的信息，然后继续运行或者进入等待。等到某个时间点，或者某个条件满足以后，再接着处理。
时间只是最容易理解的一种触发方式。
“每天10点买咖啡”按时间触发；“商品补货以后再买”需要等待库存变化；机票价格达到预设条件、账单到期、审批完成，也都可能成为任务继续执行的条件。
用户不需要一直守着Agent，也不需要条件满足以后再把之前的需求重新说一遍。
要做到这一点，任务之前的状态需要保留下来。
用户要求什么，已经完成了哪些步骤，还缺什么条件，下一次应该从哪里继续，都不能随着当前对话结束而丢失。
一些Agent运行框架已经提供了这类能力。例如LangGraph可以通过持久化和检查点保存运行状态，使任务在中断以后从已有状态继续执行。
异步Agent和普通定时器的区别，在于它恢复以后还可能根据新的环境继续判断和执行。
这在信息处理里通常不会造成太大问题。
但如果任务恢复后的下一步是付款，“继续执行”就不能等于把之前的交易动作重新放一遍。
Agent恢复的是任务，不是上一笔交易
还是以“每天上午10点买一杯冰美式”为例。
用户长期留下的是一个任务：每天到了这个时间，准备一杯咖啡。
第二天10点，这个任务仍然存在，但昨天那笔交易通常已经没有意义。
昨天选择的门店今天可能缺货，商品可能调价，优惠可能变化，配送或者取餐条件也可能不同。
所以Agent第二天恢复以后，首先要做的不是继续执行昨天留下的订单，而是重新读取今天的交易条件。
它可能需要重新确认门店是否营业、商品是否还有库存、当前价格是多少、优惠是否仍然有效，再根据这些信息形成今天的新订单。
异步Agent在商业场景里恢复的是：“继续帮用户完成这件事。”
而不是：“继续执行昨天那笔交易。”
打车更容易看出这种区别。
用户可以提前告诉Agent，每天下午6点叫车回家。但今天真正到了18点，出发地点可能已经变化，用户可能还在加班，车型、价格、候车时间也和昨天不同。
长期任务可以继承，具体交易却必须根据当前情况重新形成。
交易重新形成以后，还要再判断它是否仍然符合用户最初的要求。
用户今天还要不要执行这项任务？
当前的出发地、目的地、车型和价格，是否仍在原来的任务范围内？
如果需要付款，当前金额、账户和权限是否仍然允许继续？
用户曾经同意Agent替自己处理一类任务，并不代表之后所有交易都可以无限期沿用同一个资金权限。
授权可能限定交易金额、扣款账户、有效期限，也可能在任务运行期间被修改或者撤销。
中国支付清算协会今年发布的《智能体支付应用自律公约》要求，智能体支付授权协议明确交易限额、扣款账户和优先级、有效期等内容，同时要求加强用户身份和交易意愿核验。
对一项持续运行的任务，系统不能只保留一个“已授权”的结果。
它还需要持续判断用户授权了什么、授权到什么时候，以及当前形成的这一笔交易有没有超出原来的范围。
EMVCo今年9月公布的智能体支付框架草案，也把周期性购买、累计预算等需要跨时间管理用户意图的场景纳入讨论。其提出的Intent Services，用于登记、引用、检索和管理消费者授权意图，并维护相关意图的生命周期和状态。
异步Agent每次恢复任务、重新形成交易以后，都需要重新判断这一笔是否仍在原来的授权范围内。
任务可以恢复，支付结果必须先确认
比价格变化更麻烦的，是支付结果本身不确定。
Agent已经发起付款，请求也已经送到支付服务端，但就在结果返回时网络中断。
Agent没有收到成功，也没有收到失败。
这时候，它并不知道上一笔钱究竟发生了什么。
可能支付失败。
也可能已经成功，只是成功结果没有返回。
还可能仍然处在处理中。
如果Agent简单把“没有收到成功响应”理解成“支付失败”，恢复任务以后再付一次，就可能形成重复交易。
网络超时、重复提交和结果不明确，本来就是支付系统长期处理的问题。在异步Agent场景里，这类问题会直接进入自动化、后台化的执行流程。
因此，支付异常后的第一步不是重新付款。
而是先确认上一笔交易的真实状态。
如果已经成功，任务可以继续往后走，不能再次发起同一笔资金动作。
如果明确失败，再判断是否需要重试。
如果仍然处于处理中，或者暂时无法确认结果，就应该继续查询或者等待，而不是贸然再付一次。
只有确认上一笔确实需要重新执行以后，才进入重试。
这时候才轮到幂等。
支付接口长期以来就通过幂等机制处理安全重试。它解决的问题不是“请求永远不能再发”，而是即使因为超时、故障恢复等原因再次发送同一个请求，系统也要能够识别出这是同一个资金动作，避免重复扣款。
Stripe、PayPal等支付服务都提供了类似机制，用于识别重复请求，并在网络异常以后安全恢复交易。
Agent可能在后台持续运行，也可能自动暂停、恢复和重试。用户并不一定一直盯着屏幕，也未必知道程序究竟执行到了哪一步。
所以，Agent可以反复恢复任务，但同一笔资金动作不能被反复执行。
到了真正动钱这一步，还要重新检查交易、权限和支付状态。
任务恢复时，要根据当前环境重新形成交易，并检查这一笔是否仍然符合用户委托和支付权限。
付款发起以后，如果结果异常，先确认真实支付状态，再决定等待、结束还是安全重试。
如果任务被撤销、权限失效、条件发生重大变化或者风险升高，则应在再次动钱以前停止执行。
阿宝的“咖啡闹钟”只是一个很轻的案例。
一杯咖啡并不复杂，复杂的是任务今天建立，明天继续，后天还可能再次执行。用户最初的要求可以保留下来，真正的交易条件和资金状态却会不断变化。
Agent可以把昨天的任务继续做下去，但支付不能把昨天的交易原样重放。
这里是支付学院，关注支付，也关注每一次支付产品微小的进化。
来源丨支付之家·支付学院 (观点仅供参考)
未经允许，严禁转载。发布者：支付学院 转载或引用请注明出处：https://www.zfzj.cn/15022.html
