Agent 支付限额挡不住服务端抬价

给 AI agent 设了每笔 $1 的支付上限，它就不会乱付钱了吗？原文指出，x402 官方 TypeScript 客户端会检查服务端报价是否低于上限，却不会核对这是不是调用方原本愿意支付的价格。原价 $0.01 的资源涨到 $0.10，照样可能被签名付款。

作者围绕这个缺口复现问题、提交 SDK 修复，并引用 Base 主网结算数据说明风险范围。对接付费 API、搭建自动化 agent 的开发者，值得看的是：支付授权究竟应该在哪一步拦住价格偏差，以及链上异常金额到底能证明什么。

上限管住损失，谁来核对价格

x402 让 AI agent 通过 HTTP，用稳定币购买资源。按原文描述，客户端收到 402 Payment Required 后，会选择支付要求，检查单笔金额上限，然后签名。

issue #3866 指出的缺口就在这里：检查对象只有服务端给出的金额，没有调用方认可的价格。

支付上限回答的是「最多能付多少」，价格预期回答的是「这笔钱该不该付」。

假设资源原价 $0.01，商家中途改报 $0.10。只要单笔上限是 $1，这笔涨价 10 倍的支付仍能通过。改价可能来自商家，也可能来自被入侵的服务器，或篡改 402 响应的恶意代理。签名机制正常工作，并不能保证签下来的交易符合用户意图。

作者所在的 Boundra 用 S-BS-06 测试样本回放策略引擎，得到与对照模式拦截结果 6/6 一致的结果；Tanilo 的 x402-guard 在 hook 层配合模拟卖家复现；402Shield 则对照其支付意图偏移方案交叉核验。三方在两天内得出一致判断，但这些验证不等于证明已经发生盗刷。

主网的异常付款，能证明遭到攻击吗

原文引用 Agentic Finance Graph 对 Base 主网的测量：时间为 2026 年 10 月 12 日至 23 日，覆盖 Bazaar 收录、各有至少 20 笔结算的 80 个卖家，共 32,605 笔结算，总额 $18,950.78。

其中，1,126 笔结算达到卖家自身价格中位数的至少 10 倍，占 3.5%；同时满足至少 100 倍、金额至少 $1 的有 25 笔，合计 $1,928.23。最大一笔是 $588.00，而对应卖家的价格中位数只有 $0.01。

数字很醒目，解释却必须收住。

链上金额无法区分恶意加价和合法的按用量计费。同一个服务，小请求和大任务可能价格悬殊。大额案例背后的 13 个付款方也都是单次购买，没有呈现循环付款。

所以，这组数据描述的是潜在多付金额的风险上界，不能当作攻击损失统计。它支持的结论更窄：远高于卖家通常价格的金额，确实可以正常完成主网结算；但这些付款是否违反调用方意愿，原文没有证据。

价格校验应该发生在签名前

作者提交的 PR #3920，为 x402-foundation/x402 的 x402Client 支出控制增加了价格预期。检查放在默认支付路径、签名之前，避免每个接入者都得记住额外注册 hook。

下面的配置同时声明单笔上限、认可价格、浮动范围和收款人：

const client = new x402Client();
client.register("eip155:8453", schemeClient);
client.setSpendControls({
  maxAmountPerPayment: "$1",        // 上限：最大风险敞口
  expectedAmount: "$0.01",          // 预期：调用方认可的价格
  expectedAmountTolerance: 1.5,     // 可选的对称价格浮动范围
  expectedPayTo: "0xSeller...",     // 可选：调用方批准的收款人
});

关键是 expectedAmount 这一行，它提供了独立于服务端报价的判断依据。expectedAmountTolerance: 1.5 表示对称浮动范围；原文没有给出完整计算公式，接入时不能自行理解成任意一种百分比区间。

修复也处理了价格之外的状态问题。如果没有显式预期，可以用首次接受的报价建立锚点。后续价格越界，包括超出范围的降价诱饵，都会在调用签名器之前抛出 QuoteMismatchError。被拒绝的报价不能覆盖旧锚点。

收款人同样需要绑定：首次确认的 payTo 按 (resource, scheme, network, asset) 保存。即使金额不变，替换收款人也会被拒绝；攻击者不能靠同时涨价、换地址重新建立锚点。

无法判断的报价也不能放行。原文列举了报价账本中的小数金额、未知资产精度等情况。拒绝结果携带 source: "caller-config" | "quote-ledger" 和 field: "amount" | "payTo"，方便程序按字段处理。

社区用 A1–A9 验收矩阵、12 次记录会话、签名器调用计数和字段故障注入检查 PR。首轮通过 8/9，缺口是 A5 收款人绑定；第三轮又发现两个首次请求并发通过空账本检查的竞态，以及静默放行分支。作者称已修复，并将每个客户端的支付载荷创建串行化，最终有 798 项测试通过。

不过，原文交付的是修复 PR，没有确认它已合并并进入正式版本。 开头所说的 72 小时内修复，不能直接理解为升级已发布 SDK 就能获得这些保护。

我的判断

我认可把核价放在签名前的默认路径。链上结算完成后再告警，适合审计，却无法阻止当前这笔付款；可选 hook 能扩展能力，但容易因漏接而失效。

显式价格预期也比「首次接受」更可靠。首次报价如果已经被篡改，锚点只能守住一个错误起点。按用量计费的服务还需要说明价格对应多少资源，单独比较总金额未必够用，原文没有展开这部分。

客户端串行化解决了文中发现的竞态，但对并发调用和吞吐的影响没有对照数据。798 项测试提供了验证依据，不能替代真实业务下的性能与兼容性检查。

此外，作者同时在推销 Boundra。它声称提供签名用户策略、按 agent 划分权限并采用最严格规则、通过 ASK 请求人工签名、支出追踪，以及可离线验证的 boundra.verdict/v1 决策收据；没有签名策略则默认拒绝。评估 API 自身按每次 $0.003 USDC 收费，在 Base 主网结算。

这些是其产品设计与商业主张。原文没有给出它与本地规则、人工审批等方案的效果对照，也没有证明每个团队都需要外部策略服务。价格和收款人检查可以先在客户端做好，更复杂的策略层应由实际授权需求决定。

能拿来做什么

• 如果你在 Node 服务中接入 x402，把单笔上限、预期价格和允许的收款地址分别配置。采用上述 API 前，先确认所用 SDK 版本是否已经包含 PR #3920。
• 对固定价格资源，优先使用明确报价。使用首次接受报价作锚点时，要先解决首次报价从哪里获得信任，别把首次收到等同于用户认可。
• 给自动付款流程保留报价、策略决定和结算记录。可以用卖家价格中位数筛查异常，再结合用量判断，避免把大任务付款直接归为攻击。
• 需要人工介入的支付，应在签名前暂停并请求授权。遇到无法解析的金额或未知资产精度，明确拒绝，并把原因交给调用方处理。