博客2026年5月AWS联手Stripe与Coinbase发布AgentCore Payments，首次为AI智能体提供自主微支付基础设施。本文拆解其技术架构、国内落地路径与零售客户实战案例，探讨智能体从原型走向商业闭环的关键一步。
某零售品牌技术团队花了 3 个月，用大模型搭出一个能理解用户需求、推荐商品的导购智能体。演示效果很好，老板很满意。但上线前最后一个环节卡住了——它没法完成支付。用户说"帮我下单"，智能体只能回复"请点击链接手动付款"。从 POC 到商业闭环，差的就是这最后一步。2026 年 5 月 7 日，AWS 联合 Stripe 和 Coinbase 正式发布 Bedrock AgentCore Payments 预览版——这是业界首个让 AI Agent 能在执行环路中自主完成微支付的基础设施产品。
过去 18 个月，企业建智能体的热情高涨。客服智能体、数据分析智能体、代码审查智能体——各条线都在搭。但翻一翻实际投产数据，超过 70% 的项目在 POC 后没有进入生产环。
断点在哪？不是模型能力不够，也不是工具调用链路不通。真正的断点是：智能体缺乏"花钱"的能力。它能调用 API、能读写数据库、能生成报告，但当它需要为一次外部数据查询付费、为一次 MCP 服务调用结算、为一次内容抓取支付许可费时——整条执行链路就断了。人类必须介入，手动完成支付，然后再让智能体继续。
这本质上是智能体经济的"支付层缺位"。人机协作可以容忍人工支付节点，但自主智能体的商业闭环要求支付也必须自主、安全、可审计。AgentCore Payments 解决的就是这件事。
AWS 这次的方案不是简单地把 Stripe API 接进 Bedrock，而是从协议层到结算层重新设计了一套支付原语。核心链路如下：
关键设计有两个。第一，支付不中断推理循环——智能体收到 402 后，AgentCore 代它完成钱包签名和交易凭证回传，智能体只看到"已支付，继续"。第二，会话级支出上限不是建议值，是硬限制。超过预算自动拒绝，不存在"先扣了再说"。
| 对比维度 | 传统 API Key 模式 | AgentCore Payments |
|---|---|---|
| 接入方式 | 预注册、绑卡、拿 Key | HTTP 402 即付即用 |
| 计费粒度 | 按月/按年订阅 | 按调用、按结果微支付 |
| 风控机制 | 事后对账 | 会话级硬限额、实时拦截 |
| 结算速度 | T+1 至 T+30 | 200ms（USDC/Base） |
| 适合场景 | 人类用户 | 自主智能体 |
从技术选型角度看，支付层的引入改变了整个智能体架构决策链路。我们在之前的AI Agent 开发选型指南中讨论过模型与工具链的选择，而支付基础设施的出现意味着架构评估需要新增一个维度：交易安全与资金治理。类似地，Web 端企业智能体工程化中提到的权限分层设计，在支付场景下会变得更加关键。
AgentCore Payments 目前是 AWS 海外区预览（弗吉尼亚、俄勒冈、法兰克福、悉尼），国内企业有三种落地路径：
| 方案 | 适用场景 | 开发周期 | 预估年成本 | 风险 |
|---|---|---|---|---|
| 自建支付网关 | 有合规支付牌照、内部交易量大 | 6–12 个月 | 80–200 万 | 合规门槛高，需对接银联/网联 |
| 对接 AgentCore（海外业务） | 出海业务、跨境智能体服务 | 2–4 周 | 按交易量（约 0.5%–1.5%） | 仅适用海外用户，国内不可用 |
| 混合方案 | 国内+海外双栈，智能体根据用户区域路由 | 3–6 个月 | 50–120 万 + 交易费 | 双轨维护复杂度 |
对于绝大多数国内企业，现阶段最务实的策略是：先在海外业务线上跑通 AgentCore + 稳定币微支付的完整链路，积累智能体交易的治理经验（预算控制、异常回滚、审计日志），等国内同类基础设施成熟后再迁移。事实上，Stripe 在 2026 年 4 月的 Sessions 大会上已透露正与银联洽谈智能体支付合作——这个时间窗口可能比预想的短。
我们协助某连锁零售品牌将其客服智能体升级为具备交易能力的导购智能体。在此之前，该智能体可处理退换货咨询、商品推荐、库存查询，但一旦用户说"那就帮我下单吧"，对话就断了——需要跳转到 App 手动完成支付。类似场景我们在跨境电商领域也有实践，例如某时尚电商平台的 Stripe 支付集成就遇到过智能体与支付网关的对接挑战。
改造后，用户在同一对话流中即可完成从咨询到支付的全流程。核心技术改动：
上线 3 个月后，该智能体的订单转化率从人工跳转模式的 4.2% 升至 12.8%（提升约 3 倍），平均客诉率下降 18%。但代价是：安全门禁使单次交易延迟增加了 1.2–1.8 秒，部分高频用户反馈"确认步骤太多"。这是体验与安全的经典取舍。
我们一开始的做法是：让智能体在规划步骤中直接调用 Stripe Payment Intents API。测试环境配置了沙盒密钥，看起来没问题。但一次部署中，测试环境与生产环境共享了同一个智能体规划引擎的配置片段，导致沙盒中的支付意图被路由到了生产 Stripe 账号——产生了 3 笔真实扣款，合计约 140 美元。
事后复盘，根因不是配置错误（虽然表面上是），而是架构设计上缺乏"支付动作必须经过独立授权层"的约束。智能体的规划引擎天然是多步、多分支的，任何一个分支触达支付 API 都可能出问题。
教训很明确：智能体的支付能力不能是"又一个工具调用"。它需要独立的钱包层、独立的限额机制、独立的审计通道。AgentCore Payments 把这三层都做进了基础设施，让开发者不用自己从零搭建——这是它最大的价值，而不是省了一个 Stripe SDK 的集成工作量。
目前预览版仅覆盖 AWS 海外四个区域（美东、美西、法兰克福、悉尼），需要海外 AWS 账号和 Stripe/Coinbase 账户。国内业务直接接入不可行，但出海业务可以立即尝试。建议关注 Stripe 与银联的合作进展。
目前中国大陆对加密货币交易有严格限制。AgentCore 使用的 USDC 稳定币支付轨道主要适用于海外用户。国内智能体的支付闭环更可行的路径是等待 Stripe 等厂商推出支持人民币/银联的智能体支付方案，或采用混合架构——国内用户走传统支付网关，海外用户走稳定币微支付。
它把定价模式从"按月订阅"拉回"按调用/按结果"——智能体调用一次付费 API，结算一次。对于 API 提供商和 MCP 服务开发者，这意味着新的收入入口：你的服务不止卖给人，也卖给智能体。对于企业，这意味着智能体的运营成本变得精确可量化。
取决于牌照和合规。如果已有支付牌照（或对接持牌机构），纯技术开发约 3–6 个月。核心模块包括：钱包管理、限额引擎、交易审计、异常回滚。如果从零申请牌照，周期 12–18 个月。大多数企业选择对接已有基础设施而非自建。
智能体支付基础设施的成熟，意味着"能交易的智能体"从一个前沿概念变成了可落地的工程问题。如果你的团队正在规划智能体产品，不妨先把一个具体场景跑通闭环——从意图识别到支付结算，哪怕只支持一种支付方式、一个金额上限。
优码云（umayun）在智能体工程落地方面积累了多个行业的交付经验。如果你的团队正在评估智能体支付方案或智能体架构设计，可以联系我们做一次免费的技术评估，或查看完整案例了解我们如何帮助企业把智能体从原型推到生产环境。