ANP

简体中文

English

简体中文

English

Appearance

全球首个智能体支付落地：ANP发布AP2支付实现，智能体商务生态迈出关键一步 ​

2025年9月，Google发布了AP2（Agent Payment Protocol）协议，为智能体支付场景提供了一套开放标准。然而，协议发布至今，业界尚未出现成熟的落地案例。

今天，我们正式宣布：ANP（Agent Network Protocol）开源社区和杭州向量共识已完成AP2协议的首个落地实现，为智能体商务生态提供了可用的支付基础设施。

这是我们做的一个支持AP2的示例产品：

AP2协议解决的最大问题，就是智能体交易过程中的信任问题。就像阿里巴巴最早解决了电子商务的信任问题，让用户敢于在电脑上对着一个陌生的商家付款。AP2要解决的就是让你敢于放心的让AI代替你去购物，如果出错了，也能够找到合理的责任人，从而建立信任并且降低交易摩擦成本。

我们认为AP2是一个被低估的协议，它在未来有可能会重构商务的整个链路，这也是我们在ANP上支持AP2的原因。

ANP作为一个更加底层的协议，采用DID作为智能体身份方案，天然对AP2的公钥分发问题进行了完美的支持，是ANP上运行AP2，要比在A2A上运行AP2要简单很多。

AP2作为一个非常早期的协议，也有很多不完善的地方，我们基于ANP对AP2进行了一些完善，包括支持中国支付基础设施，增加履约凭证、完善时间戳验证等，也算是我们对行业的一些探索与贡献，推动智能体从"能对话"进化到"能交易"，这是智能体商务生态迈出的关键一步。

本文将深入解析智能体支付的核心概念、AP2协议设计，以及基于ANP的实现方案。最后介绍了我们未来的规划，包括x402的支持，以及智能体支付进一步探索的规划。

ANP开源社区和杭州向量共识作为智能体互联网的积极探索者，在上周发布全球首个基于智能体协议的开放智能体网络（参考文章 全球首个开放智能体网络）。本次发布则在开放智能体网络基础之上，进一步完善了智能体商务基础设施。

所有对开发智能体网络、智能体支付、智能体商务感兴趣的人，都可以加入我们，我们未来会增加更多的特性，同时也会举办智能体网络黑客松。欢迎加入微信群：

以下为正文部分：

什么是智能体支付 ​

与传统支付的本质区别 ​

当我们谈论智能体支付时，并不是简单地"让AI帮你付款"。它代表着交易范式的根本性转变：

自动化程度不同。传统支付需要人工介入每个环节——选择商品、确认订单、输入密码、完成付款。智能体支付则可以由智能体自主完成大部分流程，当然，关键环节（如大额支付）仍需要人的明确授权。

交易粒度不同。传统支付体系为"人"设计，最小交易单位通常是几毛钱。但智能体世界需要支持更细粒度的微支付场景——按次调用API、按量购买计算资源、按秒计费的服务订阅。

信任机制不同。传统支付依赖单一平台（淘宝、JD、美团）的背书，用户和商家在一个平台完成交易全过程。但是在智能体网络中，用户的智能体和商家的智能体可能是不同的公司开放的，需要建立跨域的信任机制。

交互模式不同。传统支付是人-机交互，人是决策主体。智能体支付是机-机交互（Agent-to-Agent），两个智能体需要在没有人工干预的情况下完成可信的价值交换。

智能体支付的核心挑战 ​

回到一个具体流程中，用户使用购物智能体，去商家智能体上购买产品，这个过程中，智能体支付面临的核心挑战包括：

  • 人如何信任购物智能体在百分之百的执行他的意图？
  • 购物智能体如何信任商家智能体？
  • 商家智能体如何信任，购物智能体代表了人的意志？

AP2协议正是为解决这些挑战而生。

智能体商务：电商的下一个形态 ​

从AI电商到智能体商务 ​

AP2提出的**智能体商务（Agent Commerce）**是一个比AI电商更加Native的一个概念：它不单单是电子商务+AI，用AI赋能电子商务，而是基于智能体重构商务交易链路。

相比AI电商，智能体商务（Agent Commerce）是完全不同的形态：智能体自主完成整个商业交易闭环——发现需求、搜索商品、比价决策、下单支付、物流跟踪、售后处理。人只需要设定偏好、预算，以及关键节点的授权（比如付款），剩下的交给智能体。

智能体商务的核心：信任 ​

商业的本质是价值交换，价值交换的前提是信任。阿里在电子商务上最大的贡献，就是解决信任的问题：让人信任屏幕背后商家，敢于下单付款。

智能体商务时代，仍然面临信任问题：人怎么信任智能体，智能体怎么信任智能体。

而谷歌AP2协议，就是为了解决智能体交易的信任问题而设计的。

如果有一天智能体商务真的颠覆了电子商务（E-Commerce），那么AP2将是一个非常重要的基础设施。

AP2协议解析 ​

AP2是什么 ​

AP2（Agent Payment Protocol）是Google于2025年9月发布的开放协议，专为智能体支付场景设计。官方网站：https://ap2-protocol.org/

也可以参考之前的一篇文章深入了解细节：深度解读谷歌智能体支付协议AP2：一个严重被低估的协议

AP2的核心目标很明确：解决智能体交易过程中的信任问题。

AP2的四个核心角色 ​

AP2定义了支付场景中的四个核心角色：

购物者智能体（Shopper Agent, SA）：代表买方/消费者。它负责与用户交互，展示订单信息，获取用户的支付授权，然后代表用户完成交易。

商户智能体（Merchant Agent, MA）：代表卖方/服务提供方。它负责生成购物车信息，创建订单，处理支付，最后发放交付凭证。

凭证提供方（Credentials Provider, CP）：提供用户身份凭证。它负责用户身份认证和授权签名的生成，确保支付操作真正得到了用户的授权。

支付处理方（Payment Processor, PP）：处理实际的支付操作。它对接底层支付渠道（支付宝、微信支付、银行卡等），完成资金的实际转移。

在最小实现中，购物者智能体可以同时承担CP和PP的功能，简化系统架构。

AP2的两种关键凭证 ​

AP2的精妙之处在于它定义了两个关键凭证，形成完整的信任链条：

CartMandate（购物车授权）：由商户智能体生成，包含订单详情、商品信息、总金额、支付方式。商户用自己的私钥签名，确保订单信息的完整性。这就像商家开具的一张"报价单"，承诺"这些商品，这个价格，我认"。

PaymentMandate（支付授权）：由购物者智能体生成，包含用户对特定订单的支付授权。用户用自己的私钥签名，确保授权的真实性。关键是，它包含前序CartMandate的哈希值，形成哈希链——这份授权明确指向那份报价单，不会被挪用到其他交易。

ANP如何支持AP2 ​

在支持AP2协议的过程中，我们发现三个有趣的事情：

  • AP2本身仍然处于早期，其协议设计尚不完善，比如时间戳的校验机制。
  • 没有完整的能够跑通的代码，代码和协议存在一些不一致的地方。
  • 可验证凭证是AP2的核心，不过签名私钥对应的公钥如何分发，是AP2没有回答的一个问题。

关键改造点 ​

正对AP2当前存在的问题，我们基于ANP做了几个核心的改造。

  • 在ANP的交互流程中支持AP2，设计了多个消息用了发送ap2的凭证。

  • 支持中国支付基础设施，比如支付宝、微信。我们目前最早支持的是二维码支付，这个是目前跨平台支付最方便的方式。未来也可以和支付基础设施提供商共同探索更加方便的支付方式。

  • 基于ANP的智能体身份方案（DID）进行AP2可验证凭证的公钥分发。AP2是对智能体互联网的理念与ANP是一致的，我们都认为未来智能体可以直连并进行交易。但是A2A并没有很好的解决智能体的身份互操作性问题，而ANP的DID方案，则能够非常方便的分发AP2的公钥。这也是基于ANP支持AP2，要比基于MCP、A2A支持AP2成本更低的一个原因。

  • 完善AP2没有考虑的点，比如时间戳，支付与交付凭证。

经过这些改造，AP2就可以在ANP协议中落地了。

完整交易流程 ​

ANP/AP2的完整交易流程分为四个阶段：

anp-ap2流程图

阶段一：创建订单

用户通过购物者智能体（SA）发起购买请求，SA向商户智能体（MA）发送create_cart_mandate请求。MA生成订单，计算总价，创建支付二维码，然后用自己的私钥签名，返回CartMandate（包含二维码）。

这一步的关键是商户承诺：商户签名的CartMandate是一份具有法律效力的报价，商户不能事后抵赖。

阶段二：授权支付

SA向用户展示订单信息和商家的付款二维码。与此同时，SA生成PaymentMandate（包含用户授权签名和前序CartMandate的哈希值cart_hash），发送给MA，MA返回确认。

然后用户扫码完成第三方支付（支付宝/微信）。支付完成后，支付处理方（PP）通过Callback通知MA支付结果。

这一步的关键是双重绑定：PaymentMandate通过哈希链明确指向特定的CartMandate，用户的扫码支付动作由用户亲自完成，智能体不接触用户的支付密码。

阶段三：交付凭证

MA收到支付成功通知后，向SA发送支付确认凭证（PaymentReceipt）。SA通知用户支付结果。

随后，MA完成订单履约（发货），向SA发送物流状态凭证（FulfillmentReceipt）。SA通知用户物流状态。

这一步的关键是凭证存档：完整的凭证链为可能的纠纷提供证据支持，支付凭证和履约凭证都包含前序PaymentMandate的哈希值，形成完整的可追溯链条。

需要特别说明的是：交付凭证部分是我们基于AP2协议添加的凭证。原生的AP2协议，仅处理了支付流程，并且没有覆盖交易的全流程，比如支付确认、履约确认。

这会导致后续的过程无法有效的追溯与验证，比如支付成功后，商户是否按照订单履约发货，或者履约后，用户是否确认收货，这些关键节点仍然需要凭证来进行确认。

哈希链设计 ​

ANP/AP2的安全基础是哈希链：

CartMandate(cart_hash) → PaymentMandate(pmt_hash) → Receipt(cred_hash)

每一步都包含前序凭证的哈希值，形成完整的交易凭证链。任何篡改都会导致哈希链断裂，确保交易可追溯验证。

这个设计借鉴了区块链的思想，但更轻量——不需要全网共识，只需要交易双方验证。

仍待解决的问题 ​

技术上，AP2协议通过密码学签名和哈希链解决了智能体交易的信任问题。但在现实世界中，仍有一些问题需要探索：

法律效力问题。当交易出现纠纷需要仲裁时，AP2的凭证链能否被法院或仲裁机构采纳为有效的法律依据？目前各国对电子签名的法律认可程度不一，AP2的数字签名是否具有法律效力，仍然需要产业界和法律界共同来探讨。

责任归属问题。如果智能体在交易过程中出现错误（如误解用户意图、选错商品），责任应归属于用户、智能体开发者，还是智能体运营平台？现有法律框架尚未对"AI代理行为"的责任边界做出清晰界定。

这些问题的答案，需要技术社区、法律界、监管机构共同探索。

不过我们相信，随着智能体商务的发展，相应的法律法规和行业标准会逐步完善。

x402协议展望 ​

什么是x402协议 ​

x402是另一个值得关注的智能体支付协议，基于HTTP 402状态码设计。

HTTP 402 Payment Required是一个"预留"的状态码，从HTTP协议诞生之初就存在，但一直没有被广泛使用。x402协议赋予了它新的生命：当智能体访问一个需要付费的API时，服务端返回402状态码和支付信息，智能体完成支付后重新请求，获得服务。

这是一种即时微支付模式，专为机器对机器（M2M）场景设计。

为什么要支持x402 ​

AP2适合订单型交易——有明确的商品、数量、价格，需要用户确认。但智能体世界还有大量即时调用型交易——调用一次API、访问一段内容、使用几秒计算资源。

这类场景的特点是：金额小、频率高、需要即时响应。让用户每次都确认显然不现实，但又不能完全放开让智能体自主决策（风险太大）。

x402的解决方案是：在HTTP协议层集成支付能力，让支付成为API调用的自然组成部分。智能体可以在预设的额度内自主完成微支付，超出额度时再请求用户授权。

我们认为，微支付将会极大的减少人工的介入、同时让支付的颗粒度更加的细，从而极大的降低智能体协作的成本，提升智能体协作的效率。

预期实现方案 ​

我们计划在ANP的HTTP传输层集成x402支持，需要做一下几个大的修改：

1、增加类似AP2凭证的支持

402协议中没有类似AP2凭证的设计，会导致交易的过程很难追溯与验证，特别是在需要进行售后问题处理的时候。所以我们倾向于直接在402中使用AP2的凭证来解决这个问题。

2、支持中国的支付基础设施

x402原生支持的是稳定币，但是稳定币在国内无法合规使用，需要更改为中国的支付基础设施。这块我们正在探索中，如果你有好的想法或合作的可能，可以联系我们。

未来展望 ​

ANP/AP2还在快速演进中，未来的计划包括：

支持"人不在场"场景。引入IntentMandate，允许用户预先设定购物意图和预算，智能体在授权范围内自主完成交易。这是真正的"代理购物"。

隐私增强。支持SD-JWT（Selective Disclosure JWT），实现细粒度的隐私保护。商户只能获得完成交易必需的最小信息集。

支付扩展。除了支付宝/微信等，探索数字人民币等新型支付方式，满足不同场景的需求。

标准对齐。与W3C VC标准对齐，实现更广泛的互操作性。让ANP/AP2能够与全球的智能体生态无缝对接。

最后 ​

智能体商务不是遥远的未来，而是正在发生的变革。

当智能体能够安全地代表我们完成支付，它就不再只是一个聊天机器人，而是一个真正的数字代理——能够在数字世界中代表我们行动、交易、创造价值。

ANP/AP2的发布，标志着智能体从"能聊天"到"能交易"的关键跨越。

但这只是开始，我们希望你能够一起参与进来。

相关链接：

版权声明

Copyright (c) 2024 GaoWei Chang
本文件依据 MIT 许可证 发布，您可以自由使用和修改，但必须保留本版权声明。