微信支付亮出“Agent Pay X402”！

“微信支付正在重新寻找自己在Agent时代的位置，而且这个位置正在不断向交易前端移动。”

文丨张盒子

出品丨支付之家 · 深度

8月底，微信支付AI专属卡又增加了两个Agent入口。

继WorkBuddy、QClaw之后，DeepSeek Harness和OpenClaw也开始支持微信支付AI专属卡。用户完成绑定后，可以在Agent中提出需求，由Agent寻找相应服务、发起订单，用户在手机端确认付款后，再继续完成后续任务。

微信支付同时披露，AI专属卡已经可以在这两个Agent中付费调用SkillHub上的700余个Pay Skill。

支撑这套付费能力的Agent支付协议，早在两个多月前就已经出现。6月26日，腾讯SkillHub上线SkillPay付费能力时，官方明确写出“微信支付Agent Pay X402协议”。20天后的7月16日，SkillPay正式对外发布，企业可以把已有服务改造成付费Skill，Agent调用后触发用户支付授权，再继续获得相应能力或结果。

到了8月底，支持范围进一步扩展到DeepSeek Harness和OpenClaw，微信支付还提供了@
tenpay/weixinpay-ai-installer安装方式。从6月底到8月底，腾讯已经连续补上Skill收费、用户授权和更多Agent接入，而Agent Pay X402始终处在这套付费机制中间。

微信支付已经拥有成熟的商户号、支付订单、风险控制和结算体系，腾讯此前也已经允许Agent通过MCP创建和查询微信支付订单。但机器能够调用支付工具，只解决了怎样把一笔已经明确的交易送进支付系统。Agent购买服务时，还要在扣款之前识别服务、价格、任务关系和用户授权，并在付款以后回到原来的任务继续执行。

传统支付系统面对的通常是一笔已经形成的交易。到了Agent环境，机器还要知道当前服务为什么收费、对应哪次调用、用户授权了什么，以及付款以后应该回到哪个任务继续执行。Agent Pay X402处理的，就是服务调用进入付款之前的这部分交易信息。

Agent Pay X402插在了哪里

按照SkillPay官方页面，企业把已有Skill升级为Pay Skill，需要生成开发者密钥，接入微信支付下单，再调用X402 AI预下单接口，并返回支付触发标识。另一份官方说明则把企业侧改造概括为开发者签名、X402预下单和支付触发返回。

微信支付下单与X402 AI预下单在官方流程中是两个连续动作。商户仍然通过微信支付形成真实订单和完成收款，Agent Pay X402增加在Skill调用与微信支付之间，用来处理一项收费服务怎样进入支付。

假设用户要求Agent制作一份行业报告，Agent需要调用一个收费数据库。过去的网页交易可以把服务介绍、价格、购买按钮和收银台展示给用户，由用户自行选择并付款。到了Agent环境，机器需要直接读取服务、价格、任务和付款条件，知道这是什么服务、由谁提供、调用一次多少钱、对应当前哪项任务，付款以后能够获得什么，以及当前付款要求是否仍然有效。这些过去主要通过页面展示给人的交易条件，需要转换成机器能够读取的数据。

腾讯元器此前公开的微信支付MCP已经可以让Agent创建微信支付订单，并查询订单状态。对于一个已经明确需要付款的场景，这些工具能够帮助Agent完成支付调用。但一个Agent执行复杂任务时，可能先后调用数据库、搜索、翻译、图片生成等多个Skill，其中一部分需要收费。创建订单以前，机器就要知道哪项服务收费、价格是多少、是否符合当前任务要求，这张订单对应哪次调用。付款以后，还要回到正确的服务继续执行。

支付API负责下单、查询和资金处理，MCP让Agent能够调用这些工具，Agent Pay X402进一步处理付费Skill怎样进入一笔交易。

MCP解决机器怎样使用工具，Agent Pay X402开始处理机器怎样理解一次付费调用。

到8月底，这套付费能力已经从WorkBuddy、QClaw扩展到DeepSeek Harness和OpenClaw。后两者可以通过安装器接入。对用户而言，Agent找到Pay Skill、发起订单、手机端确认、AI专属卡扣款，再继续执行任务，这套流程已经能够在不同Agent环境中运行。

最后的付款确认仍然留给用户。AI专属卡与微信支付主账户隔离，用户可以控制卡内余额，每一笔订单都需要本人最终确认。Agent可以寻找服务、形成订单和发起支付请求，最终资金授权仍然掌握在用户手中。

Agent Pay X402处理的是一项机器服务怎样从“被Agent调用”进入“需要付款”的状态，再接到微信支付已有的订单和资金体系。

微信的X402，与开放x402并不是同一种公开实现

腾讯的Agent Pay X402，与x402 Foundation维护的开放x402，并不是同一种公开实现。

开放x402围绕机器访问收费资源建立了一套标准化机制。客户端请求付费资源时，服务端返回结构化付款要求，客户端再提交相应支付信息，支付得到验证以后继续获得原来的资源。

V2版本已经把付款要求、支付载荷等核心对象标准化，并允许这些支付信息通过HTTP、MCP、A2A等不同方式传递。开放x402用统一的数据结构表达机器服务的付款要求，再连接不同支付方式。

微信的Pay Skill实现也出现了HTTP 402触发收费、付款后重新访问资源的过程，但实际支付方式带有明显的微信支付体系特征。

在一些公开可检索的Pay Skill实现中，402响应会带回WeixinPay-Required、X-Out-Trade-No等信息，其中包含微信支付触发信息和商户订单号。Agent随后调用微信AI支付，由用户通过AI专属卡完成确认。付款以后，Agent再次请求原服务，服务端依据微信支付订单状态判断付款是否完成，再交付相应内容。

这些字段已经出现在公开Pay Skill实现中，但Agent Pay X402的完整规范目前仍未公开。

从现有实现看，微信Pay Skill并没有直接照搬x402 Foundation V2的标准HTTP支付流程。两者共同采用了“机器请求收费资源—触发付款—付款后继续请求”的基本结构，到了实际付款环节，微信则大量复用了自己已有的支付基础。

用户授权通过AI专属卡完成，真实资金仍然进入微信支付订单体系，商户侧也可以继续利用微信支付订单状态判断付款结果。腾讯已有的人民币账户、商户收款和资金结算能力继续承担原来的角色。Agent时代新增的是怎样让机器识别某项Skill需要收费、形成支付请求，再在付款完成以后恢复服务调用。

Agent Pay X402围绕微信支付与Pay Skill组织机器付费。它与开放x402都利用402表达机器服务需要付款，但两者公开呈现出来的支付对象、用户授权和验付方式并不相同，现有资料也未披露协议兼容关系。

SkillHub负责Skill发布、发现和调用，微信支付MCP提供支付工具，AI专属卡控制用户付款，SkillPay让Skill能够收费。6月26日Agent Pay X402出现以后，这些能力之间多了一套专门处理“Agent怎样购买收费Skill”的机制。

Agent Pay X402补上的，就是“Agent怎样购买收费Skill”这一环。

一笔Pay Skill交易，需要留下什么证据

Pay Skill进入真实调用后，仅仅拉起付款还不够。普通支付发生以后，订单状态可以证明用户有没有付款、商户有没有收到支付结果。Pay Skill的前面还有Agent选择服务和发起调用，后面还有Skill执行与结果交付，仅凭一张支付成功订单，很难完整还原整个过程。

首先需要建立一次服务调用与一张支付订单之间的对应关系。当前一些公开Pay Skill实现已经可以看到这种关系。HTTP 402响应返回微信支付商户订单号，付款后Agent使用此前获得的信息再次访问原来的资源，服务端再查询对应微信支付订单状态。

对于按次收费的Skill，这种对应尤其重要。Agent连续调用同一个服务时，系统需要区分不同调用，避免此前已经使用过的付款被错误用于新的请求，也需要防止接口重试导致重复订单或重复交付。

付款完成以后，服务端还要确认这笔钱确实对应当前调用。开放x402通过标准支付对象提交付款信息。微信的Pay Skill实现则更多依赖微信支付订单本身，Agent完成AI专属卡付款后重新访问资源，服务端再通过商户订单确认支付状态。

微信支付本身已经拥有成熟的订单和查单机制，Agent协议负责把机器请求带到付款阶段，真实支付是否完成，继续由微信支付确认。

支付宝A2M提供了另一个国内参照。A2M同样处理机器访问收费资源的场景，但它把机器账单、支付证明和履约进一步结构化。服务端可以返回Payment-Needed付款信息，用户付款以后，Agent再提交Payment-Proof，商户完成验凭，并在服务交付以后留下履约记录。

几种方案都在回答机器服务怎样收费，但证明交易的方式有所不同。支付宝A2M把账单、付款证明和履约做成更明确的机器对象，微信的Pay Skill实现则较多复用微信支付订单，同时把最终付款授权保留在AI专属卡和用户本人手中。

交易还涉及被调用的Skill本身。Skill不是普通实物商品，而是一项可以被机器直接执行的服务能力。用户付钱以后，除了确认商户收到钱，还可能需要知道Agent调用了哪个Skill、哪个版本，以及内容在调用过程中有没有发生变化。

SkillHub已经具有内容签名和完整性验证机制，可以用于验证当前Skill内容是否与平台签发版本一致。但这种验证不能单独证明某一笔微信支付订单实际购买了哪个版本。

要完整还原交易，还需要进一步把Skill版本、具体调用、支付订单和最终服务结果建立对应。SkillHub的签名和完整性验证能够确认Skill版本及内容状态，交易级绑定还需要其他记录支撑。

一旦Skill版本、调用记录、支付订单和服务结果能够稳定对应，一笔Pay Skill交易就可以留下更完整的记录。用户提出什么任务，Agent调用了什么服务，服务提出什么收费要求，用户最终授权了哪笔付款，微信支付记录了什么结果，Skill又交付了什么内容，都可以成为后续风控和争议处理需要读取的信息。

风控范围也会随之扩大。传统支付重点关注用户身份、账户、设备、商户和资金异常。机器开始参与服务调用以后，Agent有没有超出任务范围、价格是否变化、同一付款是否被重复使用、Skill是否保持完整、付款后服务有没有交付，也会逐渐进入风险判断。

智能体支付需要证明的，正在从一次付款扩展到整个机器交易过程。

Agent开始参与一笔交易怎样形成

银联、支付宝、京东也在从不同位置补充智能体支付规则。

银联APOP更强调Agent身份、用户身份、交易意图和支付授权，ACT覆盖委托、商业交互、支付与存证，支付宝A2M进一步落到机器收费，京东A2P2则更加关注任务授权、用户意图和自主执行证据。

身份、授权、机器收费、资金处理和履约，已经分别进入不同协议的处理范围。机器能不能行动、能够调用什么服务、怎样表达收费、用户授权到什么程度、资金怎样支付，以及交易结束以后如何证明履约，构成了一笔Agent交易中的不同问题。

腾讯的变化同时发生在服务供给和Agent入口两侧。SkillHub已经把大量机器服务组织起来，SkillPay让其中一部分服务可以按次收费，AI专属卡承担用户付款，Agent Pay X402把付费服务调用接入微信支付。8月底，这种支付能力又从WorkBuddy、QClaw继续扩展到DeepSeek Harness和OpenClaw。

与此同时，正在测试中的微信小微也开始从问答走向任务执行。腾讯公开规则显示，小微可以通过技能和接口执行任务，使用第三方服务时还可以调用第三方智能体、Skill、接口或者操作页面，完成搜索、下单以及服务所需的信息输入和授权。在执行任务时，小微还可能根据需要选择智能体、Skill、工具和权限。

目前，小微与AI专属卡、Agent Pay X402之间尚无公开的直接接入关系。两侧的变化已经能够看到同一个方向。Agent开始选择和调用服务，Skill则开始向Agent收费，支付由此进入两者之间。

传统互联网交易中，用户通常自己寻找商品、比较服务、确认价格，再进入支付系统。支付机构接手时，很多交易条件已经由用户和商户确定。

Agent接手更多任务以后，这个顺序会发生变化。用户可能只提出目标，由Agent寻找服务、比较不同Skill、决定调用哪项能力。如果其中存在收费服务，那么用户最终看到付款确认以前，服务选择、调用对象和一部分交易条件已经由机器参与形成。

现阶段AI专属卡仍然坚持逐笔确认，最终资金授权牢牢掌握在用户手中。随着Agent执行更复杂的连续任务，总预算、单笔金额、任务期限以及允许购买哪些服务，都可能成为更丰富的授权条件。

风控也要更早读取任务、服务选择、价格和授权信息。Agent为什么选择某项服务、调用是否符合用户任务、价格是否变化、付款和服务交付能否对应，都会影响一笔交易能不能被准确还原。

支付协议开始处理交易形成以前的服务调用、价格表达和授权条件。谁决定Agent能够发现哪些服务，会影响交易流向。谁规定Skill怎样向机器表达能力、价格和付款要求，会影响Agent如何理解不同选择。谁规定授权怎样传递，则会决定机器能够自主执行到什么程度。

支付之家此前所讨论的“智能体背后的交易决策权”，正在这些具体环节里出现。

从6月26日SkillPay出现Agent Pay X402，到8月底AI专属卡扩展到更多Agent，腾讯已经把机器服务收费带进了越来越多的Agent环境。与此同时，微信自己的Agent也开始具备选择工具、调用第三方服务和执行下单的能力。

过去，支付系统面对的往往是一笔已经形成的交易。到了Agent时代，机器开始更早地参与服务选择、交易条件形成和用户授权。

传统支付协议更多处理一笔交易怎样被授权、支付和确认，智能体支付协议开始进一步参与交易怎样形成。Agent Pay X402进入的，正是这一变化。

这里是支付之家。我们关注支付表象之下的规则差异与逻辑变化，也记录智能体支付正在带来的入口迁移、授权重构和信任重排。本文为行业观察与阶段性判断，观点内容仅供参考。