腾讯“测试中”的Agent钱包，被亚马逊抢先了

还记得腾讯AI专属卡吗？

2026年6月17日，微信支付公开介绍了正在测试的“AI 专属卡”。简单来说，这是一张专门给AI Agent使用的受限支付卡，用户可以提前充值、设置额度，再把它绑定到 WorkBuddy等Agent。之后，AI就能根据用户指令完成搜索、推荐和下单，费用则从这张专属卡里扣除。

腾讯总裁刘炽平在2025年11月的财报电话会议中就提到，“微信最终会推出AI智能体，可以在微信内部帮用户完成大量任务。微信拥有社交、小程序生态，还有无缝打通的支付生态。理想的助手，理解用户需求，在微信生态内执行全部任务。”

然而直到现在，这个支付沙盒都没上线，而且自那之后再没有后续消息传出。

但今天传出消息，亚马逊抢先把这个产品做出来了。

8月19日，亚马逊AWS宣布Amazon Bedrock AgentCore Payments正式进入GA阶段。此前还只有一些简单付费场景的预览功能，现在已经可以让 AI Agent在用户授权和预算限制下，自主购买付费API、MCP服务、数字内容以及模型推理能力。

用户可以为钱包充值，开发者的密钥则被放进AgentCore Identity Secrets Manager，Agent不需要、也无法直接看到原始凭据。每次支付还可以设置金额上限和失效时间，基础设施会在交易签名前进行确定性校验，防止Agent越权花钱。

这就跟此前腾讯曾测试微信支付AI专属卡功能“撞车”了。

腾讯的做法同样是不给Agent用户完整的钱包权限，单独划出一笔资金，用户先充值、设置额度，WorkBuddy再根据指令完成搜索、推荐和下单，最后由用户确认支付。

不过两者还是有差别的，虽然从表面上看，腾讯和亚马逊都是在让AI代替用户花钱，但往下看就会发现，腾讯更生活，亚马逊更商务。

要看清两者的差别，还得从它们各自服务的对象和支付方式说起。

亚马逊Agent钱包和

腾讯AI专属卡有何区别？

先看亚马逊。

AgentCore Payments面向的并非普通的消费者，而是部署AI Agent的企业和开发者。它要解决的，是让Agent在执行任务时，能够直接购买自己所需要的数字资源。比如付费API、MCP Server、实时数据、网页内容、模型推理和算力服务。

举例来说，一个研究Agent可以按次购买金融数据，一个编程Agent可以调用收费工具，一个浏览器Agent可以访问付费网页。

所以，与其说是自动支付，我倒觉得AgentCore Payments的更像是给开发者部署的一套支付基础设施。

开发者先选择Coinbase CDP或Stripe、Privy这类钱包服务商，准备对应的API Key和Secret。然后把凭据交给亚马逊的AgentCore管理，创建支付管理器、支付连接器和支付工具，再为每一次Agent交互创建支付会话。

如果是亚马逊AgentCore Payments的终端，那就需要为钱包充值，并明确授权Agent代表自己支出，这点倒是和AI专属卡类似。

之后，当Agent遇到支持x402或MPP的收费服务时，它就可以发起支付请求。AgentCore会在交易签名前检查金额、会话状态和预算上限，只有符合规则，才能调用底层钱包完成签名并且支付。

总的来看，它的关键其实不在于“给AI安排了一张卡”，而在于把支付嵌入进了Agent的工作流。

概括一下，如果我的工作流需要用到这个，而这个又要花钱，那么AgentCore Payments就替我在后台完成花钱这个动作，这就让我可以不用跳出工作流去花钱。

再看腾讯。正如开头提到的，用户要先在微信钱包里开通AI专属卡，把一笔预算从微信零钱转进去，再将它绑定到WorkBuddy等Agent。

然后当用户跟Agent对话中，提出“帮我买团购券”或“帮我订服务”之类的需求后，Agent负责理解需求、搜索商品、比较选项并生成订单。

接下来，微信支付负责把订单和金额发送到用户手机，用户确认并验密后，款项才会从AI专属卡中扣除。

所以微信支付的AI专属卡，本质上是一张专门给Agent使用的受限副卡。而且AI专属卡并不能像AgentCore Payments一样，可以打通别的钱包，只能用AI专属卡里的钱进行消费。

换句话说，腾讯把 AI 的花钱能力压缩在“这张卡里有多少钱”这个问题上，先把最危险的无限授权变成一个可见、可控、可撤回的余额限制。

但是它AI专属卡，要比AgentCore Payments更生活化。

此前腾讯曾公开过几个使用案例，其中有一个就是用户打开WorkBuddy，在专家页面召唤“美团生活助手”，然后问它“附近有什么好吃的团购”。

WorkBuddy就会结合用户的位置信息和偏好搜索商家，再把商品推荐出来。

AI专属卡这条链路的重点，是把原来分散在搜索、比价、下单、打开微信支付几个应用里的动作，压缩成一次对话。AI先替用户“跑腿”，微信支付再把付款收回来，支付仍然是整个消费闭环的最后一步。

两者最大的差别在于，两家公司想把支付放在不同的位置。腾讯想把AI从“会推荐”推进到“能消费”，让用户说完一句话之后，生活服务能够在微信和小程序生态里闭环。

亚马逊则希望支付成为Agent工作流里的基础动作。它不要求开发者把每家服务商的结账页面、订阅体系和API Key都重新塞进Agent，而是让Agent在后台主动发现收费服务、完成结算，再继续执行任务。

这也是为什么看起来两家公司都在做AI钱包，实际却已经走向了两个不同的市场。

对比微信支付，

AWS的关键设计是什么？

亚马逊之所以敢让Agent替用户完成消费的动作，实际上有三层关键设计。

第一层是身份和凭据的分离。

微信支付的AI专属卡不需要把用户的支付密码交给WorkBuddy，Agent只能通过绑定关系和用户确认完成支付，用户需要点确认，它的支付动作，是按“一笔一笔”来的。

相对而言，亚马逊的做法更适合企业环境，开发者的Coinbase或Privy密钥由AgentCore Identity Secrets Manager负责托管，Agent本身是拿不到原始密钥的。

它只能调用支付工具，向AgentCore提交一个支付请求。在这之后，AgentCore再使用由凭据派生出的短期令牌，指示钱包服务商执行创建钱包或交易签名等操作。

也就是说，Agent只有有“请求付款”的能力，却没有直接拿着私钥转账的能力。

换句话说，AgentCore Payments从始至终不碰钱，它只负责向两边传话。“那边钱打过去了”、“这边钱打过去了”，仅此而已。

AI专属卡则是“好，你等会，我从我的兜里拿钱给你”。

简单概括成一句话，腾讯重点解决的是“我可以花多少钱”，亚马逊重点解决的是“这个Agent以什么身份、凭什么权限、在什么条件下发起这笔支付”。

对一个单一的消费者场景来说，余额隔离已经足够直观。但对企业来说，同一个Agent可能服务很多用户、调用很多供应商，还要在不同会话之间区分预算。

如果只给它一个钱包地址，后续很快就会遇到账户混用、权限无法撤回和审计困难的问题。

第二层是支付会话。

亚马逊在文档中写到，AgentCore Payments是把支付当成上下文来处理。

除了钱不够这点以外，单次会话如果时间太长，或者是会话内容有问题，那Agent都无法继续支付。

举个例子，在AgentCore Payments可以使用的诸多场景中，有一个场景是研究。用户想研究物理学知识，Agent负责替用户购买相关文献资料。但如果出现了与物理学无关的支付请求，那么Agent同样也不能完成支付。

第三层是确定性校验。

大模型是非确定性系统，它可能把网页上的一句话误读成付款授权，也可能在接口超时后重复重试。

都说英雄不问出处，然而亚马逊明确把预算校验，放在了交易签名前的基础设施层，亚马逊认为，不管你是谁，必须得问清楚来历。

只有校验通过，底层钱包才会签名。这个顺序很重要，因为它意味着亚马逊没有把最后一道安全闸门交给模型。模型只有一个权力，那就是告诉钱包，“我真的很需要这笔钱”。

第四层是协议编排。

微信支付AI专属卡目前主要嵌在微信支付和生活服务的订单流程中，但亚马逊需要面对的是一堆可能互不兼容的机器支付协议。

在预览阶段，AgentCore Payments支持由Coinbase发起的X402。亚马逊称，进入GA后，还加入了Stripe与Tempo共同制定的MPP。

亚马逊的做法其实有一点像Claude Code。无论底层面的服务商是谁，都不需要为每一种支付标准重写Agent，接入进来，就按亚马逊已经编排好的那套直接开始运行。

第五层是“最高不超过”方案。传统的按次付费通常要在请求前确定价格，但模型推理、算力和数据查询经常无法提前知道最终消耗多少。

一次请求可能只生成几百个token，也可能因为上下文变长而消耗更多资源。亚马逊在x402中加入了“upto”机制，让 Agent 先授权一个最高金额，服务商在调用结束后按照实际消耗结算。这样，服务商可以按真实token 数、算力或者返回数据量收费，而不是只能给每一次请求设一个固定价格。

AI专属卡就是固定付费，这杯奶茶卖多少钱就付多少钱。

亚马逊官方演示中，Agent可以在不同模型之间动态切换。简单任务调用便宜模型，复杂任务调用强模型，或者在价格变化时改用另一家推理服务。

Agent甚至可能在执行任务的过程中比较不同模型的价格和效果，再决定把下一次调用交给谁。

这样一套操作下来，可以帮用户省下不少钱。

为什么腾讯不敢

把AI钱包做成基础设施？

AI专属卡所使用的，也叫X402，但是全名叫腾讯X402 Agent Pay，是完全自研、微信支付体系内的国内闭源接口，跟前文提到的，国际上的X402压根不是一回事。

只是因为底层逻辑相似，都是基于Http 402状态码，在Agent调用API时触发即时小额付费，因此才用了相似的名字。

早在2026年4月，腾讯就正式对外发布了微信支付接入Skill，定位是给Cursor这类支持Skill协议的AI‑IDE所使用的开发者工具，用来帮开发者做支付产品选型、做接入安全扫描、排错，不是普通用户能直接感知的功能。

6月迭代到了2.0版本，增加代码安全评估、动态排障，并同步更新官方文档。同时在6月份的更新中，也发布了AI专属卡。首发只给WorkBuddy Mac端使用，用来跑美团生活助手这类Agent Skill的下单团购场景。

但微信支付接入Skill的GitHub页面显示，该仓库于6月之后再无更新。

腾讯能做AI支付，但暂时不太敢把它做成AgentCore Payments那种跨平台、自动化、面向机器经济的开放钱包基础设施。

如前文所述，AI专属卡到最后一步仍然需要用户本人点击确认，那么设想一下，如果腾讯把这个流程改成“只要符合额度就自动付款”又会如何？

问题马上就会变复杂。AI误解了用户的一句话，算不算用户授权？网页里的恶意提示词诱导Agent买了不该买的东西，平台要不要赔？Agent因接口超时重复调用，导致一笔订单扣了10次，责任落在Agent、商户还是支付机构？

亚马逊之所以敢这么做，是因为它把自动支付限制在了开发者、企业和小额数字服务场景里，用户基数小、承担风险能力强，而且除了酒店预订，交易往往是几美分到几美元的API、内容或推理调用，哪怕是发生失误，也不会造成多大的损失。

AI专属卡一旦面向数亿普通用户开放，腾讯所面对的责任将远远超出想象。当用户规模过大时，平台就不可能只靠一个预算规则来解决所有风险。

腾讯的优势恰恰是微信支付连接着微信、公众号、小程序、商户和本地生活服务，可也仅此而已，AI专属卡的所有支付目前仅能围绕这一套生态体系使用。

亚马逊做的却是跨生态支付。一个Agent可能在执行任务时调用不属于AWS的API，再访问Cloudflare后面的付费内容，接着通过BlockRun购买一次模型推理，最后调用Travala的旅行MCP Server预订酒店。

对腾讯来说，如果要成为这类交易的底层钱包，它就要处理跨平台身份、跨境支付、数字内容售后以及不同服务商的技术标准。所以目前腾讯的做法是号召商家入驻微信生态，而不是大家把协议对齐。

最关键的一点，不得不承认，模型之间存在着性能差距。虽然亚马逊自己的模型Nova，性能要弱于腾讯旗舰模型Hy3，但是亚马逊的AgentCore Payments本身并不绑定某一个模型，AWS官方明确表示，它可以与Amazon Bedrock内外的模型配合，包括Anthropic的Claude、OpenAI的GPT、Google的Gemini等等。

腾讯方面，目前AI专属卡公开落地的入口是腾讯自己的WorkBuddy，而WorkBuddy主要使用的是混元、DeepSeek、GLM、MiniMax、Kimi等国内模型。

腾讯并非不能接第三方模型，腾讯官方文档同时提供了自定义模型入口，允许用户接入第三方模型。可根据专业测评机构Artificial Analysis的测试，全球最顶尖的模型仍然是Claude和GPT。模型差距或许也是腾讯不敢贸然开放AI支付的原因。

不过相对的，在性价比方面仍然是国内模型领先。一旦AI支付开放给所有微信用户，其推理成本必然高到吓人，因此，性价比相对较高的国产模型也存在一定的优势。

文章来自于微信公众号 “字母AI”，作者 “字母AI”