研究智能体找到有用的数据集，仍可能在最后一步卡住：付费获取。AWS 与 Anchor Browser 正试图填补这个缺口，但不把通用钱包塞进智能体。10 月 13 日公布的集成让托管浏览器识别 x402 支付挑战，通过 Amazon Bedrock AgentCore Payments 获得授权，再重试原请求一次。
关键区别是财务权限。智能体选择请求什么；独立服务判断配置的支付工具与会话预算是否允许收费。支付成功既不能证明这份资料值得购买，也不能证明研究结论正确。
付款挑战变成浏览器操作
Anchor Browser 已经为 Playwright、Puppeteer 和 Chrome DevTools Protocol 工作流管理登录状态、导航、网络事件和交互录像。开发者用 x402: true 给会话附加支付能力。默认值为 false，因为开启意味着授权从配置的支付工具实际付款，而不是模拟交易。
在 AWS 的集成流程中，商家先返回 HTTP 402 Payment Required，列出金额、支付方式、网络及收款地址。AgentCore 验证载荷和支付工具，检查剩余额度。获批后，由配置的钱包提供商签署支付证明；浏览器附上证明，把原请求重发一次。商家完成验证、结算后提供资源。
x402 第二版使用 PAYMENT-SIGNATURE 请求头，第一版使用 X-PAYMENT。智能体无需构造这些请求头、运行钱包 SDK 或维护支付重试逻辑。能力覆盖页面导航、fetch、XMLHttpRequest，包括浏览器上下文内付费的 POST 和 PUT 调用。
格式错误的挑战、不支持的网络或耗尽的预算，会让原始 402 作为普通 HTTP 错误保留。仅重试一次防止同一个请求陷入自动付款循环，却不能阻止规划器连续发起许多独立请求；后者需要上层控制。
AWS 表示，该功能已通过 AWS Marketplace 上的 Anchor Browser 提供，并与 Generative AI Innovation Center Partner Agent Factory 合作开发。这说明它是可部署的集成，并非广泛商家采用或生产可靠性已获测量验证。
控制平面不只是一句节省开支的指令
AgentCore 架构把职责分给多个托管资源：Payment Manager 定义 AWS 账户边界；PaymentConnector 连接外部钱包设施；PaymentCredentialProvider 通过 AgentCore Identity 处理提供商凭据；PaymentInstrument 标识钱包地址。
PaymentSession 将支付工具绑定到一次交互，规定最高金额、币种与到期时间。超过限额或到期后，收费请求会被拒绝。文中列出 Coinbase Developer Platform 和 Stripe Privy 两种钱包提供商选项。钱包秘密与授权密钥保留在托管身份和秘密管理设施中，而非智能体运行时。
这类似短期云权限：允许完成有界任务，而不移交永久账户控制权。提示词里的“谨慎花钱”并不是等价安全措施。当同一运行时能够签署任意转账时，提示注入、环境变量泄露、依赖被入侵或工具误用的后果会更严重。
隔离不等于免疫。被攻陷的浏览器仍能操纵授权会话内的请求。过宽的 IAM 权限若允许直接读取提供商秘密，更可能绕过预算与审计路径。因此角色、连接器权限、秘密访问与保留策略仍属于安全边界。
CloudWatch 记录支付尝试、批准、拒绝与结算。浏览器录像和网络历史可把费用关联到触发它的导航与任务。对于长时间运行、购买多项资源的智能体，这比孤立的交易记录更有解释力。
按次获取带来新的采购问题
x402把页面、文件、API 或 MCP 工具的访问变成“请求—挑战—证明”交换；可选的 facilitator 负责验证和广播交易。客户端可以为单份资源付费，而不必先开户或购买整套订阅。
这适合动态发现：任务开始后，智能体可能遇到此前未知的付费服务。例如一项研究先后购买授权市场数据、文件分析及公司记录。每次购买都可能合理，但重复获取或低价值追加仍会耗尽全部额度。
预算上限限制风险敞口，却不阻止限额内浪费。有效挑战不能证明准确性、时效性、定价公平或必要性。商家白名单、单笔限额、品类规则、重复支付检测及人工审批阈值，需要补充会话总额度。
购买的证据还需要来源记录、保留和访问控制。缓存已授权结果有助于避免二次付费，但复用必须遵守提供商条款；交易层本身不能解决信息管理问题。
AWS 表示 Anchor 把第三方 x402 费用与浏览器费用合并计费，客户不必为每个工作流维护独立加密货币余额。这是 Anchor 的服务安排，而非 x402 的普遍属性。团队仍须确认收据、税务、记账和退款。链上结算的撤销与争议机制也可能不同于银行卡付款。
多种协议，而非万能结账入口
市场存在多条路线。Stripe 与 Tempo 的 Machine Payments Protocol使用 HTTP 身份验证挑战，强调商家报表、退款、反欺诈与结算到既有余额。Google 的 AP2 框架宣布时有超过 60 家机构参与，关注用户、智能体、商家和支付提供商之间的委托关系。
它们有重叠，却不可互换。x402 直接面向 HTTP 资源和按次 API；AP2 涵盖更广泛、跨支付方式的委托采购。商务协议还要处理商品目录、结账、履约与商家关系。AgentCore 同时支持 x402 和 MPP，承认多套标准可能并存。
多协议支持并不保证安全措施等价。稳定币和令牌化银行卡在结算、隐私、欺诈与监管影响上不同。企业需要跨支付路径一致的政策，而不只是让交易在技术上可行的适配器。
托管设计还引入依赖：Anchor Browser、AgentCore、钱包提供商、商家及结算网络必须协作。AWS 特有的 Payment Manager 资源、Identity、IAM 与 CloudWatch，可能意味着迁移时要重建政策及可观测系统。
缺少的是运行证据，而非架构解释
AWS 的文章解释架构，但没有给出支付成功率或商家延迟的比较基准。Cloudflare、Coinbase 的支持以及精选 Bazaar 发现连接，也不能证明有多少真正有用的资源。端点质量比目录规模更重要。
真实浏览还包含身份验证、重定向、JavaScript、网络故障和结算延迟。小范围评估可用一个获批付费 API 和短时会话，再对账浏览器证据、支付日志、输出质量与总成本。重复购买、拒绝、延迟及人工介入都应计入结果，不能只统计成功收费。
已知商家的低金额请求可能适合预授权；新卖家、异常金额、合同承诺、个人信息或受监管数据可能需要提示词之外执行的明确审批。集成的实际贡献是分离意图与权限。它是否改善自主任务，仍取决于买了什么、得到了什么证据，以及故障如何处理。
关于整理和保留工作上下文的相关阅读：技术文档知识库 ; AI 辅助周报工作流.