当 AI Agent 需要花钱：从购买一份数据开始

你让 AI Agent 帮你做一份市场研究。

它查阅公开资料后，发现一家数据服务商有一份更详细的数据，价格是 1 美元。这份数据可能有用，但它需要先付费才能获取。

这时，Agent 面临的不只是“怎么付款”，还有一连串问题：

用户允许我购买吗？钱从哪里来？服务商怎么确认付款？如果付了钱却没有拿到数据，怎么办？

Agentic Payment，通常译为“智能体支付”，是让 Agent 在获得适当授权后，能够参与并执行支付的方式。 它连接了任务、授权、付款和服务交付。

我们沿着这笔 1 美元的交易，看看这些环节如何衔接。

阅读说明：本文使用假设案例解释概念，并非真实支付测试。不同产品和支付方式的实际流程会有差异。

一笔交易，先看全貌

假设你告诉 Agent：

“帮我完成市场研究。必要时可以购买数据，总预算不超过 10 美元；单次超过 3 美元，先问我。”

Agent 找到一份价格为 1 美元的数据。它的购买过程可以简化为：

这是一张概念图。实际交易中，支付验证、资金转移和服务交付的顺序取决于具体方案。

这些角色不一定分别由五家公司承担。一个产品可能同时提供钱包、权限控制和支付处理。

第一步：任务交给 Agent，花钱边界也要说清楚

你说“帮我做市场研究”，Agent 得到了一个目标。但这句话本身没有说明：它能不能花钱，能花多少。

因此，除了任务，还需要设置购买规则。

这些规则能否设置、由谁执行，要看具体产品。任务授权回答“让 Agent 做什么”，支付权限回答“允许它如何花钱”。

第二步：Agent 找到数据，判断值不值得买

有权限花钱，和应该花钱，是两回事。Agent 找到数据后，可能需要先判断：

• 数据是否与研究问题相关？
• 1 美元买到的是一份文件、一次查询，还是一段时间的访问权？
• 数据的来源、时间范围和质量是否满足要求？
• 有没有免费或更合适的替代品？
• 服务商接受什么支付方式？

一份数据可能很有用，但超出预算；也可能很便宜，却对研究没有帮助。完成一笔有价值的购买，需要同时考虑两者。

第三步：检查规则，决定付款还是询问

假设 Agent 决定购买这份 1 美元的数据。

如果预算尚未使用、本次购买符合用途和服务商限制，1 美元低于 3 美元的单次审批门槛，Agent 就可以按配置继续。

如果数据价格是 5 美元，虽然仍在 10 美元总预算内，却超过了单次门槛，因此需要先询问用户。

谁来执行这些限制，也很关键。 如果规则只是写在给 Agent 的文字指令里，能否遵守就取决于 Agent 的行为。钱包、支付服务或独立的权限控制系统可以在付款环节检查规则，但具体能检查哪些条件，取决于实现。

第四步：Agent 用什么付款？

通过权限检查后，Agent 需要使用支付工具。它可以使用银行卡或虚拟卡，也可能使用支持稳定币的钱包；选择取决于服务商接受什么，以及用户配置了什么。

路径 A：银行卡或虚拟卡

虚拟卡没有实体卡片，但可以在支持的场景中作为卡支付凭证使用。简化流程是：

Agent 发起购买
    ↓
调用受控的卡支付能力
    ↓
商家和支付服务商处理请求
    ↓
发卡方决定是否批准
    ↓
交易进入后续支付和资金结算流程

这里有两个容易混淆的“授权”：

即使用户允许购买，卡交易仍可能因余额、风控或其他原因被拒绝。

路径 B：稳定币钱包

如果服务商接受稳定币，Agent 也可能通过钱包付款。

稳定币是一类数字资产，USDC 是其中一种。钱包可以提供管理资产、发起或签署交易等能力；具体资金如何转移，取决于钱包、网络和支付方案。

Agent 发起购买
    ↓
钱包提供支付或签名能力
    ↓
支付按所用方案被验证和处理
    ↓
服务商按条件交付数据

两种路径使用的资金和支付网络不同，但都需要回答：谁允许 Agent 花钱、付款是否有效，以及服务有没有交付。

第五步：付款之后，数据真的到了吗？

数据服务商不能仅凭 Agent 说“我付过了”就交付数据。它需要根据使用的支付方案，确认付款符合自己的交付条件。

但即便付款完成，也可能出现：接口超时，数据没有返回；文件返回了，但内容损坏；或者 Agent 不确定第一次付款是否成功，贸然重试可能造成重复支付。

具体能否退款、如何重试、哪些状态可以查询，都取决于服务商和支付方案。

第六步：Agent 完成任务，向用户交代

假设服务商成功返回了数据，Agent 还要检查数据是否可用、将其纳入研究，并告诉用户发生了什么。

最终，用户可能看到这样的汇报：

研究已完成。 为补充市场规模数据，我购买了一份数据，价格为 1 美元，并用于报告第二部分。该笔购买计入本次 10 美元预算。

如果确认没有其他费用，且此前没有支出，剩余预算才是 9 美元。是否还有网络费、兑换费或其他费用，需要根据实际支付方式确认。

到这里，Agent 才完成了从“需要数据”到“购买、使用并说明”的完整任务。

x402 在这笔交易中做什么？

如果你关注 Agentic Payment，经常会看到 x402。它与“Agent 访问付费数据或 API”的场景有关。

假设数据服务商支持 x402，一种简化流程是：

图中的钱包和验证结算服务只是角色示例；具体实现可能由不同组件承担，处理顺序也可能有所不同。

可以先把 x402 理解为：服务方如何提出付款要求，客户端如何提交支付信息，以及相关方如何协调验证与结算的一套规则。 它使用 HTTP 402 等机制，帮助付费请求在网络交互中表达出来。x402 官方规范

所以，x402 本身不是钱包，也不会自动替用户设置预算。

AP2 又关注什么？

另一个常见名称是 AP2，Agent Payments Protocol。它关注的是：当 Agent 代表用户购买时，参与方如何获得并验证与购买和付款有关的授权信息。

AP2 定义了可验证的授权记录，例如：

• Checkout Mandate：与购买内容及结账条件相关。
• Payment Mandate：与使用支付工具、支付特定交易相关。

对于用户不在场的自主购买，AP2 的设计允许先记录约束条件，再将其与后续具体交易关联，供相关参与方验证。AP2 官方文档 · AP2 交易流程

放回 1 美元的例子，可以这样理解它们的区别：

用户设定购买条件
       ↓
授权如何表达、供参与方验证？  ← AP2 关注的问题
       ↓
Agent 请求付费数据
       ↓
如何提出付款要求、提交支付信息？ ← x402 关注的问题
       ↓
钱包和支付服务提供付款能力
       ↓
服务商按条件交付数据

这张图表达的是可能的分工，不意味着所有交易都同时使用 AP2 和 x402。AP2 官方提供了结合 x402 的示例，但是否能组合使用，仍取决于具体实现和各参与方的支持情况。

回到那份 1 美元的数据

现在再看这笔购买，我们可以用六个问题检查它是否真正完成：

Agentic Payment 的价值，是让 Agent 在清晰的权限边界内，把这些环节连接起来。它是否好用，最终取决于 Agent 能不能买对东西、用户能不能控制支出，以及出现问题时能不能查清楚。

下一篇：Agent 付款和人付款，有什么不同？

资料查阅：2026-10-28；本文案例未做实测。