代理支付：基础设施已就绪，为何实际使用近乎空白？

以下是 2026 年代理支付的一个奇怪现象：基础设施比几乎所有人都预期的要先进，而实际使用情况却比几乎所有人都愿意承认的要落后。

六月初，万事达卡推出了 Agent Pay for Machines，这是一个面向跨卡和稳定币的机器速度支付系统，启动合作伙伴包括 Coinbase、Stripe、Polygon、Ripple 和 Solana。x402 协议让软件能用稳定币支付网络请求，现在已在 Linux 基金会下拥有一个中立的管理机构。Stripe 和 Tempo 发布了一个并行标准。AWS 将代理支付功能集成到了 Bedrock 中。从设计上看，代理经济已经拥有了自己的支付层。

然后你再看看实际数据。根据链上估算，自主代理支付的交易量仅占稳定币总量的极小一部分，每日交易数量在早期投机性飙升后急剧下降。轨道已经建好，火车却几乎是空的。

这篇文章是从建设者的角度来讲述这个故事，而不是主旨演讲式的宏观宣讲。我们将用通俗的语言解释代理支付到底是什么，为什么代理会使用加密货币，x402 支付如何通过真实代码实际运作，它在哪些地方今天就能工作，又在哪些地方会失效，需要关注的安全陷阱，以及一份简短的检查清单，帮助你决定现在是否应该构建这些东西。

什么是代理支付？用通俗的话说

代理支付是由软件代理自主发起并完成的交易，不需要人工输入卡号或点击确认。代理发现成本，选择支付方式，签署交易，并在自己的工作流程内验证结果。在当前的实践中，这几乎总是意味着使用 USDC 等稳定币支付，因为这是自主程序实际能用的轨道。

去掉术语，其实很简单。你的软件需要频繁地购买小东西。一次数据查询、一次搜索调用、一次模型推理、一个代理会话。每次花费几分之一美分，一个繁忙的代理每分钟可能要执行数百次。

人类处理这种情况是靠保存的卡和月度账单。但代理做不到——它没有人类意义上的钱包，没有账单关系，也没有耐心面对结账页面。因此，代理需要一种对代码原生、秒级结算、能在互不相识的双方之间工作的支付方式。

为什么 AI Agent 不能直接使用信用卡？

有两堵硬墙阻止代理使用常规支付方式：身份和经济。软件无法通过银行开户所需的身份验证，但它可以持有加密钱包，仅需一个私钥。同时，卡网络每笔收费的最低费用接近三十美分，这会让任何价值几分之一美分的支付变得毫无意义。低手续费的链上的稳定币同时击穿了这两堵墙。

身份墙是结构性的。银行和卡网络是围绕经过验证的个人或注册企业建立的，而自主代理两者都不是。它无法完成身份验证，而且你通常也不想把个人卡交给它，让它无上限地消费。

经济墙纯粹是数学问题。如果一个代理为单次 API 调用支付十分之一美分，三十美分的手续费就是购买金额的三百倍。只有当手续费小于支付金额时，这种模式才成立。在 Base 或 Solana 这样的链上，稳定币转账的费用仅为几分之一美分，结算时间大约一秒或更短。这就是加密货币进入这个讨论的全部原因——不是意识形态，而是因为这是唯一数字上可行的轨道。

x402 支付实际上是如何工作的？

x402 重新启用了长期休眠的 HTTP 402“Payment Required”状态码。客户端请求付费资源。服务器回复 402 并附上支付条款。客户端在本地签署一笔稳定币转账，将证明附加到同一请求上，然后重试。一个验证器检查签名并在链上结算支付，然后服务器返回数据。整个过程只需几秒钟，不需要任何账户。

走一遍握手流程，它就不再神秘。

首先，代理发出一个普通请求。没什么特别，只是对一个端点的常规调用。

第二，服务器发现没有附上支付，于是返回一个 402，并附带一个小型头部信息，描述它要什么：金额、代币、链和收款地址。

第三，代理读取这些条款，签署一个转账授权。使用 USDC 时，这采用免 Gas 费转账标准，因此代理甚至不需要该链的原生 Gas 代币来支付。私钥在本地签名，从不离开代理的进程。

第四，代理将签名支付放在头部中，重试完全相同的请求。一个验证器服务（负责链上部分）检查签名并结算转账。服务器收到确认后返回资源，通常还附带交易哈希作为收据。

这一切背后的核心理念是“支付即访问”。如果请求能支付，就能得到服务。无需注册、无需 API 密钥、无需重置密码。

代理支付的实际代码长什么样？

在服务器端添加 x402 只需要几行代码。你在受保护的路由上包裹支付中间件，指定价格、网络和收款钱包。在代理端，你包裹一次 HTTP 客户端，这样任何 402 响应都会自动支付并重试。结果就是服务器端有了一个付费 API，代理则无需任何人工步骤即可支付。

以下是一个最简单的卖家示例。这是一个 Express 服务器，使用 Coinbase 的参考 SDK，为价格快照收取十分之一美分。处理程序仅在支付清算后运行。

import express from "express";
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

const app = express();
const payTo = "0xYourReceivingAddress";
// 验证器为你检查签名并在链上结算支付
const facilitator = new HTTPFacilitatorClient({ url: "https://x402.org/facilitator" });
const server = new x402ResourceServer(facilitator)
  .register("eip155:8453", new ExactEvmScheme()); // Base 主网
app.use(
  paymentMiddleware(
    {
      "GET /market-data": {
        accepts: [{ scheme: "exact", price: "$0.001", network: "eip155:8453", payTo }],
        description: "一次实时价格快照",
        mimeType: "application/json",
      },
    },
    server
  )
);
// 仅在支付验证后运行
app.get("/market-data", (req, res) => {
  res.json({ symbol: "ETH", price: 3284.12, ts: Date.now() });
});
app.listen(4021);

现在来看买家端，即代理。你包裹一次标准的 fetch 客户端。之后，402 会自动为你处理：包装器签署支付、附上并重试。

import { wrapFetchWithPayment } from "@x402/fetch";
import { privateKeyToAccount } from "viem/accounts";

// 代理的钱包。密钥在本地签署支付，从不离开进程。
const account = privateKeyToAccount(process.env.AGENT_PRIVATE_KEY);
// 未来的每个请求现在都可以自动支付并重试
const fetchWithPay = wrapFetchWithPayment(fetch, account);
const res = await fetchWithPay("https://api.example.com/market-data");
const data = await res.json();
console.log(data); // { symbol: "ETH", price: 3284.12, ts: ... }

这就是真正有效的地方。开发者可以在一个下午完成配置，通过更改网络和代币，它可以在 Base、Solana 和其他链上工作。握手是真实的，SDK 是真实的，费用也如宣传的那样低。

那么，今天哪些实际上是可行的，哪些还不行？

可行的是：协议、SDK 和单位经济学。通过 HTTP 为每个请求支付几分之一美分是真实且已在多条链上运行的。尚不可行的是：需求。自主代理支付在稳定币总量中占比极小，早期使用量飙升后急剧下降，观察到的流量中有相当一部分是测试和自我交易，而不是真正的商业活动。基础设施领先于需求。

请记住我，以便更快登录

让我具体说明，因为差距就是整个故事。

在“可行”方面，x402 已在 Base 上处理了超过一亿笔交易，在 Solana 上处理了数千万笔，年化交易量约六亿美元，且零协议费用。标准领域的竞争虽然拥挤，但这是健康的：Coinbase 的 x402、Stripe 和 Tempo 的机器支付协议、Google 的代理支付协议，以及 Visa、Ripple 和 AWS 的动作。这些轨道并非空中楼阁。

在“不可行”方面，该交易量被总稳定币活动（每年数万亿美元）相形见绌。代理发起的支付在这个基数上只是一个四舍五入的误差。2025 年末看似爆炸式的每日交易数量在几个月内就跌至峰值的大部分。链上分析师还指出，剩余活动中的一部分是人为制造的，并非真正的买家向真正的卖家付款。

诚实的解读是，这是一个基础设施驱动的市场，而非需求驱动的市场。支付轨道的供应比实际需要大规模花钱的代理群体更早到来。这不是失败，而是正常的早期阶段。但这会改变你应该如何构建：你正在为一种真实但需求薄弱的能力而构建，这意味着你要优化安全性和可选择性，而不是还没有的量。

代理支付的安全考虑有哪些？

当代理能够自主转移资金时，核心风险就发生了变化。最大的新威胁是操纵：能够支付的代理可能通过提示注入或恶意输入被诱骗支付。其次是密钥泄露，因为泄露的代理密钥意味着钱包被掏空。再加上没有原生退款、验证器信任和重放风险。防御措施包括：支出上限、收款方白名单、范围限定且短期有效的密钥、幂等处理程序，以及超出阈值时的人工检查点。

这是大多数团队准备不足的地方，因此值得认真对待。

最危险的故障不是智能合约漏洞，而是被操纵的代理。如果你的代理读取不受信任的内容并且持有钱包，那么隐藏在该内容中的精心构造的指令可能会尝试重定向支付或夸大金额。之前导致数据泄露的相同提示注入问题现在会直接花钱。将任何具有支付能力的代理视为特权角色，永远不要将原始的不受信任输入直接流入支付决策。

密钥管理是第二道墙。代理的私钥是其资金的承载权限。不要将长期存在且高余额的密钥嵌入到接触开放互联网的进程中。使用带有少量余额的限定范围钱包，定期轮换，并在可能的情况下使用智能合约账户——它可以在钱包层面强制执行限制，而不仅仅是依赖应用代码。

实际的缓解措施并不奇特。在每个支付前面放一个策略门。

const POLICY = {
  maxPerCall: 0.05,   // 单次支付上限（美元）
  dailyCap: 25,       // 每日上限（美元）
  allowedPayees: new Set(["0xKnownVendorA", "0xKnownVendorB"]),
};
let spentToday = 0;

function assertPaymentAllowed({ amountUsd, payTo }) {
  if (amountUsd > POLICY.maxPerCall) throw new Error("超出单次调用限制");
  if (spentToday + amountUsd > POLICY.dailyCap) throw new Error("超出每日上限");
  if (!POLICY.allowedPayees.has(payTo)) throw new Error("收款方不在白名单中");
  spentToday += amountUsd;
  // 任何超过较高阈值的金额应路由到人工处理，而非自动支付
}

还有一些在生产中让团队头疼的问题。x402 没有协议级别的退款，因此如果你的处理程序在结算后失败，买家就白付了钱。确保处理程序是幂等的，并允许相同的签名支付安全地重试。验证器是便利的，但也是单点故障，因此要进行监控并有备用方案。持久化每一笔结算，包括交易哈希和金额，用于对账和税务。在身份方面，依赖新兴的“Know Your Agent”标准和签名授权，以便能够证明代理确实被授权消费。

还有一点，因为它无处不在：密钥泄露。代理工具的配置文件已经在公开仓库中暴露了数万个实时凭据。在已提交配置中的钱包密钥就是送给攻击者的礼物。将密钥保存在保险库中，永远不要放在仓库里。

你现在应该构建代理支付吗？

如果你有一个真实、高频率、低价值的支付需求，且卡网络无法经济地满足，并且你能够从一开始就实施严格的支出控制，那么现在就开始构建。如果你只是在追逐叙事，而没有实际需要亚美分、无账户支付的工作负载，那么就等等。技术已经准备好投产，但需求尚未跟上。对大多数团队来说，正确的做法是进行一个有限制的试点，而不是全面部署。

在决定之前，先用这个快速检查清单过一遍：

• 你是否有真实的亚美分、高频支付需求，还是只是在追随趋势？只有前者值得构建。
• 在代理实际转移真钱之前，你是否能强制实施单次调用和每日支出上限，以及收款方白名单？如果不能，就停在这里。
• 在支付时刻，你的代理是否与不受信任的输入隔离，以防止恶意提示重定向资金？
• 你的密钥是否范围限定、余额低、定期轮换，并且不在源代码控制中？
• 你的付费处理程序是否幂等，并且每笔结算都按交易哈希记录？
• 对于超过设定阈值的任何金额，你是否有手动检查点？

如果你能对以上所有问题回答“是”，那么一个有限制的小型试点就是一个明智的选择，你将在一个显然会变得重要的轨道上处于早期位置。如果不能，诚实的建议是等等——因为一个没有防护的带钱包代理的下行风险是即时且不可逆的。

轨道已准备好。为你的实际旅程而构建。

代理支付属于那些基础设施真正在炒作超越现实之前就已交付的罕见案例之一。握手有效。费用真实。SDK 几分钟即可安装。这些都不存在疑问。

缺少的是交易量，而交易量无法通过新闻稿凭空制造。在这里获胜的团队不会是那些拥有最响亮的代理经济演示幻灯片的团队，而是那些悄悄构建了一条小而安全、装备精良的支付路径，学习了它如何与真实资金运作，并在火车最终满员时已做好准备的团队。

轨道已建好。决定你实际要运输什么，先装上护栏，然后你就能在站台等待它到来。

正在构建代理就绪的支付基础设施，或审计能够花钱的代理的控制层？这个验证和控制层才是真实风险和真正护城河所在。这是我们做的工作。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～