如何让 AI 智能体自动向供应商付款：面向企业的落地指南（2026）

最后更新 2026-09-30。

让 AI 智能体（AI agent）自动向供应商付款需要五个步骤：按供应商类型选择支付轨道（能刷卡的商户用卡，按用量计费的 API 类供应商用 API/稳定币轨道，已经走应付账款流程的一切都保留人工审批）；写一份带有单智能体消费上限和供应商白名单的消费策略；在你选定的阈值处把人工审批接入流程；在第一笔真实付款之前（而不是之后）搭建好审计日志；并为付款出问题的那一天准备好应急预案。这些都不是什么新奇的东西——下面提到的每一项控制，都是某家发卡机构、钱包提供商或协议已经在自己文档中记录过的功能；真正的工作是有意识地选择并把它们组合起来，而不是让智能体发出一笔没有人设过上限的付款。

本指南不提供法律、税务、会计或监管方面的建议——在把真实的供应商支出交由这些控制机制处理之前，请先与你的财务和法务团队确认。

第一步：按供应商类型选择支付轨道

不是每一笔供应商付款都应该走同一种方式。要让支付轨道匹配该供应商今天实际的收款方式。

接受刷卡的供应商（SaaS 订阅、广告平台、大多数 B2B 工具）。 给智能体发一张限定于该供应商的虚拟卡，而不是一张共享的公司卡。Stripe 面向智能体的发卡产品"lets you issue virtual cards that agents can use to make purchases autonomously, with spend controls, real-time authorization decisioning, and full transaction visibility"（允许你发放虚拟卡，供智能体自主完成购买，并配有消费管控、实时授权决策和完整的交易可视性），其定位明确是"give each agent its own virtual card with per-agent spend limits, merchant category controls, and custom authorization rules"（为每个智能体提供属于它自己的虚拟卡，具备单智能体消费上限、商户类别管控和自定义授权规则）（Stripe Issuing for agents，访问于 2026-09-30——注意该产品在同一页面上被标注为处于"Private preview"（私密预览）阶段）。Lithic 的卡片平台记录了同样的单卡机制，更通用地说："Cards support a single spend_limit with spend_limit_duration of ANNUALLY, FOREVER, MONTHLY, or TRANSACTION"（卡片支持一个 spend_limit，配合 ANNUALLY、FOREVER、MONTHLY 或 TRANSACTION 之一的 spend_limit_duration）（Lithic spend limits docs，访问于 2026-09-30）。Privacy.com 的卡片 API 用一种 MERCHANT_LOCKED 卡类型支持同样的思路——该类型的卡会锁定到它第一次被使用的商户，并配有一个 spend_limit 字段，该字段会"limit approved authorizations"（限制已批准的授权），使得"transaction requests above the spend limit will be declined"（超过该消费上限的交易请求会被拒绝）（Privacy.com Cards API，访问于 2026-09-30）。关于面向智能体消费而生的或改造过的发卡机构更全面的对比，参见我们的AI 智能体虚拟卡指南。

按用量计费的供应商（LLM API、数据 API、按调用计费的工具）。 卡在这类场景里会有点别扭，因为按用量计费往往是许多笔只有事后才知道具体金额的小额扣款。这正是稳定币（stablecoin）和协议原生轨道适用的地方：x402 的 upto 支付方案正是为这种情况设计的——它"authorizes a transfer of up to a maximum amount of funds from a client to a resource server"（授权从客户端向资源服务器转移不超过某个最大金额的资金），协议要求"the settled amount MUST be less than or equal to the authorized maximum"（结算金额必须小于或等于已授权的最大值）（x402 upto scheme 规范，访问于 2026-09-30，固定提交 dd927a2）。Circle 的 Agent Wallets 和 Coinbase 的 CDP Agentic Wallet 都为这种模式记录了按调用和按周期计的 USDC 限额（见第二步）。关于按支付轨道逐项对比的更全面内容，参见面向 AI 智能体的最佳支付 API。

已有的应付账款发票。 如果某个供应商已经走你的应付账款（accounts payable）流程——一张 net-30 发票、一笔电汇、一笔由人工设置的定期 ACH 代扣——就不要动这个流程。本指南中提到的控制机制是为智能体发起的卡和钱包付款设计的，不是用来取代人工审批的发票流程。给智能体只读权限去起草或标记发票供人工审批，而不是让它拥有付款权限。

第二步：先写策略，再接线

在给任何智能体发放卡或钱包之前，先按每个智能体、每个供应商类别写下：单笔最大消费、单周期最大消费、允许哪些供应商、屏蔽哪些类别，以及超过多少美元需要人工审批。用我们的消费策略模板作为起草文档——它存在的意义就是不让这一步在凌晨两点被跳过或临时拼凑。

你实际要配置的控制项，对应的是供应商今天已经记录好的字段。在卡这一侧：Stripe 的 spending_controls.spending_limits 字段族让你可以设置"spending limit rules [that] limit the total amount of spending for categories over intervals of time"（限制某些类别在一段时间内总消费额的消费上限规则）（Stripe spending controls guide，访问于 2026-09-30）；Lithic 则让一个账户可以同时携带多个限额，因为"accounts support multiple concurrent spend limits: daily, monthly, and lifetime"（账户支持同时并存的按日、按月和终身消费上限）（Lithic spend limits docs，访问于 2026-09-30），其速率限制规则（velocity rules）限制的是"the maximum total spend allowed within the period, in cents"（该周期内允许的最大总消费，以分计）（Lithic velocity limit rules，访问于 2026-09-30）。在钱包/API 这一侧：Circle 的 Agent Wallets 支持"transfer limits, recipient allowlists, and contract blocklists per agent wallet"（为每个智能体钱包设置转账限额、收款方白名单和合约黑名单）（Circle Agent Wallets，访问于 2026-09-30），并附带一条规则："limits must be monotonic: per-tx ≤ daily ≤ weekly ≤ monthly"（限额必须单调：单笔 ≤ 每日 ≤ 每周 ≤ 每月）（Circle Agent Wallet Policy skill，访问于 2026-09-30，固定提交 58ab8648）——也就是说你不能把每日上限设得比单笔上限还低。Coinbase 的 CDP Agentic Wallet 记录了一对配套的旋钮："Max per call: Max for a single payment (e.g., $0.05)"（单次调用上限：单笔付款的最大值，例如 0.05 美元）和"Max per session: Total session limit (e.g., $5.00)"（单个会话上限：会话总限额，例如 5.00 美元），并保证"agents respect these limits but can't change them"（智能体会遵守这些限制，但无法修改它们）（Coinbase CDP Agentic Wallet FAQ，访问于 2026-09-30）。Payman 的仪表盘策略直接命名了同样的三个控制杆："Per Transaction Maximum amount allowed per single payment"（单笔交易：单笔付款允许的最大金额），"Daily Limit Maximum total amount allowed per day"（每日限额：每日允许的最大总金额），以及一个"Threshold Amount above which manual approval is needed"（审批阈值：超过此金额需要人工审批）（Payman dashboard policies，Wayback 快照，抓取于 2025-11-18，访问于 2026-09-30——docs.paymanai.com 的实时域名在核查时返回证书错误；这份同一官方页面的存档副本可以正常打开）。关于谁记录了什么，更全面的逐工具对比参见AI 智能体消费治理工具对比和如何设置单智能体消费上限。

第三步：为超过阈值的一切接入审批

上限能挡住失控的消费；审批步骤能挡住上限之内的一笔坏付款。各家供应商在是否以及如何记录人工介入（human-in-the-loop）审批步骤上并不一致——把你的流程建立在实际有文档记录的能力上，而不是你以为存在的能力上：

  • AgentCard 要求在正式（production）卡发放前完成通行密钥（passkey）确认："Production answers 202 approval_pending with an approval_url the member confirms with a passkey"（正式环境会返回 202 approval_pending，并附带一个由成员用通行密钥确认的 approval_url）（AgentCard card creation API reference，访问于 2026-09-30）。
  • Payman 让你设置一个独立于硬性单笔和每日上限之外的美元Threshold（审批阈值），超过它"manual approval is needed"（需要人工审批）（同上述 Payman 来源）。
  • Stripe 记录的是发卡决策中的人工复核步骤，而不是一道拦截式的审批闸门："if anything looks off, decline it and flag with the agent or a human reviewer"（如果发现异常，就拒绝该笔交易，并标记给智能体或人工审核员）（Stripe Issuing for agents，访问于 2026-09-30）。另外，对于其通用 MCP 服务器（非 Issuing 专属），Stripe 要求用户在某些操作执行前"click the URL provided by your agent and review the details of the request"（点击智能体提供的链接并审核该请求的详情）（Stripe MCP docs，访问于 2026-09-30）。
  • Circle 不会以这种方式为单笔付款设卡，但它会为策略变更设卡："setting or resetting limits requires OTP confirmation in an interactive terminal session"（设置或重置限额需要在交互式终端会话中进行 OTP 确认）（引用同上的 Circle Agent Wallet Policy skill）——因此智能体（或攻破了智能体的攻击者）无法在没有人工输入一次性验证码的情况下上调自己的消费上限。

如果某个供应商没有记录上述任何一项，就把它当作一个缺口来对待：在智能体的调用到达该供应商之前，加上你自己的内部审批步骤，而不是假设该供应商已经落实了它自己都没说落实的机制。

第四步：在第一笔真实付款之前搭建审计与对账

你需要的是一条能把每一笔付款追溯回智能体、策略版本，以及（如果有的话）批准者的记录链——要在第一笔资金动之前就准备好，而不是事后从供应商的对账单里拼凑出来。Stripe 明确表示"every transaction your agent makes is traceable"（智能体发起的每一笔交易都是可追溯的）（Stripe Issuing for agents，访问于 2026-09-30）。Openfort 的智能体产品页面描述了"full audit trails"（完整的审计记录），并配有"spending caps, contract allowlists, and time-boxed sessions that let agents sign inside guardrails"（消费上限、合约白名单，以及让智能体在护栏内签名的限时会话）（Openfort AI agents page，访问于 2026-09-30）。Nevermined 描述了通过授权链条追溯一笔扣款的过程——"the system can trace it back to the delegation token, the agent's identity, and the specific user who granted the permission"（系统可以将其追溯到该授权令牌、智能体的身份，以及授予该权限的具体用户）（Nevermined agentic payments guide，访问于 2026-09-30）。不管你选择哪条轨道，在正式上线前都要确认它的日志能回答"哪个智能体、在哪个策略下、由谁批准"——而不只是"花了多少钱"。

第五步：提前为事故做好预案

一张卡被攻破的智能体使用、一次提示注入（prompt injection）触发了非预期的付款、一个钱包的限额被误调高——现在就规划好应对方式，而不是等事故发生时再想。冻结一张卡、吊销 API 密钥，以及发起争议，在这些轨道中的好几家都是有文档记录的、机械化的步骤，我们已经在一份专门的应急手册里列出了具体的命令和阈值：参见AI 智能体支付事故应急手册。

需要规划的风险

以下是供应商自己记录的运营层面风险——不是法律、责任、税务或监管方面的指导。除下面这些机制之外的任何事项，请与你的财务和法务团队确认。

  • 提示注入（prompt injection）。 Stripe 自己的 MCP 文档直接点名了这一点："enable human confirmation of tools and exercise caution when using the Stripe MCP with other servers to avoid prompt injection attacks"（启用工具的人工确认，并在将 Stripe MCP 与其他服务器一起使用时保持谨慎，以避免提示注入攻击）（Stripe MCP docs，访问于 2026-09-30）。任何在决定付款之前会读取不可信内容（供应商网站、一封邮件、一份文档）的智能体都暴露在这个风险之下；硬性上限和审批阈值是你的兜底手段，不能替代谨慎的工具设计。
  • 智能体上调自己的限额。 这正是 Circle 要求为限额变更专门做交互式 OTP 确认（见第三步）、而不是把限额变更当成一次普通 API 调用来处理的原因——一个能悄悄上调自己上限的智能体（或冒充智能体的东西），会让本指南中的所有其他控制机制形同虚设。
  • 按用量计费轨道上的结算不可撤销。 设计你的按调用和按会话上限（第二步）时，要假设该笔付款一旦结算就在该轨道上是终局的——不要指望事后能把一笔按用量计费的付款追回来；应查阅该具体轨道自己的退款或争议机制，而不要假设它一定存在。
  • 供应商侧的制裁与合规筛查不能替代你自己的白名单。 Circle 指出"all transfers are screened against sanctions controls before submission onchain"（所有转账在提交上链之前都会经过制裁管控筛查）（Circle Agent Wallets，访问于 2026-09-30）——这很有用，但它筛查的是收款方，而不是你的智能体本来是否就应该向这个收款方付款。你的供应商白名单（第二步）仍然是你自己的责任。

FAQ

让 AI 智能体向供应商付款，我们需要一个区块链钱包吗？ 不需要。如果你要付款的每个供应商都接受刷卡，一张带有单智能体限额的限定虚拟卡（第一步）就够用了。稳定币/API 轨道（如 Circle、Coinbase 的 CDP 钱包或 x402）专门适用于不通过卡网络计费的、按用量计费的 API 类供应商。

在让智能体付任何钱之前，我们至少需要什么控制？ 至少需要一个单笔上限和一个单周期上限，并且要尽量设置在轨道本身（发卡机构或钱包）支持的地方，而不是只放在你自己的应用代码里。由服务商持有的上限，即便你的应用逻辑出了 bug，依然会生效；只存在于你代码里的上限则不会。

智能体能被信任去设置或调整自己的消费上限吗？ 本文引用的两家会记录这一点的供应商都给出了否定答案。Circle 要求任何限额变更都必须经过人工 OTP 确认，Coinbase 的 CDP 钱包则明确表示"agents respect these limits but can't change them"（智能体会遵守这些限制，但无法修改它们）（均引用于第二步/第三步）。即便在没有为你强制执行这一点的轨道上，也应该在你自己的策略中把限额变更当作只能由人工完成的操作。

这和直接给智能体一张公司卡有什么不同？ 一张共享的公司卡对所有持卡人只有一个限额。本指南中的做法为每个智能体提供属于它自己的卡或钱包、属于它自己的上限、属于它自己的供应商白名单，以及属于它自己的审计记录——这样一个失控或被攻破的智能体，其影响范围只是一张卡，而不是整个团队的消费权限。

Pink Agentic AI Payments（PinkWallet 出品，早期访问）是 AI 智能体与公司资金之间的审批层：由自然语言规则、每个智能体的预算和人工审批来决定每一笔付款，之后才会签发一次性卡或银行转账。

本指南由 PinkWallet 发布，我们正在打造 Pink Agentic AI Payments（早期访问）。我们在这个领域并不中立，这正是本文每一条事实性陈述都链接到原始来源的原因。