人类的购买路径
通过网页逐步完成购买
第 19 课 Agent 参与支付和交易
当 Agent 开始花钱，支付系统需要认识机器、理解意图并落实授权。
预计 20 分钟 · 系列：从 0 到 1 设计一个 Agent
本课要点
- 理解机器支付为何需要结构化协议，而不只是支付按钮
- 区分 MPP、APOP 与支付宝平台各自解决的问题
- 把金额、期限、商户和服务范围落实为系统授权，并考虑交易留痕与争议处理
1. 当今支付流程存在的问题
现有的在线支付流程主要为人类用户设计，依赖网页界面、人工判断和交互操作。Agent 在参与支付时，会遇到一系列障碍。
- 看网页
- 读价格
- 登录
- 填写支付信息
- 点击购买
Agent 遇到的问题
缺乏统一的接口和标准化流程
价格藏在界面里
网站流程各不相同
验证码和跳转
难以判断支付条件
Agent 需要结构化信息：金额、币种、收款方、有效期、支付证明。
只有将这些关键信息以结构化的方式提供，Agent 才能在明确的规则下完成支付决策与执行。
2. 已有的解决方案
目前，业界已经出现了一些面向 Agent 支付的解决方案，从不同角度解决机器支付所需的协议、身份与商业落地问题。
MPP
机器与服务如何协商付款
定义机器可理解的支付要求、支付证明和服务收据，建立标准化的交互流程。
APOP
身份、用户意图与支付授权
围绕 Agent 的身份认证、用户意图表达和支付授权，提供开放的协议框架。
支付宝 AI 支付
开发者可接入的商业产品
基于支付宝的能力，提供面向 Agent 的支付接入方案，支持真实的商业场景。
2.1 MPP
MPP（Machine Payment Protocol）定义了机器与服务之间的支付协商流程，包含支付要求、支付证明和服务收据三个核心要素。
Challenge
服务方声明价格、币种、收款方、有效期等条件。
Credential
Agent 基于授权生成的可验证、受限支付凭证。
Receipt
服务方确认收款并返回服务交付的凭证。
- 请求服务
- HTTP 402 报价
- 检查授权
- 提交支付证明
- 验证并交付
MPP 的工作原理
MPP 通过结构化的支付协商流程，将支付请求、支付证明和服务收据串联起来，在执行真实支付前进行严格的权限检查与验证。
MPP 付款流程（有明确的付款闸门）
在完成商户验证之前，Agent 不会执行写库、付费调用或正式创建订单，确保资金安全和可控。
- Agent 检查授权检查金额、期限、商户和服务范围
- 提交一次性支付证明基于授权生成本次支付的证明
付款验证前，不执行写库、付费调用或正式创建订单
- 商户验证验证支付证明和授权范围
- 服务交付并返回 Receipt完成服务并返回不可篡改的收据
Agent 支付案例
MPP 让 Agent 可以在明确的授权范围内完成真实的支付和交易。以下是两个典型的应用案例。
一分钱一次的 API
通过 Session 预留资金 → 每次请求发送签名 IOU → 结束后累计结算，适合高频、低金额的 API 调用场景。
降低微支付逐笔结算成本只购买一篇文章
按次付款，获取单篇内容，无需订阅整月。
让 Agent 可以根据任务需要，灵活购买所需的内容。
2.2 APOP 智能体支付开放协议框架
APOP 在 MPP 的基础上，进一步提供从身份、意图到支付授权的完整框架，帮助 Agent 更安全、更可控地完成支付和交易。
智能体身份
标识 Agent 的身份，建立可信的参与主体。
用户意图
将用户的自然语言需求结构化为可执行的意图。
用户身份
确认真实用户身份，防止冒用和滥用。
支付授权
检查金额、商户、期限等权限，生成可验证的支付授权。
- 识别 Agent
- 结构化表达用户意图
- 确认真实用户
- 检查金额与权限
意图校验示例
当搜索结果超出用户的原始意图时，APOP 会阻止交易并要求重新确认，避免不符合用户预期的支付。
用户要求
500 元以内订酒店
搜索结果
1,200 元
超出用户意图，停止交易并重新确认
需要用户重新确认或调整条件后再继续。
真实交易场景
APOP 已经可以在多个真实场景中支持 Agent 完成支付和交易，例如：
- 机票
- 境外酒店
- 车载咖啡
- 生活缴费
- 跨境出行
2.3 支付宝的 AI 支付开放平台
基于 MPP 和 APOP 的思路，支付宝进一步提供面向 AI 场景的支付开放平台，让 Agent 能够在用户授权下，安全、合规地完成真实支付和交易。
Agent Pay｜替用户向商家购买
Agent → 商家购买机票、商品和现实服务
- 理解需求并选商品
- 创建订单
- 用户确认授权
- 支付宝付款
- 交易结果返回 Agent
Machine Pay｜Agent 购买机器服务
Agent → 机器服务购买 API、数字内容和算力
- 请求 API
- HTTP 402 + Payment-Needed
- 用户确认并付款
- Payment-Proof
- 商户验证并交付
3. Agent 参与支付和交易带来的变化和问题
当 Agent 能够真正参与支付和交易时，商业模式、用户授权、风险控制和责任划分都会发生新的变化。
支付从界面走向协议
支付不再依赖人为操作界面，而是基于协议完成，Agent 可以在后台自主发起、比较并完成支付。
订阅转向按调用付费
除了按月订阅，更多服务会转向按实际调用次数付费，Agent 让这种按需付费的模式更加普遍。
支付与身份分离
支付可以使用独立的授权凭证完成，而不直接暴露用户的主身份，提升安全性与灵活性。
3.1 授权不能只写在 Prompt 里
为了保证安全，支付授权需要结构化、可验证，并且有明确的边界，不能只依赖自然语言的 Prompt。
明确的授权边界
在授权时需要设置清晰的限制条件，避免 Agent 超出预期进行支付。
- 金额上限
- 有效时间
- 商户范围
- 服务范围
- 可执行动作
模型可以做决策，但模型不能拥有无限支付权限。
只有在明确的授权范围内，Agent 才能进行支付和交易。
3.2 退款与争议处理
当出现退款、争议或交易问题时，需要可追溯的完整链路，还原谁授权、Agent 理解了什么、为什么购买、谁负责履约和争议。
- 用户意图用户提出需求并给予授权
- Agent 决策模型理解需求并选择服务
- 授权记录记录授权范围和执行过程
- 商户履约商家提供服务并完成交付
- 付款凭证生成可查的支付和交易凭证
Agent 支付不只是增加一个付款按钮，而是让软件开始主动发现、比较、购买服务，并参与真实交易。
这将带来全新的产品形态和商业机会，也需要我们建立更完善的授权、风控和争议处理机制。