副标题：能体支付协议：从电子商务（E-commerce）到智能体商务（Agent Commerce）的核心基础设施。

前言

谷歌的AP2（Agent Payments Protocol，智能体支付协议）发布后，并没有在中国的网络媒体上引起大的反响。我们社区第一时间对AP2做了研究讨论，也对比了我们之前的智能体交易方案。

对AP2进行深入的研究后，我认为AP2是一个严重被低估的协议。因此，我决定写一篇文章，对AP2做一个系统、全面的解读。

我本人在电商领域工作过，我们社区也开发了ANP协议，前面一段时间我们也设计了一个智能体交易方案，所以这篇文章会结合我们的思考和实践，以对AP2进行更加深入的解读，希望能够让读者看到AP2背后的设计考量与其重要的意义。

我们之前设计的智能体交易方案：基于ANP的智能体点对点交易方案

谷歌AP2规范链接：https://ap2-protocol.org/specification/

全文核心要点

如果你没有时间读完全文，下面是这篇文章的核心要点：

• AP2解决的核心难题是智能体交易过程中的信任问题。智能体的出现会重构现有的电子商务交易流程，AP2称之为智能体商务。比如，用户和商家使用智能体进行交易过程中，用户如何与其使用的购物智能体建立信任，用户的购物智能体如何与商家智能体之间建立信任。这都是随着智能体渗透到交易过程中后出现的新问题。

• 之所以我认为AP2被严重低估，根本原因是，如果基于智能体的交易流程能够跑通，并且在交易成本上比现有的电子商务交易成本更低（比如人花费的时间）、体验更好，新的交易范式将会大规模的替代现有的电子商务模式，这个变化将是颠覆性的。AP2这类的智能体支付协议，将会是智能体经济的一个重要拼图。

• AP2的出现，让我想到马云对中国电子商务最大的贡献，就是解决电子商务的信任难题，让你敢于在电脑上对着一个陌生的商家付款。AP2要解决的就是让你敢于放心的让AI代替你去购物，如果出错了，也能够找到合理的责任人，从而建立信任并且降低交易摩擦成本。

• AP2提出的智能体商务（Agent Commerce）是一个比AI电商更加Native的一个概念：它不单单是电子商务+AI，而是基于智能体重构商务交易链路。如果有一天智能体商务真的颠覆了电子商务（E-Commerce），那么AP2将是一个非常重要的基础设施。

• AP2在整体的设计上，我认为要比A2A要好，无论是对问题的定义，还是设计原则等，都非常的不错。当然，AP2还处于早期，设计上还有些模糊的地方需要完善。反过来，A2A以任务为核心的设计思路，明显是在问题的定义上出错了，或者他们本来就是为企业内部场景而设计的。

• AP2的核心设计亮点有两个，一个是将购物智能体、支付凭证管理、用户密钥管理分离，尽量降低单一角色作恶的可能，二是使用可验证凭证（VDCs，可验证数字凭证）来构建信任，可验证凭证的底层技术是密码学。

• 可验证凭证是否具备法律效力，是另外一个问题，是一个需要产业界和法律界共同来探讨的问题。

• 为什么又是谷歌提出了AP2，而不是亚马逊或者阿里？谷歌在协议领域有深厚的积累（quic、Webrtc等协议都是谷歌主导），谷歌内部肯定有人能够看到，协议是传输上下文最好的载体，也是智能体交互最高效的方式。通过AP2协议，也许谷歌可以颠覆现有的电子商务，获得更大的市场。

• 谷歌在提出AP2的时候，国内的电商公司在干什么？正在打外卖补贴大战。如果未来智能体商务真正颠覆了传统电商，那么中国头部电商们放弃创新、靠烧钱补贴血拼的现状，无疑将成为 AP2 等开放智能体协议兴起最鲜明的历史注脚。

• 我们社区在今年5月份就提出了智能体交易的方案，在核心的流程、使用的技术上，AP2和我们的方案有很多相似之处。比如，我们的方案也是基于可验证凭证技术。同时我们的方案也有独特之处，比如VC hash链，将交易过程的关键环节全部用VC进行确认，这样能够确保整个交易过程的不可篡改性。

• 从谷歌的A2A和AP2，能够看到我们社区在智能体协议技术上非常的具有前瞻性。但是，我们社区没有谷歌那么大的影响力和资源。从AP2的协议能够看得出来，他们对这个协议的投入是远大于我们的。我们希望能够和中国的产业界在智能体协议上进行合作。现在，中国无论是在技术，还是理念上，都不比美国差，我们需要敢于站在行业最前沿，并且发出我们的声音。

AP2详细介绍

下面我将从场景、问题、设计原则、角色设计、信任建立、流程等几个模块，对AP2协议做一个介绍与解读。如果你是协议开发人员，可以直接阅读原文。

协议场景

AP2对智能体交易场景的设想是，人们使用购物智能体（也可以是具备购物功能的Personal Agent）来购买商品，购物智能体帮助人们从商家端（也可以是具备销售功能的商家智能体）挑选商品、谈判价格、下单支付。

这里的购物智能体和商家智能体，是不同公司开发和运营的智能体，AP2要解决的，就是不同公司智能体之间如何建立信任，并且低成本的完成交易。

在这个场景中，智能体是交易的核心角色，是连接人和商家的重要媒介。

问题定义

当交易流程从人类直接与可信界面交互，转向人类委托智能体自主处理，信任问题变得更加复杂，现有的电子商务信任基础被打破了。

我把智能体引入交易后出现的问题，归纳为下面几个方面：

• 人们如何信任他们使用的购物智能体？如果出了问题，如何界定责任？比如我让它购买100元的商品，它却购买了1000元的商品，如何避免，或事后如何界定责任、追回损失？这其实是一个授权和可审计的问题，用户如何给智能体设定清晰的行动边界，什么样的证明能够表明用户确实授权了智能体的这个行为。

• 商家如何信任代替人类执行请求的购物智能体？如何确认智能体发送的请求，确实是来自消费者真实、准确的意图和明确、清晰授权？特别是现在AI会出现幻觉，智能体对用户意图理解出现偏差的情况下，商家如何判断？

• 如何更加安全的处理支付？防止购物智能体在未经人类授权的情况下，私自支付？现有的支付基础设施如何适配智能体发起的交易？

• 当交易出现问题时，责任应该由谁承担？是委托任务的用户？购物智能体的开发者？接受订单的商家？还是处理交易的支付网络？如何建立清晰的责任界定机制？

这些信任问题都是因为智能体成为交易关键角色后，出现的新的问题。本质上，智能体作为新的交易中介，打破了现有支付基础设施基于"人类直接操作可信界面"的信任假设。如果无法解决，智能体商务就难以大规模的普及。

信任的问题，曾经是电子商务首要解决的问题，现在，它仍然是智能体商务首要解决的问题。信任是商业的基石。

设计原则

AP2在设计原则上，我觉得确实考虑得比较周到，主要体现在下面几个方面：

开放性和兼容性。AP2不是为某个特定协议（比如A2A）定制的支付协议，而是一个开放的、可以被各种协议集成的支付协议。这个设计思路很不错，意味着ANP、MCP甚至其他很多协议都可以接入AP2。这种开放性确保了协议的通用性和未来的扩展性。

用户控制权原则。用户必须始终保持最终决定权，这一点我认为是核心。用户要能够清楚地知道智能体在做什么，并且可以对智能体的行动进行精细化的授权——哪些事情可以干，哪些不可以干。更重要的是，如果智能体在没有人类明确授权的情况下私自行动，那责任要由智能体的开发者和运营者来承担。这样设计，既保护了用户权益，也给智能体开发者建立了明确的责任边界。

可验证意图，而非推测行为。这个原则很关键。AP2强调交易必须基于确定性的、不可否认的意图证明，而不是基于对AI智能体模糊输出的推测。换句话说，不能因为AI说"我觉得用户想买这个"就直接下单，必须有用户明确的、可验证的授权凭证。

责任界定清晰化。在各种异常情况下，都要能够清楚地界定责任归属。这对于建立整个智能体支付生态的信任至关重要，也是传统支付体系愿意接纳智能体交易的前提。

这些原则看起来很简单，但要真正落地执行，还是需要很多技术细节的支撑。

角色设计

AP2的架构设计，我觉得最巧妙的地方是对角色的职责分离。目前的角色设计以及各自的职责：

用户（User），这个就不用多解释了，就是要买东西的人。

购物智能体（Shopping Agent，SA），这是用户的购物智能体，或者具备购物能力的Personal Agent，负责帮用户挑选商品、和商家谈判、组装购物车等。

凭证提供商（Credentials Provider，CP），凭证提供商在设计中被视为用户的数字钱包，用于存储用户所有交易相关凭证，管理用户的支付方式，与购物智能体交互中接收交易过程产生的支付凭证，并进行支付凭证和实际支付过程令牌的绑定，起到如下作用

1. 支付凭证和实际支付过程令牌建立关联，支持溯源审计

2. 支付流程中的实际支付过程令牌关联真实支付工具（银行卡号、账户号、钱包密钥等）信息，但是交易各方只能通过令牌引用，只有支付工具的清算网络和机构才掌握这些信息。

3. 保存支付凭证，支付凭证包含交易过程中的所有信息，以便用于用户举证和争议处理

商家端点（Merchant Endpoint，ME），可能是一个网页、一个MCP server，也可能是一个商家智能体，负责展示商品、接收订单、完成交易。

商家支付处理端点（MPP），简单理解就是商家的收银系统，专门处理支付相关的事务。在很多情况下，ME和MPP可能是一个系统。

网络与发卡机构，这就是传统的支付基础设施，比如中国银联、招商银行、工商银行等，提供支付网络和发行支付凭证。

规范中有设计，但是图中没有画出来的是一个类似硬件的密钥管理器，比如，在你确认购物车的时候，需要人的生物识别，这个时候可以调起硬件设备获得人的指纹信息以获得授权。它应该不属于上面的任何一个角色，可能是你手机自带的。

这种角色分离的设计哲学，实际上是一种"权力制衡"的思路。你的购物智能体再聪明，也碰不到你的钱；你的支付系统再强大，也决定不了你买什么。每个角色都有明确的边界和职责，这样就算某个环节出问题，也不会导致整个系统的安全崩塌。

信任建立

说完了角色分离，接下来的问题是：这些角色之间如何建立信任？AP2的答案是可验证数字凭证（Verifiable Digital Credentials，VDCs）。

我觉得用一个比喻来理解VDCs最合适：就像你在商店买东西会有购物小票。这个小票能证明你确实买了什么、花了多少钱、什么时候买的，出了问题可以拿着小票去退货。AP2中的可验证凭证，就是智能体交易过程中的"电子小票"。

这个"电子小票"有几个关键特性：

防篡改性。凭证基于公私钥加密技术（就是比特币、HTTPS网站用的那套加密技术），任何人都无法在不被发现的情况下修改凭证内容。

可验证性。只要你能出示这个凭证，就能证明这个信息确实经过了相关方私钥的签名确认。验证方能够根据公开信息进行快速的校验。

不可否认性。凭证能够从技术上确定凭证是用户的私钥进行签名的。

但是有一点需要注意，可验证凭证的技术特性和法律效力是两回事。技术上能防篡改、能验证，不代表法院一定认可这个证据。这需要法律层面的配套，是一个需要产业界和法律界共同推进的事情。

AP2设计的三个核心可验证凭证

• 购物车授权（Cart Mandate）：这是人在场交易时捕获用户购买授权的基础凭证，由商家基于用户请求生成，并由用户使用设备上的硬件支持密钥进行加密签名。Cart Mandate包含用户和商家的身份信息、商品信息、价格、支付方式、履约方式等信息。

• 意图授权（Intent Mandate）：这是人不在场交易场景中的关键可验证数字凭证，用于用户授权智能体在其缺席时执行购买。由购物智能体基于用户请求生成，相当于购物车授权，增加了用户的意图信息，以及授权的生命周期。

• 支付授权（Payment Mandate）：这是一个专门为支付生态系统（网络/发卡机构）提供智能体交易可见性的可验证数字凭证。主要目的是帮助网络/发卡机构建立对智能体交易的信任。也就是说，这个授权不包含能够使支付网络直接进行支付的相关信息。

核心支付流程

有了上面的铺垫之后，我们来看下AP2的支付流程设计，人类在场交易核心流程如下：

1. 设置阶段：用户为其购物智能体设置一个第三方的凭证提供商，可能需要在凭证提供商的可信页面上进行身份验证。

2. 发现与协商：用户向购物智能体提交购物任务，购物智能体与一个或多个商家交互，根据用户的喜好、价格、品牌等信息组合合适的购物车。

3. 商家验证购物车：关键步骤——商家必须对创建的购物车进行签名，表明他们有能力履行该购物车中的商品和服务，这为后续纠纷提供了责任界定依据。

4. 提供支付方式：购物智能体向凭证提供商提供支付上下文并请求适用的支付方法（以引用或加密形式共享），同时获取可能影响支付方法选择的忠诚度/折扣信息。

5. 展示购物车：购物智能体在可信界面向用户展示最终购物车和适用的支付方法，用户通过身份验证过程进行批准。

6. 签名与支付：用户确认购物车，然后使用签名对购物车信息进行签名、授权。该授权与商家共享作为纠纷时的证据。同时，创建支付授权，并且可能与网络和发卡机构共享以进行交易授权。

7. 支付执行：购物车授权的支付部分必须传达给凭证提供商和商家以完成交易。这可能通过多种方式实现：

• 购物智能体(SA)可能请求凭证提供商与商家完成支付，或者

• 购物车可能向商家提交订单，触发支付授权流程，商家/PSP从凭证提供商请求支付方法

8. 发送交易给发卡机构：商家或PSP将交易路由到发卡机构或支付方法运营的网络。交易数据包可能附加AI智能体参与信号，确保网络/发卡机构了解智能体交易。

9. 挑战机制：任何参与方（发卡机构、凭证提供商、商家等）都可以通过现有机制（如3DS2）选择挑战交易。挑战需要由用户智能体呈现给用户，可能需要重定向到可信界面完成。

10. 解决挑战：用户应该有办法在可信界面（如银行应用、网站等）上解决挑战。

11. 授权交易：发卡机构批准支付并确认成功。这会传达给用户和商家，以便订单可以履行。支付收据与凭证提供商共享，确认交易结果。

上面支付过程，你可以理解为是一个信用卡的使用过程，会更好的理解。相当于你把信用卡给商家，商家使用POS机刷卡。它和我们在淘宝中使用资金托管的交易方式是不同的。

上面是人类在场的支付过程。AP2也支持人不在场的支付，比如用户对购物智能体说："从<这个商家>为7月的拉斯维加斯演出购买2张<这场音乐会>的票，一旦有票就买。预算是1000美元，我们希望尽可能靠近主舞台"。购物智能体拿着用户的意图授权，实时监控商家订单，有库存的时候，直接向商家申请创建订单，后续的支付流程与人在场交易相同。

纠纷处理

发生纠纷时的证据与责任界定：

• 恶意退款：用户发起退款，却声称交易存在欺诈，此时可以通过购物车授权和支付授权来界定责任。

• 购物智能体错误：购物智能体错误的选择了商品，可以根据购物车授权或意图授权中的人类意图以及商品信息界定责任。

• 商家不履行订单：根据购物车授权以及支付授权、支付记录、商家承诺等来界定责任。

ANP交易方案与AP2对比

我们在今年五月发布了一个智能体点对点交易的方案。我们叫智能体交易，而非支付，因为交易涉及商品的买卖，支付仅是其中一部分。

详细方案：https://mp.weixin.qq.com/s/wFVUDs31e6CKLpu8F3LDWg

我们方案的架构图：

我们做了一个简单的对比：

对场景的理解：基本一致，用户的智能体与商家的智能体，在开放的环境中，进行跨域、跨平台的交易。说明我们和AP2对未来的设想还是比较一致的。

解决的问题：类似，核心还是交易信任的问题。

参与的角色：角色上大部分相同，在凭证提供商上我们有不一样。我们原有的方案没有这个角色，而是增加了另外一个角色：支付智能体（或支付系统），用于托管交易过程中的资金。我们的思路和中国目前主流的资金托管逻辑非常像：用户购买一个产品，并不直接将钱打给商家，而是将资金托管在一个双方都认可的金融机构（比如支付宝），等待商品交付完成，用户确认后，金融机构再打款。如果交易发生纠纷，则可以让仲裁智能体进行判断，确定资金如何处理。

信任建立：我们也使用可验证凭证来建立智能体之间的信任，不同的是，我们使用的可验证凭证，是W3C定义的凭证，AP2的凭证是他们自己定义的。

交易流程：基本过程基本类似。我们是使用可验证凭证将每个关键节点都进行单独的定义，然后将这些可验证凭证用hash+类似区块链的方式连接到一起，防止中间过程数据被篡改。

纠纷处理：引入公证智能体和仲裁智能体，处理买卖双方的纠纷。

两个方案差异分析：

anp的设计：

1. 没有单独定义一个用户侧的凭证钱包用于保存用户的交易凭证，而是将其纳入用户智能体的功能范围。

2. 用户支付方式选择纳入支付智能体与用户智能体的交互中，具体支付工具的相关隐私信息（银行卡号等）只在用户和支付智能体间暴露，商户侧完全隔离

ap2的设计:

1. 没有定义居间的支付智能体，而是定义用户侧的凭证提供商(credencials provider)，生成具体一次交易的支付工具令牌，用于交易各方引用和执行支付（既可以是购物智能体通知凭证钱包支付，也可以是商户侧推送支付请求）

2. 用户具体支付过程发生在凭证提供商和支付工具对应的清算网络和机构间。

两个方案的差异是在共同的设计目标（实现可审计的多方交易过程同时保护用户的支付敏感信息）下不同的设计哲学的体现。

1. anp引入了支付智能体概念和用户智能体进行配合，用户智能体被视为完全由用户掌控的运行实体，这是智能体网络理念下的设计。

2. ap2扩展了用户侧电子钱包的功能，设计场景为电子钱包存在于用户设备，而为用户提供购物服务的智能体可以运行在其他服务器上或是用户设备上的一般性运行实体，不掌握用户的支付方式，这是在既有网络应用环境下的设计。

我们方案的独特之处：

智能体身份与公钥分发：大家都知道，ANP的身份方案基于DID构建。DID最大的优势便在于公钥的分发上，而可验证凭证的验证过程就需要安全的获得对方的公钥，所以DID和可验证凭证天然配合比较好的智能体身份方案，非常适合这种分布式、去中心化的交易过程。

VC hash链：通过在关键节点产生可验证凭证，并且使用类似区块链的方案把可验证凭证链接成一个不可篡改的可验证凭证链，有助于后期对交易过程的详细审计与纠纷处理。

交易资金托管：我们设计的第一个版本，并没有使用AP2优先支持的类似信用卡的支付方式，而是使用中国常见的资金托管模式。资金托管的流程相对简单，并且方便进行纠纷的处理。同时，可以在对现有支付方式（比如支付宝）不进行大的重构的情况下，低成本的支持我们的智能体交易方案。

总结一下

我们想表达的观点，在前面的全文核心要点部分已经表达了。

这里再次强调一下我的看法，AP2是一个被低估的协议，它致力于解决智能体交易过程中遇到的信任问题，它是智能体经济的重要一环。

回到我们社区，从智能体通信协议，到智能体交易（支付）协议，谷歌一直在Fllow我们的脚步。

我们现在还在坚持的两个技术上的非共识是：基于DID的智能体身份，以及基于linked-data的信息组织方式。我们认为在不久的将来，这两个非共识也会成为行业的共识。

最后，ANP的github star数超过1K了，作为一个自然增长、这么小众的项目，能够突破1K确实难得。如果你没有为我们的项目打过star，可以帮我们打一个：

https://github.com/agent-network-protocol/AgentNetworkProtocol

欢迎持续关注我们开源项目，有任何合作，都可以和我们联系。