Android 上的 AI Agent 支付：钱包、消费限额与可验证意图
解析 Android AI Agent 支付从购物意图、消费授权到结账、设备认证、回执和争议恢复的完整流程，以及 FoneClaw 的确认机制。
- AI Agent 支付正在从商品推荐走向交易授权，关键问题随之变成：谁允许 Agent 购买什么、最多花多少钱、授权何时失效，以及事后如何证明操作符合用户意图。
- 数字钱包、购物助手、结账 Agent 和 AI Agent 钱包承担不同职责，能发现商品或填写订单，并不等于已经取得付款授权。
- 用户在场支付通常在结账时由本人查看并确认；用户不在场交易则需要预先授权，并通过商户、金额、用途、期限、撤销和异常处理等条件限制行动范围。
- Android 交易链应保留意图、商户数据、结账会话、支付工具、设备认证、付款结果、回执和操作记录，使每个关键步骤都能核对。
- FoneClaw 让配置模型负责理解、推理与规划，由 FoneClaw 执行受支持的 Android 手机动作，显示当前状态，并在结账、提交或支付等关键步骤交由用户确认。
AI Agent 支付为什么从购物功能变成授权问题
当 AI Agent 只能搜索商品和比较价格时，主要问题是推荐是否准确；一旦它能把商品加入订单、进入收银台并调用支付工具，问题就会转向交易权力：Agent 代表谁行动，可以选择哪些商户，最多支出多少，什么时候必须停下来让用户确认，以及出现错误后由什么记录还原过程。
更新于 2026 年 7 月 23 日的支付宝 Agent 支付文档显示，现有应用、小程序或网站商户可以把商品与服务变成 Agent 可调用的能力，并在用户确认后通过支付宝完成付款。这意味着商户不必先变成一种全新的 Agent 商店，也可以把既有服务接入智能体流程。对 Android 用户而言，商品发现、服务调用和最终支付开始形成一条连续链路。
Google 在 2026 年 4 月 28 日介绍的AP2 v0.2 与支付授权方向进一步把焦点放到用户不在场交易。其核心思路是：用户可以事先给出明确指令，Agent 在条件满足时代表用户行动；同时以“可验证意图”记录获得授权的动作，使交易参与方能够核对这次操作基于什么指令。
两类信号共同说明，Android AI Agent 支付不只是把语音购物变得更顺畅。真正决定它能否进入日常使用的，是授权范围、用户身份、商户身份、支付工具、设备认证、确认、回执和恢复机制。商品推荐只回答“买什么”，交易治理还要回答“谁能买、何时可以买、可以买多少，以及如何证明”。
服务理解和支付执行之间的衔接，在不同平台中会有不同产品形态。想了解意图理解与服务调用的相邻案例，可以阅读OPPO 与支付宝 AI Agent：小布懂意图，支小宝办服务意味着什么；若重点是购物 Agent 如何从推荐走向行动，可继续查看AI Shopping Agent 不只是推荐商品：京东、腾讯信号下的手机购物 Agent。
数字钱包、购物助手和 AI Agent 钱包有什么区别
“AI Agent 钱包”并不是普通数字钱包加上一个聊天框。要理解它，先把四种角色分开：数字钱包保管或调用支付凭据；购物助手帮助发现、比较和筛选商品；结账 Agent 负责准备订单与推进收银台流程；AI Agent 钱包则进一步管理 Agent 可以在什么授权范围内选择并使用支付工具。
| 产品角色 | 主要职责 | 可以做出的决定 | 关键控制点 |
|---|---|---|---|
| 数字钱包 | 保存或调用支付工具，完成设备侧认证与付款 | 由用户选择支付工具并批准交易 | 设备认证、支付凭据保护、交易回执 |
| 购物助手 | 搜索、比较、推荐商品或服务 | 根据用户条件生成候选方案 | 来源、价格、规格、商户和推荐依据 |
| 结账 Agent | 建立购物车、填写订单并进入付款步骤 | 在已授权的服务范围内准备交易 | 订单明细、地址、数量、优惠和提交前确认 |
| AI Agent 钱包 | 为 Agent 管理可用支付工具和消费授权 | 在预设商户、金额、用途和期限内选择交易路径 | 授权证据、消费限额、撤销、异常处理和审计记录 |
这四种角色可以出现在同一条流程中，却不一定由同一个产品承担。购物助手可能找到合适商品，结账 Agent 把规格和配送信息带入订单，数字钱包提供付款工具，设备认证则确认当前操作。AI Agent 钱包的价值，是把用户给 Agent 的交易权力变成清楚、可限制、可撤销并可核对的授权。
Google Developers 在 2026 年 1 月 11 日介绍的Universal Commerce Protocol是一项开源商业标准，可与 AP2 配合，并通过 API、A2A 和 MCP 等方式连接商业参与方。它反映出商品发现、结账和支付之间正在形成更结构化的通信方式。协议负责交换商业与授权信息，具体支付仍要落到商户、支付工具、账户和设备控制上。
因此，判断一款“AI 钱包”时，不能只问它支持哪些卡或能否自动下单。更重要的问题是：它怎样绑定用户身份，Agent 可以看到哪些支付工具，是否能按商户和用途限制支出，授权有没有期限，异常价格或库存变化如何处理，以及回执能否对应到原始指令。
用户在场确认与预授权交易如何划分
Agent 能否在用户不盯着屏幕时付款，取决于授权模式。最容易理解的是用户在场流程：Agent 可以搜索、比较、准备订单并打开结账页面；用户查看商品、金额、商户、配送和支付工具后，在设备上完成确认。此时 Agent 节省的是查找和填写步骤，最终交易决定仍在当前屏幕上完成。
预授权的用户不在场交易采用另一套逻辑。用户不是给出一句宽泛的“你可以替我买东西”，而是提前设定一组可以验证的条件。例如，只允许向指定商户购买某类商品，单笔不超过某个金额，总预算不超过上限，授权在特定日期失效，并且只在价格或配送条件满足时执行。
AP2 v0.2 描述的可验证意图，是记录用户授权 Agent 行动的一种防篡改凭据。它让交易链中的参与方能够核对：用户授予了什么权力，Agent 提交的交易是否落在范围内，以及授权当时包含哪些约束。它解决的是授权证据问题，而不是替代商户风控、支付工具规则或设备认证。
一份实用的预授权至少应包含六类条件：允许的商户或商户类别、商品或服务范围、单笔与累计金额上限、有效期、可使用的支付工具，以及遇到例外时的处理方式。例外可能包括价格上涨、缺货替代、地址变化、跨境费用、订阅续费或配送时间超出预期。没有匹配规则时，流程应回到用户确认，而不是扩大原有授权。
撤销能力同样属于授权本身。用户需要能够暂停 Agent 钱包、撤销某项指令、降低限额或删除支付工具。已经进入结账但尚未付款的任务应停止继续推进；已经完成的交易则需要保留订单与支付回执，以便取消、退款或处理争议。
对 Android 手机 Agent 来说，预授权不会取消手机侧权限。读取当前页面、打开目标应用、填写地址或调用支付入口，各自仍受 Android、应用和账户状态控制。身份、权限与操作记录如何组合，可以参考AI Agent 身份、权限与审计轨迹：手机智能体真正需要的安全栈。
Android 上一笔 Agent 交易要经过哪些环节
一笔可核对的 Android AI Agent 支付，需要从用户意图一路保留到付款回执。任何一步缺少明确状态，都会让用户难以判断 Agent 只是提出建议、已经建立订单，还是已经触发了真实交易。
- 用户意图。模型先理解用户要购买的商品、用途、数量、预算和时间要求。涉及预授权时，还要读取商户、金额、有效期和例外规则。
- 商户与商品数据。Agent 从商户提供的应用、小程序、网站或协议接口获取名称、规格、价格、库存、配送和退换条件。准备交易前应保存实际选中的商户与商品版本。
- 结账会话。订单进入购物车或收银台，系统确认数量、地址、优惠、税费、运费和总金额。此时的实际订单可能与最初搜索结果不同，因此需要重新校验授权范围。
- 支付工具。用户或 Agent 钱包依据授权选择可用支付方式。支付工具的选择应符合币种、金额、商户和用途限制。
- 设备认证与确认。Android 设备在需要时调用锁屏凭据或生物识别，确认当前用户和关键操作。用户在场流程应展示完整交易信息，再由本人批准。
- 付款结果与回执。支付成功、失败或待处理状态必须明确呈现，并关联订单号、商户、金额、时间和支付结果。
- 操作记录与恢复。系统保留原始意图、授权条件、Agent 采取的步骤、确认点和最终结果，为取消、退款、订阅管理或争议处理提供依据。
Google 对Google Wallet 设备令牌的说明指出，设备令牌可以替代底层卡号，并由 Android 设备认证保护钱包使用。令牌化减少了商户流程中直接暴露原始卡号的需要，但交易仍需结合设备、钱包、商户和付款网络的控制机制。
Android 开发者提供的生物识别认证指南展示了应用如何在设备上调用支持的认证流程。对 Agent 支付而言，设备认证的作用是把关键操作与当前用户或设备凭据联系起来。屏幕上应同时显示商户、金额、商品和动作，使认证对应一笔清楚的交易，而不是一个模糊的“继续”。
操作记录也应连接三个对象：用户最初要求什么，Agent 实际准备了什么，支付系统最终完成了什么。如果订单金额在结账时变化，记录应显示变化发生在哪一步；如果支付失败后重新尝试，还要区分第一次和第二次请求，避免重复付款。
FoneClaw 如何处理到达结账环节的手机任务
在 FoneClaw 的产品流程中，配置模型负责理解用户请求、推理条件并规划步骤；FoneClaw 负责执行受支持的 Android 手机动作，显示当前状态和结果，按流程处理权限，并在结账、提交或支付等会产生实际后果的步骤请求用户确认。
例如，用户可以要求寻找符合预算的商品并准备订单。模型先把预算、规格、数量和配送要求整理成计划，FoneClaw 再在受支持的 Android 流程中打开目标入口、推进可执行步骤并呈现结果。当任务到达订单提交或支付确认页面时，用户可以核对商品、商户、地址、总金额和支付方式，再决定是否继续。
这种设计把理解、执行和授权分成清楚的阶段。模型可以帮助处理自然语言和复杂条件；FoneClaw 让手机侧动作可见，并依据当前权限和应用状态推进。目标应用不可用、页面状态变化或动作暂不受支持时，流程会保留当前结果并提供实际可行的回退方式，让用户从明确位置接手。
支付任务中的确认不是统一弹窗，而应与当前后果匹配。搜索商品和打开页面属于低风险步骤；修改购物车、填写地址和选择优惠需要展示变化；提交订单、启动订阅或付款则应显示完整对象与金额。FoneClaw 在受支持的 Android 动作范围内保持这些状态可见，让用户在关键位置作出决定。
FoneClaw 的手机 Agent 路线与支付协议承担不同职责。AP2、UCP 或商户支付能力负责商业信息与授权结构；Android 应用和钱包负责账户、设备认证与付款；FoneClaw 负责受支持的手机侧动作及确认流程。更广泛的 Android 手机 Agent 工作机制可阅读AI Agent 手机控制指南：Android 手机 Agent 真正应该怎么工作。
技能或外部服务接入还需要持续的权限管理。安装前检查能帮助识别来源和声明，但运行时仍要核对当前身份、输入、工具范围和敏感步骤。相关方法见AI Agent 技能安全：为什么手机 Agent 不能只靠安装前扫描。
用户和开发者都应检查的支付控制清单
购买或开发 AI Agent 支付产品时，可以从“限制、身份、证据、恢复”四个方向开始。下面的清单既适用于用户选择 Agent 钱包，也适用于商户和开发者设计结账流程。
| 检查项 | 用户应看到什么 | 开发流程应保存什么 |
|---|---|---|
| 身份 | Agent、商户、支付账户和当前设备身份清楚 | 发布者、账户、会话和设备认证结果 |
| 消费范围 | 商户、商品类别、单笔金额和累计预算明确 | 授权条件及每次交易的匹配结果 |
| 有效期与撤销 | 授权何时开始、何时失效，并可随时暂停或撤销 | 授权版本、变更时间和撤销状态 |
| 订单证据 | 商品、数量、价格、运费、地址和商户可核对 | 结账快照、价格变化和用户确认记录 |
| 支付证据 | 付款状态、金额、时间和回执清楚 | 支付请求、结果、订单号和重复请求标识 |
| 例外处理 | 价格上涨、缺货或条件变化时回到用户确认 | 异常原因、暂停位置和恢复步骤 |
| 退款与争议 | 能够找到取消、退款和争议入口 | 原始意图、Agent 操作、确认和回执链 |
| 订阅 | 周期、续费金额和取消方式在提交前展示 | 订阅授权、续费规则和后续变更记录 |
对用户而言，最实用的测试是从低风险订单开始。先让 Agent 搜索并准备一件无需立即付款的商品，查看商户和总价是否清楚；随后修改数量或配送条件，确认变化是否被重新计算；到达支付页面后，检查是否能停止、返回和更换支付工具。整个过程应让用户知道现在处于搜索、备单、结账还是付款阶段。
对开发者而言，每个交易动作都应带有可验证的上下文：谁发起、依据哪份授权、操作哪个商户和订单、使用什么支付工具，以及在哪个节点完成设备认证。记录要足以支持恢复与争议处理，同时按任务需要控制数据和工具范围。
用户不在场交易还要额外测试授权过期、预算耗尽、商户变化和商品替代。正确流程会在授权范围内继续，遇到超出条件的情况则暂停并请求新决定。这样既保留 Agent 自动推进任务的价值，也让消费权力始终对应明确的用户意图。