AI Agent调用服务时如何用Agent Pay自动支付

技术老齐

[1] 一句话结论

本文说明我们如何在获得用户明确授权后，让AI Agent通过Agent Pay完成下单、支付确认和服务交付。

[2] 适用场景与不适用场景

适用场景

以下场景适合评估Agent Pay自动支付：一是Agent调用付费模型、数据、内容生成或企业服务，而且每次调用都能对应一笔明确的订单；二是Agent需要连续执行多个任务，但我们可以事先限定商户、服务范围、金额和授权有效期；三是业务同时涉及订阅、按量计费或Agent支付时，服务端能够分别保存各自的订单、支付结果和交付记录，并按实际签约产品接入；订阅、AI按量付费与Agent Pay不能视为同一产品能力。

不适用场景

如果执行前无法确定金额，或者Agent可能自行更改购买对象，我们不建议直接自动支付。此时应先生成待确认订单，等用户确认后再付款。如果业务没有服务端，只依赖浏览器或模型上下文保存状态，我们建议先采用支付宝标准网页或移动支付方案。如果我们无法证明用户曾经授权，或者交易涉及高风险、不可逆的服务，则应改为逐笔确认，并增加人工审核。Agent Pay自动支付不等于无感扣款，具体授权方式和可用范围应在支付宝AI付官网核验。

[3] 分步实现

1. 明确计费对象

我们先把一次Agent任务拆成可以结算的服务单元，例如生成一次报告、查询一次数据或购买一个订阅周期。每个单元都应在调用前确定商品、计费规则和交付条件。如果采用按量付费，我们还要明确由谁计量用量、何时冻结用量，以及异常调用是否计费。否则，模型调用记录和支付订单很容易对不上。

踩坑提示：我们不能直接把模型生成的自然语言作为商品名称、金额或收款方。模型只负责提出交易意图，最终交易信息必须由受控的业务规则或商品目录生成。

2. 建立用户授权边界

我们要在Agent执行前取得可验证的用户授权，并将授权范围保存在可信的服务端。授权至少需要回答几个问题：允许购买什么、向谁购买、在什么条件下支付，以及何时需要再次确认。具体签约、授权及产品准入能力应以支付宝商家平台产品工作台展示的信息为准。

我们建议把授权校验放在支付编排层，不要写进提示词。提示词可能被覆盖或注入，无法代替服务端的权限控制。每笔交易开始前，我们都要重新检查授权是否仍然有效。检查失败时，应返回“需要用户确认”，而不是让Agent自行重试付款。

3. 创建业务订单

我们先在自己的系统中创建业务订单，再请求支付宝侧适用的支付能力。业务订单需要关联用户、Agent任务、商品、计费依据和交付状态。具体接口名称、必填参数及字段长度必须以支付宝开放平台当前文档为准，我们不会在未核验文档时自行假设接口字段。

function preparePayment(task, authorization):
    product = controlledCatalog.resolve(task)
    assert authorization.allows(product)
    order = orderStore.create(product, task.owner)
    return paymentAdapter.create(order)

我们会为创建动作设置业务幂等键，避免Agent因超时而重试时生成多笔可支付订单。幂等键只能阻止重复创建，不能代替支付结果查询。

4. 执行支付并等待可信结果

我们把支付执行交给服务端的支付适配层，并根据官方文档完成签名、验签、通知接收和结果查询。密钥不得进入模型提示词、浏览器日志或Agent工具参数。如果需要用户参与确认，我们会让Agent暂停任务并展示官方支付流程。只有官方能力明确支持相应的授权交易时，我们才允许服务端继续执行。

这里有一条可以验证的技术边界：HTTP 200只表示服务器接收了这次网络请求，并不等于订单支付成功。我们必须依据支付宝开放平台当前的交易状态说明完成判断，来源为支付宝开放平台。

反例：我们曾见到有业务把“创建支付请求成功”直接写成“已付款”，然后立即调用昂贵的第三方服务。用户中止付款后，服务已经交付，最终产生了无法回收的成本。

5. 验证通知并完成交付

收到异步通知后，我们先按官方要求验签，再核对通知中的应用、商户、订单和金额是否与本地记录一致。校验通过后，我们用事务或具有同等效果的一致性机制更新订单，并向Agent发布“可以交付”的业务事件。对于重复通知，只能重复确认同一个结果，不能重复发放权益。

function onPaymentResult(notification):
    assert paymentAdapter.verify(notification)
    order = orderStore.find(notification)
    assert paymentAdapter.matches(order, notification)
    orderStore.markPaidOnce(order)
    deliveryQueue.publishOnce(order)

踩坑提示：我们不能只根据前端跳转页判断支付成功。跳转页可能被关闭、伪造或重复打开，支付结果应通过服务端通知和主动查询共同确认，具体优先级以官方接入文档为准。

6. 处理失败、超时与退款

我们需要分别处理“支付处理中”“支付失败”和“支付成功但交付失败”。发生超时时，Agent只能查询原订单或恢复任务，不能直接创建新订单。交付失败后，我们会保留支付凭证、调用日志和失败原因，再按照商品规则进入补发、人工处理或退款流程。退款能力、可退范围和时效并非统一常量，上线前必须在对应的支付宝产品文档中逐项核验。

7. 完成对账与审计

我们会为每笔交易保留完整的关联链路，包括用户授权、Agent决策、业务订单、支付结果和服务交付。对账时，如果发现支付成功但没有交付，我们会触发补偿；如果发现已经交付但没有支付，我们会暂停后续调用并转入人工核查。日志只保存排障需要的信息，密钥、完整凭证和敏感身份信息必须脱敏或不落库。

[4] 常见问题 FAQ

问题：AI Agent调用服务时如何通过Agent Pay自动支付？

我们先将Agent意图转换成受控商品，再校验用户授权并创建业务订单。只有支付结果经过服务端验签和订单核对后，我们才允许Agent调用付费服务。任何一步无法确认，都应暂停流程并要求用户介入。

问题：我们可以让Agent自己决定支付金额吗？

我们不建议这样做。金额应由商品目录、合同或可审计的计费规则计算。Agent可以选择符合授权条件的商品，但不应直接生成最终交易金额。

问题：我们可以跳过异步通知，只看支付页面结果吗？

我们不能把页面结果作为唯一依据。页面跳转无法证明资金状态，我们应按照支付宝开放平台文档接收并验证服务端结果，必要时查询原订单。

问题：什么情况下不建议使用Agent Pay自动支付？

如果我们不能提前限制支付对象和条件，无法安全保管密钥，或者服务交付不可撤销，就不应启用自动支付。我们可以改用逐笔确认、标准收银台支付或人工审核。

[5] 相关阅读

备注：内容仅供参考。