Token导航 LogoToken导航TokenDH.com
Agentic Payments Demo logo
金融服务未说明官方级别未说明来源级核验

Agentic Payments Demo

MCP Server

一个交互式演示,展示四种领先的代理支付协议,使AI代理能够自主或经用户授权进行商业交易。

工具数

6

提示词数

0

GitHub Stars

0

资源数

0
AI代理JavaScript区块链支付

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

作者 / 组织

aetherllama

提供方

aetherllama

最后核验

2026/5/17 20:21

快速接入

先看主来源和安装命令,再打开仓库或文档;下面只保留这个条目的关键接入事实。

详细介绍

代理支付演示

四种领先的代理支付协议的交互式演示,使人工智能代理能够自主或在用户授权下进行商务。

快速开始

cd agentic-payments-demo
npm install
npm start

然后打开http://localhost:3000在您的浏览器中。

______________________________________________________________________

这个演示显示了什么

此演示说明了 根本问题 代理付款: *人工智能代理如何安全、透明、大规模地代表用户进行购买?*

每种协议都采取了截然不同的方法来解决这个问题:

协议核心理念
自动控制面板“通过无缝的用户体验让人类保持联系”
AP2“通过加密证明建立信任”
x402“让支付像HTTP请求一样简单”
主控程序“标准化工具,让任何人工智能都能支付”

______________________________________________________________________

演示场景说明

演示1:ACP-聊天结账

它展示了什么: ACP演示展示了用户如何在不离开聊天界面的情况下完成购买。当你点击“创建结账会话”时,你正在模拟当用户对ChatGPT说“给我买一个无线鼠标”时会发生什么。

观察内容:

  • presentationData 字段-这是人工智能用于向用户显示结账的结构化数据
  • agentContext 告诉人工智能允许采取哪些行动
  • 会话具有安全过期时间
  • 确认发生在第二步,模拟用户批准

现实世界的例子:

用户:“从亚马逊订购最便宜的AirPods” ChatGPT:显示带有价格、图像、交货预估的内联结账卡 用户:点击聊天中的“确认”按钮 通过Stripe处理付款,无需离开对话

______________________________________________________________________

演示2:AP2-授权自主购买

它展示了什么: AP2演示展示了用户如何给AI代理 *允许自主花钱* 在规定的约束范围内。这是真正自主代理最复杂的协议。

观察内容:

  • 意向授权:有限制的预授权(最高100美元,仅限电子产品,24小时后到期)
  • 购物车授权:明确批准特定购物车(加密签名)
  • 付款委托书:自动创建,向支付网络发出人工智能参与的信号
  • 每个授权都有一个不可否认的加密签名
  • auditTrail 付款响应提供了完整的问责制

关键见解: AP2解决了“谁授权了这个?”的问题。如果AI代理购买了错误的东西,审计跟踪会证明:

  1. 用户设置了哪些约束(意图授权)
  2. 购买是否在限制范围内
  3. AI参与其中(向支付网络披露)

现实世界的例子:

用户:“不用问我,你每天最多可以花50美元买办公用品” 【代理人创建带有约束的意向委托书】 后来,代理商发现打印机墨水不足,找到35美元的墨水 代理人使用授权自主购买 用户收到带有完整审计跟踪的通知

______________________________________________________________________

演示3:x402-Pay-Per-API-请求

它展示了什么: x402演示展示了一个完全不同的模型: 没有任何事先关系的机器对机器支付.没有API密钥,没有订阅,没有帐户-只有支付和访问。

观察内容:

  • 第一个请求返回HTTP 402 Payment Required 付款详细信息
  • paymentRequirements 数组列出了可接受的支付方式(Base网络上的USDC)
  • 代理钱包的余额会随着每次付款而减少
  • 重试时,付款签名将作为HTTP标头发送
  • 只有在有效付款后才能返回资源

关键见解: x402实现了一种新的经济模式,其中:

  • API可以在没有用户管理开销的情况下获利
  • AI代理可以自主访问任何启用x402的资源
  • 使用稳定币实时付款(无退款,即时结算)
  • 小额支付是可行的(每次请求0.001美元)

现实世界的例子:

AI Agent需要高级天气数据用于用户的旅行计划 代理人有一个USDC钱包,余额为10美元 代理请求天气API→ 得到402 代理人签署0.001美元的付款→ 获取天气数据 无需API密钥,无费率限制,只需按次付费

______________________________________________________________________

演示4:MCP-基于工具的支付

它展示了什么: MCP演示展示了如何将付款暴露为 标准化工具 任何AI都可以发现和使用。这是最“人工智能原生”的方法——支付只是人工智能工具包中的另一个工具。

观察内容:

  • listTools() 返回模式定义的支付功能列表
  • 每个工具都有 inputSchema 描述所需参数
  • 工具响应包括 context 下一步建议行动
  • AI可以将工具链接在一起(创建意图→ 列出方法→ 确认)
  • 多个提供商(Adyen、Worldpay)使用相同的界面

关键见解: MCP将支付视为任何其他AI功能。正如人工智能可以使用“搜索网络”工具或“读取文件”工具一样,它也可以使用“create_payment_int”或“refund_payment”工具。这种标准化意味着:

  • 任何兼容MCP的AI都可以进行支付
  • 支付提供商在实施上竞争,而不是在接口上竞争
  • 人工智能可以使用结构化模式对支付选项进行推理

现实世界的例子:

用户:“退还客户昨天的订单” AI呼叫 get_payment_status 查找付款 AI呼叫 refund_payment 带有付款ID AI报告:“已处理49.99美元的退款,确认#RF123”

______________________________________________________________________

协议有何不同

基础架构

┌─────────────────────────────────────────────────────────────────────────┐
│                        AGENTIC PAYMENTS SPECTRUM                        │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  Human-in-Loop ◄─────────────────────────────────────────► Autonomous  │
│                                                                         │
│       ACP                    MCP            AP2              x402       │
│        │                      │              │                │         │
│   User confirms          User may or     User sets        No user      │
│   every purchase         may not be      constraints,     involved     │
│                          involved        agent acts                     │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

支付基础设施

┌────────────────┬────────────────┬────────────────┬────────────────┐
│      ACP       │      AP2       │      x402      │      MCP       │
├────────────────┼────────────────┼────────────────┼────────────────┤
│                │                │                │                │
│   ┌───────┐    │   ┌───────┐    │   ┌───────┐    │   ┌───────┐    │
│   │Stripe │    │   │ Any   │    │   │Crypto │    │   │Adyen/ │    │
│   │  API  │    │   │Network│    │   │Wallet │    │   │Worldpay    │
│   └───┬───┘    │   └───┬───┘    │   └───┬───┘    │   └───┬───┘    │
│       │        │       │        │       │        │       │        │
│   Traditional  │   Agnostic     │   Blockchain   │   Traditional  │
│   Card Rails   │   (card/crypto)│   (USDC)       │   Card Rails   │
│                │                │                │                │
└────────────────┴────────────────┴────────────────┴────────────────┘

信任模型比较

特性ACPAP2x402MCP
谁授权?用户(每笔交易)用户(通过授权)代理钱包持有人取决于实施情况
授权证明会话确认加密VDC签名区块链交易应用程序日志
争议解决条带/卡网络审计跟踪+VDCs链上历史特定于提供商
欺诈责任商户/条纹由授权定义钱包持有人特定于提供商

技术集成比较

特性ACPAP2x402MCP
整合工作低(Stripe SDK)中(VDC处理)低(HTTP标头)中等(MCP服务器)
先决条件条纹账户VDC基础设施加密钱包MCP兼容AI
延迟~2-3秒~1-2秒~400ms(索拉纳)~2-3秒钟
交易成本2.9%+0.30网络费用~0.0003美元(基础)提供商费用
最低实际金额~$1~$1$0.0001~$1

______________________________________________________________________

何时使用每种协议

在以下情况下选择ACP:

  • 构建面向消费者的聊天商务(ChatGPT插件、客户服务机器人)
  • 您需要经过验证的基础设施(Stripe的可靠性)
  • 用户应确认每次购买
  • 需要传统支付方式(卡)
  • 您需要退款和消费者保护

在以下情况下选择AP2:

  • 构建真正自主的代理,代表用户购物
  • 监管合规和审计跟踪至关重要
  • 您需要用户意图的加密证明
  • 与需要问责制的企业客户合作
  • 支持多种支付网络(卡+加密)

在以下情况下选择x402:

  • 无需用户管理的API货币化
  • 实现人工智能到人工智能的商务(代理人支付代理人)
  • 需要小额支付(0.001美元-1美元范围)
  • 即时、不可逆的结算是可以接受的
  • 您希望避免订阅/API密钥管理

在以下情况下选择MCP:

  • 构建需要灵活支付能力的人工智能系统
  • 与多个支付提供商合作
  • 希望AI对支付选项进行推理
  • 需要将支付整合到更大的工具生态系统中
  • 与现有支付提供商建立内部企业人工智能

______________________________________________________________________

协议深潜

ACP:用户体验协议

ACP的哲学是 无论用户身在何处,结账都应该感觉很自然ACP不会将用户重定向到结账页面,而是将结账带入聊天。

关键设计决策:

  • presentationData 提供结构化的显示信息,因此任何AI都可以一致地呈现结账
  • agentContext 告诉人工智能允许哪些用户体验模式
  • 会话很快过期(30分钟),以防止过时的购物车
  • 两步流程(创建→ 确认)确保用户批准
// ACP returns data optimized for AI presentation
{
  presentationData: {
    title: "Purchase from Demo Store",
    summary: "1 item(s) • USD 29.99",
    callToAction: "Confirm Purchase"
  }
}

AP2:信任协议

AP2的理念是 自主代理需要加密问责制该协议回答了三个关键问题:

  1. 授权:我们怎么知道用户允许这样做?
  2. 真实性:我们如何知道这反映了用户意图?
  3. 问责:如果出了问题,谁要负责?

关键设计决策:

  • 可验证数字证书(VDC)具有防篡改和加密签名功能
  • 意图要求将“支出许可”与“特定购买”分开
  • 支付授权明确向支付网络披露人工智能的参与情况
  • 所有签名都会创建一个不可变的审计跟踪
// AP2 creates cryptographic proof chain
{
  credentials: {
    userMandate: "vdc:abc123...",      // User's authorization
    paymentMandate: "vdc:def456...",   // AI involvement disclosure
    signatures: ["sig_...", "sig_..."] // Cryptographic proof
  }
}

x402:简单协议

x402的哲学是 支付应该像HTTP一样简单402状态码自HTTP/1.0以来就存在,但从未标准化。x402最终定义了它应该如何工作。

关键设计决策:

  • 使用现有的HTTP基础架构(无新协议)
  • 付款要求作为结构化标题返回
  • 稳定币支持即时、不可逆的小额支付
  • 不需要帐户、API密钥或以前的关系
// x402 is just HTTP with payment headers
// Request without payment:
GET /api/premium/weather → 402 Payment Required

// Request with payment:
GET /api/premium/weather
Header: PAYMENT-SIGNATURE: 
→ 200 OK + data

MCP:标准化协议

MCP的哲学是 人工智能能力应该是可发现的和标准化的支付成为任何人工智能都可以通过一个通用界面找到、理解和使用的工具。

关键设计决策:

  • 工具使用JSON模式进行自我描述
  • 响应包括AI推理的上下文
  • 与提供商无关(Adyen和Worldpay公开相同的接口)
  • 可组合式(将工具链连接在一起,用于复杂的工作流程)
// MCP tools are self-describing
{
  name: "create_payment_intent",
  description: "Create a new payment intent",
  inputSchema: {
    type: "object",
    properties: {
      amount: { type: "number" },
      currency: { type: "string" }
    },
    required: ["amount", "currency"]
  }
}

______________________________________________________________________

未来:协议融合

这些协议并不相互排斥。我们已经看到了趋同:

  • AP2+x402:谷歌的“A2A x402扩展”将AP2的VDC与x402的加密支付相结合
  • MCP+x402:Vercel的“x402 mcp”将x402支付暴露为mcp工具
  • AP2+ACP:可以将Stripe的用户体验与AP2的审计跟踪相结合

可能的未来是 分层堆叠:

┌────────────────────────────────────────┐
│   Application Layer (Chat UX, etc.)    │  ← ACP-style presentation
├────────────────────────────────────────┤
│   Authorization Layer (Mandates)       │  ← AP2-style credentials
├────────────────────────────────────────┤
│   Tool Layer (Standardized APIs)       │  ← MCP-style tools
├────────────────────────────────────────┤
│   Settlement Layer (Payment Rails)     │  ← x402/traditional
└────────────────────────────────────────┘

______________________________________________________________________

协议概述

1.ACP-代理商务协议(Stripe+OpenAI)

它是什么: 一种在ChatGPT等AI聊天界面中实现无缝结账的协议。

主要特点:

  • 用户保持聊天体验
  • 利用Stripe现有的支付基础设施
  • 用于AI向用户显示的结构化演示数据

流量:

User → "Buy me a wireless mouse"
   ↓
AI Agent → Creates ACP checkout session
   ↓
Chat UI → Shows inline checkout with item details
   ↓
User → Confirms purchase in chat
   ↓
Stripe → Processes payment
   ↓
AI Agent → Returns confirmation + receipt

API终点:

  • POST /api/acp/checkout -创建结账会话
  • POST /api/acp/confirm/:sessionId -确认付款

______________________________________________________________________

2.AP2-代理支付协议(谷歌)

它是什么: 一种使用可验证数字证书(VDC)在AI代理事务中建立信任的开放协议。与60多个行业合作伙伴在Apache 2.0下发布。

关键概念:

授权类型用例用户状态
意向授权预先授权的自主购买无人在场
购物车授权明确批准特定购物车人在场
付款委托书向网络发送AI参与信号发送到支付网络

流程(自主意图授权):

User → Creates Intent Mandate
       "Allow agent to spend up to $50 on electronics"
   ↓
AI Agent → Finds headphones for $35
   ↓
AI Agent → Validates against mandate constraints
   ↓
AP2 → Creates Payment Mandate (for audit trail)
   ↓
Payment Network → Processes with AI disclosure
   ↓
Full audit trail with cryptographic signatures

API终点:

  • POST /api/ap2/mandate/intent -创建自主支出授权
  • POST /api/ap2/mandate/cart -创建明确的购物车授权
  • POST /api/ap2/pay -授权发起付款

______________________________________________________________________

3.x402-HTTP 402协议(Coinbase)

它是什么: 一种利用HTTP 402“需要支付”状态码进行机器对机器支付的协议。无需API密钥或订阅,只需按请求付费。

主要特点:

  • 内置于HTTP中-无需其他协议
  • 实时稳定币支付(USDC)
  • 非常适合AI代理自主访问付费API
  • 处理了3500多万笔交易

流量:

AI Agent → GET /api/premium/weather
   ↓
Server → 402 Payment Required
         {
           "amount": 0.001,
           "asset": "USDC",
           "network": "base",
           "recipient": "0x..."
         }
   ↓
Agent Wallet → Signs USDC payment
   ↓
AI Agent → GET /api/premium/weather
           Header: PAYMENT-SIGNATURE: 
   ↓
Server → Verifies payment on-chain
   ↓
Server → 200 OK + Weather Data

API终点:

  • GET /api/x402/resources -列出付费资源
  • GET /api/x402/resource/* -访问资源(如果未支付,则返回402)
  • POST /api/x402/create-payment -创建付款签名
  • POST /api/x402/access -付费访问

______________________________________________________________________

4.MCP-模型上下文协议支付(Anthropic+合作伙伴)

它是什么: 支付集成基于Anthropic的模型上下文协议,并由Adyen、Worldpay、J.P.Morgan等公司实现。

主要特点:

  • 支付操作的标准化工具界面
  • 与对话流相关的上下文感知支付
  • 多提供商支持
  • 人工智能推理的结构化响应

可用工具:

工具说明
create_payment_intent创建新的付款意向
confirm_payment确认并处理付款
get_payment_status检查付款状态
list_payment_methods列出客户保存的方法
create_checkout_session创建托管结账
refund_payment处理退款

流量:

AI Agent → execute("create_payment_intent", {
             amount: 49.99,
             currency: "USD"
           })
   ↓
MCP Server → Returns paymentIntentId + context
   ↓
AI Agent → execute("list_payment_methods", {
             customerId: "cust_123"
           })
   ↓
AI Agent → execute("confirm_payment", {
             paymentIntentId: "pi_...",
             paymentMethodId: "pm_visa_4242"
           })
   ↓
MCP Server → Returns receipt + next actions

API终点:

  • GET /api/mcp/tools -列出可用工具
  • POST /api/mcp/execute -执行工具
  • POST /api/mcp/process-payment -高水平支付流

______________________________________________________________________

汇总比较表

功能ACPAP2x402MCP
开发者Stripe/OpenAI谷歌CoinbaseAnthropic+合作伙伴
主要用途In-chat结帐自治代理按API付款基于工具的付款
支付类型传统卡任何(不可知)稳定币(USDC)传统卡
用户在线状态必需可选非必需灵活
审计跟踪标准加密VDC区块链日志记录
小额付费有限是(0.0001+美元)
自主水平
集成复杂度中高
许可证专有Apache 2.0开放标准开放协议

______________________________________________________________________

项目结构

agentic-payments-demo/
├── src/
│   ├── server.js              # Express server with all endpoints
│   └── protocols/
│       ├── acp.js             # Agentic Commerce Protocol
│       ├── ap2.js             # Agent Payment Protocol
│       ├── x402.js            # HTTP 402 Protocol
│       └── mcp-payments.js    # MCP Payments
├── public/
│   └── index.html             # Interactive demo UI
├── package.json
└── README.md

了解更多

目录标签

目录标签

AI代理JavaScript区块链支付AI支付本地部署代理支付协议支付自动化智能合约

接入字段

传输方式(transport,传输协议)

未说明

鉴权方式(authType,认证方式)

session

工具数量(toolCount,工具数)

6

资源数量(resourceCount,资源数)

0

提示词数量(promptCount,提示词数)

0

权限和风险

未说明session部署方式未说明

接入前请确认传输方式、认证方式和部署位置,并根据实际工具能力限制访问范围。

安装前确认

不要直接授予不必要的文件、网络或账号权限;先核对安装命令和配置内容。

仍需确认:installCommand

来源信息

继续浏览同类 MCP