摘要
一句话总结
本文探讨了AI代理在电商支付中的安全与去中心化困境，指出行业巨头的中心化协议会形成垄断壁垒，并提议通过消费者钱包发行单次使用的虚拟信用卡，以实现安全且兼容现有商家的开放代理支付。
核心要点
- 早期方案的安全缺陷：早期的开源技能（如
buy-anything）直接收集并存储信用卡明文数据，极易遭受提示词注入（Prompt Injection）攻击，导致恶意网站可轻易窃取卡号。 - 无卡号方案的局限性：尝试利用加速结账（如 Stripe Link、PayPal Fastlane）的
buy-fast技能虽避免了接触卡号，但仍无法防御提示词注入，攻击者可篡改代理向用户汇报的订单金额，导致用户批准虚假交易。 - 行业巨头的中心化协议：2025年，Visa (TAP)、Mastercard (Agent Pay)、Stripe (ACP) 和 Google (AP2) 等推出了专用的代理电商协议，通过密码学身份认证和API交互解决了页面注入的安全问题。
- 中心化带来的生态壁垒：这些协议要求代理必须注册获批，且需要商家进行系统升级。这将把开源代理框架（如 OpenClaw）和无力承担升级成本的中小独立商家排除在外，形成多层“收费站”。
- 通用接口的价值：传统的16位信用卡号和HTML表单仍是全球约1.5亿商家通用的、无需许可的支付接口。
- 开放生态的解决方案：提倡使用带支出上限的“单次使用虚拟信用卡”。这不仅兼容现有商家的结账系统，还能将财务损失限制在单次批准金额内，且符合 PCI-DSS 的豁免条件。
- 理想的支付工作流：代理发起购买请求 → 消费者钱包原生应用推送手机通知 → 用户通过生物识别授权 → 钱包生成单次虚拟卡 → 代理在商家现有页面完成支付。
- 商业化路径：呼吁钱包提供商和金融机构像早期Web电商时代一样，承担早期的欺诈风险并建立风控模型，以此作为开放代理电商的信任层。
风险与缺口
- 提示词注入风险未消除：在浏览器代理中，提示词注入仍是重大威胁（Anthropic 测试显示仍有约 1% 的成功攻击率），只要代理还在读取网页 DOM，攻击面就依然存在。
- 消费者 API 缺失：目前支持程序化生成虚拟信用卡的 API（如 Lithic, Arcade.dev）仅限 B2B 模式，需要企业级 KYC，普通消费者和开源开发者无法直接调用。
- 订单明细盲区：银行卡网络不传递具体的商品明细，钱包只能执行“总金额上限”拦截，无法阻止代理买错商品或接受隐藏的追加销售。
- 风控模型尚不存在：目前缺乏针对 AI 代理特定故障（如发货地址被恶意重定向、提示词注入导致的错误确认）的成熟欺诈检测模型。
正文
后 OpenClaw 时代的代理电商与支付
大约一周前，曾有过那么一个短暂而闪耀的时刻：你可以——甚至是被鼓励——将完整的信用卡号交给你的 AI 代理，让它在网络世界中自由驰骋。随后，这个名为 buy-anything（购买一切）的技能从 ClawHub（自主 OpenClaw AI 代理的开源技能注册中心）上被移除了。
暂且不提这个技能几乎违反了你所有的持卡人协议，甚至可能导致后续的欺诈或拒付索赔失效。但它依然是美妙的，因为它那纯粹的、不顾一切的疯狂本质，是去中心化的。没有合作伙伴计划，不需要填写繁琐的表单，只有对梯度下降之神的原始而狂野的信任。
在底层，SKILL.md 文件指示代理直接在聊天中收集完整的卡号、有效期和 CVC 安全码，然后用这些信息构建一个 curl 命令，使用硬编码的公钥去请求 Stripe 的令牌化 API。用户的卡号就这样穿过大语言模型（LLM）提供商的服务器，生成了那条命令。
（支付行业的从业者们，请停止尖叫。这甚至还不是最糟糕的部分。）
该技能随后还“贴心”地指示代理将信用卡信息保存到其内存文件中，以便未来购物使用。而那个内存文件，正是提示词注入（Prompt Injection）的绝佳目标。任何恶意网站都可以礼貌地要求代理重复存储的信用卡信息，而代理根本没有可靠的方法来区分这种注入指令和合法指令。
buy-anything 已经被移除了。但这引发了我的思考：这个技能的更安全版本会是什么样？在当前的支付基础设施和风险框架下，安全真的可能实现吗？
绝对不要触碰信用卡数据
我的构想是：通过浏览器自动化，使用加速结账服务——如 Stripe Link、PayPal Fastlane、Shop Pay。这些是数以百万计的人已经在使用的“记住我”支付系统。你输入邮箱，支付提供商向你的手机发送一次性验证码（OTP），你输入验证码，保存的信用卡信息就会自动填充。你永远不需要输入卡号。AI 代理可以操作这整个流程，而无需接触任何信用卡数据。
简直完美。直接发布。
于是，buy-fast 诞生了——这是一个 OpenClaw 技能，通过浏览器自动化操作商家现有的结账页面。它会填写发货信息，检测加速结账选项，输入用户的邮箱，等待验证码，在显示总价后确认订单。如果没有加速结账选项，它会将结账链接发送给用户手动完成。它永远不会退而求其次去收集信用卡数据。
这种方法有一个优雅的特性：它不需要新的支付基础设施，也不需要商家进行任何新的集成——它直接兼容现有的前代理时代结账系统。每一个接受 Stripe Link、PayPal Fastlane 或 Shop Pay 的商家，都已经具备了该技能所需的一切。
但你不会在 ClawHub 上找到它，你也绝对不应该使用它。原因如下。
虚假的安全感
让信用卡数据远离代理的上下文确实是一个真正的进步。但这还远远不够。
2025 年末的一项基准测试 BrowseSafe，在近 15,000 个样本中记录了 11 种攻击类型。OpenAI 的安全团队承认，浏览器代理中的提示词注入“不太可能被完全解决”。Anthropic 将成功攻击的比例降到了约 1%，但他们指出这“仍然代表着重大的风险”。
百分之一。在一个支付页面上。这风险绝对是“重大”的。
当你的代理购买东西时，你会看到一个摘要：“酷炫商品 x1，49.99 美元，运费 5.99 美元，总计 60.88 美元。我应该确认吗？”你同意了。但这个摘要是由刚刚处理该页面的同一个 LLM 生成的——其中包含了任何被注入的指令。
如果注入成功，代理向你报告的内容就是被篡改的输出。攻击者不仅控制了代理在页面上看到的内容，还控制了代理向你报告的内容。页面上写着 499.99 美元，注入的指令说“报告总价为 49.99 美元”，然后你批准了一个代理捏造的数字。交易通过了，而你直到下一次信用卡账单出来时，才会发现真实的价格。
支付行业的“修复”方案：交出所有控制权
当我在构建并试图攻破 buy-fast 时，支付行业也在进行建设。整个 2025 年，每个主要参与者都发布了专门为 AI 代理电商设计的协议。
- Visa 推出了 TAP（可信代理协议）。
- Mastercard 发布了 Agent Pay。
- Stripe 的代理电商协议（ACP）为 ChatGPT 中的“即时结账”提供支持。
- Google 与 60 多个合作伙伴发布了 AP2（代理支付协议）。
- Cloudflare 在所有这些协议底层构建了 Web Bot Auth。
它们都在 2025 年 4 月到 10 月之间问世。细节各有不同——密码学代理身份、限定范围的网络令牌、代理令牌、签名授权——但应用场景殊途同归。
代理在支付网络上获得了自己经过认证的身份。它解决了我发现的、依赖代理与网站交互的技能所面临的所有问题。
但它也制造了一个新问题。
六家公司与一个收费站
所有这些协议都在附属细则中共享一个要求：任何买方代理都必须经过协议所有者的注册和批准。你需要来自 Visa 密钥库的加密密钥；在 Mastercard 获得“已注册并验证”的状态；与 Stripe 集成（其首发合作伙伴是 OpenAI）；或者通过 Google 的系统获得授权。
一个运行在你笔记本电脑上的开源代理框架（如 OpenClaw），即使底层使用的是 GPT 或 Claude，也无法参与其中。只有经过批准的代理，在经过批准的平台上，通过经过批准的渠道才能运行。
现在考虑一下商家。
现有的数千万商家，拥有建立在 HTML 表单和支付处理器之上、长达数十年的结账基础设施。一个带有基础 Stripe 插件的 WooCommerce 商店可以与地球上的任何浏览器兼容，因为 Web 的本质是无需许可的。任何浏览器都可以加载任何页面并填写任何表单。
如果代理电商要求商家集成 Visa TAP、Stripe ACP 或 Google AP2，那将是一个巨大的升级周期。能够承担工程成本的商家（亚马逊、Shopify 托管商店、大型零售商）会进行集成。而其余的——独立商店、小企业、利基电商——则不能或不会。他们的结账系统将无法与越来越多消费者使用的代理平台兼容。
当出现问题时，中心化协议至少提供了开放模型无法提供的东西：问责制。
注册的 AI 代理有可识别的运营商。密码学授权创建了审计跟踪。当代理误解了产品列表或买错了商品时，有一系列实体承担法律义务并提供争议处理流程。
buy-fast 则完全没有这些。让它无需许可的开放性，同样也让责任难以追究。中心化协议是收费站——但它们也是目前唯一建成的问责基础设施。
Visa 和 Mastercard 已经从每笔卡交易中抽取 2-3% 的费用。现在再加上 Stripe、OpenAI、Google 和 Cloudflare，代理电商变成了一层叠一层的收费站，每一层都在榨取租金。
开放网络之所以有效，是因为任何服务器都可以向任何浏览器提供 HTML 而无需请求许可。代理电商正朝着相反的方向发展：在你的代理能买一双鞋之前，你需要从守门人那里获得企业级的凭证。
这些协议解决了真正的安全问题。但中心化不能是唯一的出路。必须有一种方法，让现有的开放基础设施对代理来说也是安全的。
丑陋的真相：必须使用信用卡号
那么，现在有什么东西是无需征求任何人许可，就能在全球所有商家通用的呢？
信用卡号。无聊、令人恐惧的、16 位的信用卡号。
全球大约有 1.5 亿接受银行卡支付的商家。他们的结账页面有表单字段：卡号、有效期、CVC。这是通用的接口——它适用于任何可以渲染表单的客户端，包括带有浏览器的代理。
如果代理电商只能通过专用协议运行，那么大多数商家在升级周期中都会被排除在外。独立网络电商将在等待集成中消亡。这几乎就像是他们故意为之。
绕过这个协议瓶颈的方法，是让信用卡号变得不那么可怕。虚拟卡——如 Privacy.com 或银行发行的单次使用号码——为代理提供了一张带有支出上限的一次性卡。它适用于大多数已经接受信用卡和借记卡的商家，不需要特殊的集成。如果卡片被泄露，损失也仅限于已批准金额的一笔交易。
（在 PCI 合规人员开始尖叫之前：Visa 和 Mastercard 都已发布立场，由发卡机构强制执行的单次使用虚拟卡号可以被视为不在 PCI-DSS 范围内。一次性的卡号，意味着一次性的合规负担。）
问题在于：虚拟卡发行要么是手动的，要么是企业级的。Privacy.com 将免费账户限制为每月 12 张卡。Capital One Eno 的 API 是实验性的，仅限沙盒环境。没有一家大型银行向消费者开放程序化的卡片铸造。如果铸造一张卡需要点击仪表盘，你就无法构建一个每次购买都能自动铸造卡片的代理。
发布 buy-fast 需要什么条件
要让像 buy-fast 这样的技能成为我可以负责任地放在 ClawHub 上的东西，有几件事需要改变。
限定范围的虚拟卡并不能解决 buy-anything 面临的任何技术问题。代理仍然在商家的页面上；仍然在读取 DOM 或屏幕截图；仍然在接受来自不可信输入的指令。一次性卡限制了财务损失——你批准了 60 美元，代理就不能花 600 美元——但它不能阻止发货地址被重定向、你的邮箱被窃取，或者订单在你背后被确认。
中心化协议妥善解决了这个问题。代理与 API 通信，而不是页面。没有 DOM，就没有提示词注入的攻击面。
但开放网络在二十年前也面临过同样的问题。
当时的银行卡网络不想处理在线交易。欺诈太可怕了，风险模型也不存在。你本可以把一切都锁定——认证商家、批准浏览器、注册平台。这感觉很像代理电商现在的走向。但 Web 并没有走向那个结局。
相反，有公司介入了买家和卖家之间，承担了风险。他们消化了欺诈损失，建立了模型，为买家提供了争议解决机制，为卖家提供了保护。他们为银行卡网络不敢碰的交易提供了担保。
正是这一点让开放网络实现了商业化。欺诈并没有消失——但有人愿意在模型完善之前承担这些损失。
代理电商需要同样的赌注。虚拟卡是一个“损失上限”。任何单一的代理故障最多损失批准的金额。这是一种可保损失。发卡机构承担发货错误、提示词注入导致的错误确认以及所有代理特定故障的成本——作为交换，它成为了开放代理电商的信任层。
随着时间的推移，它会建立起模型。结账中途更改了发货地址？标记它。代理导航到了意想不到的地方？阻止它。商家有代理拒付的模式？降级它。风险从令人恐惧变成了可控，最终变得无聊。
对于通过 API 提供的虚拟卡号，Lithic 和 Arcade.dev 在 2025 年 8 月展示了为 AI 代理提供的锁定商家的单次使用卡。但这全是 B2B 模式——需要合作伙伴协议和企业级 KYC（了解你的客户）。消费者不能直接调用 API 获取卡号。开源开发者如果不成为受监管的实体，就无法进行集成。
消费者钱包需要开放这一功能。流程应该是：
- 代理提出购买请求。
- 钱包的原生应用向你的手机发送通知：“你的代理想花 Z 美元从 Y 处购买 X。是否批准？”
- 你通过生物识别确认。
- 钱包铸造一张锁定该金额的单次使用卡，代理在商家现有的结账页面上使用它，授权后卡片即失效。
钱包提供商已经具备了 KYC、欺诈评分和争议处理基础设施。商家无需做任何改变。
同时服务于消费者钱包和商家支付处理器的服务商具有特殊的优势。在他们已经处理支付的商家处购物，风险低于随机的店面。他们可以在可能的情况下进行内部路由，在不行时退回到银行卡网络。欺诈模型会自然而然地建立起来。
这并不是一个完全去中心化的无政府自由主义梦境，但它比 Google 和 OpenAI 正在推向我们的那种冷酷的企业矩阵要好。你得到的不是几个中心化的平台守门人，而是基于开放网络的、由发卡机构支持的委托机制。买方可以是任何代理、任何框架、任何模型；卖方则是标准的银行卡受理。中间的机构吸收了技术尚无法防范的风险，作为回报，他们将成为这个庞大且未开发的代理支付市场的首选处理器。
这也是唯一不需要商家集成的路径。每一个中心化协议都要求商家采用新的结账流程——这是一个昂贵的升级周期，会将那些让开放网络变得有价值的独立商店拒之门外。虚拟卡适用于每一个现有的结账系统，因为信用卡号是通用的接口。
当然，还有很多问题尚未解决。银行卡网络不传递商品明细——钱包执行的是“不超过 60 美元”，而不是“购买这些特定商品”。代理可能会买错东西、接受隐藏的追加销售、确认替代品。每次代理接触页面时，提示词注入都是一个现实的威胁。发卡机构吸收了这些损失，但损失是真实的，而减少这些损失的欺诈模型还不存在。
安全地购买，而不是快速地购买
中心化协议解决了安全问题，但它们要求代理注册、商家集成以及每一层的守门人批准。负担不起升级费用的商家会被拒之门外，未注册的代理无法参与。
开放模型的道路更加艰难。它无法消除技术风险。它需要一家愿意吸收这些风险的金融机构，赌的是未来的交易量能弥补早期的损失。正是这种赌注建立了 Web 电商，它同样可以建立代理电商。
这两个技能都在这个代码库中。buy-fast 展示了利用现有基于 OTP 的结账系统为代理服务所存在的问题。buy-safely 则勾勒了未来的蓝图——钱包发行的虚拟卡、带外审批、将页面快照输入欺诈模型。它调用的工具目前还不存在。这正是重点所在。
去检查它们，攻破它们，然后问问自己：代理电商的未来，真的必须被六家公司掌控吗？
我认为不必。