还记得腾讯 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 支付开放给所有微信用户，其推理成本必然高到吓人，因此，性价比相对较高的国产模型也存在一定的优势。