t54 披露 2000 万笔 Agent 微支付：x402 风控必须在付款前完成

t54 披露 2000 万笔 Agent 微支付：x402 风控必须在付款前完成

AWS 9 月 1 日公布了 t54 与 Amazon Bedrock AgentCore payments 的生产案例。t54 称其 x402-secure 已处理超过 2000 万笔 Agent 交易，单笔金额在 0.001 至 0.01 美元之间，没有逐笔等待人工批准。这类交易适合购买实时数据或付费 API，付款前的身份、额度和收款方风险也成为基础设施。

数据来自 AWS 与服务商的联合案例，不等同于独立审计或整个 Agent 支付市场的统计。它仍提供了一组值得研究的工程边界：Agent 只拿到 session ID 和 payment instrument ID，签名私钥由钱包服务商保存；会话额度耗尽就停止，运行中的 Agent 没有自行充值或重建额度的路径。

x402 解决付款协商，不能替收款方背书

x402 使用 HTTP 402 状态码表达付款要求。Agent 调用收费 API 后收到金额与付款信息，再由支付设施完成签名和结算。它减少了为每个服务单独创建账号、订阅和充值的摩擦，但协议能正确传递付款要求，不代表要求付款的地址可信，也不能判断 API 返回是否值这个价格。

[AWS 案例](https://aws.amazon.com/blogs/machine-learning/how-t54-built-a-trust-layer-with-amazon-bedrock-agentcore-payments/)中，t54 的 Trustline 在结算前检查链上地址历史、目标网页、社交信息、API 实时健康状态，并形成综合风险分。任何单一信号都不能授权交易。风险分仍可能误判，特别是新服务缺少历史、合法服务被仿冒，或多个信息源共同受到操纵时，因此它更适合作为阻断异常的信号，而非商业信誉证明。

对购买模型 API、数据接口或 MCP 工具的 Agent，服务发现与付款授权要分开。注册表告诉 Agent 有什么工具，x402 告诉它如何付款，企业策略决定该任务能否购买。高价值、首次收款方和异常频率仍应进入人工复核，常用低额服务则可在明确额度内自动完成。

花钱的进程不能同时修改自己的预算

t54 把付款执行、规则配置、凭据管理和收款方评分拆成不同角色。Agent runtime 可以发起付款，却不能提高会话上限、创建新钱包或读取原始凭据。每次 ProcessPayment 前都有确定性的风险门；模型即使在提示中声称任务紧急，也不能绕过代码判断。这种分工比在 system prompt 里写“谨慎消费”可靠得多。

会话预算还需要绑定用户、任务和有效期。AWS 的实现允许支付会话设置 15 到 480 分钟的过期窗口，并实时跟踪可用金额。生产系统还应为付款请求提供幂等键，防止网络重试造成重复结算；对循环调用增加次数和速率限制，避免一万个合法小额支付在总额上变成事故。

日志至少要关联会话、工具、收款方、金额、风险决定、支付状态和业务结果。只记录链上成功不足以说明任务获得了有效数据。若付费 API 返回错误或内容质量不达标，系统还需要争议、退款或服务降级规则。可以让独立风险引擎复核模型选择，但涉及资金与合规的最终策略应由确定性规则执行。

AI 中转站可能同时面对模型计费与工具支付

统一模型网关现在多以预充值或月结方式为模型调用计费，x402 则适合 Agent 临时发现并购买外部能力。两套账不能混在一个“剩余额度”里：模型 Token、工具服务费、支付网络成本和失败重试要分别归因，否则团队看不出一次任务为何变贵。

对于 API 提供方，按调用自动收费会降低接入门槛，也会增加响应真实性、退款和防滥用责任。返回 402 前应给出稳定服务标识、明确金额、币种或网络、有效期和幂等范围；完成付款后也不能跳过 API Key、速率限制与内容授权。支付凭证证明付过钱，不证明调用者有权读取某个租户的数据。

AnyAIS 可继续承担多模型调用与用量管理；若未来接入 Agent 支付，应把模型路由、工具发现、付款授权和业务审计保持为独立层。Agent 可以执行付款，但额度、收款方信任和停止条件必须留在模型无法修改的控制面。