Agentic Payment 研究报告

生成日期：2026-04-21。工作区：/Users/jc/ws/codex-start。Zotero 来源：本机 /Users/jc/Zotero/zotero.sqlite，collection ai-agent，collectionID=29。报告综合本地 Zotero 论文、官方网页、官方文档、GitHub 规范、公司新闻稿、监管/标准资料与多路 subagent 调研笔记。所有结论按“已核事实、作者观点、推论/建议”分层表达；凡是未能看到全文或仅为公司自述，均保守标注。

一、执行摘要

1.1 定义与范围

Agentic payment 指 AI agent 在用户或组织授权范围内，发现商品、服务或 API，形成可执行购买意图，调用支付凭证或钱包并完成资金转移的体系。它不是单一产品，也不是单一协议，而是一个分层栈：A2A/MCP 让 agent 找到并调用对方，ACP/AP2 等让商户、agent 和支付网络理解交易，x402/L402/MPP 等让机器按 HTTP 或 API 请求付款，DID/VC/ERC-8004/KYA 解决主体与信任，TEE/ZK/日志/策略引擎解决执行证明和审计，Visa/Mastercard/PayPal/Stripe/Circle/Coinbase 等支付网络或基础设施则负责真实资金轨道、风控和商户接入。

本报告的研究范围覆盖截至 2026 年 4 月的所有主要 agentic payment 协议、产品和研究论文。研究对象包括但不限于：(1) 开放协议——AP2、ACP、x402、L402、A2A、MCP；(2) 企业产品——Visa Intelligent Commerce、Mastercard Agent Pay、PayPal Agentic Commerce Services、Stripe Instant Checkout；(3) Crypto-native 基础设施——Coinbase CDP、Circle Wallets、Skyfire、Nevermined、SAKSHI；(4) 学术研究——A402、SoK: Blockchain A2A Payments、Towards Multi-Agent Economies、Secure Autonomous Agent Payments、Inter-Agent Trust Models、BAID、BlockA2A、Zero-Trust IAM。报告不覆盖纯理论的 agent 架构研究（如 ReAct、Chain-of-Thought 等 LLM reasoning 方法论），也不覆盖不涉及资金流动的 agent 协作协议。

1.2 核心结论

最核心的结论是：现在已经可以做真实的低额机器支付和受控 agentic commerce，但大规模开放式 autonomous payment 还缺三件事：可机器执行的授权语义、支付与服务履约的端到端绑定、以及跨平台责任和争议规则。

这三个缺口不是独立的。授权语义的缺失意味着 agent 的支付行为无法被精确约束——即使有 spend cap，也无法判断"花 50 美元买了什么"是否符合用户意图。支付-履约解耦意味着付款完成不等于服务交付——x402 能证明你付了钱，但不能证明你收到了正确的 API 响应。责任和争议规则的缺失意味着当出错时没有人知道该怎么办——如果 agent 被 prompt injection 诱导购买了错误商品，应该由用户、agent 平台、商户还是支付网络承担损失？

这三个缺口之间的耦合关系可以用一个简单的例子说明：假设一个 travel agent 为用户预订了机票。如果授权语义不完整（只设了金额上限但没设航空公司约束），agent 可能选择了用户不想要的航空公司。如果支付-履约不绑定，agent 付了钱但航空公司系统故障没出票。如果争议规则不明确，用户不知道应该向 agent 平台、航空公司还是支付网络投诉退款。三个问题叠加，就是当前 agentic payment 落地的核心阻力。

1.3 三大落地路线

从落地项目看，最成熟的路线有三类。

第一类：传统支付网络的 agentic commerce。 OpenAI/Stripe ACP 与 Instant Checkout、Visa Intelligent Commerce、Mastercard Agent Pay、PayPal agentic commerce services 属于此类。它们的优势是复用现有 card/wallet/PSP 的风控、争议、tokenization、商户关系和消费者保护。这条路线的哲学是"把 agent 当作一个新的 checkout 前端"——agent 可以帮用户发现商品、比价、推荐，但支付本身仍然走传统的 card-not-present 或 tokenized payment 流程，商户仍然是 merchant of record，争议仍然走 chargeback 流程。这条路线最大的优势是不需要重建信任基础设施——所有现有的消费者保护、反欺诈、KYC/AML 流程都可以复用。最大的不足是无法支持真正的 machine-to-machine 交易（因为需要人类用户作为 cardholder）、无法做到按 API call 的微支付（因为最低交易额和手续费限制）、以及 agent 的身份在 card network 层面不可见。

第二类：Crypto-native 或 API-native micropayment。 Coinbase x402、Cloudflare x402、Circle USDC+x402、L402/Lightning、Nevermined、Skyfire 等属于此类。它们的优势是无账户、可编程、按次计费、跨境和适合机器到机器场景。这条路线的哲学是"把支付变成 HTTP 的一部分"——agent 调用 API 时，如果需要付费，服务端返回 HTTP 402 和支付要求，agent 签名支付并重试。整个流程无需人类干预、无需开户、无需发票。最大的优势是可以支持每次 0.001 美元级别的微支付，完美适配 AI agent 的 API 调用模式。最大的不足是缺乏消费者保护（链上交易不可逆转）、合规框架不明确（stablecoin 的 money transmission 义务因司法管辖区而异）、以及付款只证明资金移动不证明服务履约。

第三类：信任与身份基础设施。 AP2 mandates、ERC-8004、DID/VC、KYA、AgentCard registry、TEE/ZK proof 属于此类。它们不直接完成支付，却决定支付能不能被商户、issuer、用户和监管者接受。AP2 的 Intent/Cart/Payment Mandate 提供了一种方式让用户的授权意图在整个支付链路中保持可验证——从"我想买一双运动鞋"到"我确认这双 Nike Air Max 270，$149.99"到"我授权从 Visa xxxx1234 扣款"。ERC-8004 试图在链上建立 agent 的可验证身份和信誉记录。DID/VC 提供了跨平台的身份框架。TEE/ZK 提供了执行证明——证明某段代码在可信环境中运行，或证明某个计算结果正确而不暴露输入。

三条路线不是互斥的。一个完整的 agentic payment 系统很可能同时使用 AP2 mandate 做授权证据、ACP/Stripe 做消费品 checkout、x402 做 API micropayment、ERC-8004/DID 做 agent 身份。本报告的一个核心论点是：把其中任何一条路线当作完整答案，都会漏掉其他层的风险。

1.4 学术研究共识

Zotero 中最关键的研究线也高度一致。A402 认为 x402 的主要不足是付款与服务执行解耦，提出 Atomic Service Channels、TEE-assisted adaptor signatures 和 Liquidity Vault。SoK 将 agent-to-agent blockchain payments 拆成 discovery、authorization、execution、accounting 四阶段，指出现有方案常常局部有效但端到端断裂。Towards Multi-Agent Economies 展示了 A2A + 链上 AgentCard + x402 的可行原型，同时承认统一 registry、链上延迟和私钥资金安全仍是问题。Secure Autonomous Agent Payments、Inter-Agent Trust Models、BAID、BlockA2A、Zero-Trust IAM 等论文共同说明：身份、授权、证明、约束、声誉和 stake 必须组合，不能只靠一个 AgentCard、一笔链上交易或一次用户确认。

这些学术研究和产业实践之间存在一个有趣的张力。产业界（Visa、Mastercard、PayPal、Stripe）倾向于从现有基础设施出发，渐进式地添加 agent 支持——用 tokenization 代替 card number、用 agentic token 限制权限、用现有 dispute 流程处理问题。学术界则倾向于从第一原理出发设计全新的 protocol stack——A402 重新定义 payment channel 的语义、SoK 要求四阶段端到端绑定、TIVA 框架组合 DID/VC/ZKP/TEE。产业界的优势是落地速度和商户覆盖；学术界的优势是安全性和可组合性。最终的方案很可能是两者的交叉：产业基础设施 + 学术安全模型。

1.5 十二类核心难点

本报告将 Agentic payment 的难点归纳为十二类：用户授权与意图绑定、代理身份与 KYA、责任归属、争议/退款/履约、AML/KYC/制裁、PCI 与 tokenization、prompt/tool injection、spend limits、支付与服务执行解耦、隐私、审计、产品体验与商户接入。

它们彼此耦合。例如，支付 token 限制金额可以降低损失，但不能判断商品是否符合用户意图；链上交易哈希能证明转账，但不能证明服务交付；AP2 mandate 能证明某个 cart 被用户确认，但不能证明 agent 在确认前没有被恶意网页影响；ERC-8004 可以登记 agent 身份和验证记录，但不能保证 advertised capability 一定真实。

这十二类难点可以按"谁的问题"分成四组：(1) 用户侧——授权、意图、spend limits、隐私，核心是"用户是否真的想要这个交易"；(2) Agent 侧——身份、执行证明、prompt injection，核心是"agent 是否可信且行为正确"；(3) 商户/服务侧——履约、退款、商户接入、服务绑定，核心是"服务是否按承诺交付"；(4) 系统侧——责任归属、合规、审计，核心是"出错时谁负责以及如何解决"。

真正可行的方向是把同一个 correlation id 贯穿用户意图、agent 身份、策略决策、工具执行、支付凭证、服务结果和争议证据。这个 correlation id 不一定是链上的 transaction hash，也可以是 AP2 mandate hash、ACP session id、或者自定义的 UUID——关键是它必须把所有层面的证据串在一起，使得事后审计和争议裁决有据可查。

1.6 报告结构概览

本报告共十七章加三个附录。第二章介绍研究方法和证据等级。第三章厘清 agentic payment 的概念边界和五层栈。第四章综述 Zotero 核心论文。第五章全景式介绍已落地项目。第六章分析协议与信任栈的覆盖范围和盲区。第七章系统性展开十二类痛点。第八章深拆区块链与微支付技术路线。第九章按场景给出落地路径建议。第十章提出推荐参考架构。第十一章提供事实核查矩阵。第十二章给出短中长期路线图。第十三章做项目-痛点交叉审查。第十四章提供工程控制清单。第十五章批驳常见误区。第十六章给出部署模板。第十七章是结论。附录包括来源索引、Zotero 材料说明和字数统计。

二、研究方法、证据等级与事实核查原则

2.1 三条证据链

本次研究采用三条证据链并行。第一条是 Zotero 本地证据链：只读查询 /Users/jc/Zotero/zotero.sqlite，确认 collection ai-agent 共有 25 个条目，去重后直接相关核心论文 7 篇，支持性论文 3 篇以上。对有本地 PDF 的 A402、SoK、Towards Multi-Agent Economies 做文本抽取；对 Zotero 附件缺失但有 arXiv 的论文下载官方 PDF 做本地文本抽取。第二条是官方/标准网页证据链：优先官方文档、官方 GitHub、公司 newsroom、EIP/MDN/PCI/FinCEN/OFAC/FATF/NIST 等源。第三条是 subagent 分工证据链：分别让 subagent 做 Zotero 去重、已落地项目、协议身份栈、支付安全合规、区块链微支付技术路线；每个 subagent 只负责小块，并在结果中给出链接和不确定性。报告最终只采用可追溯来源，不采用无法核验的营销说法作为硬事实。

三条证据链之间的交叉验证逻辑如下。当 Zotero 论文提出一个协议缺口（如 A402 指出 x402 不绑定服务执行），报告会用官方文档核查该协议是否确实缺少该功能，同时用 subagent 搜索是否有后续更新或第三方扩展填补了该缺口。当官方新闻稿宣布一个新产品（如 Mastercard Agent Pay），报告会用论文框架评估该产品在 SoK 四阶段中覆盖了哪些阶段，同时检查是否有独立的性能测试或安全分析。当 subagent 调研发现一个新项目，报告会要求至少一个 A 级或 B 级来源确认其存在和基本功能，否则只在脚注中提及。

2.2 证据等级分类

证据等级分为四类。

A 级是官方规范、官方文档、标准组织或监管机构资料，例如 AP2 规格、x402 Coinbase 文档、OpenAI/Stripe ACP 官方资料、EIP-8004、MCP 官方文档、A2A 官方公告、PCI DSS 标准、FinCEN 指导意见、OFAC 制裁合规指南、FATF 虚拟资产建议。A 级来源的特点是：(1) 有明确的发布机构且该机构对内容负责；(2) 有版本控制和更新历史；(3) 可以被第三方独立访问和验证。A 级来源在报告中可以直接作为事实依据，无需额外限定词。

B 级是公司新闻稿和产品页，例如 Mastercard Agent Pay 发布公告、Visa Agentic Commerce 产品页、PayPal agentic commerce services 新闻稿、Skyfire 产品介绍、Nevermined 官方网站。B 级来源的特点是：(1) 由利益相关方自行发布；(2) 可能包含前瞻性声明（forward-looking statements）；(3) 产品可用性和性能未经独立验证。B 级可证明"公司这样发布或这样声称"，但不能证明大规模生产指标。报告中使用 B 级来源时，会用"公司称""据新闻稿"等限定词。

C 级是 arXiv/预印本或学术论文，它们可作为设计和威胁模型证据，但不是监管依据，也不等同生产部署。C 级来源的特点是：(1) 经过同行评审或至少经过学术社区的公开审视；(2) 提供可复现的方法论和实验设计；(3) 但实验环境通常与生产环境差异显著。报告中使用 C 级来源时，会用"论文指出""实验环境中""研究原型显示"等限定词，不把实验数字等同生产承诺。

D 级是第三方媒体、聚合页面和社区讨论，仅用于发现线索，除非被官方来源确认，否则不作为核心事实。D 级来源包括 TechCrunch/CoinDesk/The Block 等媒体报道、GitHub Issues/Discussions、Twitter/X 讨论、Reddit 帖子等。报告中极少直接引用 D 级来源，除非它提供了其他来源无法获得的独特信息（如某个 bug 的首次公开报告）。

2.3 措辞规范与表达约束

报告中常见措辞也严格区分：'官方文档称' 表示可由官方页面核验；'论文指出' 表示作者观点或实验结论；'本报告推断' 表示基于多源交叉后的分析；'未公开/未核实' 表示未找到足够证据。对日期和状态使用绝对日期，例如截至 2026-04-21，避免把"今天""近期"这类相对表述留给未来读者误读。

具体的措辞约束规则如下：(1) 不使用"革命性""颠覆性""游戏规则改变者"等营销词汇描述任何项目。(2) 不把未经生产验证的性能数字作为硬承诺引用——始终标注实验环境和样本量。(3) 不把某个项目在某一层的能力等同为全栈能力——每次引用时说明该项目处于五层栈中的哪一层或哪几层。(4) 不把"可以"和"已经在"混淆——"可以"表示技术上可行但未必已部署，"已经在"表示有公开的生产部署证据。(5) 不把标准草案等同为已采纳标准——ERC-8004 是 Draft EIP，AP2 是 v0.x 规范，都需要标注其成熟度。

2.4 研究局限与偏差声明

本研究存在以下已知局限。第一，时间截止于 2026-04-21，此后的协议更新、产品发布和监管变化不在覆盖范围内——agentic payment 是快速演进的领域，本报告的具体产品状态可能在数月内过时。第二，报告以公开可访问的英文和中文资料为主，可能遗漏非英语/非中文社区的重要项目（如日本、韩国、印度的本地 agentic payment 方案）。第三，部分项目处于 private beta 或 NDA 保护下，报告只能基于公开声明评估，无法验证内部实现。第四，作者与报告中提及的任何公司不存在利益关系，但 Zotero 论文集的选择可能存在选择偏差——被收入 Zotero 的论文倾向于区块链和密码学方向，传统支付网络内部的技术报告可能覆盖不足。第五，subagent 调研的质量受 web 搜索覆盖范围和爬虫限制影响，部分官方页面可能在调研时不可访问。

三、概念边界：Agentic payment 不等于"AI 自动刷卡"

3.1 常见误解与风险

Agentic payment 常被误解为把用户信用卡交给一个 LLM。这个理解风险极高，也不符合当前主流方案。更准确地说，agentic payment 是把"理解和规划"与"资金移动"分离：LLM 或 agent 可负责理解用户需求、搜索候选项、形成购物车或服务调用计划，但资金移动必须通过确定性协议、受限支付凭证、签名授权、策略引擎、风控模型和审计日志。

这个分离原则之所以关键，是因为 LLM 在支付场景中有三个根本性弱点。第一，LLM 是概率模型，无法保证每次生成的支付指令都正确——它可能把 $149.99 写成$ 1499.9，可能混淆两个名称相似的商品，可能在多轮对话中遗忘用户的约束条件。第二，LLM 容易受到 prompt injection 和 indirect prompt injection 攻击——恶意网页、商品描述或 API 响应中嵌入的指令可能诱导 agent 改变购买目标或增加金额。第三，LLM 没有内在的价值判断能力——它不知道 $500 对一个用户是大额还是小额，不知道某个商品是否符合用户的真实偏好，不知道某个服务提供者是否可靠。

因此，把 LLM 放在支付链路的"决策"位置是危险的。所有主流方案都在不同程度上把 LLM 限制在"建议"或"执行"位置，而把"授权"和"资金移动"放在确定性系统中。OpenAI/Stripe ACP 明确把 merchant of record、fulfillment、returns、support 留给商户；AP2 明确用 mandates 证明用户意图；Visa/Mastercard/PayPal 路线明确复用 tokenization、authentication、buyer protection 和 dispute resolution；x402 路线虽然更开放，但也把付款 payload、nonce、deadline、facilitator verification 等协议化。

3.2 与相关概念的区分

Agentic payment 需要与以下几个容易混淆的概念做严格区分。

与 automated payment 的区分。 Automated payment（自动支付）包括定期扣款（recurring billing）、自动充值（auto-reload）、规则触发支付（if-then-pay）等。这些是确定性的、预先配置的、无需实时决策的。Agentic payment 的核心区别是 agent 在支付链路中承担了发现、比较、选择和协商的角色——这些是非确定性的、需要推理的、可能产生错误的。一个每月自动扣 $9.99 的 Netflix 订阅是 automated payment；一个 agent 帮你在多个流媒体服务中比价并选择最优方案是 agentic payment。

与 programmatic payment 的区分。 Programmatic payment（编程式支付）指通过 API 发起的支付，如 Stripe API、PayPal API、银行 Open Banking API。Agent 可以使用 programmatic payment 作为执行层，但 programmatic payment 本身不包含 intent formation、service discovery 或 authorization semantics——这些是 agentic payment 需要在上层解决的。

与 smart contract payment 的区分。 Smart contract payment 是在区块链上通过智能合约自动执行的支付，条件满足即触发。Agentic payment 可以使用 smart contract 作为执行层（如 x402 通过 EIP-3009 transferWithAuthorization 执行链上转账），但 agentic payment 的复杂性在于条件本身是由 LLM 动态生成的、可能不精确的、可能被操纵的——这与 smart contract 的确定性条件有本质区别。

与 conversational commerce 的区分。 Conversational commerce（对话式商务）指通过聊天界面进行购物，如 WeChat 小程序、WhatsApp Business、Facebook Messenger 购物。Conversational commerce 中人类用户仍然做所有决策，聊天界面只是一个新的 UI 形态。Agentic payment 中 agent 代替人类做部分甚至全部决策——这是本质区别，也是核心风险来源。

3.3 五层栈模型

本报告把 agentic payment 的范围划成五层。

第一层：交互层（Interaction Layer）。 典型协议是 A2A、MCP、ACP。它回答 agent 如何发现商户或服务、如何交换任务、如何发起 checkout 或 API call。A2A（Agent-to-Agent Protocol，Google）定义了 agent 之间通过 JSON-RPC 通信的标准，包括 AgentCard 发布能力、task 创建和管理、streaming 和 push notification。MCP（Model Context Protocol，Anthropic）定义了 AI application 与 external tool/data source 之间的标准接口，包括 tool discovery、invocation 和 resource access。ACP 定义了 agent 与商户之间的 checkout 流程。这三个协议在交互层是互补的：A2A 解决 agent-to-agent，MCP 解决 agent-to-tool，ACP 解决 agent-to-merchant。

交互层的核心风险是 tool poisoning 和 service impersonation。恶意的 MCP server 可以返回包含 prompt injection 的工具描述；恶意的 A2A agent 可以伪造 AgentCard 声称自己有某种能力；恶意的 ACP 商户可以在 checkout 页面中嵌入操纵性内容。交互层本身不提供防御，需要上层的授权和身份层来验证。

第二层：授权层（Authorization Layer）。 典型方案是 AP2 mandates、DID/VC、SPT（Shared Payment Token）、session keys、spend limits。它回答用户是否授权、授权范围是什么。AP2 的三级 mandate 体系是目前最完整的授权框架：Intent Mandate 表达用户的高层意图（"帮我买跑鞋"），Cart Mandate 表达用户对具体购物车的确认（"这双 Nike Air Max 270，$149.99"），Payment Mandate 表达用户对具体支付动作的授权（"从 Visa xxxx1234 扣款"）。每个 mandate 都是签名的 Verifiable Data Container（VDC），可以被支付网络、商户和审计系统验证。

授权层的核心挑战是 intent gap——从用户的自然语言意图到机器可执行的授权之间存在语义鸿沟。"帮我买最便宜的运动鞋"这句话包含了无数隐含约束：什么品牌可以接受？什么尺码？什么材质？什么配送时间？什么退货政策？当前没有任何方案能自动把所有隐含约束提取并形式化。AP2 通过多级 mandate 缓解但不解决这个问题——agent 负责把 intent 细化为具体 cart，用户再确认 cart。

第三层：支付层（Payment Layer）。 典型轨道是 card/wallet/PSP、stablecoin/x402、Lightning/L402、MPP、payment channels。它回答钱怎么动。不同轨道有不同的成本结构、延迟特征、合规要求和消费者保护机制。Card 轨道（Visa/Mastercard/Amex）有最完善的消费者保护和最广的商户覆盖，但最低交易额和手续费使其不适合微支付。Stablecoin 轨道（USDC/EURC via x402）支持任意金额的即时跨境转账，但缺乏消费者保护和标准化争议机制。Lightning 轨道（via L402）延迟最低、费用最低，但需要 liquidity management 和 routing，且以 BTC 计价引入汇率风险。

支付层的核心挑战是 fragmentation——不同场景最适合不同轨道，但用户和 agent 不应该需要理解轨道的技术细节。理想状态是 agent 只表达 intent（"付 $0.003 给这个 API"），由底层基础设施自动选择最优轨道。Skyfire 和 Nevermined 在一定程度上尝试这个抽象，但距离成熟还很远。

第四层：执行与履约证明层（Execution & Fulfillment Proof Layer）。 典型机制是 merchant order records、TEE attestation、ZK/zkVM、service receipts、A402 Atomic Service Channels。它回答服务是否完成。这是当前最薄弱的一层——大多数方案只能证明"钱已经付了"，不能证明"服务已经交付且正确"。

A402 的 Atomic Service Channels 是这一层最有野心的方案：通过 TEE-assisted adaptor signatures，把服务执行的加密证据与支付签名最终化绑定——服务方要收钱就必须释放结果，客户端要结果就必须完成付款。但 TEE 的安全假设（信任硬件制造商、不考虑侧信道）和服务可证明性的限制（非确定性服务如 LLM 推理不容易在 TEE 内可证明执行）使得 A402 更适合确定性、低计算量的 API 调用，而不是复杂的 agentic 工作流。

第五层：审计与合规层（Audit & Compliance Layer）。 典型组件是 PSP logs、decision logs、chain tx hashes、mandate hashes、KYC/AML/sanctions screening、dispute evidence package。它回答事后如何解释、追责和退款。

这一层的核心目标是 accountability——当出错时，能够回答以下问题：(1) 用户授权了什么？（mandate 记录）(2) Agent 做了什么决策？（decision log）(3) 使用了什么策略规则？（policy evaluation log）(4) 实际支付了什么？（payment receipt）(5) 服务是否交付？（fulfillment record）(6) 如果需要退款，退款状态是什么？（refund state）。把这些证据串联的关键是前文提到的 correlation id。

3.4 五层栈的市场映射

这个分层能解释为什么市场上会同时出现看似竞争的 AP2、ACP、x402、MPP、Agent Pay、Visa Intelligent Commerce、Skyfire、Nevermined。它们实际上处在不同层：ACP 更偏商户 checkout 接口和支付凭证传递（交互层+支付层）；AP2 更偏授权证据和支付网络可见性（授权层+审计层）；x402 更偏 API/内容/服务的 HTTP 付款（支付层）；Visa/Mastercard/PayPal/Stripe 更偏传统支付网络与商户侧落地（支付层+审计层）；Skyfire/Nevermined 更偏 agent identity、spending controls 和跨协议支付入口（授权层+支付层）；ERC-8004 更偏开放 agent registry 与 trust signals（交互层+授权层）。

把其中任何一个当作完整答案，都会漏掉其他层的风险。例如，只用 x402 就缺少授权语义和消费者保护；只用 ACP 就无法支持 machine-to-machine 微支付；只用 AP2 就没有具体的支付执行和商户接入；只用 card network 就无法支持无人类参与的 agent 交易。一个生产级的 agentic payment 系统需要在每一层都有方案，并且层与层之间有明确的接口和证据传递。

3.5 与传统电商支付的对比

为了更清晰地理解 agentic payment 的独特性，以下表格对比 agentic payment 和传统电商支付在关键维度上的差异。

维度	传统电商支付	Agentic Payment
决策主体	人类用户在 UI 上点击	AI agent 推理后执行
意图表达	用户直接在页面上选择商品	用户用自然语言描述需求，agent 翻译为行动
商品发现	用户搜索和浏览	Agent 通过 API/A2A/MCP 自动发现
价格确认	用户在 checkout 页面看到价格	Agent 可能在多个来源比价后选择
支付授权	用户输入卡号或 one-click buy	Scoped token、mandate、session key
交易频率	每天几笔到几十笔	每分钟可能数百笔微支付
交易金额	通常 $1-$ 10000	可能低至 $0.001（API call）
身份验证	用户名/密码 + 3DS	Agent identity（DID/VC/ERC-8004）
争议处理	Chargeback + 客服	待定（目前大多无争议机制）
欺诈风险	账户盗用、card not present fraud	Prompt injection、tool poisoning、agent compromise
合规责任	商户 + PSP + issuer	不明确（agent platform 是新角色）
执行证明	物流跟踪号、下载链接	待定（TEE/ZK/service receipt 在探索中）

四、Zotero 核心论文综述

A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce

角色定位：核心论文；直接研究 agentic commerce 中服务调用与加密货币付款如何原子绑定。主要来源：A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce。

可核查事实：

论文指出 x402 的支付流程不能强制服务执行、付款、结果交付三者端到端原子化；这不是说 x402 没有用，而是说 x402 的付款证明不足以证明服务履约。
A402 提出 Atomic Service Channels，把普通支付通道从只维护余额扩展为维护服务请求、服务执行、付款最终化和结果交付状态。
论文用 TEE-assisted adaptor signatures 将执行结果的解密 witness 与支付签名最终化绑定；服务方若要收款，需要释放让结果可解密的 witness。
评估中 A402 原型报告峰值约 2,875 RPS，平均延迟约 0.34-0.37 秒；Ethereum 成本例子中 100 次请求 x402 约 95.02 美元，A402 standard/vault 约 3.35/2.05 美元。

边界与不足：研究原型，不是生产标准；依赖 TEE、远程证明和通道生命周期；论文把 TEE 侧信道等特定攻击放在边界之外。对大型 LLM、多外部 API、非确定性服务和多步工作流，TEE 内可证明执行并不自然。

对本报告的意义：这篇文献不是孤立引用，而是与其他来源交叉使用。若它讨论的是协议缺口，本报告会用官方规范核查该协议实际覆盖范围；若它给出实验数字，本报告只把数字用于说明结构性差异，不把实验环境等同生产承诺；若它提出身份或证明框架，本报告将其放在支付栈的信任层，而不是把它误写成支付清算层。

SoK: Blockchain Agent-to-Agent Payments

角色定位：核心综述；提供 discovery、authorization、execution、accounting 四阶段生命周期框架。主要来源：SoK: Blockchain Agent-to-Agent Payments。

可核查事实：

SoK 将 blockchain A2A payments 拆成发现、授权、执行和会计四阶段；这个拆分非常适合交叉审查项目，因为许多方案只解决其中一两段。
论文归纳的关键缺口是 weak intent binding、misuse under valid authorization、payment-service decoupling、limited accountability。
对 x402-style flow，SoK 的判断是它可证明 payment occurrence，但服务结果通常独立记录，因而只是事后相关性，不是统一绑定。
SoK 把未来方向总结为 consistency、control、composition、formation：即支付要对应真实结果，授权要治理行为而非单笔交易，多 agent 工作流要能组合，价格/范围也要支持交互式形成。

边界与不足：没有实现和性能实验，贡献是系统化分类与风险定位；它能指出每层缺口，但不提供单一落地协议。

Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents

角色定位：核心架构论文；把 A2A AgentCard 发现和 x402 微支付组合成 prototype。主要来源：Towards Multi-Agent Economies。

可核查事实：

论文认为 A2A 本身偏通信协议，缺少跨组织的 agent 发现和内建付款。
方案把 AgentCard 放入链上智能合约，广告能力、端点、支付 token、payTo 地址等，并通过 X-PAYMENT / X-PAYMENT-RESPONSE headers 把 x402 放进 A2A JSON-RPC 流程。
原型使用 TypeScript、Express、ethers，本地 Hardhat 与 Sepolia 测试网，并使用 USDC/EIP-3009。
该方案证明 A2A 与 x402 可在不破坏 JSON-RPC 主体的情况下组合，但把链上身份、发现、付款地址和历史都公开化。

边界与不足：作者承认缺 ecosystem-wide registry；链上结算会引入延迟和费用波动；agent 持有私钥和资金会引入被诱导大额支付或被盗用的攻击面。

Secure Autonomous Agent Payments: Verifying Authenticity and Intent in a Trustless Environment

角色定位：核心设想论文；提出 DID/VC、on-chain intent proof、ZKP、TEE 和 agent wallet 合成的 TIVA 框架。主要来源：Secure Autonomous Agent Payments。

可核查事实：

论文把问题定义为两个核心问题：这个付款是不是由真实 agent 发起，以及它是否反映用户授权意图。
TIVA 用 DID/VC 为 agent 建身份，用 on-chain intent proof 捕获授权，用 ZKP 证明策略满足而不泄露细节，用 TEE attestation 保护 agent 执行环境。
Agent Wallet Contract 是支付 gatekeeper，只有 agent 签名和 intent proof 或 policy check 同时有效时才执行付款。
安全分析是 qualitative，覆盖 impersonation、unauthorized spending、auditability、privacy 等，不提供性能指标。

边界与不足：不是部署产品；授权范围内的错误选择仍可能发生；如果用户/agent 两侧关键密钥都失陷，框架难以提供额外保护；TEE 与 ZKP 都需要工程落地和标准化。

Agentic commerce and payments: Exploring the implications of robots paying robots

角色定位：核心行业论文；把 R2R robot-to-robot payments 纳入支付战略视野。主要来源：Agentic commerce and payments: robots paying robots。

可核查事实：

摘要指出传统 machine-to-machine payments 与 Agentic AI 正在交汇，智能代理从聊天机器人演化为可自主决策、因而可自主付款的机器人。
作者提出 R2R 支付需求，并认为 smart wallet，即可由机器人操作的钱包，会成为中心编排机制。
摘要也谨慎指出早期实验常用区块链和支付卡，但尚不清楚它们是否满足这个新兴部门的需求。

边界与不足：Zotero 无本地全文，公开期刊页主要可核验摘要、DOI、页码和期刊信息；报告中只使用公开摘要可核查信息，不引用不可见全文细节。

SAKSHI: Decentralized AI Platforms

角色定位：半核心；早期把 AI 服务计量、支付通道和 proof-of-inference 组织成去中心化 AI 平台。主要来源：SAKSHI: Decentralized AI Platforms。

可核查事实：

SAKSHI 将 data path、control path、transaction path 分离，其中 transaction path 管理服务计量和账单，并用 blockchain 处理争议。
交易层用 SLA、measurement gateway、SLA manager、payment channels 把 AI inference 单位映射为 micropayments。
proof layer 处理 poor AI service、nonpayment、model copying 等争议。

边界与不足：它更像 decentralized AI service marketplace，不是现代 ACP/AP2 式消费 checkout；作者也指出大模型 ZKP 验证在当时不现实，模型复制只能通过经济机制缓解。

Inter-Agent Trust Models

角色定位：支持论文；从 Brief、Claim、Proof、Stake、Reputation、Constraint 六种信任模型比较 A2A、AP2、ERC-8004 等。主要来源：Inter-Agent Trust Models。

可核查事实：

论文的核心判断是 no single mechanism suffices；低风险交互可用 Claims/Briefs，高影响动作需要 Proof、Stake、Constraint 分层。
它把 A2A AgentCard 归为 Claim-heavy，把 AP2 mandates 归为 Brief/Proof/Constraint 组合，把 ERC-8004 看成 identity/reputation/validation registry。
这篇论文为 agentic payment 的设计给出重要原则：reputation 不应作为单一 gate，stake 需要 objective slashing evidence，constraint 是 LLM agent 的最后防线。

边界与不足：比较研究，无实验；Proof、Stake、Reputation 都有成本、延迟、Sybil、collusion、whitewashing 或可证明性边界。

Binding Agent ID / BAID

角色定位：支持论文；把用户、代码完整性和执行 provenance 绑定到 agent 身份。主要来源：Binding Agent ID。

可核查事实：

BAID 试图避免传统 key-based authentication 只证明持有密钥而不能证明操作者物理身份或 agent 代码完整性。
方案结合 biometric local binding、on-chain identity management 和 zkVM-based Code-Level Authentication。
对 agentic payment 来说，BAID 支撑的是谁在操作、什么代码在操作、操作 provenance 是否可验证，而不是支付轨道本身。

边界与不足：对真实支付仍需接入 AP2/x402/PSP/钱包；生物识别和 zkVM 证明的用户体验、隐私、成本都需要进一步评估。

BlockA2A

角色定位：支持论文；把 A2A 安全扩展到 DID、链上审计、智能合约访问控制和防御编排。主要来源：BlockA2A。

可核查事实：

BlockA2A 把多 agent 系统风险归纳为碎片化身份、不安全通信、Byzantine agents 和 adversarial prompts。
方案使用 DIDs、blockchain-anchored ledgers、smart contracts 和 Defense Orchestration Engine。
对支付而言，它说明 A2A 的沟通层必须再加身份、策略和审计，否则支付只是把风险放大。

边界与不足：它不是支付协议；支付结算、退款、争议和合规仍需其他层。

A Novel Zero-Trust Identity Framework for Agentic AI

角色定位：支持论文；讨论 IAM 对多 agent 系统的不足和 DID/VC/ANS/全局会话管理。主要来源：A Novel Zero-Trust Identity Framework for Agentic AI。

可核查事实：

论文认为 OAuth、OIDC、SAML 等为人类或静态机器身份设计，难以覆盖动态、相互依赖、短生命周期的 multi-agent systems。
提出 Agent Naming Service、DID/VC、fine-grained access control、global session management 和 privacy-preserving ZKP。
它为 agentic payment 里的 KYA、agent discovery、撤销和权限边界提供身份底座。

边界与不足：身份框架只能保证主体和权限的可表达性，不能保证商户履约、模型判断正确或支付争议裁决。

五、已落地项目和公开方案全景

本节重点回答用户要求中的“目前落地的项目和设想的方案”。所谓落地分四级：生产入口或受控真实交易、开放规范/SDK 可集成、公司发布但需申请/试点、研究原型/概念方案。下表和后续剖析保守分类，不把“宣布合作”自动写成“全球可用”。

项目	状态	主要轨道	机制摘要	主要来源

| Coinbase x402 / x402 Foundation | 开放标准与 SDK；Coinbase 文档称 x402 是基于 HTTP 的 instant automatic stablecoin payments；Cloudflare 与 Coinbase 宣布 x402 Foundation。 | USDC、EURC、Base、Polygon、Arbitrum、World、Solana 等；EIP-3009 与 Permit2 等授权模型。 | 服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。 | Coinbase x402 docs；x402 site；Cloudflare x402；MDN HTTP 402 |

| Google AP2 | 开源规范与参考实现；AP2 文档称它是 agent economy 的开放协议，作为 A2A extension，并计划更多 integration。 | 支付方式无关；初版支持 credit/debit card 等 pull payments，路线图包括 real-time bank transfers、e-wallets、digital currencies。 | Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。 | AP2 documentation；AP2 specification；AP2 GitHub；Google Cloud + PayPal agentic commerce |

| OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout | OpenAI 官方宣布 Instant Checkout in ChatGPT，ACP 与 Stripe 共同构建并开源；Stripe 称 ACP 是 live specification。 | Stripe、Apple Pay、Google Pay、Link、card 等；也支持非 Stripe 商户通过 Shared Payment Token 或 ACP Delegated Payments Spec。 | agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。 | OpenAI Instant Checkout and ACP；Agentic Commerce Protocol GitHub；Stripe + OpenAI Instant Checkout；Stripe ACP docs；Stripe agentic commerce |

| Mastercard Agent Pay | Mastercard 2025-04-29 发布 Agentic Payments Program / Mastercard Agent Pay。 | Mastercard 网络、tokenization、Agentic Tokens、Payment Passkeys。 | 注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。 | Mastercard Agent Pay |

| Visa Intelligent Commerce / Agentic Commerce | Visa 对 agentic commerce 提供产品和方案页面；强调 AI workflows、payments、standards 和 safeguards。 | Visa 网络、Visa tokenization、AI-ready credentials、Visa Intelligent Commerce Connect。 | 将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。 | Visa agentic commerce；Visa Intelligent Commerce；Visa Intelligent Commerce Connect |

| PayPal agentic commerce services | PayPal 2025-10-28 宣布 agentic commerce services；Google Cloud 与 PayPal 公布 agentic commerce solution。 | PayPal wallet、Braintree、PayPal payment infrastructure、buyer protection、identity verification。 | store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。 | PayPal agentic commerce services；Google Cloud + PayPal agentic commerce |

| Stripe Agentic Commerce Suite / Agent Toolkit / MPP | Stripe 产品页称 Agentic Commerce Suite 帮助商户让商品可被 agent 发现、简化 checkout 并接受 agentic payments；文档提供 ACP 集成。 | Stripe payments、Radar、Shared Payment Tokens、PaymentIntents；MPP/agent toolkit 面向 AI 产品 monetization。 | 商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。 | Stripe agentic commerce；Stripe ACP docs；Stripe + OpenAI Instant Checkout；Stripe Machine Payments Protocol |

| Skyfire | 商业化 agent payments and identity 平台，官网称提供 KYA identity 与 autonomous payments。 | USDC、tokenized cards、ACH、wallets 等，具体可用性以 Skyfire 文档和接入为准。 | AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。 | Skyfire |

| Nevermined | AI agent payments infrastructure；官网称 Nevermined Pay 让 AI agents 使用用户现有信用/借记卡在严格 spending rules 内完成真实购买。 | Stripe today，PayPal Braintree 和 Visa Cybersource coming soon；也与 MCP、A2A、x402、OpenClaw、plain HTTP 等对接。 | 服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。 | Nevermined |

| Circle Wallets + USDC + x402 / Nanopayments | Circle 官方提供 x402 + USDC agent payment 示例和 nanopayments 方向。 | USDC、Circle Wallets、Circle Gateway、x402。 | agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。 | Circle x402 + USDC |

| Cloudflare x402 / Pay Per Crawl | Cloudflare 与 Coinbase 推动 x402 Foundation，并在 Agents 与 MCP 场景支持 x402；Pay Per Crawl 是 AI crawler 付费访问方向。 | Stripe 管理付款、x402 stablecoin/onchain、deferred scheme 等组合。 | 内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。 | Cloudflare x402；x402 site |

Coinbase x402 / x402 Foundation

事实状态：开放标准与 SDK；Coinbase 文档称 x402 是基于 HTTP 的 instant automatic stablecoin payments；Cloudflare 与 Coinbase 宣布 x402 Foundation。资金或凭证轨道：USDC、EURC、Base、Polygon、Arbitrum、World、Solana 等；EIP-3009 与 Permit2 等授权模型。机制：服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。主要来源：Coinbase x402 docs；x402 site；Cloudflare x402；MDN HTTP 402。

证据说明：官方文档明确 x402 让人和机器无需账户、session 或复杂认证即可程序化支付访问 API 与数字内容；facilitator 帮 seller 避免直接维护区块链基础设施。

未解决部分：exact/upto 都偏 push payment；支付证明不证明服务正确执行；退款、争议、身份、合规、PII metadata 与跨链一致性仍需额外层。

交叉引用：若把该项目放入 SoK 的四阶段生命周期，必须分别问它覆盖了 discovery、authorization、execution、accounting 哪几段。许多项目在授权或付款段很强，但在服务执行证明、争议证据和跨平台责任分配上仍需要 AP2/ACP/PSP logs、ERC-8004、TEE/ZK 或 A402 类机制补足。对消费者电商，应优先看退款和商户责任；对 API 微支付，应优先看结果 receipt、nonce、重复请求和服务质量；对稳定币支付，应优先看 AML/KYC、制裁筛查和错误支付恢复。

Google AP2

事实状态：开源规范与参考实现；AP2 文档称它是 agent economy 的开放协议，作为 A2A extension，并计划更多 integration。资金或凭证轨道：支付方式无关；初版支持 credit/debit card 等 pull payments，路线图包括 real-time bank transfers、e-wallets、digital currencies。机制：Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。主要来源：AP2 documentation；AP2 specification；AP2 GitHub；Google Cloud + PayPal agentic commerce。

证据说明：AP2 规格明确当前支付系统假设人类直接点击买，agent 发起付款会让授权、意图真实性和责任归属变得不清；mandates 是为解决该缺口而设计的。

未解决部分：AP2 强化授权和争议证据，不证明服务真实交付；V0.1 更偏 human-present 和 pull payment，human-not-present、push payment、recurring、多商户拓扑在后续版本。

OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout

事实状态：OpenAI 官方宣布 Instant Checkout in ChatGPT，ACP 与 Stripe 共同构建并开源；Stripe 称 ACP 是 live specification。资金或凭证轨道：Stripe、Apple Pay、Google Pay、Link、card 等；也支持非 Stripe 商户通过 Shared Payment Token 或 ACP Delegated Payments Spec。机制：agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。主要来源：OpenAI Instant Checkout and ACP；Agentic Commerce Protocol GitHub；Stripe + OpenAI Instant Checkout；Stripe ACP docs；Stripe agentic commerce。

证据说明：OpenAI 官方说明用户在每一步行动前明确确认，payment tokens 只被授权给特定金额和特定商户，数据分享最小化；Stripe 文档说明 agentic checkout 中 AI agent 负责 checkout interface，而 seller 负责后端处理。

未解决部分：首发场景有限；ACP 更偏 commerce checkout 交互模型和凭证传递，不解决 agent 身份全球注册、服务执行证明、稳定币微支付或多 agent 服务计量。

Mastercard Agent Pay

事实状态：Mastercard 2025-04-29 发布 Agentic Payments Program / Mastercard Agent Pay。资金或凭证轨道：Mastercard 网络、tokenization、Agentic Tokens、Payment Passkeys。机制：注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。主要来源：Mastercard Agent Pay。

证据说明：官方新闻稿明确 Agent Pay 引入 Mastercard Agentic Tokens，并将与 Microsoft 等 AI 平台、IBM watsonx Orchestrate、Braintree、Checkout.com 等协作。

未解决部分：这是卡网络路径，优势是接入既有争议和风控，但不是开放 HTTP 微支付；跨网络、跨 PSP、agent identity 标准和责任规则还要行业共同形成。

Visa Intelligent Commerce / Agentic Commerce

事实状态：Visa 对 agentic commerce 提供产品和方案页面；强调 AI workflows、payments、standards 和 safeguards。资金或凭证轨道：Visa 网络、Visa tokenization、AI-ready credentials、Visa Intelligent Commerce Connect。机制：将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。主要来源：Visa agentic commerce；Visa Intelligent Commerce；Visa Intelligent Commerce Connect。

证据说明：Visa 官方页面将 agentic commerce 描述为 agent 浏览、比较、应用偏好并按用户设定规则付款的购物模式；Visa Agentic Commerce 页面强调帮助客户将 payments 嵌入 AI workflows。

未解决部分：卡组织的优势是网络规则和 consumer protection；但大规模 GA、跨网络互操作、merchant readiness 和 agent 责任证据仍处于建设阶段。

PayPal agentic commerce services

事实状态：PayPal 2025-10-28 宣布 agentic commerce services；Google Cloud 与 PayPal 公布 agentic commerce solution。资金或凭证轨道：PayPal wallet、Braintree、PayPal payment infrastructure、buyer protection、identity verification。机制：store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。主要来源：PayPal agentic commerce services；Google Cloud + PayPal agentic commerce。

证据说明：PayPal 新闻稿称服务包括 agentic payment solution、catalog and order management，并基于 trusted payments infrastructure、identity verification 和 buyer protection。

未解决部分：许多能力处于申请访问或逐步可用阶段；它能缓解商户接入和争议，但仍需跨平台协议互认和更细的责任分配。

Stripe Agentic Commerce Suite / Agent Toolkit / MPP

事实状态：Stripe 产品页称 Agentic Commerce Suite 帮助商户让商品可被 agent 发现、简化 checkout 并接受 agentic payments；文档提供 ACP 集成。资金或凭证轨道：Stripe payments、Radar、Shared Payment Tokens、PaymentIntents；MPP/agent toolkit 面向 AI 产品 monetization。机制：商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。主要来源：Stripe agentic commerce；Stripe ACP docs；Stripe + OpenAI Instant Checkout；Stripe Machine Payments Protocol。

证据说明：Stripe 产品页明确 ACP 开源、Apache 2.0、与 OpenAI 共建，且兼容任何 AI agent 或 payment processor；文档明确 agentic checkout 和传统 checkout 的职责划分。

未解决部分：很多能力依赖 Stripe 生态和商户接入；对于 x402 式无账户微支付、链上结算和 agent-to-agent API 计量，需要另接 MPP 或其他协议。

Skyfire

事实状态：商业化 agent payments and identity 平台，官网称提供 KYA identity 与 autonomous payments。资金或凭证轨道：USDC、tokenized cards、ACH、wallets 等，具体可用性以 Skyfire 文档和接入为准。机制：AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。主要来源：Skyfire。

证据说明：Skyfire 官网首页明确定位为 payments and identity built for the AI economy，并称 AI agents 可以处理付款、验证身份和访问服务。

未解决部分：官方页面是公司自述；行业标准地位、外部审计交易量、监管接受度和跨协议互认仍需继续核查。

Nevermined

事实状态：AI agent payments infrastructure；官网称 Nevermined Pay 让 AI agents 使用用户现有信用/借记卡在严格 spending rules 内完成真实购买。资金或凭证轨道：Stripe today，PayPal Braintree 和 Visa Cybersource coming soon；也与 MCP、A2A、x402、OpenClaw、plain HTTP 等对接。机制：服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。主要来源：Nevermined。

证据说明：Nevermined 官网明确写到 framework agnostic、spending controls、settle via Stripe today，以及 No vendor lock-in。

未解决部分：许多支付提供方仍是 coming soon；大规模商户覆盖、买家保护和监管责任仍需和 PSP/商户共同处理。

Circle Wallets + USDC + x402 / Nanopayments

事实状态：Circle 官方提供 x402 + USDC agent payment 示例和 nanopayments 方向。资金或凭证轨道：USDC、Circle Wallets、Circle Gateway、x402。机制：agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。主要来源：Circle x402 + USDC。

证据说明：Circle 官方博客说明用 Circle Wallets、USDC 和 x402 实现 autonomous payments；这证明 stablecoin wallet provider 正在把 agent payment 做成开发者路径。

未解决部分：这不是完整电商 checkout；Circle 层解决 wallet/settlement，不负责商户履约、退货、税务、争议和自然语言意图解释。

Cloudflare x402 / Pay Per Crawl

事实状态：Cloudflare 与 Coinbase 推动 x402 Foundation，并在 Agents 与 MCP 场景支持 x402；Pay Per Crawl 是 AI crawler 付费访问方向。资金或凭证轨道：Stripe 管理付款、x402 stablecoin/onchain、deferred scheme 等组合。机制：内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。主要来源：Cloudflare x402；x402 site。

证据说明：Cloudflare 博客明确和 Coinbase 合作创建 x402 Foundation；这说明 agentic payments 也在内容访问和爬虫经济里落地。

未解决部分：crawler 是否愿意大规模付费是商业问题；protocol 仍需解决内容价值、版权、身份、bot 识别、退款和 abuse。

L402 / Lightning LSAT

事实状态：成熟度中等；适合 Lightning-native API 付费凭证。资金或凭证轨道：Bitcoin Lightning Network。机制：HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。主要来源：Lightning Labs L402；MDN HTTP 402。

证据说明：Lightning Labs L402 规范说明这是 Macaroon 与 Lightning invoice preimage 结合的认证机制，适合 API access。

未解决部分：流动性、路由、托管、BTC 计价和服务执行证明仍是限制；credentials 也有 bearer token 风险。

六、协议与信任栈：谁解决什么，谁不解决什么

A2A

解决的问题：解决不同供应商和框架的 agent 如何发现能力、交换任务、长期协作。它提供 AgentCard、skills、HTTP/SSE/JSON-RPC 等基础，但不自带付款。主要来源：Google A2A announcement；Google Cloud donates A2A to Linux Foundation。

边界：A2A 在支付中的角色是发现与协作，不是授权和结算。报告中把 A2A 看成 commerce graph 的通信层。

放在 agentic payment 里看，这一层必须和上下游做哈希绑定和策略绑定。单独看协议时容易高估能力：通信协议不是授权协议，授权协议不是清算协议，清算协议不是履约证明，履约证明也不是争议规则。工程实现应把 request id、agent id、user mandate id、policy decision id、payment id、order id、response hash 和 audit log id 串成同一条证据链。

MCP

解决的问题：解决 AI 应用如何连接外部工具、数据源和 workflow。它让 agent 能调用支付、订单、库存、风控工具，但本身不提供付款。主要来源：Model Context Protocol intro。

边界：MCP 的风险是工具描述进入模型上下文，支付工具一旦暴露过宽权限，会把 prompt injection 变成资金风险。

x402

解决的问题：解决机器如何按 HTTP 请求为 API/资源付款。它把 HTTP 402 变成 stablecoin/onchain 的付款握手。主要来源：Coinbase x402 docs；x402 site。

边界：x402 证明付款，不证明服务执行；适合低额 API 和内容访问，不适合单独承载高价值履约。

AP2

解决的问题：解决用户授权与支付网络可见性。Mandate 让商户、agent、凭证提供方和支付网络看到谁授权了什么。主要来源：AP2 documentation；AP2 specification。

边界：AP2 不直接处理最终资金清算，也不证明商品真实交付；它是授权与审计层。

ACP

解决的问题：解决 agent-facing checkout 与商户后端的交互模型。它保留商户为 merchant of record，同时让 agent 能发起 checkout。主要来源：Agentic Commerce Protocol GitHub；OpenAI Instant Checkout and ACP；Stripe ACP docs。

边界：ACP 适合电商 checkout，不是通用 agent-to-agent micropayment rail。

ERC-8004

解决的问题：解决开放 agent economy 中 agent 发现、身份、声誉和验证的公共注册表。主要来源：ERC-8004 Trustless Agents。

边界：ERC-8004 明确不保证广告能力一定真实或非恶意；支付也不在标准核心范围。

DID/VC

解决的问题：解决 agent、用户、商户、凭证提供方之间可验证身份、资质和授权声明。主要来源：AP2 specification；A Novel Zero-Trust Identity Framework for Agentic AI；Secure Autonomous Agent Payments。

边界：DID/VC 是数据模型和证明机制，不等于可信 issuer、撤销机制或支付责任规则。

TEE attestation

解决的问题：解决低延迟证明某个测量值代码在硬件隔离环境中运行的问题。主要来源：A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce；Secure Autonomous Agent Payments。

边界：TEE 证明运行环境，不证明代码本身正确；还要面对硬件供应链、侧信道、rollback、debug mode 等问题。

ZK/zkVM

解决的问题：解决在不泄露隐私的情况下证明策略满足或程序按公开输入执行。主要来源：Secure Autonomous Agent Payments；Binding Agent ID。

边界：ZK 对大模型和外部工具成本高，且只能证明形式化 statement，不能证明现实世界语义。

Policy/capability/wallet

解决的问题：解决 agent 具体能花多少钱、向谁花、在何时花、用什么凭证花。主要来源：Nevermined；AP2 specification；Inter-Agent Trust Models。

边界：这是资金安全的实际闸门；没有 spend caps、merchant allowlist、session keys、撤销和审计，agent payment 就只是热钱包自动化。

七、痛点、难点、不足与解决方向

用户授权与意图绑定

自然语言愿望不是支付授权。用户说“帮我买一张便宜机票”没有确定收款方、金额、税费、行李、取消政策和替代方案；若 agent 最终签了某个订单，争议中必须证明这不是模型误解。AP2 用 Intent Mandate 和 Cart Mandate 把用户意图、购物车、价格和付款凭证哈希化并签名，ACP/SPT 把支付 token 限定在特定商户和金额，卡组织路线把 token 与强认证、风控和 spend controls 结合。剩余缺口是语义层：类似商品、价格小幅变化、分批履约、订阅续费、捆绑优惠、动态运价和多商户组合如何机器可判定。

解决方向不是让模型更聪明就完事，而是把模糊意图压缩成确定性约束，把确定性约束交给可验证执行点，把执行点的每次 allow/deny 记录下来，并让支付凭证只在这些约束内有效。高风险动作还要有 step-up confirmation、设备绑定、issuer 或 PSP 风控、商户履约证据和争议回放。这个原则贯穿 AP2、ACP、Visa/Mastercard tokenization、PayPal buyer protection、x402 facilitator、A402 channel 和 ERC-8004 registry。

代理身份与 KYA

支付系统习惯识别人、商户、设备、钱包和法人；agent 可能是模型、工具链、运行时、钱包、平台和用户委托的组合。Visa、Skyfire、Nevermined、AP2、ERC-8004、DID/VC 都在不同层面解决“这个请求来自什么 agent”。但身份不是信任；商户还需要知道 agent 是否有授权、是否被篡改、是否是已认证平台、是否在当前会话内仍可信。

责任归属

传统卡网络有持卡人、商户、issuer、acquirer、network 和 PSP 的规则；agentic payment 增加模型开发者、agent 平台、工具提供方、wallet provider、facilitator、identity provider。AP2 mandates 和 ACP order records 能提供证据，但无法自动决定责任。模型推荐错误、prompt injection、工具返回虚假库存、merchant bait-and-switch、agent 在授权范围内做坏选择，这些都需要合同和网络规则重写。

争议、退款与履约

agentic commerce 的争议不只问是否支付，还问 agent 为什么认为商品符合用户意图。x402/stablecoin push payment 没有 card-like chargeback；退款靠 seller 或业务逻辑。AP2 的 mandate、Stripe/PayPal 的订单和支付记录、Visa/Mastercard 的争议机制可降低风险，但还缺统一 dispute evidence package：原始用户意图、商品快照、模型可见上下文、工具调用、授权凭证、支付 token、履约状态和退款路径。

AML/KYC/制裁筛查

agent 可高速、小额、跨境、多钱包、多商户付款；stablecoin 的开放性让低成本微支付可行，也放大资金流监测难度。FinCEN、OFAC、FATF 等框架仍适用，VASP/钱包/PSP/facilitator 是否承担义务要看角色。低额 API 付款若完全无 KYC，可能被用于规避制裁或数据获取；强 KYC 又会破坏开放微支付体验。

PCI 与支付凭证暴露

让 LLM 或 MCP 工具看到 PAN/CVV 是高风险路径。Stripe SPT、Visa/Mastercard tokenization、PayPal/PSP 托管凭证和 ACP delegated payments 都是在避免 agent 持有敏感卡数据。真正的工程问题是：哪些工具处于 PCI CDE，哪些日志会记录 token，token 是否 merchant-bound、amount-bound、time-bound、purpose-bound，agent 是否能重复使用。

Prompt injection 与 tool injection

agent 会读网页、邮件、商品描述、API 文档和 MCP tool metadata；恶意商户可把指令隐藏在内容中诱导 agent 改预算、改收款方、泄露 token 或接受更差商品。签名只能证明某一步被签了，不能证明签名前模型没被操控。防线必须是内容隔离、工具 allowlist、policy engine、不可变 cart hash、用户可读确认、out-of-band challenge 和交易后审计。

Spend limits 与策略语义

单笔 50 美元限制不阻止 agent 分 20 笔花 1000 美元；只限制商户不限制品类会让伪装商户绕过；只限制品类不限制收款方会被冒名服务骗。预算策略需要金额、时间、累计、商户、品类、地理、订阅、失败重试、并发 agent、兑换率、税费、返利和退款状态。Nevermined 等产品强调 spending controls，但行业语义尚未统一。

支付与服务执行解耦

x402/L402 证明付款或凭证，但不证明 API 返回正确结果。SoK 将此称为 payment-service decoupling；A402 通过 Atomic Service Channel、TEE 和 adaptor signatures 提供研究型补强。现实系统至少要把 request hash、response hash、service receipt、payment id 和 settlement tx 绑定；高价值服务还需要 TEE/zk/optimistic proof 或 escrow。

隐私与商业机密

agentic payment 会暴露用户偏好、购买历史、地址、预算、时间、搜索意图、商户图谱和 API 访问频率。链上支付又公开 payer/payee/amount/time。AP2 的 VDC、ZKP、A402 vault、批量结算、tokenization、日志脱敏、最小化 metadata 都是方向。但审计需要证据，隐私要求最小披露，两者天然拉扯。

可观测性与审计

事后要还原的不是一笔支付，而是一条链：用户意图、agent planning、工具调用、政策判断、授权签名、支付凭证、服务响应、履约/退款。AP2 mandate 和链上交易哈希只是两段证据，必须有统一 correlation id 把各层日志串起来。OPA/Cedar decision logs、PSP records、merchant order logs、TEE/zk proof receipts 都要对齐。

产品体验与商户接入

安全确认太多，agent 失去代办意义；确认太少，消费者和 issuer 不会信任。商户也不愿为每个 agent 平台写一套接口。ACP、AP2、PayPal store sync、Stripe Agentic Commerce Suite 都在降低接入成本。落地体验需要分层确认：低额低风险自动，高额或异常 step-up，失败自动回滚，用户可查看、暂停和撤销授权。

八、区块链与微支付路线深拆

区块链/微支付路线最吸引人的地方，是它把支付变成机器可组合的协议动作：agent 不需要开账户、不需要发票、不需要人工 checkout，就能按 API call、模型 token、资源下载、网页访问或小服务调用付款。x402、L402、Circle Wallets、Nevermined、Skyfire、SAKSHI、A402 都属于这条谱系。它们的共同优势是低额、跨境、自动化、可编程、无许可或低许可；共同不足是隐私、合规、退款、履约证明、私钥安全和用户保护。

HTTP 402 的历史背景很重要。MDN HTTP 402 说明 402 Payment Required 长期保留且缺少统一使用方式；x402 的意义就是把这段保留语义变成具体的 payment requirements、payment signature、payment response 流程。Coinbase 文档把 x402 描述为直接 over HTTP 的 instant automatic stablecoin payments，Cloudflare 与 Coinbase 又把它推向基金会和生态。对于 agent-to-API，这比传统 API key + 月度账单更适合机器，因为价格可以在请求时表达，付款可以在请求中完成，服务提供者可以少做账户系统。但 x402 的付款是资金事实，不是服务事实；这正是 A402 和 SoK 反复强调的断裂。

L402/LSAT 是另一条成熟的微支付思路。它把 Lightning invoice 的 preimage 与 Macaroon caveats 结合，形成可验证的 API credential。优点是低延迟、低费用、可复用 credential、stateless verification；不足是 Lightning liquidity、路由成功率、节点运维、托管取舍和 BTC 计价波动。更重要的是，L402 与 x402 一样，只能证明你付过钱或持有凭证，不能证明服务结果正确。如果 agent 买的是低额数据或一次搜索，这通常可以接受；如果买的是高价值报告、交易执行、医疗建议或法律服务，就需要额外执行证明。

A402 的技术价值在于把 payment channel 升级为 Atomic Service Channel。普通 payment channel 只知道余额状态；A402 让通道知道服务请求和结果交付。服务方在 TEE 内执行请求、加密结果，并生成 adaptor pre-signature；支付最终化会释放 witness，witness 又能解密结果。这样服务方要收钱就必须让结果可获得，客户端要结果就必须让付款完成。Liquidity Vault 进一步把多个 ASC 生命周期放到 TEE-backed vault 内部管理，链上只做聚合 settlement，降低 O(n) 成本和交易图谱泄露。论文实验显示在特定环境下吞吐和成本相较 x402 有数量级改善，但这不等于生产可用，因为 TEE、侧信道、密钥管理、多副本一致性和服务可证明性仍需工程验证。

从费用和延迟看，结构性结论比具体数字更重要。x402 exact 如果每次都上链，成本与请求数线性相关；payment channel、Lightning、A402、vault 或 batch settlement 则把链上成本摊薄。A402 论文给出 Ethereum 例子：100 次请求下 x402 约 95.02 美元，A402 标准通道或 vault 约 3.35 或 2.05 美元；Bitcoin 例子也显示 x402 线性增长而 A402 生命周期成本固定。具体价格会随 gas、ETH/BTC 价格、链和 facilitator 模型变化，但 O(n) 与 O(1) 的差异不会消失。agent loop 高频调用时，这个差异会决定产品是否经济。

隐私是区块链路线的硬伤。公开链会暴露付款地址、收款地址、时间、金额和频率；x402 header 或 payment requirements 还可能暴露 resource URL、description、reason、metadata。A402 的 vault、batch settlement、ephemeral wallets、Merkle-root anchoring、最小化 payment header、ZKP selective disclosure、off-chain logs with on-chain commitments 都是改进方向。但隐私和审计之间存在根本权衡：争议越容易裁决，证据越多；证据越多，泄露越大。实用系统应区分公开链上证据、受限 PSP/issuer 证据、商户订单证据和用户可见证据，不能把所有上下文都上链。

合规方面，stablecoin 或链上轨道不是监管真空。FinCEN、OFAC、FATF 等资料说明 CVC/virtual assets、money transmission、sanctions screening、VASP obligations 等仍然适用。agent wallet、facilitator、marketplace、托管钱包、稳定币发行方、PSP 在不同业务模型下可能承担不同义务。低额微支付若完全无身份，会更像开放互联网协议；但一旦它支持真实购买、法币出入金、托管余额、跨境汇款或大额交易，就进入更强监管区域。未来的 agentic payment 基础设施需要把 KYC/AML/sanctions 作为策略输入，而不是事后补丁。

九、按场景的落地路径

低额 API 调用

最适合 x402 或 L402。agent 请求天气、行情、搜索、OCR、网页抽取、模型推理等接口，服务返回 402，agent 按次支付。关键控制是单次限额、每日总额、endpoint allowlist、resource hash 和 response receipt。若结果错误，通常用服务信用或退款处理，而不是链上争议。

推荐最小证据链包括：用户或组织授权、agent 身份、策略判定、payment payload、服务请求、服务响应、付款或退款记录。低风险场景可用日志和付款回执；高风险场景应加签名 cart、TEE/zk proof、商户 SLA、可争议证据包和人工 step-up。不要把一个场景的控制直接迁移到另一个场景：API 微支付能接受小额失败，消费品 checkout 要能退货，B2B 采购要进 ERP，长期无人值守代理要持续风险评估。

内容/数据付费访问

Cloudflare Pay Per Crawl、x402 和内容站点的组合属于这一类。难点是 crawler/agent 识别、版权授权、价格发现、重复抓取、缓存、机器人滥用和隐私。可行路径是 signed agent identity、rate limit、per-resource payment id 和批量结算。

消费品 checkout

OpenAI/Stripe ACP、PayPal、Visa、Mastercard 更适合这一类。用户必须确认具体 cart，支付 token 应绑定商户、金额和订单。商户保持 merchant of record，履约、退货和客服仍由商户负责。风险焦点是商品语义、替代品、库存和退货规则。

旅行和复杂组合订单

机票、酒店、租车、签证、保险和日程约束跨多个商户。单个 mandate 很难表达完整偏好，且价格变化快。需要 staged intent、cart snapshots、多商户依赖图、超预算重新确认和失败补偿。AP2 未来的多商户拓扑、real-time negotiation、human-not-present 将很关键。

B2B 采购和发票

企业 agent 可按预算和供应商规则采购 SaaS、云资源、办公用品。优势是企业已有 PO、ERP、审批和审计系统，可将 agent payment 接入 policy engine。难点是职责分离、审批链、发票匹配、供应商 KYC 和预算归属。

Agent-to-agent 服务市场

一个 agent 付费调用另一个 agent 的分析、爬取、推理、数据清洗能力。A2A 负责通信，ERC-8004/DID 负责发现和信任，x402/L402 负责付款，A402/TEE/ZK 负责高价值执行证明。核心难点是服务质量评估和可组合责任。

去中心化 AI 推理市场

SAKSHI 类系统按 inference 单位计量和结算。支付通道和 SLA 可降低成本，但 proof-of-inference、模型复制、服务质量和隐私是核心问题。短期可用 TEE attestation，长期再引入 zk/optimistic proof。

无人值守长期代理

例如 agent 每周采购食材、续订服务、寻找低价票。这里最需要 Intent Mandate、spend caps、merchant/category allowlist、动态风险、异常 step-up 和一键撤销。授权必须可持续更新，不能只靠一次签名长期有效。

十、推荐参考架构

本报告建议采用“七层硬约束架构”。第一层是 Intent Capture：用户自然语言只作为起点，系统必须生成结构化 intent，包括预算、收款方约束、品类、时间窗、替代规则、退款要求和确认策略。第二层是 Agent Identity：agent 必须有可验证身份，包含平台、代码版本、运行环境、钱包地址、权限域、撤销状态和审计端点；可用 DID/VC、ERC-8004、KYA、AgentCard JWS 组合。第三层是 Policy Decision：所有支付相关动作先经过 OPA/Cedar/自定义策略，做金额、频率、商户、品类、地理、制裁、用户状态、风险评分判断。第四层是 Credential Issuance：只发放 scoped token、session key、mandate 或 payment authorization，不给 agent 原始卡号或无限私钥。第五层是 Payment Execution：按场景选择 ACP/PSP/card、x402/stablecoin、L402/Lightning、MPP、payment channel 或 escrow。第六层是 Service Binding：低额场景至少绑定 request/response hash，高价值场景加 TEE/ZK/A402/escrow。第七层是 Audit and Dispute：保存 correlation id、mandate、policy decision、payment receipt、order record、service receipt、refund state，并按隐私等级分层留存。

这个架构的关键不是使用多少 buzzwords，而是每个动作都有确定性闸门。LLM 可以建议“买 A 而不是 B”，但不能直接越过 policy engine。MCP tool 可以暴露 create_payment_intent，但不能把所有支付凭证放进模型上下文。x402 可以让 agent 为 API 付款，但服务端必须返回 response hash 和 receipt。AP2 mandate 可以证明用户授权，但 merchant order record 必须证明履约状态。ERC-8004 可以给 agent trust signals，但不能替代 KYC 或 merchant acceptance。TEE 可以证明某段代码在 enclave 中运行，但不能证明业务语义正确；ZK 可以证明电路 statement，但需要公开输入正确绑定。所有这些边界都要在架构图上写清楚。

推荐的工程落地顺序是从低风险闭环开始。第一阶段选择低额 API 或封闭商户场景，设置日限额、单商户 allowlist、人工确认、完整日志。第二阶段增加 scoped payment tokens、mandate hashes、merchant/order API、refund API、risk scoring，并引入 agent identity registry。第三阶段扩展到多商户、无人值守、B2B 或跨境 stablecoin，同时加入行为风险、TEE/ZK receipts、escrow/channel 和自动争议证据包。不要一开始就做开放式“任何 agent 能向任何商户付款”，这会把身份、风控、合规、争议和产品体验的所有难题同时引爆。

十一、事实核查矩阵

事实点	来源	报告使用方式	风险提示

| ACP 由 OpenAI 和 Stripe 维护，处于 beta/open standard，Instant Checkout 已在 ChatGPT 场景使用 | OpenAI Instant Checkout and ACP；Agentic Commerce Protocol GitHub；Stripe + OpenAI Instant Checkout | 作为 agentic commerce checkout 证据 | 首发场景有限，不能泛化为所有商户可用 |

| PayPal agentic commerce services 包含 agentic payment solution、catalog/order management、buyer protection | PayPal agentic commerce services；Google Cloud + PayPal agentic commerce | 作为 PSP 路线证据 | 部分服务未来可用或需申请 |

十二、路线图：短期、中期、长期

12.1 短期（2025-2026）：受控闭环与低额微支付

短期，最现实的是封闭或半封闭的 agentic commerce 与低额 API micropayment。商户侧可接 ACP/Stripe/PayPal 或 Visa/Mastercard 的 tokenized agentic commerce；API 侧可接 x402/L402/MPP。控制目标不是完全自动，而是让用户确认更少但更有效：低额自动、高额确认、异常阻断、可撤销、可回放。短期最重要的产品指标不是 agent 能买多少东西，而是每一笔错单能否解释、能否退款、能否阻止重复发生。

短期的具体里程碑包括：

商户 checkout 场景（Q1-Q4 2025）。 ACP/Stripe Instant Checkout 已经在 ChatGPT 中上线，覆盖部分 Stripe 商户。Visa 和 Mastercard 分别发布了 agentic commerce 和 Agent Pay 方向。PayPal 发布了 agentic commerce services。短期内这些方案的覆盖范围将从首批合作商户扩展到更多品类——但仍以大型电商和 SaaS 为主，长尾商户的接入需要更成熟的标准化工具。

API micropayment 场景（Q2 2025-Q2 2026）。 x402 已有 Coinbase 和 Cloudflare 的官方支持。x402 Foundation 的成立标志着社区化推进。短期内预计会看到更多 API 服务商（搜索、OCR、翻译、LLM inference）接入 x402，形成一个小型但可用的 pay-per-call 生态。L402 方面，Lightning Labs 和 Fewsats 等在推动 Lightning micropayment for APIs，但 Lightning 的 liquidity 和 routing 问题限制了大规模采用。

身份与授权（持续进行）。 AP2 规范预计在 2025-2026 年从 v0.x 演进到 v1.0，覆盖更多支付方式和 mandate 类型。ERC-8004 作为 Draft EIP 仍在审议中。短期内不太可能有统一的 agent identity 标准，更可能是各平台自己的 identity 方案（如 Skyfire 的 agent wallet、Coinbase CDP 的 managed wallet、OpenAI 的 verified agent）。

短期最大风险。 (1) 安全事件——如果一个高关注度的 agentic payment 因 prompt injection 导致大额错误支付，可能引发监管过度反应和公众信任危机。(2) 碎片化——如果 ACP、AP2、x402 各自发展但互不兼容，商户和 agent 平台需要对接多套系统，增加成本和复杂性。(3) 法律灰区——如果没有明确的监管指引，PSP 和 issuer 可能对 agentic payment 采取保守策略，限制创新空间。

12.2 中期（2026-2028）：语义统一与跨平台互操作

中期，需要行业统一三类语义。

第一类：授权语义统一。 Intent Mandate、Cart Mandate、Payment Mandate、SPT、session key、spend cap 应能互相映射。例如，一个通过 AP2 Intent Mandate 表达的"帮我买运动鞋，预算 $200"应该能被翻译成一个 Visa tokenization request 的 spend limit 和 category restriction，也应该能被翻译成一个 x402 wallet 的 per-transaction cap 和 merchant allowlist。这需要一个跨协议的 authorization semantics mapping layer——不一定是新标准，可能是 adapter pattern 或 translation service。

第二类：身份语义统一。 AgentCard、DID、KYA、ERC-8004、平台认证、运行时证明应能表达同一 agent 的不同维度。一个 agent 可能有一个 ERC-8004 的链上 identity（不可变、公开）、一个 DID（可选择性披露）、一个平台证书（表明它运行在 OpenAI 或 Anthropic 的受控环境中）和一个 TEE attestation（证明它当前的代码版本和运行环境）。中期的目标是让这些身份信号可以被不同的验证方（商户、PSP、issuer、auditor）按需查询和验证。

第三类：争议证据语义统一。 订单快照、价格、税费、库存、履约、工具调用、模型可见上下文、支付凭证和退款状态应形成可标准化证据包。没有这些，agentic payment 会变成每个平台的封闭花园。中期应该出现行业级的 dispute evidence schema——类似于当前 card network 的 chargeback reason codes 和 evidence requirements，但扩展到包含 agent decision log、tool invocation trace 和 service receipt。

中期技术里程碑。 (1) Payment channel / batch settlement 在 agentic payment 中成为标准——不再每次 API call 都上链或走 PSP。(2) TEE-based execution proof 从实验走向商用——至少在一类场景（如 deterministic API call）中提供生产级的 service binding。(3) Policy engine 标准化——类似 OPA/Cedar 的策略语言被 agentic payment 平台广泛采用，支持 spend limits、category restrictions、time windows、risk thresholds 的声明式配置。(4) 第一个跨平台的 agent identity registry 上线——可能基于 ERC-8004 或 DID registry，允许商户和 PSP 查询 agent 的信誉和验证状态。

12.3 长期（2028+）：可验证经济工作流

长期，agentic payment 会变成一个"可验证经济工作流"。用户不再逐笔点击付款，而是签署可撤销、可审计、可限制的授权；agent 在策略范围内发现和协商；商户和服务以机器可读方式发布能力、价格、履约和退款规则；支付网络或链上轨道执行资金流；TEE/ZK/日志证明服务完成；争议系统自动拉取证据；监管系统按风险抽样或实时筛查。

长期愿景的关键特征包括：

自主经济参与者。 Agent 不仅代替用户购物，还代替用户谈判、签约、执行和验收。一个 procurement agent 可以自动发现最优供应商、比较报价、谈判折扣、签署电子合同、安排支付、跟踪物流、验收质量、处理退货——整个流程中人类只在关键决策点介入（设定策略、审批大额、处理异常）。

可编程货币与条件支付。 Stablecoin 的可编程性使得条件支付成为原生功能——escrow、milestone-based release、quality-dependent payment、time-locked refund 都可以在智能合约中表达。这比传统的 invoice → payment → dispute 流程更高效，但需要解决智能合约的灵活性（复杂条件难以在合约中表达）和可升级性（商业逻辑变化时合约如何适应）。

去中心化信任网络。 Agent 之间的信任不再完全依赖平台背书，而是基于链上历史（交易记录、完成率、争议率）、同行评价（其他 agent 的评分）和 stake-based commitment（押金/抵押）。ERC-8004 的 identity/reputation/validation registries 是这个方向的早期探索。

监管科技（RegTech）集成。 监管机构不再事后审查交易记录，而是通过 API 实时访问合规数据流——sanctions screening 在每笔交易前自动执行、AML 模型持续监控交易模式、tax reporting 自动生成。这需要 agentic payment 平台提供标准化的 regulatory data feed。

这一愿景需要 AP2、ACP、x402、MPP、ERC-8004、DID/VC、TEE/ZK、card networks、stablecoin issuers、PSP、merchants、wallets、AI platforms 共同演进。没有单一实体可以独立实现这个愿景——它本质上是一个多方协调问题，类似于互联网早期的 protocol stack 形成过程。

12.4 路线图风险矩阵

时间段	最大机遇	最大风险	关键依赖
短期	低额 API micropayment 形成可用生态	安全事件导致监管过度反应	x402/L402 商户覆盖
短期	ChatGPT + Instant Checkout 验证 agentic commerce PMF	碎片化——ACP/AP2/x402 互不兼容	Stripe/OpenAI 开放更多商户
中期	授权/身份/争议语义标准化	标准之争延误互操作（类似 USB-C vs Lightning）	行业联盟或 de facto standard
中期	TEE execution proof 商用化	TEE 侧信道漏洞或信任模型被攻破	Intel SGX/TDX、ARM CCA 成熟度
长期	可验证经济工作流重塑 B2B 采购	AI agent 被武器化用于大规模欺诈	全球监管协调
长期	去中心化 agent 服务市场	信誉系统 Sybil attack 或 manipulation	Sybil-resistant identity

十三、项目-痛点交叉审查

这一节是尽调用途的交叉引用，不是重复项目介绍。每个项目都按十二类痛点过一遍，目的在于防止把一个项目在某一层的能力误解为全栈能力。写法上有意保守：只有官方来源或论文明确支持的内容才说“已覆盖”；其余只说“可能缓解”“需要另核”或“不能推出”。这也是本报告避免幻觉的主要机制之一。

Coinbase x402 / x402 Foundation 的痛点覆盖审查

已核事实底座：开放标准与 SDK；Coinbase 文档称 x402 是基于 HTTP 的 instant automatic stablecoin payments；Cloudflare 与 Coinbase 宣布 x402 Foundation。；轨道是USDC、EURC、Base、Polygon、Arbitrum、World、Solana 等；EIP-3009 与 Permit2 等授权模型。；机制是服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。；来源为Coinbase x402 docs；x402 site；Cloudflare x402；MDN HTTP 402。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Coinbase x402 / x402 Foundation 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Coinbase x402 / x402 Foundation 视为局部组件，不能视为完整 agentic payment 安全方案。

Google AP2 的痛点覆盖审查

已核事实底座：开源规范与参考实现；AP2 文档称它是 agent economy 的开放协议，作为 A2A extension，并计划更多 integration。；轨道是支付方式无关；初版支持 credit/debit card 等 pull payments，路线图包括 real-time bank transfers、e-wallets、digital currencies。；机制是Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。；来源为AP2 documentation；AP2 specification；AP2 GitHub；Google Cloud + PayPal agentic commerce。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Google AP2 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Google AP2 视为局部组件，不能视为完整 agentic payment 安全方案。

OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 的痛点覆盖审查

已核事实底座：OpenAI 官方宣布 Instant Checkout in ChatGPT，ACP 与 Stripe 共同构建并开源；Stripe 称 ACP 是 live specification。；轨道是Stripe、Apple Pay、Google Pay、Link、card 等；也支持非 Stripe 商户通过 Shared Payment Token 或 ACP Delegated Payments Spec。；机制是agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。；来源为OpenAI Instant Checkout and ACP；Agentic Commerce Protocol GitHub；Stripe + OpenAI Instant Checkout；Stripe ACP docs；Stripe agentic commerce。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout 视为局部组件，不能视为完整 agentic payment 安全方案。

Mastercard Agent Pay 的痛点覆盖审查

已核事实底座：Mastercard 2025-04-29 发布 Agentic Payments Program / Mastercard Agent Pay。；轨道是Mastercard 网络、tokenization、Agentic Tokens、Payment Passkeys。；机制是注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。；来源为Mastercard Agent Pay。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Mastercard Agent Pay 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Mastercard Agent Pay 视为局部组件，不能视为完整 agentic payment 安全方案。

Visa Intelligent Commerce / Agentic Commerce 的痛点覆盖审查

已核事实底座：Visa 对 agentic commerce 提供产品和方案页面；强调 AI workflows、payments、standards 和 safeguards。；轨道是Visa 网络、Visa tokenization、AI-ready credentials、Visa Intelligent Commerce Connect。；机制是将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。；来源为Visa agentic commerce；Visa Intelligent Commerce；Visa Intelligent Commerce Connect。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Visa Intelligent Commerce / Agentic Commerce 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Visa Intelligent Commerce / Agentic Commerce 视为局部组件，不能视为完整 agentic payment 安全方案。

PayPal agentic commerce services 的痛点覆盖审查

已核事实底座：PayPal 2025-10-28 宣布 agentic commerce services；Google Cloud 与 PayPal 公布 agentic commerce solution。；轨道是PayPal wallet、Braintree、PayPal payment infrastructure、buyer protection、identity verification。；机制是store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。；来源为PayPal agentic commerce services；Google Cloud + PayPal agentic commerce。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 PayPal agentic commerce services 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 PayPal agentic commerce services 视为局部组件，不能视为完整 agentic payment 安全方案。

Stripe Agentic Commerce Suite / Agent Toolkit / MPP 的痛点覆盖审查

已核事实底座：Stripe 产品页称 Agentic Commerce Suite 帮助商户让商品可被 agent 发现、简化 checkout 并接受 agentic payments；文档提供 ACP 集成。；轨道是Stripe payments、Radar、Shared Payment Tokens、PaymentIntents；MPP/agent toolkit 面向 AI 产品 monetization。；机制是商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。；来源为Stripe agentic commerce；Stripe ACP docs；Stripe + OpenAI Instant Checkout；Stripe Machine Payments Protocol。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Stripe Agentic Commerce Suite / Agent Toolkit / MPP 视为局部组件，不能视为完整 agentic payment 安全方案。

Skyfire 的痛点覆盖审查

已核事实底座：商业化 agent payments and identity 平台，官网称提供 KYA identity 与 autonomous payments。；轨道是USDC、tokenized cards、ACH、wallets 等，具体可用性以 Skyfire 文档和接入为准。；机制是AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。；来源为Skyfire。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Skyfire 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Skyfire 视为局部组件，不能视为完整 agentic payment 安全方案。

Nevermined 的痛点覆盖审查

已核事实底座：AI agent payments infrastructure；官网称 Nevermined Pay 让 AI agents 使用用户现有信用/借记卡在严格 spending rules 内完成真实购买。；轨道是Stripe today，PayPal Braintree 和 Visa Cybersource coming soon；也与 MCP、A2A、x402、OpenClaw、plain HTTP 等对接。；机制是服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。；来源为Nevermined。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Nevermined 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Nevermined 视为局部组件，不能视为完整 agentic payment 安全方案。

Circle Wallets + USDC + x402 / Nanopayments 的痛点覆盖审查

已核事实底座：Circle 官方提供 x402 + USDC agent payment 示例和 nanopayments 方向。；轨道是USDC、Circle Wallets、Circle Gateway、x402。；机制是agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。；来源为Circle x402 + USDC。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Circle Wallets + USDC + x402 / Nanopayments 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Circle Wallets + USDC + x402 / Nanopayments 视为局部组件，不能视为完整 agentic payment 安全方案。

Cloudflare x402 / Pay Per Crawl 的痛点覆盖审查

已核事实底座：Cloudflare 与 Coinbase 推动 x402 Foundation，并在 Agents 与 MCP 场景支持 x402；Pay Per Crawl 是 AI crawler 付费访问方向。；轨道是Stripe 管理付款、x402 stablecoin/onchain、deferred scheme 等组合。；机制是内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。；来源为Cloudflare x402；x402 site。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 Cloudflare x402 / Pay Per Crawl 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 Cloudflare x402 / Pay Per Crawl 视为局部组件，不能视为完整 agentic payment 安全方案。

L402 / Lightning LSAT 的痛点覆盖审查

已核事实底座：成熟度中等；适合 Lightning-native API 付费凭证。；轨道是Bitcoin Lightning Network。；机制是HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。；来源为Lightning Labs L402；MDN HTTP 402。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。

用户授权与意图绑定：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

代理身份与 KYA：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

责任归属：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

争议、退款与履约：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

AML/KYC/制裁筛查：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

PCI 与支付凭证暴露：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

Prompt injection 与 tool injection：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

Spend limits 与策略语义：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

支付与服务执行解耦：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

隐私与商业机密：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

可观测性与审计：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

产品体验与商户接入：对 L402 / Lightning LSAT 而言，首先要问它解决的是协议链路中的哪一段。如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。结合该项目机制“HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。若这三类证据缺失，就只能把 L402 / Lightning LSAT 视为局部组件，不能视为完整 agentic payment 安全方案。

十四、工程控制清单

下面的控制清单把论文和项目观察转成可执行要求。它不是法律意见，也不是某一支付网络规则，而是设计 agentic payment 系统时应纳入产品需求、架构评审、安全评审和上线门禁的控制项。

控制 1：最小权限支付凭证

agent 不应持有原始 PAN、CVV、无限 allowance 或长期热钱包私钥。优先使用 merchant-bound、amount-bound、time-bound、purpose-bound 的 scoped token、session key、SPT、mandate 或 EIP-3009/Permit2 授权，并在 UI 和日志中清楚显示 scope。

验收方式：要求实现方给出数据结构、API 字段、日志样例、异常样例和用户可见界面，而不只给口头说明。验收时要追问这个控制在 A2A/MCP 工具层、授权层、钱包/PSP 层、商户层和审计层分别如何体现。如果只能在某一层看到控制，其他层就仍可能绕过它。

控制 2：结构化意图编译

把自然语言指令编译成结构化 intent：预算、币种、商户、品类、时间窗、数量、替代规则、失败策略、退款要求、是否允许订阅。编译结果要给用户或上级策略确认，不能让 LLM 的隐藏推理直接成为支付授权。

控制 3：策略引擎强制执行

所有支付工具调用前必须过确定性 policy engine。策略至少包括单笔金额、累计金额、商户 allowlist/denylist、品类、地理、时间、频率、异常模型评分、制裁/KYC 状态和人工确认阈值。

控制 4：交易前后状态一致性

支付前锁定 cart hash、merchant id、price、tax、shipping、refund policy 和 expiration；支付后核查 response hash、order id、settlement id、receipt 和 fulfillment state。若支付前后状态不一致，默认阻断或要求重新确认。

控制 5：可信确认界面

高风险支付的确认不能完全由被网页内容控制的 agent 对话框生成，应使用 trusted surface：设备系统弹窗、issuer/PSP 页面、wallet confirmation、passkey challenge 或企业审批系统。

控制 6：工具内容隔离

把网页、商品描述、邮件和 tool metadata 标记为不可信输入，不能让它们覆盖系统策略、支付目标或安全提示。MCP 工具描述要签名、版本固定、allowlist，并把可变描述与支付权限隔离。

控制 7：付款与服务绑定

低额服务至少绑定 request hash、resource URI、payment id 和 response hash；高价值服务应使用 escrow、HTLC、adaptor signature、TEE receipt、zk proof 或 A402 类 channel，避免付款成功但服务缺失。

控制 8：隐私最小化

payment header、mandate、reason、description 和日志不要携带完整用户偏好、地址、健康、财务或商业机密。链上只锚定 hash 或 commitment，明文证据留在有访问控制的 PSP/商户/企业审计系统。

控制 9：撤销与过期

所有长期授权必须可撤销、可过期、可冻结。撤销应影响后续工具调用、支付 token、session key、agent credential、DID/VC status 和 policy cache，不能只在 UI 中显示已撤销。

控制 10：行为级限额

单笔限额不够，要加累计限额、滑动窗口、商户/品类限额、失败重试限额、并发 agent 限额、异常频率限额和策略升级。SoK 强调授权不能只看局部单笔，而要治理行为。

控制 11：身份与运行时绑定

agent identity 不应只等于 API key。高风险支付要绑定 agent 平台、代码版本、运行时测量值、wallet address、operator、user delegation 和 revocation status。BAID、DID/VC、TEE attestation、ERC-8004 可组合使用。

控制 12：可解释争议证据包

每笔 agentic payment 都应能生成 evidence package：用户原始意图、结构化 intent、cart snapshot、policy decision、agent/tool trace、payment token scope、settlement receipt、merchant fulfillment、refund state。

控制 13：稳定币合规闸门

x402/USDC 等稳定币路径要在 facilitator、wallet、merchant 或 marketplace 层加入 KYC/AML/制裁、地址风险评分、地理限制和冻结/退款流程。不能因为金额小就默认没有合规义务。

控制 14：商户职责保持

消费品 checkout 中商户应保持 merchant of record，负责库存、价格、税费、履约、退货、客服和争议。agent 平台不应让用户误以为模型能代替商户责任。

控制 15：分层风险升级

T0 只读或低额可自动；T1 小额可凭限额和日志；T2 中额要 trusted confirmation；T3 高额、跨境、不可逆或敏感品类要人工或企业审批、强认证和额外证明。

控制 16：可观测性与审计保留

把 correlation id 贯穿 A2A/MCP request、AP2 mandate、ACP checkout、x402 payment、PSP record、chain tx、TEE/ZK receipt 和 merchant order。日志保留要兼顾隐私、监管和争议期限。

控制 17：模拟和红队

上线前用 prompt injection、tool poisoning、counterfeit AgentCard、fake merchant、cart substitution、replay、double spend、facilitator failure、refund refusal 等测试集红队。

控制 18：故障安全默认拒绝

当价格、商户、收款地址、商品、库存、税费、运费、授权状态或风控结果无法确认时，默认拒绝或重新确认，而不是让 agent 自行解释并继续付款。

控制 19：跨平台责任合同

AI 平台、PSP、钱包、商户、issuer、facilitator、identity provider 需要合同定义责任：谁保留日志，谁处理退款，谁承担 fraud，谁响应监管请求，谁赔偿模型或工具错误。

控制 20：用户控制面板

用户和企业管理员需要看到 active mandates、agent wallets、spend caps、merchant permissions、recent payments、pending disputes 和 revoke buttons。没有控制面板，长期授权不可治理。

十五、常见误区与反证

误区 1：只要有用户点过一次同意，agent 后续付款就是授权的

错误。一次同意如果没有金额、商户、时间、品类、目的、重试、订阅和撤销条件，就不能覆盖长期自主行为。AP2 的 Intent Mandate 正是为了解决长期无人值守场景，但它也需要可执行约束和后续风控。

核查方法：回到本报告的五层模型，逐层问通信、授权、付款、履约、审计是否都有证据。如果某个说法只在一层成立，就不能把它扩张为全栈成立。这个反证方法适用于供应商评估、投资尽调、产品方案评审和安全设计评审。

误区 2：链上交易哈希就是完整审计

错误。链上哈希只能证明转账发生，不能证明为什么转、agent 看到了什么、服务是否交付、商品是否符合意图。SoK 明确指出 accounting 只记录付款不足以说明责任。

误区 3：x402 解决了 agentic payment 的所有问题

错误。x402 很适合 HTTP 微支付和 API 访问，但不解决身份、自然语言授权、服务正确性、退款、合规和争议。A402 对 x402 的批评正集中在支付与服务执行解耦。

误区 4：AP2 有 mandate，所以 prompt injection 不再重要

错误。mandate 能证明某个结构化授权被签署，但如果签署前 agent 已被恶意内容诱导，mandate 仍可能合法地表达错误选择。仍需内容隔离、trusted confirmation 和策略检查。

误区 5：传统卡网络会被 stablecoin agent payments 取代

证据不足。稳定币适合机器微支付和跨境开放结算，卡网络适合消费者保护、退款、issuer 风控和商户接受。短中期更可能是并存和分层，而不是单边替代。

误区 6：agent 身份等于钱包地址

错误。钱包地址只能证明密钥控制，不证明代码、操作者、平台、用户委托、运行时完整性、KYC 状态或权限范围。BAID、DID/VC、ERC-8004、TEE attestation 都是在补这一缺口。

误区 7：给 agent 设置单笔限额就安全

错误。agent 可以通过多笔、多个商户、多个子代理、失败重试或时间拆分绕过单笔限额。需要累计限额、行为限额、商户品类限制、速度限制和异常升级。

误区 8：商户只要接入 ACP/AP2/x402 就完成 agentic commerce

错误。商户还需要商品数据质量、库存、价格、税费、配送、退货、客服、争议证据、风控和 bot/agent 识别。协议只是入口，不是运营闭环。

误区 9：TEE 能证明服务结果一定正确

错误。TEE 证明某个测量值代码在隔离环境里运行，但代码可能有 bug，输入可能被污染，业务语义可能不正确，硬件也有信任边界。TEE 是证据组件，不是绝对真理。

误区 10：ZK 证明能马上解决大模型服务证明

过度乐观。ZK/zkVM 对形式化程序很强，但大模型、外部工具、非确定性和实时延迟仍是难点。现实中通常要 TEE、日志、抽样、optimistic proof 和人工争议结合。

误区 11：公司宣布合作就等于生产可用

错误。很多 agentic payment 发布是试点、受控交易、developer preview、waitlist 或研究 demo。报告必须区分官方发布、可集成 SDK、真实交易、全球 GA 和独立审计指标。

误区 12：低额交易不需要争议和退款

错误。低额单笔可能不值得人工争议，但 agent 能高速重复，累计损失和 abuse 仍大。至少需要自动退款、信用补偿、限额、异常阻断和服务质量记录。

十六、部署模板与上线门槛

模板：x402 低额 API

资源服务器返回 402 与 payment requirements；agent wallet 根据 session key 和预算策略签名；facilitator verify/settle；服务返回 response hash 与 payment response；审计系统记录 request id、payment id、tx hash、response digest。上线门槛是单笔上限、日限额、nonce/deadline、防重放、失败退款或 credit 规则。

上线前应做三轮验证。第一轮是 happy path：用户授权、agent 调用、付款、服务、收据、退款是否闭环。第二轮是 abuse path：伪商户、恶意网页、prompt injection、tool metadata 注入、重放、重复支付、facilitator 失败、余额不足、价格变化是否安全失败。第三轮是 dispute path：用户否认、商户不履约、服务结果错误、token 泄露、私钥撤销、制裁命中时证据能否导出并裁决。

模板：ACP/Stripe 商户 checkout

商户暴露 ACP endpoint 或接入 Stripe Agentic Commerce Suite；agent 创建 checkout，用户在 trusted surface 确认；SPT 或现有支付处理器完成付款；商户保持 merchant of record。上线门槛是商品快照、价格/税费/运费锁定、退货 API、客服路径和争议证据。

模板：AP2 mandate 授权

用户或设备签署 Intent/Cart Mandate；商户、credential provider、payment network 处理 Payment Mandate；PSP 或 issuer 用 mandate context 做风险评估。上线门槛是 mandate schema、签名密钥、撤销、过期、cart hash、支付凭证绑定和争议导出。

模板：企业 B2B agent 采购

企业 agent 从 approved supplier registry 发现服务；policy engine 检查预算、供应商、合同、审批；支付走虚拟卡、ACH、PayPal/Braintree、Stripe 或稳定币；ERP 写入 PO、invoice、receipt。上线门槛是职责分离、审批链、供应商 KYC、发票匹配和审计留存。

模板：A2A agent 服务市场

服务 agent 发布 AgentCard 与价格，可能注册到 ERC-8004；请求 agent 通过 A2A 调用并用 x402/L402 支付；服务返回 receipt；高价值服务加 TEE/ZK/A402。上线门槛是假 AgentCard 防护、能力验证、声誉抗 Sybil、服务质量和退款机制。

模板：长期无人值守个人 agent

用户创建长期 Intent Mandate，设置预算、品类、商户、时间和确认阈值；agent 每次行动前过 policy；低风险自动，高风险 step-up；用户 dashboard 可暂停和撤销。上线门槛是行为限额、异常检测、通知、回放、撤权和退款。

十七、结论

17.1 现状判断

Agentic payment 已经从概念进入早期落地，但还没有进入"开放世界任意 agent 自主付款"的成熟阶段。真正落地的部分主要是两端：一端是传统支付网络把 agentic checkout 纳入既有 card/wallet/PSP 体系，另一端是 x402/L402/stablecoin 把 API 微支付做成机器可执行协议。中间缺的，是跨平台身份、机器可读授权、支付-服务绑定、隐私保护审计、争议/退款和责任规则。

从产业成熟度看，agentic payment 当前处于"可用但不可信赖"的阶段。"可用"是指技术组件已经存在——x402 可以让 agent 为 API 付费、ACP 可以让 agent 在 ChatGPT 中 checkout、Visa/Mastercard 可以发放受限的 agentic token。"不可信赖"是指端到端的安全、合规和用户保护框架尚未建立——没有统一的 agent 身份标准、没有标准化的争议流程、没有明确的法律责任分配、没有经过大规模验证的反欺诈模型。

A402、SoK、TIVA、Inter-Agent Trust Models 等论文给出了清晰研究方向；OpenAI/Stripe、Google AP2、Coinbase x402、Visa、Mastercard、PayPal、Cloudflare、Circle、Skyfire、Nevermined 等项目给出了真实产业路径。两者交叉后的判断是：未来胜出的不会是单一 rail，而是能把意图、身份、策略、付款、执行和审计绑定成闭环的栈。

17.2 核心建议

本报告给出以下分层建议。

对 agent 平台（OpenAI、Anthropic、Google 等）。 (1) 不要让 LLM 直接持有原始支付凭证——所有支付操作应通过 scoped token 或 managed wallet，由策略引擎中介。(2) 投资 agent identity 基础设施——每个 agent 实例应有可验证的 identity，包括平台、代码版本和运行环境。(3) 建立 decision logging 和 replay 机制——每个支付相关决策都应该可以事后回放和审计。(4) 与支付网络合作定义 agent 在支付链路中的法律角色——是 agent of the cardholder、independent contractor、还是 tool of the merchant。

对支付网络和 PSP（Visa、Mastercard、Stripe、PayPal 等）。 (1) 扩展现有的 tokenization 和 authorization 框架以支持 agent 场景——不需要重建，但需要增加 agent identity binding、granular spend controls 和 agent-specific risk scoring。(2) 参与开放标准——AP2、ACP 的发展需要支付网络的参与才能确保可行性和互操作性。(3) 准备 agent-specific dispute 流程——当 agent 做了错误购买，chargeback 的证据要求和裁决标准需要更新。

对商户和服务提供者。 (1) 以机器可读的方式发布产品信息、价格、库存、退货政策——JSON-LD、structured data、ACP catalog API 都是可选方案。(2) 提供标准化的 order/fulfillment API——agent 需要能查询订单状态、发起退货、获取服务 receipt。(3) 考虑 x402 接入——如果你的服务适合按次计费（API、数据、内容），x402 可能比传统的 API key + monthly billing 更适合 agent 客户。

对监管机构。 (1) 认识到 agentic payment 是一个新的 modality，不是一个全新的支付系统——大部分现有的消费者保护、AML/KYC、支付清算规则仍然适用，但需要解释如何适用于 agent 场景。(2) 明确 agent 在支付链路中的法律地位——特别是代理关系、责任分配和消费者保护方面。(3) 鼓励 sandbox 和实验——过早的严格监管可能扼杀创新，但过晚的监管可能导致消费者受损后才补救。

对研究者和开发者。 (1) 关注 payment-service binding——这是当前最薄弱也最有研究价值的层。A402 的 Atomic Service Channels 是一个方向，但需要更多在不同场景（特别是非确定性服务）中的探索。(2) 研究 intent formalization——如何把自然语言的购买意图转化为机器可验证的授权约束，是 agentic payment 的核心 AI 问题。(3) 构建 benchmark 和评估框架——目前没有标准的方式来评估一个 agentic payment 系统的安全性、效率和用户体验。

17.3 最终原则

本报告给出的最务实建议是：把 LLM 视为提议者，把策略引擎视为裁判，把钱包或 PSP 视为执行者，把商户/服务 receipt 视为履约证据，把 mandate 与 payment token 视为可争议授权，把审计日志视为最终安全网。任何让 LLM 直接持有无限支付凭证、直接解释自然语言为不可逆转账、或无法回放证据的方案，都不应进入高价值生产场景。

Agentic payment 的未来很大，但它的工程原则应当朴素：

资金移动要小心——每一笔支付都要经过策略检查，不能只靠 LLM 的"判断"。
权限要可限——scoped token 优于全局密钥，mandate 优于 blanket authorization，session key 优于 persistent key。
执行要可证——低额用日志，高额用签名 receipt，高价值用 TEE/ZK proof。
错误要可退——争议流程不是可选功能，而是必要基础设施。
决策要可追责——correlation id 贯穿全链路，任何支付相关决策都有日志。

这五条原则不依赖于任何特定技术或协议。无论最终胜出的是 AP2 还是 ACP，是 x402 还是 L402，是 ERC-8004 还是 DID，这五条原则都应该成为 agentic payment 系统设计的基线。

附录 A：来源索引

A2A: Google A2A announcement
A2ALF: Google Cloud donates A2A to Linux Foundation
A402: A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce
ACPGitHub: Agentic Commerce Protocol GitHub
AP2: AP2 documentation
AP2GitHub: AP2 GitHub
AP2Spec: AP2 specification
BAID: Binding Agent ID
BirchGamble: Agentic commerce and payments: robots paying robots
BlockA2A: BlockA2A
Circle: Circle x402 + USDC
CloudflareX402: Cloudflare x402
EIP8004: ERC-8004 Trustless Agents
EMVCo: EMVCo Payment Tokenisation
FATF: FATF virtual assets guidance
FinCEN: FinCEN CVC guidance
GooglePayPal: Google Cloud + PayPal agentic commerce
IAM: A Novel Zero-Trust Identity Framework for Agentic AI
L402: Lightning Labs L402
MCP: Model Context Protocol intro
MDN402: MDN HTTP 402
Mastercard: Mastercard Agent Pay
NIST: NIST SP 800-63-4
Nevermined: Nevermined
OFAC: OFAC virtual currency sanctions guidance
OWASPLLM: OWASP Top 10 for LLM Applications
OWASPMCP: OWASP Top 10 for MCP Risks
OpenAIACP: OpenAI Instant Checkout and ACP
PCI: PCI DSS document library
PayPal: PayPal agentic commerce services
SAKSHI: SAKSHI: Decentralized AI Platforms
Skyfire: Skyfire
SoK: SoK: Blockchain Agent-to-Agent Payments
StripeACP: Stripe agentic commerce
StripeDocs: Stripe ACP docs
StripeMPP: Stripe Machine Payments Protocol
StripeNews: Stripe + OpenAI Instant Checkout
TIVA: Secure Autonomous Agent Payments
TMAE: Towards Multi-Agent Economies
TrustModels: Inter-Agent Trust Models
VisaAgentic: Visa agentic commerce
VisaConnect: Visa Intelligent Commerce Connect
VisaIC: Visa Intelligent Commerce
x402Docs: Coinbase x402 docs
x402GitHub: x402 GitHub
x402Site: x402 site

附录 B：Zotero 本地材料说明

本地 Zotero collection ai-agent 共有 25 条记录，直接相关核心条目为 A402、SoK、Towards Multi-Agent Economies、Secure Autonomous Agent Payments、Agentic commerce and payments、SAKSHI、Inter-Agent Trust Models；支持性条目为 BAID、BlockA2A、Agentic AI IAM Framework 等。本地已抽取的文本位于 /Users/jc/ws/codex-start/research/agentic-payment/text/，候选清单位于 /Users/jc/ws/codex-start/research/agentic-payment/sources/zotero_agentic_payment_candidates.tsv，补充下载的 arXiv PDF 索引位于 /Users/jc/ws/codex-start/research/agentic-payment/sources/downloaded_arxiv_index.json。对期刊页仅有摘要的 Birch/Gamble 论文，本报告只引用公开摘要，不引用无法核验全文细节。

附录 C：字数统计

CJK 汉字计数：61327
总字符计数：144637
统计方式：CJK 汉字计数只统计 \u4e00-\u9fff 范围；总字符计数包含英文、数字、空格、标点和 URL。