t54 如何在 Amazon Bedrock AgentCore 上构建 AI 支付信任层

AI 代理系统可以自主研究、推理并编排多步骤工作流，但一旦遇到付费墙就会停下来——它没有钱包、没有信用卡、也没有预设的消费上限。t54 正是为了解决这一问题而生。该公司面向的客户场景典型如金融服务团队：一套监控股票组合的代理系统需要实时调用付费市场数据 API，每小时可能产生数千次调用。在这种机器速度下，人工逐笔审批根本无法跟上，而完全放开又意味着不可控的财务风险。

t54 的解决方案分为两个协同层。Amazon Bedrock AgentCore 支付能力提供底层基础设施：会话级消费上限、凭证隔离和支付执行。t54 自研的 x402-secure 则提供信任智能：在代理发起付款之前，对目标端点进行实时评分，判断其是否安全可信。两者结合，让开发团队无需自行搭建定制化支付编排系统，即可获得受治理的代理支付能力。底层协议采用开放标准 x402，利用 HTTP 402 状态码让客户端直接通过 HTTP 为 API 付费。

Trustline 评分引擎在每笔交易结算前独立评估五项信号：支付地址的区块链历史、目标网页的合法性、服务的社交媒体足迹、API 的实时健康状态，以及由前四项综合得出的整体风险评分。每项信号针对不同类型的不可信端点设计，且任何单一弱信号均无法单独授权一笔交易。t54 创始人 Chandler Fang 表示，开发者真正担心的是代理做出具有真实财务后果的操作，而他们的目标就是让开发者对此放心。

架构层面，t54 遵循严格的职责分离原则：负责花钱的组件，永远不应是制定消费规则的组件。系统通过 IAM 拆分为四个角色，代理运行时可以执行支付，但无法修改自身限额、创建新钱包或直接访问凭证。代理在调用时仅获得一个会话 ID 和一个支付工具 ID。开发者凭证通过 Amazon Bedrock AgentCore Identity 加密存储于 AWS Secrets Manager，终端用户的钱包签名密钥则保留在 Coinbase 等钱包提供商处，代理只能拿到会话范围内的令牌。

信任检查被设计为每次支付前的强制性确定性门控，而非模型提示层面的建议。负责集成的 Frank He 博士解释道，将风险检查设为 ProcessPayment 前的必经环节会引入少量延迟，但这是他们愿意接受的代价——唯一的保证是：没有经过新鲜风险决策的交易，一律不会结算。如果端点评分未达阈值、被标记为欺诈或存在 URL 不匹配，支付将在代码层面被阻断，模型无法绕过这一机制。

t54 的产品矩阵还包括 ClawCredit，一个面向代理原生场景的信用额度工具。Amazon Bedrock AgentCore 支付能力负责执行每个会话的消费上限，ClawCredit 则在此上限内提供信用支持的资金来源，两个层次独立治理支出。这套架构已在生产环境中处理超过 2000 万笔代理发起的交易，验证了在高频微支付场景下，自主性与安全合规可以同时实现。

要点

• t54 的 x402-secure 在 Amazon Bedrock AgentCore 支付能力之上构建信任层，已处理超 2000 万笔 AI 代理自主交易，全程无人工审批
• Trustline 评分引擎在每笔付款结算前评估五项独立信号，任何单一弱信号均无法单独授权交易，从根本上防止欺诈端点收款
• 架构采用严格的 IAM 角色分离，执行支付的代理运行时无法修改自身消费上限或访问原始凭证，实现职责隔离
• 信任检查是代码层面的确定性门控而非模型建议，模型无法绕过，确保每笔结算前都有新鲜的风险决策
• 该方案为需要自主调用付费 API 的企业级代理系统提供了可复用的治理范式，无需团队自行搭建定制支付编排