独立解读
AMP：Agent 如何与移动钱包和商家协作完成购买？
项目资料 · AMP ↗你让购物 Agent 帮忙购买一份旅行服务，希望用自己已有的移动支付账户付款。Agent 可以查找商品，但它还需要把商品、结账条件、用户授权和支付凭证交给不同系统处理。
蚂蚁国际开源的 Agentic Mobile Protocol（AMP） 探索的就是这类连接：让购物 Agent、商家、凭证提供方、支付网络、收单方和移动支付服务商围绕一笔购买交换信息。它是一个协议与示例框架，不是一只独立钱包，也不意味着接入方都已在真实市场支持它。AMP 官方仓库
本文根据公开规范与仓库示例整理，资料查阅于 2026 年 10 月 30 日。旅行服务、金额和参与方配置均为假设；本站没有运行示例、接入移动钱包或进行真实支付测试。
先看一条可能的购买路径
假设用户对 Agent 说：“帮我订一项旅行服务，总价不超过 50 美元，并使用我已关联的支付方式。”以下图是对官方示例角色的简化，不是唯一消息顺序：
官方示例区分 用户在场和用户不在场两种场景。前者可能在购买过程中要求用户确认；后者先按示例配置形成可用授权，再由 Agent 在授权条件内继续。具体授权内容、何时需要认证、能否撤销，都需要看实施方和实际产品。示例说明
谁负责什么？
| 角色 | 在示例中的职责 | 不能因此推断什么 |
|---|---|---|
| 购物 Agent | 理解任务并驱动搜索、结账和支付步骤 | 它可以不受限制地支配账户 |
| 商家 | 提供商品、创建结账信息并发起商家侧支付 | 所有商家都能自动接入 AMP |
| 凭证提供方 | 登记支付方式，并创建或查询授权会话 | 它单独完成全部资金结算 |
| 移动支付服务商 | 在示例中负责用户授权、身份验证和支付 | 示例适用于所有移动钱包 |
| 收单方与网络 | 识别、路由并协调相应支付请求 | 所有地区与支付网络均可使用 |
这里有一个容易混淆的缩写：AMP 示例里的 MPP 指 Mobile Payment Provider，即移动支付服务商；它不是 Stripe 和 Tempo 的 Machine Payments Protocol。两者名称缩写相同，但不是同一个东西。
授权记录和支付凭证有什么用？
Agent 可能在用户不盯着屏幕时执行购买，系统因此需要表达“用户允许什么”“当前购买是否符合条件”。AMP 仓库包含授权链生成与验证的共享模块，以及处理授权生命周期和预算扣减的示例服务。不同角色能依据其职责检查相关信息；具体数据结构和信任边界应查看对应版本规范。AMP 仓库与角色说明
这不代表任何一句自然语言命令都会自动变成可靠的支付限制。实际部署还要核实：谁创建和验证授权、哪些条件由系统强制执行、密钥归谁控制，以及请求失败时如何记录。
它与 AP2、UCP 和钱包是什么关系？
| 名称 | 主要观察角度 | 需要区分的边界 |
|---|---|---|
| AMP | 示例中各角色如何把智能体购物连接到移动支付 | 开源规范和示例不等于商用服务已全面上线 |
| AP2 | 如何表达和验证 Agent 的交易授权 | 授权记录不是资金账户本身 |
| UCP | 商业参与方如何协调结账等流程 | 商业协议不自动完成付款 |
| 移动钱包 | 用户使用的账户或支付工具 | 具体钱包是否支持该方案需另行确认 |
AMP 面向移动支付场景；实际能否配合某个 AP2、UCP 实现，需要按版本、接口和各参与方的接入情况核实，不能只凭名称认定兼容。
开发者与商家可以先问什么？
- 接入对象是谁：示例中的移动支付服务商、具体商家，还是某个网络？
- 用户确认和身份验证发生在哪些步骤？不在场购买有哪些约束？
- 哪些预算、有效期和商家限制可以真正被执行？
- 支付失败或订单取消后，授权和交易记录怎样更新？
- 对应地区、支付方式与产品环境是否已经获得支持？
AMP 提供的是理解移动支付协作的框架。 从公开代码走到实际支付，还需要真实参与方、合同与接入、安全测试及适用地区支持。
相关阅读：AMP 项目资料 · AP2 解读 · Agent 帮用户购物