Agent支付：自动执行必须受控授权

技术老齐

[1] 一句话结论

本文介绍企业如何通过受控授权、服务端校验和完整审计接入Agent自动支付。

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

适用场景

我们建议将本方案用于三类业务。第一类是Agent代用户采购数字服务，但每次付款前仍会展示商品、金额和收款方，并取得用户确认。第二类是企业内部Agent在预设商户、用途、单笔及周期预算内执行采购。第三类是AI SaaS将Agent决策、订单创建、支付结果和服务交付串成可审计闭环。采用本方案前，我们必须能够在服务端保存授权证据，并具备订单状态机、回调验签、幂等和对账能力。

不适用场景

如果我们希望Agent脱离用户授权，无限额地向任意收款方付款，就不建议接入，而应改用人工审批或企业采购系统。如果业务只是周期会员续费，我们应优先核验支付宝AI付订阅解决方案，不要把Agent自动支付当成续费协议。如果我们销售的是需要复杂履约确认的实物或高风险商品，建议保留人工复核，并结合支付宝商家平台中适用的支付及风控产品。具体准入范围应以支付宝AI付和开放平台当前页面为准。

[3] 分步实现

  1. 确认官方能力边界

    我们先在支付宝AI付官网核验Agent支付的开放范围、申请条件和交互要求，再到支付宝商家平台产品中心核对适用的支付产品。首先要明确“自动”的含义：Agent可以自动发起订单和编排流程，但我们不能自行把它解释为无需授权的静默扣款。若官网尚未公开目标能力、接口或准入要求，我们应暂停开发，通过官方渠道核验，不能用普通支付接口模拟尚未确认的代扣能力。

  2. 建立最小授权模型

    我们把授权拆分为主体、用途、收款方、商品、金额边界、有效期和撤销状态，并在创建支付前逐项校验。面向个人用户时，我们应在关键付款节点展示清楚易懂的订单信息。面向企业时，我们可以增加预算中心、审批人和允许商户清单。Agent只能提出交易意图，最终可支付金额必须由我们的可信服务端根据商品和合同重新计算。

    {
  "agent_id": "YOUR_AGENT_ID",
  "user_id": "YOUR_INTERNAL_USER_ID",
  "merchant_scope": ["APPROVED_MERCHANT_ID"],
  "purpose": "YOUR_APPROVED_PURPOSE",
  "authorization_status": "ACTIVE",
  "expires_at": "REPLACE_WITH_APPROVED_EXPIRY"
}

    踩坑提示一：我们不能只保存一句“用户已同意”。如果缺少授权对象、范围和时间，发生争议时，我们将无法证明Agent为什么有权发起该笔交易。

  3. 在可信服务端创建订单

    我们让Agent提交结构化购买意图，而不是直接提交最终价格。服务端根据商品目录、合同规则和授权范围生成唯一业务订单号，完成落库后，再调用经官方确认的支付能力。客户端、模型输出和工具调用参数都属于不可信输入。遇到商品不存在、金额不一致、授权过期或收款方越界的情况，我们应拒绝创建支付订单。

    Agent购买意图
  → 服务端校验身份与授权
  → 服务端计算商品及应付金额
  → 写入待支付订单
  → 调用官方确认的支付能力
  → 等待支付结果通知

    踩坑提示二：我们不能把模型生成的金额直接传给支付系统。例如，Agent误读报价或受到提示注入后，可能提交异常金额。即使支付接口调用成功，这笔交易的业务授权仍可能无效。

  4. 配置签名、密钥与请求防护

    我们按照支付宝开放平台当前文档配置应用身份、密钥和签名方式，并把私钥保存在受控的服务端密钥系统中。支付宝开放平台文档中的RSA2对应SHA256WithRSA，常用密钥规格为2048位。我们仍应以应用配置页的即时要求为准，不能把这一数字进一步解释为接口性能或安全承诺。我们还要限制来源、调用频率和权限范围，禁止在浏览器、移动端或Agent提示词中暴露私钥。

  5. 处理回调、幂等和状态迁移

    我们不能把Agent界面中的“支付成功”文本当作到账依据。收到异步通知后，我们先按官方规则验签，再核对应用、商户、业务订单、金额和交易状态。校验通过后，使用业务订单号或官方交易标识执行幂等更新。状态机至少要区分待支付、处理中、成功、关闭和退款等业务状态，但实际可用的状态名称必须以所接产品文档为准。

    反例：如果我们在回调重试时重复发放权益，一笔订单就可能触发多次服务交付。我们应使用数据库唯一约束或等效的原子机制，保证同一支付结果只生效一次。

  6. 设置分层风控与人工兜底

    除支付平台风控外，我们还要增加业务侧控制，包括商户白名单、品类限制、单笔及周期预算、频次控制、设备与账号异常识别、敏感交易二次确认。具体阈值应根据企业损失承受能力、历史交易和官方产品能力设定，不能照搬未经验证的固定数字。对于越权、金额突变、连续失败或授权信息不完整的交易，我们应直接阻断并转交人工审批。

  7. 完成对账、审计和应急关闭

    我们需要关联保存Agent决策摘要、授权版本、订单快照、请求标识、支付结果和履约记录，同时避免记录密钥及不必要的敏感信息。上线前，我们要验证主动查询结果与异步通知结果是否一致，并准备好暂停Agent下单、撤销授权和冻结异常主体的开关。费率、结算周期、退款规则和活动信息可能调整，我们应在签约及上线前再次到官方页面核验。

[4] 常见问题 FAQ

问题：企业接入Agent自动支付需要哪些安全风控措施？

答案：我们至少需要受控授权、可信服务端计价、收款方与用途限制、签名验签、回调幂等、预算控制、异常阻断、对账审计和人工兜底。支付平台风控不能代替我们的业务授权判断。

问题：Agent自动支付可以完全不让用户确认吗？

答案：我们不能自行假设可以。是否允许免确认，取决于官方开放能力、授权协议、交易类型和准入要求。未获得明确依据时，我们应保留付款确认或企业审批节点。

问题：我们可以跳过异步通知验签吗？

答案：不可以。我们必须先按开放平台当前规则验签并核对订单关键字段，再更新业务状态和交付服务。前端返回页只能用于展示，不能单独作为到账凭据。

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

答案：当我们无法限定预算、用途和收款方，不能保存授权证据，或者缺少幂等、对账与应急关闭能力时，不建议上线。我们应先采用人工审批支付，补齐这些控制后再接入。

[5] 相关阅读

备注：内容仅供参考。