💻 build_report.py
python · 638 lines · ⬇️ Download
from __future__ import annotations
import re
from pathlib import Path
BASE = Path("/Users/jc/ws/codex-start/research/agentic-payment")
OUT = BASE / "agentic_payment_research_report.md"
def cjk_count(text: str) -> int:
return sum(1 for ch in text if "\u4e00" <= ch <= "\u9fff")
def total_chars(text: str) -> int:
return len(text)
def md_link(label: str, url: str) -> str:
return f"[{label}]({url})"
SOURCES = {
"A402": ("A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce", "https://arxiv.org/abs/2603.01179"),
"SoK": ("SoK: Blockchain Agent-to-Agent Payments", "https://arxiv.org/abs/2604.03733"),
"TMAE": ("Towards Multi-Agent Economies", "https://arxiv.org/abs/2507.19550"),
"TIVA": ("Secure Autonomous Agent Payments", "https://arxiv.org/abs/2511.15712"),
"BirchGamble": ("Agentic commerce and payments: robots paying robots", "https://hstalks.com/doi/10.69554/NGEA2302/"),
"SAKSHI": ("SAKSHI: Decentralized AI Platforms", "https://arxiv.org/abs/2307.16562"),
"TrustModels": ("Inter-Agent Trust Models", "https://arxiv.org/abs/2511.03434"),
"BAID": ("Binding Agent ID", "https://arxiv.org/abs/2512.17538"),
"BlockA2A": ("BlockA2A", "https://arxiv.org/abs/2508.01332"),
"IAM": ("A Novel Zero-Trust Identity Framework for Agentic AI", "https://arxiv.org/abs/2505.19301"),
"AP2": ("AP2 documentation", "https://ap2-protocol.org/"),
"AP2Spec": ("AP2 specification", "https://ap2-protocol.org/specification/"),
"AP2GitHub": ("AP2 GitHub", "https://github.com/google-agentic-commerce/AP2"),
"GooglePayPal": ("Google Cloud + PayPal agentic commerce", "https://cloud.google.com/blog/topics/financial-services/introducing-an-agentic-commerce-solution-for-merchants-from-paypal-and-google-cloud"),
"x402Docs": ("Coinbase x402 docs", "https://docs.cdp.coinbase.com/x402/welcome"),
"x402Site": ("x402 site", "https://www.x402.org/"),
"x402GitHub": ("x402 GitHub", "https://github.com/x402-foundation/x402"),
"CloudflareX402": ("Cloudflare x402", "https://blog.cloudflare.com/x402/"),
"OpenAIACP": ("OpenAI Instant Checkout and ACP", "https://openai.com/blog/buy-it-in-chatgpt/"),
"ACPGitHub": ("Agentic Commerce Protocol GitHub", "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol"),
"StripeACP": ("Stripe agentic commerce", "https://stripe.com/use-cases/agentic-commerce"),
"StripeDocs": ("Stripe ACP docs", "https://docs.stripe.com/agentic-commerce/protocol"),
"StripeNews": ("Stripe + OpenAI Instant Checkout", "https://stripe.com/newsroom/news/stripe-openai-instant-checkout"),
"StripeMPP": ("Stripe Machine Payments Protocol", "https://stripe.com/blog/machine-payments-protocol"),
"Mastercard": ("Mastercard Agent Pay", "https://www.mastercard.com/news/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai"),
"VisaAgentic": ("Visa agentic commerce", "https://corporate.visa.com/en/solutions/acceptance/agentic-commerce.html"),
"VisaIC": ("Visa Intelligent Commerce", "https://corporate.visa.com/en/products/intelligent-commerce.html"),
"VisaConnect": ("Visa Intelligent Commerce Connect", "https://corporate.visa.com/en/products/intelligent-commerce-connect.html"),
"PayPal": ("PayPal agentic commerce services", "https://newsroom.paypal-corp.com/2025-10-28-PayPal-Launches-Agentic-Commerce-Services-to-Power-AI-Driven-Shopping"),
"Skyfire": ("Skyfire", "https://skyfire.xyz/"),
"Nevermined": ("Nevermined", "https://nevermined.ai/"),
"Circle": ("Circle x402 + USDC", "https://www.circle.com/blog/autonomous-payments-using-circle-wallets-usdc-and-x402"),
"A2A": ("Google A2A announcement", "https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/"),
"A2ALF": ("Google Cloud donates A2A to Linux Foundation", "https://developers.googleblog.com/google-cloud-donates-a2a-to-linux-foundation/"),
"MCP": ("Model Context Protocol intro", "https://modelcontextprotocol.io/docs/getting-started/intro"),
"EIP8004": ("ERC-8004 Trustless Agents", "https://eips.ethereum.org/EIPS/eip-8004"),
"FinCEN": ("FinCEN CVC guidance", "https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-persons-administering"),
"OFAC": ("OFAC virtual currency sanctions guidance", "https://ofac.treasury.gov/recent-actions/20211015"),
"FATF": ("FATF virtual assets guidance", "https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html"),
"PCI": ("PCI DSS document library", "https://www.pcisecuritystandards.org/document_library/"),
"EMVCo": ("EMVCo Payment Tokenisation", "https://www.emvco.com/specifications/payment-tokenisation/"),
"NIST": ("NIST SP 800-63-4", "https://pages.nist.gov/800-63-4/sp800-63.html"),
"OWASPLLM": ("OWASP Top 10 for LLM Applications", "https://owasp.org/www-project-top-10-for-large-language-model-applications/"),
"OWASPMCP": ("OWASP Top 10 for MCP Risks", "https://genai.owasp.org/resource/owasp-top-10-for-mcp-risks-2025/"),
"MDN402": ("MDN HTTP 402", "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402"),
"L402": ("Lightning Labs L402", "https://github.com/lightninglabs/L402"),
}
PAPERS = [
{
"title": "A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce",
"role": "核心论文；直接研究 agentic commerce 中服务调用与加密货币付款如何原子绑定。",
"source": "A402",
"facts": [
"论文指出 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 美元。",
],
"limits": "研究原型，不是生产标准；依赖 TEE、远程证明和通道生命周期；论文把 TEE 侧信道等特定攻击放在边界之外。对大型 LLM、多外部 API、非确定性服务和多步工作流，TEE 内可证明执行并不自然。",
},
{
"title": "SoK: Blockchain Agent-to-Agent Payments",
"role": "核心综述；提供 discovery、authorization、execution、accounting 四阶段生命周期框架。",
"source": "SoK",
"facts": [
"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 工作流要能组合，价格/范围也要支持交互式形成。",
],
"limits": "没有实现和性能实验，贡献是系统化分类与风险定位；它能指出每层缺口，但不提供单一落地协议。",
},
{
"title": "Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents",
"role": "核心架构论文；把 A2A AgentCard 发现和 x402 微支付组合成 prototype。",
"source": "TMAE",
"facts": [
"论文认为 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 主体的情况下组合，但把链上身份、发现、付款地址和历史都公开化。",
],
"limits": "作者承认缺 ecosystem-wide registry；链上结算会引入延迟和费用波动；agent 持有私钥和资金会引入被诱导大额支付或被盗用的攻击面。",
},
{
"title": "Secure Autonomous Agent Payments: Verifying Authenticity and Intent in a Trustless Environment",
"role": "核心设想论文；提出 DID/VC、on-chain intent proof、ZKP、TEE 和 agent wallet 合成的 TIVA 框架。",
"source": "TIVA",
"facts": [
"论文把问题定义为两个核心问题：这个付款是不是由真实 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 等，不提供性能指标。",
],
"limits": "不是部署产品；授权范围内的错误选择仍可能发生；如果用户/agent 两侧关键密钥都失陷，框架难以提供额外保护；TEE 与 ZKP 都需要工程落地和标准化。",
},
{
"title": "Agentic commerce and payments: Exploring the implications of robots paying robots",
"role": "核心行业论文；把 R2R robot-to-robot payments 纳入支付战略视野。",
"source": "BirchGamble",
"facts": [
"摘要指出传统 machine-to-machine payments 与 Agentic AI 正在交汇，智能代理从聊天机器人演化为可自主决策、因而可自主付款的机器人。",
"作者提出 R2R 支付需求，并认为 smart wallet，即可由机器人操作的钱包，会成为中心编排机制。",
"摘要也谨慎指出早期实验常用区块链和支付卡，但尚不清楚它们是否满足这个新兴部门的需求。",
],
"limits": "Zotero 无本地全文，公开期刊页主要可核验摘要、DOI、页码和期刊信息；报告中只使用公开摘要可核查信息，不引用不可见全文细节。",
},
{
"title": "SAKSHI: Decentralized AI Platforms",
"role": "半核心；早期把 AI 服务计量、支付通道和 proof-of-inference 组织成去中心化 AI 平台。",
"source": "SAKSHI",
"facts": [
"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 等争议。",
],
"limits": "它更像 decentralized AI service marketplace，不是现代 ACP/AP2 式消费 checkout；作者也指出大模型 ZKP 验证在当时不现实，模型复制只能通过经济机制缓解。",
},
{
"title": "Inter-Agent Trust Models",
"role": "支持论文；从 Brief、Claim、Proof、Stake、Reputation、Constraint 六种信任模型比较 A2A、AP2、ERC-8004 等。",
"source": "TrustModels",
"facts": [
"论文的核心判断是 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 的最后防线。",
],
"limits": "比较研究，无实验；Proof、Stake、Reputation 都有成本、延迟、Sybil、collusion、whitewashing 或可证明性边界。",
},
{
"title": "Binding Agent ID / BAID",
"role": "支持论文；把用户、代码完整性和执行 provenance 绑定到 agent 身份。",
"source": "BAID",
"facts": [
"BAID 试图避免传统 key-based authentication 只证明持有密钥而不能证明操作者物理身份或 agent 代码完整性。",
"方案结合 biometric local binding、on-chain identity management 和 zkVM-based Code-Level Authentication。",
"对 agentic payment 来说，BAID 支撑的是谁在操作、什么代码在操作、操作 provenance 是否可验证，而不是支付轨道本身。",
],
"limits": "对真实支付仍需接入 AP2/x402/PSP/钱包；生物识别和 zkVM 证明的用户体验、隐私、成本都需要进一步评估。",
},
{
"title": "BlockA2A",
"role": "支持论文；把 A2A 安全扩展到 DID、链上审计、智能合约访问控制和防御编排。",
"source": "BlockA2A",
"facts": [
"BlockA2A 把多 agent 系统风险归纳为碎片化身份、不安全通信、Byzantine agents 和 adversarial prompts。",
"方案使用 DIDs、blockchain-anchored ledgers、smart contracts 和 Defense Orchestration Engine。",
"对支付而言，它说明 A2A 的沟通层必须再加身份、策略和审计，否则支付只是把风险放大。",
],
"limits": "它不是支付协议；支付结算、退款、争议和合规仍需其他层。",
},
{
"title": "A Novel Zero-Trust Identity Framework for Agentic AI",
"role": "支持论文；讨论 IAM 对多 agent 系统的不足和 DID/VC/ANS/全局会话管理。",
"source": "IAM",
"facts": [
"论文认为 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、撤销和权限边界提供身份底座。",
],
"limits": "身份框架只能保证主体和权限的可表达性，不能保证商户履约、模型判断正确或支付争议裁决。",
},
]
PROJECTS = [
{
"name": "Coinbase x402 / x402 Foundation",
"status": "开放标准与 SDK；Coinbase 文档称 x402 是基于 HTTP 的 instant automatic stablecoin payments；Cloudflare 与 Coinbase 宣布 x402 Foundation。",
"rails": "USDC、EURC、Base、Polygon、Arbitrum、World、Solana 等；EIP-3009 与 Permit2 等授权模型。",
"mechanism": "服务端返回 HTTP 402 与 payment requirements，agent/客户端签名 payment payload 后重试，facilitator 可负责 verify/settle。",
"sources": ["x402Docs", "x402Site", "CloudflareX402", "MDN402"],
"evidence": "官方文档明确 x402 让人和机器无需账户、session 或复杂认证即可程序化支付访问 API 与数字内容；facilitator 帮 seller 避免直接维护区块链基础设施。",
"gaps": "exact/upto 都偏 push payment；支付证明不证明服务正确执行；退款、争议、身份、合规、PII metadata 与跨链一致性仍需额外层。",
},
{
"name": "Google AP2",
"status": "开源规范与参考实现；AP2 文档称它是 agent economy 的开放协议，作为 A2A extension，并计划更多 integration。",
"rails": "支付方式无关；初版支持 credit/debit card 等 pull payments，路线图包括 real-time bank transfers、e-wallets、digital currencies。",
"mechanism": "Intent Mandate、Cart Mandate、Payment Mandate 三类 VDC，把用户意图、具体购物车、支付网络可见信号形成签名证据链。",
"sources": ["AP2", "AP2Spec", "AP2GitHub", "GooglePayPal"],
"evidence": "AP2 规格明确当前支付系统假设人类直接点击买，agent 发起付款会让授权、意图真实性和责任归属变得不清；mandates 是为解决该缺口而设计的。",
"gaps": "AP2 强化授权和争议证据，不证明服务真实交付；V0.1 更偏 human-present 和 pull payment，human-not-present、push payment、recurring、多商户拓扑在后续版本。",
},
{
"name": "OpenAI + Stripe Agentic Commerce Protocol / Instant Checkout",
"status": "OpenAI 官方宣布 Instant Checkout in ChatGPT，ACP 与 Stripe 共同构建并开源；Stripe 称 ACP 是 live specification。",
"rails": "Stripe、Apple Pay、Google Pay、Link、card 等；也支持非 Stripe 商户通过 Shared Payment Token 或 ACP Delegated Payments Spec。",
"mechanism": "agent 负责展示 checkout 与收集受限凭证，seller 保留自己的数据模型、订单处理、payment processing、fulfillment 和 support。",
"sources": ["OpenAIACP", "ACPGitHub", "StripeNews", "StripeDocs", "StripeACP"],
"evidence": "OpenAI 官方说明用户在每一步行动前明确确认，payment tokens 只被授权给特定金额和特定商户，数据分享最小化；Stripe 文档说明 agentic checkout 中 AI agent 负责 checkout interface，而 seller 负责后端处理。",
"gaps": "首发场景有限；ACP 更偏 commerce checkout 交互模型和凭证传递，不解决 agent 身份全球注册、服务执行证明、稳定币微支付或多 agent 服务计量。",
},
{
"name": "Mastercard Agent Pay",
"status": "Mastercard 2025-04-29 发布 Agentic Payments Program / Mastercard Agent Pay。",
"rails": "Mastercard 网络、tokenization、Agentic Tokens、Payment Passkeys。",
"mechanism": "注册和验证 trusted agents，使用 agentic tokens 基于既有 tokenization 能力，让消费者、商户、issuer 在既有网络内处理代理交易。",
"sources": ["Mastercard"],
"evidence": "官方新闻稿明确 Agent Pay 引入 Mastercard Agentic Tokens，并将与 Microsoft 等 AI 平台、IBM watsonx Orchestrate、Braintree、Checkout.com 等协作。",
"gaps": "这是卡网络路径，优势是接入既有争议和风控，但不是开放 HTTP 微支付；跨网络、跨 PSP、agent identity 标准和责任规则还要行业共同形成。",
},
{
"name": "Visa Intelligent Commerce / Agentic Commerce",
"status": "Visa 对 agentic commerce 提供产品和方案页面；强调 AI workflows、payments、standards 和 safeguards。",
"rails": "Visa 网络、Visa tokenization、AI-ready credentials、Visa Intelligent Commerce Connect。",
"mechanism": "将支付嵌入 AI workflow，用 token、authentication、spend control、risk signal 帮助 agent 能安全完成购买。",
"sources": ["VisaAgentic", "VisaIC", "VisaConnect"],
"evidence": "Visa 官方页面将 agentic commerce 描述为 agent 浏览、比较、应用偏好并按用户设定规则付款的购物模式；Visa Agentic Commerce 页面强调帮助客户将 payments 嵌入 AI workflows。",
"gaps": "卡组织的优势是网络规则和 consumer protection；但大规模 GA、跨网络互操作、merchant readiness 和 agent 责任证据仍处于建设阶段。",
},
{
"name": "PayPal agentic commerce services",
"status": "PayPal 2025-10-28 宣布 agentic commerce services；Google Cloud 与 PayPal 公布 agentic commerce solution。",
"rails": "PayPal wallet、Braintree、PayPal payment infrastructure、buyer protection、identity verification。",
"mechanism": "store sync、agent ready、PayPal Agent 与 merchant agent 通过 A2A 通信并集成 AP2；PayPal 侧处理 trusted surface、payment method recommendation、BNPL eligibility 和授权。",
"sources": ["PayPal", "GooglePayPal"],
"evidence": "PayPal 新闻稿称服务包括 agentic payment solution、catalog and order management，并基于 trusted payments infrastructure、identity verification 和 buyer protection。",
"gaps": "许多能力处于申请访问或逐步可用阶段；它能缓解商户接入和争议，但仍需跨平台协议互认和更细的责任分配。",
},
{
"name": "Stripe Agentic Commerce Suite / Agent Toolkit / MPP",
"status": "Stripe 产品页称 Agentic Commerce Suite 帮助商户让商品可被 agent 发现、简化 checkout 并接受 agentic payments；文档提供 ACP 集成。",
"rails": "Stripe payments、Radar、Shared Payment Tokens、PaymentIntents；MPP/agent toolkit 面向 AI 产品 monetization。",
"mechanism": "商户把产品目录接入 agent surfaces，ACP 处理 checkout lifecycle，SPT 降低 PCI 敏感凭证暴露，Radar 处理 fraud signals。",
"sources": ["StripeACP", "StripeDocs", "StripeNews", "StripeMPP"],
"evidence": "Stripe 产品页明确 ACP 开源、Apache 2.0、与 OpenAI 共建，且兼容任何 AI agent 或 payment processor；文档明确 agentic checkout 和传统 checkout 的职责划分。",
"gaps": "很多能力依赖 Stripe 生态和商户接入；对于 x402 式无账户微支付、链上结算和 agent-to-agent API 计量，需要另接 MPP 或其他协议。",
},
{
"name": "Skyfire",
"status": "商业化 agent payments and identity 平台，官网称提供 KYA identity 与 autonomous payments。",
"rails": "USDC、tokenized cards、ACH、wallets 等，具体可用性以 Skyfire 文档和接入为准。",
"mechanism": "AI agent 发起服务请求，服务验证 agent identity 和 payment，付款完成后服务交付；强调 Know Your Agent。",
"sources": ["Skyfire"],
"evidence": "Skyfire 官网首页明确定位为 payments and identity built for the AI economy，并称 AI agents 可以处理付款、验证身份和访问服务。",
"gaps": "官方页面是公司自述；行业标准地位、外部审计交易量、监管接受度和跨协议互认仍需继续核查。",
},
{
"name": "Nevermined",
"status": "AI agent payments infrastructure；官网称 Nevermined Pay 让 AI agents 使用用户现有信用/借记卡在严格 spending rules 内完成真实购买。",
"rails": "Stripe today，PayPal Braintree 和 Visa Cybersource coming soon；也与 MCP、A2A、x402、OpenClaw、plain HTTP 等对接。",
"mechanism": "服务注册、连接支付提供方、设置 per-transaction limits、daily caps、merchant categories，并可 revoke。",
"sources": ["Nevermined"],
"evidence": "Nevermined 官网明确写到 framework agnostic、spending controls、settle via Stripe today，以及 No vendor lock-in。",
"gaps": "许多支付提供方仍是 coming soon；大规模商户覆盖、买家保护和监管责任仍需和 PSP/商户共同处理。",
},
{
"name": "Circle Wallets + USDC + x402 / Nanopayments",
"status": "Circle 官方提供 x402 + USDC agent payment 示例和 nanopayments 方向。",
"rails": "USDC、Circle Wallets、Circle Gateway、x402。",
"mechanism": "agent 收到 HTTP 402 后用 Circle Wallet 生成签名支付授权，Circle/Gateway 批量或直接结算。",
"sources": ["Circle"],
"evidence": "Circle 官方博客说明用 Circle Wallets、USDC 和 x402 实现 autonomous payments；这证明 stablecoin wallet provider 正在把 agent payment 做成开发者路径。",
"gaps": "这不是完整电商 checkout；Circle 层解决 wallet/settlement，不负责商户履约、退货、税务、争议和自然语言意图解释。",
},
{
"name": "Cloudflare x402 / Pay Per Crawl",
"status": "Cloudflare 与 Coinbase 推动 x402 Foundation，并在 Agents 与 MCP 场景支持 x402；Pay Per Crawl 是 AI crawler 付费访问方向。",
"rails": "Stripe 管理付款、x402 stablecoin/onchain、deferred scheme 等组合。",
"mechanism": "内容/API 服务可返回价格和支付要求，AI crawler 或 agent 付费后访问。",
"sources": ["CloudflareX402", "x402Site"],
"evidence": "Cloudflare 博客明确和 Coinbase 合作创建 x402 Foundation；这说明 agentic payments 也在内容访问和爬虫经济里落地。",
"gaps": "crawler 是否愿意大规模付费是商业问题；protocol 仍需解决内容价值、版权、身份、bot 识别、退款和 abuse。",
},
{
"name": "L402 / Lightning LSAT",
"status": "成熟度中等；适合 Lightning-native API 付费凭证。",
"rails": "Bitcoin Lightning Network。",
"mechanism": "HTTP 402 返回 Lightning invoice 与 Macaroon；支付后 preimage 与 Macaroon 组合成 L402 authorization。",
"sources": ["L402", "MDN402"],
"evidence": "Lightning Labs L402 规范说明这是 Macaroon 与 Lightning invoice preimage 结合的认证机制，适合 API access。",
"gaps": "流动性、路由、托管、BTC 计价和服务执行证明仍是限制；credentials 也有 bearer token 风险。",
},
]
PROTOCOLS = [
("A2A", "解决不同供应商和框架的 agent 如何发现能力、交换任务、长期协作。它提供 AgentCard、skills、HTTP/SSE/JSON-RPC 等基础，但不自带付款。", ["A2A", "A2ALF"], "A2A 在支付中的角色是发现与协作，不是授权和结算。报告中把 A2A 看成 commerce graph 的通信层。"),
("MCP", "解决 AI 应用如何连接外部工具、数据源和 workflow。它让 agent 能调用支付、订单、库存、风控工具，但本身不提供付款。", ["MCP"], "MCP 的风险是工具描述进入模型上下文，支付工具一旦暴露过宽权限，会把 prompt injection 变成资金风险。"),
("x402", "解决机器如何按 HTTP 请求为 API/资源付款。它把 HTTP 402 变成 stablecoin/onchain 的付款握手。", ["x402Docs", "x402Site"], "x402 证明付款，不证明服务执行；适合低额 API 和内容访问，不适合单独承载高价值履约。"),
("AP2", "解决用户授权与支付网络可见性。Mandate 让商户、agent、凭证提供方和支付网络看到谁授权了什么。", ["AP2", "AP2Spec"], "AP2 不直接处理最终资金清算，也不证明商品真实交付；它是授权与审计层。"),
("ACP", "解决 agent-facing checkout 与商户后端的交互模型。它保留商户为 merchant of record，同时让 agent 能发起 checkout。", ["ACPGitHub", "OpenAIACP", "StripeDocs"], "ACP 适合电商 checkout，不是通用 agent-to-agent micropayment rail。"),
("ERC-8004", "解决开放 agent economy 中 agent 发现、身份、声誉和验证的公共注册表。", ["EIP8004"], "ERC-8004 明确不保证广告能力一定真实或非恶意；支付也不在标准核心范围。"),
("DID/VC", "解决 agent、用户、商户、凭证提供方之间可验证身份、资质和授权声明。", ["AP2Spec", "IAM", "TIVA"], "DID/VC 是数据模型和证明机制，不等于可信 issuer、撤销机制或支付责任规则。"),
("TEE attestation", "解决低延迟证明某个测量值代码在硬件隔离环境中运行的问题。", ["A402", "TIVA"], "TEE 证明运行环境，不证明代码本身正确；还要面对硬件供应链、侧信道、rollback、debug mode 等问题。"),
("ZK/zkVM", "解决在不泄露隐私的情况下证明策略满足或程序按公开输入执行。", ["TIVA", "BAID"], "ZK 对大模型和外部工具成本高，且只能证明形式化 statement，不能证明现实世界语义。"),
("Policy/capability/wallet", "解决 agent 具体能花多少钱、向谁花、在何时花、用什么凭证花。", ["Nevermined", "AP2Spec", "TrustModels"], "这是资金安全的实际闸门；没有 spend caps、merchant allowlist、session keys、撤销和审计，agent payment 就只是热钱包自动化。"),
]
PAINS = [
("用户授权与意图绑定", "自然语言愿望不是支付授权。用户说“帮我买一张便宜机票”没有确定收款方、金额、税费、行李、取消政策和替代方案；若 agent 最终签了某个订单，争议中必须证明这不是模型误解。AP2 用 Intent Mandate 和 Cart Mandate 把用户意图、购物车、价格和付款凭证哈希化并签名，ACP/SPT 把支付 token 限定在特定商户和金额，卡组织路线把 token 与强认证、风控和 spend controls 结合。剩余缺口是语义层：类似商品、价格小幅变化、分批履约、订阅续费、捆绑优惠、动态运价和多商户组合如何机器可判定。"),
("代理身份与 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，失败自动回滚，用户可查看、暂停和撤销授权。"),
]
SCENARIOS = [
("低额 API 调用", "最适合 x402 或 L402。agent 请求天气、行情、搜索、OCR、网页抽取、模型推理等接口，服务返回 402，agent 按次支付。关键控制是单次限额、每日总额、endpoint allowlist、resource hash 和 response receipt。若结果错误，通常用服务信用或退款处理，而不是链上争议。"),
("内容/数据付费访问", "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 和一键撤销。授权必须可持续更新，不能只靠一次签名长期有效。"),
]
def source_list(keys):
return "；".join(md_link(SOURCES[k][0], SOURCES[k][1]) for k in keys)
def build_report() -> str:
parts: list[str] = []
parts.append("# Agentic Payment 研究报告\n")
parts.append("生成日期：2026-04-21。工作区：`/Users/jc/ws/codex-start`。Zotero 来源：本机 `/Users/jc/Zotero/zotero.sqlite`，collection `ai-agent`，`collectionID=29`。报告综合本地 Zotero 论文、官方网页、官方文档、GitHub 规范、公司新闻稿、监管/标准资料与多路 subagent 调研笔记。所有结论按“已核事实、作者观点、推论/建议”分层表达；凡是未能看到全文或仅为公司自述，均保守标注。\n")
parts.append("\n## 一、执行摘要\n")
parts.append(
"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 等支付网络或基础设施则负责真实资金轨道、风控和商户接入。最核心的结论是：现在已经可以做真实的低额机器支付和受控 agentic commerce，但大规模开放式 autonomous payment 还缺三件事：可机器执行的授权语义、支付与服务履约的端到端绑定、以及跨平台责任和争议规则。\n"
)
parts.append(
"从落地项目看，最成熟的路线有三类。第一类是传统支付网络的 agentic commerce：OpenAI/Stripe ACP 与 Instant Checkout、Visa Intelligent Commerce、Mastercard Agent Pay、PayPal agentic commerce services，它们的优势是复用现有 card/wallet/PSP 的风控、争议、tokenization、商户关系和消费者保护。第二类是 crypto-native 或 API-native micropayment：Coinbase x402、Cloudflare x402、Circle USDC+x402、L402/Lightning、Nevermined、Skyfire 等，它们的优势是无账户、可编程、按次计费、跨境和适合机器到机器场景。第三类是信任与身份基础设施：AP2 mandates、ERC-8004、DID/VC、KYA、AgentCard registry、TEE/ZK proof，它们不直接完成支付，却决定支付能不能被商户、issuer、用户和监管者接受。\n"
)
parts.append(
"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、一笔链上交易或一次用户确认。\n"
)
parts.append(
"本报告将 Agentic payment 的难点归纳为十二类：用户授权与意图绑定、代理身份与 KYA、责任归属、争议/退款/履约、AML/KYC/制裁、PCI 与 tokenization、prompt/tool injection、spend limits、支付与服务执行解耦、隐私、审计、产品体验与商户接入。它们彼此耦合。例如，支付 token 限制金额可以降低损失，但不能判断商品是否符合用户意图；链上交易哈希能证明转账，但不能证明服务交付；AP2 mandate 能证明某个 cart 被用户确认，但不能证明 agent 在确认前没有被恶意网页影响；ERC-8004 可以登记 agent 身份和验证记录，但不能保证 advertised capability 一定真实。真正可行的方向是把同一个 correlation id 贯穿用户意图、agent 身份、策略决策、工具执行、支付凭证、服务结果和争议证据。\n"
)
parts.append("\n## 二、研究方法、证据等级与事实核查原则\n")
parts.append(
"本次研究采用三条证据链并行。第一条是 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 只负责小块，并在结果中给出链接和不确定性。报告最终只采用可追溯来源，不采用无法核验的营销说法作为硬事实。\n"
)
parts.append(
"证据等级分为四类。A 级是官方规范、官方文档、标准组织或监管机构资料，例如 AP2 规格、x402 Coinbase 文档、OpenAI/Stripe ACP 官方资料、EIP-8004、MCP 官方文档、A2A 官方公告、PCI/FinCEN/OFAC/FATF。B 级是公司新闻稿和产品页，例如 Mastercard Agent Pay、Visa Agentic Commerce、PayPal agentic commerce services、Skyfire、Nevermined。B 级可证明“公司这样发布或这样声称”，但不能证明大规模生产指标。C 级是 arXiv/预印本或学术论文，它们可作为设计和威胁模型证据，但不是监管依据，也不等同生产部署。D 级是第三方媒体、聚合页面和社区讨论，仅用于发现线索，除非被官方来源确认，否则不作为核心事实。\n"
)
parts.append(
"报告中常见措辞也严格区分：'官方文档称' 表示可由官方页面核验；'论文指出' 表示作者观点或实验结论；'本报告推断' 表示基于多源交叉后的分析；'未公开/未核实' 表示未找到足够证据。对日期和状态使用绝对日期，例如截至 2026-04-21，避免把“今天”“近期”这类相对表述留给未来读者误读。\n"
)
parts.append("\n## 三、概念边界：Agentic payment 不等于“AI 自动刷卡”\n")
parts.append(
"Agentic payment 常被误解为把用户信用卡交给一个 LLM。这个理解风险极高，也不符合当前主流方案。更准确地说，agentic payment 是把“理解和规划”与“资金移动”分离：LLM 或 agent 可负责理解用户需求、搜索候选项、形成购物车或服务调用计划，但资金移动必须通过确定性协议、受限支付凭证、签名授权、策略引擎、风控模型和审计日志。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 等协议化。\n"
)
parts.append(
"因此，本报告把 agentic payment 的范围划成五层。第一层是交互层，典型协议是 A2A、MCP、ACP，它回答 agent 如何发现商户或服务、如何交换任务、如何发起 checkout 或 API call。第二层是授权层，典型方案是 AP2 mandates、DID/VC、SPT、session keys、spend limits，它回答用户是否授权、授权范围是什么。第三层是支付层，典型轨道是 card/wallet/PSP、stablecoin/x402、Lightning/L402、MPP、payment channels，它回答钱怎么动。第四层是执行与履约证明层，典型机制是 merchant order records、TEE attestation、ZK/zkVM、service receipts、A402 Atomic Service Channels，它回答服务是否完成。第五层是审计与合规层，典型组件是 PSP logs、decision logs、chain tx hashes、mandate hashes、KYC/AML/sanctions screening、dispute evidence package，它回答事后如何解释、追责和退款。\n"
)
parts.append(
"这个分层能解释为什么市场上会同时出现看似竞争的 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。把其中任何一个当作完整答案，都会漏掉其他层的风险。\n"
)
parts.append("\n## 四、Zotero 核心论文综述\n")
for p in PAPERS:
parts.append(f"\n### {p['title']}\n")
parts.append(f"角色定位：{p['role']} 主要来源：{md_link(SOURCES[p['source']][0], SOURCES[p['source']][1])}。\n")
parts.append("可核查事实：\n")
for fact in p["facts"]:
parts.append(f"- {fact}\n")
parts.append(f"边界与不足：{p['limits']}\n")
parts.append(
"对本报告的意义：这篇文献不是孤立引用，而是与其他来源交叉使用。若它讨论的是协议缺口，本报告会用官方规范核查该协议实际覆盖范围；若它给出实验数字，本报告只把数字用于说明结构性差异，不把实验环境等同生产承诺；若它提出身份或证明框架，本报告将其放在支付栈的信任层，而不是把它误写成支付清算层。\n"
)
parts.append("\n## 五、已落地项目和公开方案全景\n")
parts.append(
"本节重点回答用户要求中的“目前落地的项目和设想的方案”。所谓落地分四级：生产入口或受控真实交易、开放规范/SDK 可集成、公司发布但需申请/试点、研究原型/概念方案。下表和后续剖析保守分类，不把“宣布合作”自动写成“全球可用”。\n"
)
parts.append("| 项目 | 状态 | 主要轨道 | 机制摘要 | 主要来源 |\n|---|---|---|---|---|\n")
for pr in PROJECTS:
parts.append(f"| {pr['name']} | {pr['status']} | {pr['rails']} | {pr['mechanism']} | {source_list(pr['sources'])} |\n")
for pr in PROJECTS:
parts.append(f"\n### {pr['name']}\n")
parts.append(f"事实状态：{pr['status']} 资金或凭证轨道：{pr['rails']} 机制：{pr['mechanism']} 主要来源：{source_list(pr['sources'])}。\n")
parts.append(f"证据说明：{pr['evidence']}\n")
parts.append(f"未解决部分：{pr['gaps']}\n")
parts.append(
"交叉引用：若把该项目放入 SoK 的四阶段生命周期，必须分别问它覆盖了 discovery、authorization、execution、accounting 哪几段。许多项目在授权或付款段很强，但在服务执行证明、争议证据和跨平台责任分配上仍需要 AP2/ACP/PSP logs、ERC-8004、TEE/ZK 或 A402 类机制补足。对消费者电商，应优先看退款和商户责任；对 API 微支付，应优先看结果 receipt、nonce、重复请求和服务质量；对稳定币支付，应优先看 AML/KYC、制裁筛查和错误支付恢复。\n"
)
parts.append("\n## 六、协议与信任栈：谁解决什么，谁不解决什么\n")
for name, solves, refs, caveat in PROTOCOLS:
parts.append(f"\n### {name}\n")
parts.append(f"解决的问题：{solves} 主要来源：{source_list(refs)}。\n")
parts.append(f"边界：{caveat}\n")
parts.append(
"放在 agentic payment 里看，这一层必须和上下游做哈希绑定和策略绑定。单独看协议时容易高估能力：通信协议不是授权协议，授权协议不是清算协议，清算协议不是履约证明，履约证明也不是争议规则。工程实现应把 request id、agent id、user mandate id、policy decision id、payment id、order id、response hash 和 audit log id 串成同一条证据链。\n"
)
parts.append("\n## 七、痛点、难点、不足与解决方向\n")
for title, body in PAINS:
parts.append(f"\n### {title}\n")
parts.append(body + "\n")
parts.append(
"解决方向不是让模型更聪明就完事，而是把模糊意图压缩成确定性约束，把确定性约束交给可验证执行点，把执行点的每次 allow/deny 记录下来，并让支付凭证只在这些约束内有效。高风险动作还要有 step-up confirmation、设备绑定、issuer 或 PSP 风控、商户履约证据和争议回放。这个原则贯穿 AP2、ACP、Visa/Mastercard tokenization、PayPal buyer protection、x402 facilitator、A402 channel 和 ERC-8004 registry。\n"
)
parts.append("\n## 八、区块链与微支付路线深拆\n")
parts.append(
"区块链/微支付路线最吸引人的地方，是它把支付变成机器可组合的协议动作：agent 不需要开账户、不需要发票、不需要人工 checkout，就能按 API call、模型 token、资源下载、网页访问或小服务调用付款。x402、L402、Circle Wallets、Nevermined、Skyfire、SAKSHI、A402 都属于这条谱系。它们的共同优势是低额、跨境、自动化、可编程、无许可或低许可；共同不足是隐私、合规、退款、履约证明、私钥安全和用户保护。\n"
)
parts.append(
f"HTTP 402 的历史背景很重要。{source_list(['MDN402'])} 说明 `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 反复强调的断裂。\n"
)
parts.append(
"L402/LSAT 是另一条成熟的微支付思路。它把 Lightning invoice 的 preimage 与 Macaroon caveats 结合，形成可验证的 API credential。优点是低延迟、低费用、可复用 credential、stateless verification；不足是 Lightning liquidity、路由成功率、节点运维、托管取舍和 BTC 计价波动。更重要的是，L402 与 x402 一样，只能证明你付过钱或持有凭证，不能证明服务结果正确。如果 agent 买的是低额数据或一次搜索，这通常可以接受；如果买的是高价值报告、交易执行、医疗建议或法律服务，就需要额外执行证明。\n"
)
parts.append(
"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、侧信道、密钥管理、多副本一致性和服务可证明性仍需工程验证。\n"
)
parts.append(
"从费用和延迟看，结构性结论比具体数字更重要。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 高频调用时，这个差异会决定产品是否经济。\n"
)
parts.append(
"隐私是区块链路线的硬伤。公开链会暴露付款地址、收款地址、时间、金额和频率；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 证据、商户订单证据和用户可见证据，不能把所有上下文都上链。\n"
)
parts.append(
"合规方面，stablecoin 或链上轨道不是监管真空。FinCEN、OFAC、FATF 等资料说明 CVC/virtual assets、money transmission、sanctions screening、VASP obligations 等仍然适用。agent wallet、facilitator、marketplace、托管钱包、稳定币发行方、PSP 在不同业务模型下可能承担不同义务。低额微支付若完全无身份，会更像开放互联网协议；但一旦它支持真实购买、法币出入金、托管余额、跨境汇款或大额交易，就进入更强监管区域。未来的 agentic payment 基础设施需要把 KYC/AML/sanctions 作为策略输入，而不是事后补丁。\n"
)
parts.append("\n## 九、按场景的落地路径\n")
for title, body in SCENARIOS:
parts.append(f"\n### {title}\n")
parts.append(body + "\n")
parts.append(
"推荐最小证据链包括：用户或组织授权、agent 身份、策略判定、payment payload、服务请求、服务响应、付款或退款记录。低风险场景可用日志和付款回执；高风险场景应加签名 cart、TEE/zk proof、商户 SLA、可争议证据包和人工 step-up。不要把一个场景的控制直接迁移到另一个场景：API 微支付能接受小额失败，消费品 checkout 要能退货，B2B 采购要进 ERP，长期无人值守代理要持续风险评估。\n"
)
parts.append("\n## 十、推荐参考架构\n")
parts.append(
"本报告建议采用“七层硬约束架构”。第一层是 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，并按隐私等级分层留存。\n"
)
parts.append(
"这个架构的关键不是使用多少 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，但需要公开输入正确绑定。所有这些边界都要在架构图上写清楚。\n"
)
parts.append(
"推荐的工程落地顺序是从低风险闭环开始。第一阶段选择低额 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 能向任何商户付款”，这会把身份、风控、合规、争议和产品体验的所有难题同时引爆。\n"
)
parts.append("\n## 十一、事实核查矩阵\n")
parts.append("| 事实点 | 来源 | 报告使用方式 | 风险提示 |\n|---|---|---|---|\n")
fact_rows = [
("AP2 是开放 agent payment 协议，核心是 Intent/Cart/Payment Mandate 和 VDC", ["AP2", "AP2Spec"], "作为授权与审计层证据", "不把 AP2 写成清算网络或履约证明"),
("x402 让 stablecoin payments directly over HTTP，并通过 402/payment payload/facilitator 实现", ["x402Docs", "x402Site"], "作为 API/machine micropayment 落地证据", "不把 x402 写成服务执行原子性方案"),
("ACP 由 OpenAI 和 Stripe 维护，处于 beta/open standard，Instant Checkout 已在 ChatGPT 场景使用", ["OpenAIACP", "ACPGitHub", "StripeNews"], "作为 agentic commerce checkout 证据", "首发场景有限，不能泛化为所有商户可用"),
("Mastercard Agent Pay 发布 Agentic Tokens 与 tokenization 路线", ["Mastercard"], "作为卡网络落地证据", "新闻稿证明发布，不证明全球默认可用"),
("Visa 提供 agentic commerce / Intelligent Commerce 产品方向", ["VisaAgentic", "VisaIC", "VisaConnect"], "作为卡组织/网络安全控制方向", "部署状态和地区可用性需另查"),
("PayPal agentic commerce services 包含 agentic payment solution、catalog/order management、buyer protection", ["PayPal", "GooglePayPal"], "作为 PSP 路线证据", "部分服务未来可用或需申请"),
("A402 原型报告 2,875 RPS 与 0.34-0.37 秒延迟", ["A402"], "作为研究性能证据", "实验环境，不代表生产 SLA"),
("SoK 四阶段生命周期和四类缺口", ["SoK"], "作为分析框架", "综述论文，无产品实现"),
("ERC-8004 提供 identity、reputation、validation registries", ["EIP8004"], "作为开放 agent trust layer", "标准自述不能保证 advertised capabilities 真实"),
("MCP 是连接 AI applications 与 external systems 的开放标准", ["MCP"], "作为工具调用层", "MCP 不是支付授权或风控机制"),
("FinCEN/OFAC/FATF 等虚拟资产合规资料仍相关", ["FinCEN", "OFAC", "FATF"], "作为合规风险背景", "具体法律适用需律师按业务模型判断"),
]
for fact, refs, use, risk in fact_rows:
parts.append(f"| {fact} | {source_list(refs)} | {use} | {risk} |\n")
parts.append("\n## 十二、路线图：短期、中期、长期\n")
parts.append(
"短期，最现实的是封闭或半封闭的 agentic commerce 与低额 API micropayment。商户侧可接 ACP/Stripe/PayPal 或 Visa/Mastercard 的 tokenized agentic commerce；API 侧可接 x402/L402/MPP。控制目标不是完全自动，而是让用户确认更少但更有效：低额自动、高额确认、异常阻断、可撤销、可回放。短期最重要的产品指标不是 agent 能买多少东西，而是每一笔错单能否解释、能否退款、能否阻止重复发生。\n"
)
parts.append(
"中期，需要行业统一三类语义。第一类是授权语义：Intent Mandate、Cart Mandate、Payment Mandate、SPT、session key、spend cap 应能互相映射。第二类是身份语义：AgentCard、DID、KYA、ERC-8004、平台认证、运行时证明应能表达同一 agent 的不同维度。第三类是争议证据语义：订单快照、价格、税费、库存、履约、工具调用、模型可见上下文、支付凭证和退款状态应形成可标准化证据包。没有这些，agentic payment 会变成每个平台的封闭花园。\n"
)
parts.append(
"长期，agentic payment 会变成一个“可验证经济工作流”。用户不再逐笔点击付款，而是签署可撤销、可审计、可限制的授权；agent 在策略范围内发现和协商；商户和服务以机器可读方式发布能力、价格、履约和退款规则；支付网络或链上轨道执行资金流；TEE/ZK/日志证明服务完成；争议系统自动拉取证据；监管系统按风险抽样或实时筛查。这一愿景需要 AP2、ACP、x402、MPP、ERC-8004、DID/VC、TEE/ZK、card networks、stablecoin issuers、PSP、merchants、wallets、AI platforms 共同演进。\n"
)
parts.append("\n## 十三、项目-痛点交叉审查\n")
parts.append(
"这一节是尽调用途的交叉引用，不是重复项目介绍。每个项目都按十二类痛点过一遍，目的在于防止把一个项目在某一层的能力误解为全栈能力。写法上有意保守：只有官方来源或论文明确支持的内容才说“已覆盖”；其余只说“可能缓解”“需要另核”或“不能推出”。这也是本报告避免幻觉的主要机制之一。\n"
)
for pr in PROJECTS:
parts.append(f"\n### {pr['name']} 的痛点覆盖审查\n")
parts.append(
f"已核事实底座：{pr['status']}；轨道是{pr['rails']}；机制是{pr['mechanism']}；来源为{source_list(pr['sources'])}。以下审查只基于这些来源和 Zotero 论文框架，不把营销措辞扩张为生产保证。\n"
)
for title, _body in PAINS:
parts.append(
f"**{title}**：对 `{pr['name']}` 而言，首先要问它解决的是协议链路中的哪一段。"
f"如果该项目主要处理付款或 checkout，那么它最多能缓解资金移动、凭证暴露或商户接入问题，不能自动证明 agent 的原始意图、服务履约和监管责任。"
f"结合该项目机制“{pr['mechanism']}”，可核查的正面作用是把这一痛点中的一部分约束前移到协议或支付网络中；"
f"但仍应要求实现方提供三类证据：第一，授权对象、金额、时间、商户或资源是否被机器可读地绑定；第二，异常、退款、撤销、失败重试是否有明确规则；第三，日志是否能把用户意图、agent 身份、策略决策、支付凭证和服务结果串成同一审计链。"
f"若这三类证据缺失，就只能把 `{pr['name']}` 视为局部组件，不能视为完整 agentic payment 安全方案。\n"
)
controls = [
("最小权限支付凭证", "agent 不应持有原始 PAN、CVV、无限 allowance 或长期热钱包私钥。优先使用 merchant-bound、amount-bound、time-bound、purpose-bound 的 scoped token、session key、SPT、mandate 或 EIP-3009/Permit2 授权，并在 UI 和日志中清楚显示 scope。"),
("结构化意图编译", "把自然语言指令编译成结构化 intent：预算、币种、商户、品类、时间窗、数量、替代规则、失败策略、退款要求、是否允许订阅。编译结果要给用户或上级策略确认，不能让 LLM 的隐藏推理直接成为支付授权。"),
("策略引擎强制执行", "所有支付工具调用前必须过确定性 policy engine。策略至少包括单笔金额、累计金额、商户 allowlist/denylist、品类、地理、时间、频率、异常模型评分、制裁/KYC 状态和人工确认阈值。"),
("交易前后状态一致性", "支付前锁定 cart hash、merchant id、price、tax、shipping、refund policy 和 expiration；支付后核查 response hash、order id、settlement id、receipt 和 fulfillment state。若支付前后状态不一致，默认阻断或要求重新确认。"),
("可信确认界面", "高风险支付的确认不能完全由被网页内容控制的 agent 对话框生成，应使用 trusted surface：设备系统弹窗、issuer/PSP 页面、wallet confirmation、passkey challenge 或企业审批系统。"),
("工具内容隔离", "把网页、商品描述、邮件和 tool metadata 标记为不可信输入，不能让它们覆盖系统策略、支付目标或安全提示。MCP 工具描述要签名、版本固定、allowlist，并把可变描述与支付权限隔离。"),
("付款与服务绑定", "低额服务至少绑定 request hash、resource URI、payment id 和 response hash；高价值服务应使用 escrow、HTLC、adaptor signature、TEE receipt、zk proof 或 A402 类 channel，避免付款成功但服务缺失。"),
("隐私最小化", "payment header、mandate、reason、description 和日志不要携带完整用户偏好、地址、健康、财务或商业机密。链上只锚定 hash 或 commitment，明文证据留在有访问控制的 PSP/商户/企业审计系统。"),
("撤销与过期", "所有长期授权必须可撤销、可过期、可冻结。撤销应影响后续工具调用、支付 token、session key、agent credential、DID/VC status 和 policy cache，不能只在 UI 中显示已撤销。"),
("行为级限额", "单笔限额不够，要加累计限额、滑动窗口、商户/品类限额、失败重试限额、并发 agent 限额、异常频率限额和策略升级。SoK 强调授权不能只看局部单笔，而要治理行为。"),
("身份与运行时绑定", "agent identity 不应只等于 API key。高风险支付要绑定 agent 平台、代码版本、运行时测量值、wallet address、operator、user delegation 和 revocation status。BAID、DID/VC、TEE attestation、ERC-8004 可组合使用。"),
("可解释争议证据包", "每笔 agentic payment 都应能生成 evidence package：用户原始意图、结构化 intent、cart snapshot、policy decision、agent/tool trace、payment token scope、settlement receipt、merchant fulfillment、refund state。"),
("稳定币合规闸门", "x402/USDC 等稳定币路径要在 facilitator、wallet、merchant 或 marketplace 层加入 KYC/AML/制裁、地址风险评分、地理限制和冻结/退款流程。不能因为金额小就默认没有合规义务。"),
("商户职责保持", "消费品 checkout 中商户应保持 merchant of record，负责库存、价格、税费、履约、退货、客服和争议。agent 平台不应让用户误以为模型能代替商户责任。"),
("分层风险升级", "T0 只读或低额可自动；T1 小额可凭限额和日志；T2 中额要 trusted confirmation；T3 高额、跨境、不可逆或敏感品类要人工或企业审批、强认证和额外证明。"),
("可观测性与审计保留", "把 correlation id 贯穿 A2A/MCP request、AP2 mandate、ACP checkout、x402 payment、PSP record、chain tx、TEE/ZK receipt 和 merchant order。日志保留要兼顾隐私、监管和争议期限。"),
("模拟和红队", "上线前用 prompt injection、tool poisoning、counterfeit AgentCard、fake merchant、cart substitution、replay、double spend、facilitator failure、refund refusal 等测试集红队。"),
("故障安全默认拒绝", "当价格、商户、收款地址、商品、库存、税费、运费、授权状态或风控结果无法确认时，默认拒绝或重新确认，而不是让 agent 自行解释并继续付款。"),
("跨平台责任合同", "AI 平台、PSP、钱包、商户、issuer、facilitator、identity provider 需要合同定义责任：谁保留日志，谁处理退款，谁承担 fraud，谁响应监管请求，谁赔偿模型或工具错误。"),
("用户控制面板", "用户和企业管理员需要看到 active mandates、agent wallets、spend caps、merchant permissions、recent payments、pending disputes 和 revoke buttons。没有控制面板，长期授权不可治理。"),
]
parts.append("\n## 十四、工程控制清单\n")
parts.append(
"下面的控制清单把论文和项目观察转成可执行要求。它不是法律意见，也不是某一支付网络规则，而是设计 agentic payment 系统时应纳入产品需求、架构评审、安全评审和上线门禁的控制项。\n"
)
for i, (name, detail) in enumerate(controls, start=1):
parts.append(f"\n### 控制 {i}：{name}\n")
parts.append(detail + "\n")
parts.append(
"验收方式：要求实现方给出数据结构、API 字段、日志样例、异常样例和用户可见界面，而不只给口头说明。验收时要追问这个控制在 A2A/MCP 工具层、授权层、钱包/PSP 层、商户层和审计层分别如何体现。如果只能在某一层看到控制，其他层就仍可能绕过它。\n"
)
misconceptions = [
("只要有用户点过一次同意，agent 后续付款就是授权的", "错误。一次同意如果没有金额、商户、时间、品类、目的、重试、订阅和撤销条件，就不能覆盖长期自主行为。AP2 的 Intent Mandate 正是为了解决长期无人值守场景，但它也需要可执行约束和后续风控。"),
("链上交易哈希就是完整审计", "错误。链上哈希只能证明转账发生，不能证明为什么转、agent 看到了什么、服务是否交付、商品是否符合意图。SoK 明确指出 accounting 只记录付款不足以说明责任。"),
("x402 解决了 agentic payment 的所有问题", "错误。x402 很适合 HTTP 微支付和 API 访问，但不解决身份、自然语言授权、服务正确性、退款、合规和争议。A402 对 x402 的批评正集中在支付与服务执行解耦。"),
("AP2 有 mandate，所以 prompt injection 不再重要", "错误。mandate 能证明某个结构化授权被签署，但如果签署前 agent 已被恶意内容诱导，mandate 仍可能合法地表达错误选择。仍需内容隔离、trusted confirmation 和策略检查。"),
("传统卡网络会被 stablecoin agent payments 取代", "证据不足。稳定币适合机器微支付和跨境开放结算，卡网络适合消费者保护、退款、issuer 风控和商户接受。短中期更可能是并存和分层，而不是单边替代。"),
("agent 身份等于钱包地址", "错误。钱包地址只能证明密钥控制，不证明代码、操作者、平台、用户委托、运行时完整性、KYC 状态或权限范围。BAID、DID/VC、ERC-8004、TEE attestation 都是在补这一缺口。"),
("给 agent 设置单笔限额就安全", "错误。agent 可以通过多笔、多个商户、多个子代理、失败重试或时间拆分绕过单笔限额。需要累计限额、行为限额、商户品类限制、速度限制和异常升级。"),
("商户只要接入 ACP/AP2/x402 就完成 agentic commerce", "错误。商户还需要商品数据质量、库存、价格、税费、配送、退货、客服、争议证据、风控和 bot/agent 识别。协议只是入口，不是运营闭环。"),
("TEE 能证明服务结果一定正确", "错误。TEE 证明某个测量值代码在隔离环境里运行，但代码可能有 bug，输入可能被污染，业务语义可能不正确，硬件也有信任边界。TEE 是证据组件，不是绝对真理。"),
("ZK 证明能马上解决大模型服务证明", "过度乐观。ZK/zkVM 对形式化程序很强，但大模型、外部工具、非确定性和实时延迟仍是难点。现实中通常要 TEE、日志、抽样、optimistic proof 和人工争议结合。"),
("公司宣布合作就等于生产可用", "错误。很多 agentic payment 发布是试点、受控交易、developer preview、waitlist 或研究 demo。报告必须区分官方发布、可集成 SDK、真实交易、全球 GA 和独立审计指标。"),
("低额交易不需要争议和退款", "错误。低额单笔可能不值得人工争议，但 agent 能高速重复，累计损失和 abuse 仍大。至少需要自动退款、信用补偿、限额、异常阻断和服务质量记录。"),
]
parts.append("\n## 十五、常见误区与反证\n")
for i, (claim, rebuttal) in enumerate(misconceptions, start=1):
parts.append(f"\n### 误区 {i}：{claim}\n")
parts.append(rebuttal + "\n")
parts.append(
"核查方法：回到本报告的五层模型，逐层问通信、授权、付款、履约、审计是否都有证据。如果某个说法只在一层成立，就不能把它扩张为全栈成立。这个反证方法适用于供应商评估、投资尽调、产品方案评审和安全设计评审。\n"
)
deployment_templates = [
("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 规则。"),
("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 可暂停和撤销。上线门槛是行为限额、异常检测、通知、回放、撤权和退款。"),
]
parts.append("\n## 十六、部署模板与上线门槛\n")
for name, detail in deployment_templates:
parts.append(f"\n### 模板：{name}\n")
parts.append(detail + "\n")
parts.append(
"上线前应做三轮验证。第一轮是 happy path：用户授权、agent 调用、付款、服务、收据、退款是否闭环。第二轮是 abuse path：伪商户、恶意网页、prompt injection、tool metadata 注入、重放、重复支付、facilitator 失败、余额不足、价格变化是否安全失败。第三轮是 dispute path：用户否认、商户不履约、服务结果错误、token 泄露、私钥撤销、制裁命中时证据能否导出并裁决。\n"
)
parts.append("\n## 十七、结论\n")
parts.append(
"Agentic payment 已经从概念进入早期落地，但还没有进入“开放世界任意 agent 自主付款”的成熟阶段。真正落地的部分主要是两端：一端是传统支付网络把 agentic checkout 纳入既有 card/wallet/PSP 体系，另一端是 x402/L402/stablecoin 把 API 微支付做成机器可执行协议。中间缺的，是跨平台身份、机器可读授权、支付-服务绑定、隐私保护审计、争议/退款和责任规则。A402、SoK、TIVA、Inter-Agent Trust Models 等论文给出了清晰研究方向；OpenAI/Stripe、Google AP2、Coinbase x402、Visa、Mastercard、PayPal、Cloudflare、Circle、Skyfire、Nevermined 等项目给出了真实产业路径。两者交叉后的判断是：未来胜出的不会是单一 rail，而是能把意图、身份、策略、付款、执行和审计绑定成闭环的栈。\n"
)
parts.append(
"因此，本报告给出的最务实建议是：把 LLM 视为提议者，把策略引擎视为裁判，把钱包或 PSP 视为执行者，把商户/服务 receipt 视为履约证据，把 mandate 与 payment token 视为可争议授权，把审计日志视为最终安全网。任何让 LLM 直接持有无限支付凭证、直接解释自然语言为不可逆转账、或无法回放证据的方案，都不应进入高价值生产场景。Agentic payment 的未来很大，但它的工程原则应当朴素：资金移动要小心、可限、可证、可退、可追责。\n"
)
parts.append("\n## 附录 A：来源索引\n")
for key, (label, url) in sorted(SOURCES.items()):
parts.append(f"- `{key}`: {md_link(label, url)}\n")
parts.append("\n## 附录 B：Zotero 本地材料说明\n")
parts.append(
"本地 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 论文，本报告只引用公开摘要，不引用无法核验全文细节。\n"
)
text = "\n".join(parts)
draft_footer = (
"\n\n## 附录 C：字数统计\n"
f"- CJK 汉字计数：{cjk_count(text)}\n"
f"- 总字符计数：{total_chars(text)}\n"
"- 统计方式：CJK 汉字计数只统计 `\\u4e00-\\u9fff` 范围；总字符计数包含英文、数字、空格、标点和 URL。\n"
)
draft = text + draft_footer
footer = (
"\n\n## 附录 C：字数统计\n"
f"- CJK 汉字计数：{cjk_count(draft)}\n"
f"- 总字符计数：{total_chars(draft)}\n"
"- 统计方式：CJK 汉字计数只统计 `\\u4e00-\\u9fff` 范围；总字符计数包含英文、数字、空格、标点和 URL。\n"
)
return text + footer
def main() -> None:
report = build_report()
OUT.write_text(report, encoding="utf-8")
print(f"wrote {OUT}")
print(f"CJK={cjk_count(report)} total={total_chars(report)}")
if __name__ == "__main__":
main()