AWS与Anchor Browser联手：让AI智能体自主完成链上支付

当AI智能体不再只是浏览网页、调用API，而是能够自主为访问的资源付费时，整个Agent经济的底层逻辑将被重写。AWS Generative AI Innovation Center的Partner Agent Factory团队与Anchor Browser合作，构建了一套让AI智能体能自主完成支付的完整方案。

核心问题：智能体如何安全地花"别人"的钱？

传统AI智能体在执行任务时，访问受保护的Web资源或调用付费API是一个根本性障碍。要么预先配置静态API密钥，要么由人类在循环中手动完成支付环节。这两种方式都无法支撑真正自主、可扩展的Agent工作流。

x402协议的出现提供了一种可能——它是一个基于HTTP 402状态码的支付层协议，允许服务端直接向客户端发起支付请求。Anchor Browser则在此基础上，为智能体提供可编程的浏览器环境。当智能体访问一个x402保护的资源时，服务端返回402状态码和支付要求，智能体的浏览器层捕获这一信号并触发支付流程。

关键在于：如何在不将钱包私钥暴露给智能体运行时（Agent Runtime）的前提下，完成交易签名和重试？

HTTP 402状态码是HTTP协议中预留但长期未被广泛使用的状态码，其语义为"Payment Required"（需要付款）。它最初在HTTP/1.1规范（RFC 7231）中被定义为为未来数字支付场景预留，但多年来几乎没有标准化的实现。x402协议正是重新激活并扩展了这一状态码的语义：服务端在响应中返回402以及结构化的支付要求（如金额、收款地址、支持的支付方式），客户端据此发起链上或链下支付，完成后携带支付凭证重试原请求。这一模式的巧妙之处在于，它无需发明新的传输层协议，而是复用现有HTTP语义，使任何支持自定义响应处理的客户端（包括智能体浏览器）都能参与支付交互。

钱包私钥是区块链账户的最高权限凭证，持有私钥即拥有对应资产的完全控制权。在传统的支付集成中，私钥通常需要注入应用运行时或通过环境变量传递，这带来严重的攻击面——一旦智能体被提示注入攻击（Prompt Injection）劫持，或运行时环境被攻破，私钥就会泄露，造成不可逆的资产损失。因此，将签名操作隔离在智能体无法访问的受控环境中，是Agent支付方案区别于普通支付网关的核心安全前提。

AgentCore payments：三层安全架构

Amazon Bedrock AgentCore payments 模块的设计思路是将支付能力从智能体本身上抽离。整个流程被拆分为三个独立层：

预算检查层位于最前端。每一次支付请求首先经过AgentCore的预算验证，系统根据预设的支出阈值和速率限制决定是否放行。这防止了智能体在循环故障或被恶意诱导时产生无限支出。

交易签名层是安全的核心。钱包凭据存储在AgentCore的受控环境内，智能体运行时（Agent Runtime）始终无法接触私钥。当支付请求通过预算检查后，AgentCore在隔离环境中完成交易签名，仅将签名后的交易哈希返回给调用链。

请求重试层处理支付完成后的原请求重放。签名交易上链确认后，AgentCore自动重试此前被402拦截的HTTP请求，并将资源返回给智能体。整个过程对智能体透明——它感知不到支付的发生，只看到资源最终可访问。

这一架构的意义在于：智能体的自主性和资金安全性不再互斥。开发者可以放心地让智能体在开放Web环境中运行，而无需担心凭据泄露或意外超支。

交易签名是指用私钥对交易数据进行密码学签名，以证明该交易由账户所有者授权。在区块链场景下，签名后的交易会被广播到网络，由矿工或验证者打包确认。签名本身不暴露私钥，但签名操作必须在能够接触私钥的环境中完成，因此签名层的位置至关重要。AgentCore将签名放在与智能体运行时隔离的受控环境内，智能体只能拿到签名后的交易哈希（Transaction Hash），即交易上链后的唯一标识符，用于查询确认状态，而无法反向推导出私钥或伪造新交易。

Agent Runtime指智能体实际执行代码和推理的环境，通常包含大语言模型调用、工具调用和浏览器操作等能力。由于智能体可能被恶意输入诱导执行非预期操作，Agent Runtime应被视为不可信区域。AgentCore payments的设计原则正是基于这一威胁模型：任何涉及资金的操作都不在Agent Runtime内完成，而是通过平台层的安全边界代理执行。这种"能力抽离"模式与云安全中的最小权限原则一脉相承。

实际场景与Agent经济的基础设施

这套方案解锁的工作流相当具体。Meta的Agent Factory项目已经在实验让AI智能体自主研究、调用第三方数据服务并付费获取结果的场景。一个典型的流程是：智能体被要求分析某个市场趋势，它需要访问三个付费数据API，每个API通过x402收取微额费用。AgentCore分别完成预算检查、签名和重试，智能体最终拿到完整数据并生成分析报告。

Anchor Browser的角色则更靠近前端。它为智能体提供了带支付能力的浏览器沙盒，使得x402协议中的402响应能被自动识别和处理，而不是像传统浏览器那样直接报错或跳转到支付页面。

从更宏观的视角看，这套基础设施解决的是Agent经济中最基础的信任问题：服务方需要确认付款会到账，智能体的部署方需要确认资金不会被滥用，而智能体本身需要获得无摩擦的资源访问能力。三方需求通过AgentCore的"预算-签名-重试"流水线同时得到满足。

浏览器沙盒是一种隔离的运行环境，智能体在其中可以安全地加载和操作网页，而不会影响宿主系统或其他进程。Anchor Browser提供的带支付能力的浏览器沙盒，额外集成了对x402协议响应的拦截与处理逻辑：当页面或API返回402状态码时，普通浏览器会显示错误页面或跳转到支付网关，而该沙盒会捕获该响应，提取支付要求并触发AgentCore的支付流程，最后自动重试请求并渲染最终资源。这种设计使智能体无需感知支付细节，即可像访问普通网页一样访问付费资源。

微额费用（Micropayment）指金额极小的支付，通常低至几分钱甚至更少。传统支付渠道因手续费和最低限额限制，难以支持微额交易。区块链和x402协议使按次、按量的小额支付在经济上变得可行，这为智能体频繁调用付费API或访问付费内容提供了基础。Agent经济中的许多场景——如每次数据查询付费、每次网页抓取付费——都依赖微额支付机制才能规模化运行。

对开发者的启示

如果你正在构建需要访问外部资源的AI智能体，这套架构提供了一个值得参考的范式：将支付能力作为平台层的原语，而非嵌入智能体逻辑中。这意味着智能体的代码不需要包含任何支付处理逻辑，支付策略可以通过平台配置动态调整。

另一个值得注意的设计选择是重试机制与支付流程的深度耦合。在传统架构中，支付和请求重试是两个独立模块，开发者需要手动处理两者的一致性。AgentCore将两者绑定，确保"付款成功但请求失败"的情况不会留下不一致状态。

随着越来越多的Web服务开始支持x402等智能体原生支付协议，Agent与资源之间的交互将逐渐从"预配置凭据"模式转向"运行时按需交易"模式。AWS和Anchor Browser的这次合作，是这一转变中拿出的第一批工程化答案之一。