数字员工过去调用付费 API，通常依赖企业预先采购的账号、密钥和月度订阅。Agent 一旦需要在任务中临时购买数据、模型推理、MCP 工具或付费内容，就会撞上一道边界：谁授权、最多花多少、付给谁、失败后是否重复扣款，以及这笔支出如何进入业务账本。
AWS 在 2026 年 8 月 18 日宣布 Amazon Bedrock AgentCore payments 正式可用。它把钱包连接、机器支付协议、会话限额和观测接入 Agent Runtime。对企业而言，这不是一个“让 Agent 会付款”的小功能，而是把采购权和资金副作用带进了模型执行循环。
官方能力：支付成为运行时原语
按照 AWS 官方资料，AgentCore payments 可连接 Coinbase CDP 和 Stripe Privy 钱包。最终用户在 Agent 之外完成注资与委托，Agent 看不到卡号、银行信息或钱包私钥；服务通过 AgentCore Identity 保存开发者凭证，并使用短时令牌请求钱包提供商执行签名。
支付编排支持 HTTP 402 Payment Required 驱动的 x402，也在 GA 时加入 MPP。x402 的 upto 模式允许商户在调用结束后按实际用量结算，因而可用于按 Token、算力或 API 用量收费。AWS 同时把一批付费 x402 端点通过 AgentCore Gateway 的 MCP 服务暴露给 Agent 发现。
每次交互可以创建 PaymentSession，配置最大金额与失效时间。基础设施在签名前检查预算，超限就拒绝；CloudWatch 与 AgentCore Observability 记录支付生命周期、成功率、平均交易额、日志和链路。以上是官方功能事实，不等于任何模型、商户或钱包已经通过独立安全审计。
会话限额不是完整授权
AWS 安全最佳实践提出四角色 IAM 模式：控制面管理、会话配置、实际支付与资源读取相互分离，使单一角色不能同时抬高预算并花掉预算。工具访问再由 Cedar 策略决定“谁能用什么工具和参数”，PaymentSession 只决定“能花多少、能花多久”。
这一区分很关键。Prompt 中写“只买必要数据”不是授权控制，模型也不应生成收款地址。AWS 明确说明服务端不会自动限制 payTo，应用必须维护已验证商户地址、核对当前支付请求，并拒绝未知收款方。多租户系统若只用 IAM 模式，UserId 请求头的正确性仍由应用负责；官方建议需要可验证终端用户身份时采用 CUSTOM_JWT。
因此，企业至少需要四道确定性门：用户是否明确委托，Agent 是否允许调用该类付费工具，商户与收款地址是否在可信范围，本次金额与累计预算是否都合规。任何一道都不应交给语言模型自行判断。
付款以后，必须还有业务账本
一次支付成功，不代表业务交付成功。Agent 可能已付款但内容读取失败，也可能工具返回超时后自动重试，产生重复扣款。AWS 文档要求实现幂等、限制重试并处理补偿交易；签名失败的预算扣减可以回滚，但这不能覆盖所有商户交付、链上确认、退款与争议场景。
建议把任务 ID、用户委托 ID、策略版本、工具调用 ID、PaymentSession、商户、报价、支付证明、交付结果和补偿状态写入独立业务账本。支付前生成稳定幂等键；重试时先查询支付与交付状态。不可逆或高金额操作增加人工审批，不能因为 AgentCore 已经记录 trace 就省略财务凭证和业务对账。
这与 实时 Agent 的幂等与恢复 是同一类问题：网络恢复提供的是执行连续性，业务系统仍要证明没有重复副作用。企业还应把支付失败、商户不可用和钱包授权撤销纳入 长时 Agent 评测，而不是只测一次顺利路径。
对模型路由和采购模式的影响
“按次购买推理”可能让数字员工动态选择模型与工具，无需为每家供应商长期保存密钥。但它也把成本从固定订阅变成任务内的实时决策：同一任务可能同时产生模型 Token、工具调用、Runtime、网关、日志、钱包与网络费用。
模型路由器不能只比较 全模型目录 的输入输出单价，而要计算每次成功交付的总成本，并设置任务级、员工级、部门级和租户级预算。低风险数据查询可以在小额限额内自动完成；涉及客户承诺、合同、采购或跨境支付的动作，应保留审批和传统采购通道。
企业上线前的八项验收
- 用户注资与付款委托必须在 Agent 之外完成，且可随时撤销；
- 管理预算与执行支付使用不同角色，任何单点都不能自批自付；
- 付费工具、参数、商户和
payTo地址都有确定性白名单； - 每个任务使用短时、最小金额 PaymentSession，并有部门总预算；
- 超时、重试、恢复和并发场景不会产生重复支付；
- 付款成功但交付失败时存在查询、退款或补偿流程；
- CloudWatch trace 能与财务凭证、业务结果和用户委托一一关联；
- 钱包、稳定币、地域、税务、数据与供应商退出风险完成法务和采购审查。
更完整的 Runtime 比较可参考 企业 Agent Runtime 选型清单；AgentCore 的模块、成熟度与来源持续记录在 生态观察页。
研究限制与编辑判断
本文的功能与安全边界来自 AWS 官方博客、AgentCore 概览、支付核心概念和安全最佳实践。AWS 博客中的客户案例和上线效率属于厂商及客户自述，尚无独立生产评测证明所有协议、钱包、地域和故障组合均达到同等可靠性。
稳定币、钱包托管、商户验证、退款争议和跨境合规会随地区与业务形态变化，本文不构成法律或财务意见。我们的编辑判断是：Agent 支付已达到企业架构研究门槛，因为它改变的不只是结算方式，而是数字员工的权限模型——资金动作必须像数据库写入和生产发布一样，具备最小权限、确定性策略、幂等、补偿、审计与人工接管。