x402 不缺卖家，缺"第二次调用"：Agent 支付的授权与验收

一键发币： x402兼容 | Aptos | X Layer | SUI | SOL | BNB | ETH | BASE | ARB | OP | Polygon | Avalanche

一句话结论：x402 已经解决了"Agent 怎么付钱"——协议对比和数据口径我们都拆过了。真正卡住第二次调用的是支付之外的三层：签名前谁来决定这笔钱能不能付、执行前谁来判断这笔操作是否合理、交付后谁来决定"这活干得值不值得付钱"。缺任何一层，买家的下一次调用就不会发生。

本文整理四篇近日实操：

• @terminator_agent《The x402 bottleneck isn't buyers. It's the second call.》（2026-10-14）——爬完 31,620 条 x402 服务后对"需求侧"的修正；
• @mubaraqabba《From Prompt to Policy: How I Made a Solana Agent Safe Enough to Run Unattended》（2026-10-10）——五天内搭出的 deny-by-default 策略层与两次压力测试；
• @scriptmasterlabs01《The Aave MCP Prepares, the Agent Wallet Signs — But Who Judges?》（2026-10-10）——Aave MCP × MetaMask Agent Wallet 的分工，与"静态规则抓不住坏判断"的实测；
• @kurumi《Your AI agent finished the task. Who decides if it's good enough to pay for?》（2026-10-15）——用托管合约 + 评分细则 + 多模型陪审团把"验收"自动化。

一、需求侧真相：供应不缺，缺的是"第二次调用"

@lowkeybuilds 这周把 31,620 条 x402 Bazaar 服务全部爬了一遍，发现 77% 的条目在 30 天内只有不超过两个付款人——而且大多数情形下，那"第二个"大概率就是卖家自己的测试调用。结论很直接：x402 的瓶颈不是供应，是买家。

但爬虫看不到的是"买家出现之后发生了什么"。作者转述了另一位买家 Alex 的实测：他对 85 家 x402 卖家各付 0.01 美元并逐条记录——

Alex 自己的保留意见：不能用一个样本断言需求缺口是结构性的。但作者把这 4/85 看成了故事的另一半：爬虫看不见"买完就不回来"。一个认真做事的端点收 0.02 美元、返回的却是填充内容——它就永久失去了那位买家的第二次调用。作者自己的经历也类似：挂出一份 USDC 明码标价的审计服务，三天没有回复，同一标签下挤满了十几个几乎一模一样的"探测 + 审计"帖子。向已经被坑过一次的买家卖"确定性"，是这条支付轨道上最难的销售。

所以他建议的月度指标不是"有多少只有 1 个付款人的服务"，而是那个 4/85：收钱不交付，轨道就永久损失一个买家。一句话：第一次调用是营销，第二次调用才是生意。

而要让第二次调用发生，得先在支付的前后补上三层控制。

二、签名前：把"能不能付"交给代码，而不是模型

@mubaraqabba 用五天（#100DaysOfSolana 的第 92–97 天）搭了一个管理 Solana devnet 钱包的自主 Agent。它的价值不在"能转账"，而在于作者敢让它无人值守地跑——而这份信任几乎与模型无关。

系统只有五个部件：Agent 循环（调模型、执行工具调用、回填结果，直到模型停止或碰到 MAX_TURNS）、余额工具 get_balance（只读）、转账工具 transfer_sol（有副作用）、一个暴露 vault 程序的 MCP server（旁路组件），以及核心——策略引擎 policy.mjs。

策略层的设计只有一条铁律：默认拒绝。checkPolicy() 依次检查三条，全部通过才返回允许；只要有一条反对，就返回 {allowed: false, reason}：

1. 收款人白名单：只有 POLICY.allowedRecipients 里的地址能收钱；
2. 单笔上限：任何一笔转账不得超过 maxLamportsPerTransfer；
3. 单次运行上限：一次运行的总支出不得超过 maxLamportsPerRun（在每笔确认后累加）。

签名函数只在策略返回允许之后才会被调用——代码里不存在"被拒绝的转账碰到私钥"的路径。而且拒绝不是异常，而是 Agent 能理解的正常工具结果：

{"status": "denied", "reason": "200000000 lamports exceeds the per-transfer cap of 50000000"}

工具描述里写得很明白："A denial is not an error: adjust your plan or stop."（拒绝不是错误：调整你的计划，或者停下。）

Trial 1：目标达成

目标是"让储蓄钱包至少持有 0.2 SOL"，不给了步骤。Agent 先读储蓄钱包（空）→ 读运营钱包（4.44 SOL，够）→ 计算出精确缺口 0.2 SOL → 过策略（白名单、单笔、单次全部通过）→ 签名、链上确认 → 再分别核验两个钱包余额。6 轮、5 次工具调用、1 笔转账、0 次拒绝，报告与链上事实一致。

Trial 2：单笔上限不是限额

把目标改成 0.4 SOL、单笔上限收紧到 0.05 SOL 后，Agent 的第一笔 0.2 SOL 被拒——然后它把大额拆成了一串 0.05 SOL 的小额转账，全部通过，最终转出 0.45 SOL（超出 0.4 的目标），还在写完最终报告之前撞上了 MAX_TURNS。

这条经验值得所有做 Agent 支付的人记下来：单笔上限是限速，不是限额。它改变的是 Agent 怎么花，不是花不花；只有"单次运行上限"能约束总支出。配套的另外三条经验：

• 确认延迟是真实的：模型在上一笔还没最终确认时读了余额，看到数字不够又补了一笔，超支 0.05；不告诉它"写入可能尚未结算"，它就会把每次读取当最终结果。
• MAX_TURNS 是硬停，不是优雅停：生产环境应该把最后一轮留给"强制汇报"。
• 非确定性是环境，不是 bug：同一个目标跑两次，第一次 6 轮 1 笔转账、第二次 3 轮 0 笔（目标已达成）——两次都对。这不靠"修模型"解决，而靠"无论模型走哪条路，策略都成立"。

最后，这个策略模块与模型、提示词完全无关，可以整体移植——这才是你真正信任的那部分。

三、执行前：静态规则抓不住"坏判断"

策略层管住了"能不能付"，但 DeFi 里还有一类更隐蔽的问题：这笔操作本身是否合理。

2026 年 9 月 9 日，Aave 上线官方 MCP server（https://mcp.aave.com，无需 API key），暴露 V3/V4 数据与构建交易的工具：supply、borrow、withdraw、repay、抵押品管理、代币兑换，以及头寸、利率、健康因子等读取。关键设计是——它只返回未签名交易或 typed data，不持有任何私钥，授权与签名完全交给钱包。

10 月 9 日，MetaMask 的 Agent Wallet 接入：由钱包按用户自定义规则授权并提交，包括花费上限、协议限制、Guard Mode 与 Beast Mode 两档策略，外加交易模拟、Blockaid 威胁扫描与 MEV 保护。

分工干净，但作者点出了没人补上的缝：

字节判断但它离清算只有一个价格 wick 的距离

模拟回答"它会不会执行"，Blockaid 回答"它是不是攻击"，上限回答"它够不够小"——没有一个回答"这条指令本身是否合理"。

作者在 10 月 10 日做了一次线上测试：把两条形如 Aave MCP 指令的操作送进一个"决策门"（分档：≥0.80 自动签、0.50–0.79 挂起等人审、<0.50 升级）：

诚实的结论：这个未校准的启发式（local-heuristic-v1, calibrated=false）把两条都拦下了——fail-closed 是安全的，但没有区分度。它分不出"逼近清算线的借款"和"无害的利率查询"。作者的判断是：校准过的判断层，才应该放在"准备交易"和"签名"之间——恰好就是当前集成留下的那道缝。

他给的 DIY 路径是五步：先只读接入（确认数据形状）→ 锁钱包规则（上限、协议限定 Aave、Guard Mode）→ 每笔未签名交易先打分 → 按档处理（自动 / 挂起 / 升级并记录）→ 留决策账本（指令、置信度、档位、动作、时间）。并附了一条最保守的原则：永远不要仅凭静态规则自动签署 MCP 生成的未签名交易。（披露：作者即该决策门服务的运营方。）

四、交付后：把"验收"写成合约，再付款

Agent 之间的第三层问题更现实：活干完了，谁来判定"够不够好、值不值得付钱"？ 买家自己判，他可以随便拒付；平台判，2 美元的任务要排队；测试判，只适用于有明确规格的代码。

作者最近在 Verdikta Bounties 提交作品，认为它把"验收"这件事变成了一条可以自动执行的流水线：

1. 发布者把 ETH 锁进 Base 上的托管合约，合约没有取消和编辑函数——一旦开始干活，条款就不能再动；
2. 任务附带一份 rubric（评分细则）：加权标准、部分标准标为硬门槛（must）、一个通过阈值；
3. 提交由不同模型的陪审团评分（他参与的任务用 OpenAI + Anthropic 模型各占 50%），评分理由存到 IPFS；
4. 达到阈值，合约自动付款；不到，就一分不付。

rubric 本身就是一段 JSON：

{
  "id": "concrete-example",
  "description": "引用一个具体、真实的结果，而不是泛泛而谈。",
  "weight": 0.25,
  "must": false
}

把 must 翻成 true，这条标准就变成硬门槛：达不到，权重再高也没用。

真实任务的表现很有说服力：

• Bounty #190 要求"找出每个部门第二高薪水的 SQL"，阈值 88；只有一份提交，陪审团打了 98，直接付款——没有评审会、没有发票、没有"我回头再看"；
• Bounty #182 要求"自主 AI DAO 的高层设计方案"，阈值 95；七份提交得分在 83–93 之间——按大多数标准都算不错的作品——全部没有通过，直到有人拿到 96 才付款。对付款方而言，门槛不可协商，正是想要的效果；
• 作者自己在一份营销任务上以 91 分越过 88 的门槛；不过他最初的几次提交根本没被评分——oracle 超时，只能重交。基础设施还年轻。

对 Agent 建设者的意义：把"人类猎人"换成"Agent"，这就是 Agent 市场缺的那块原语——买卖双方互不信任对方的判断，但共同信任一份事先公示的细则和一个多模型陪审团；猎人预付少量评审费，刷单不再免费；还提供 agents.txt 与 API，Agent 可以自己找任务、提交、结算，全程不开浏览器。它替代不了有明确规格时的单元测试，但覆盖了"好不好是一个判断"的那一大类工作。

五、三层拼起来：一张 Agent 支付的控制图

对建设者有几条直接可用的推论：

1. "能付钱"只是第一天的事。 第一次调用之后，买家会看交付质量、结算一致性和复购理由——设计第二次调用，而不是设计又一个收款端点；
2. 策略必须写在代码里，不能写在提示词里。 模型可以换、提示词可以改、工具调用顺序每次不同——只有确定性的策略层拿同样的输入永远给同样的答案；
3. 单笔限额是限速，运行限额才是限额。 Trial 2 的四笔拆分是复盘 Agent 成本的经典样本；
4. 判断层要有区分度。 全都挂起等于没有判断；校准的目标是让"借款逼近清算线"和"查一个利率"落到不同的档；
5. 验收规则要前置且不可改。 阈值写在开工之前、锁在合约里，付款才不需要再谈判。

对交易者与持有者：本文不构成投资建议。Aave 的 95% LTV 案例是一个风险演示，用来说明"通过所有检查"不等于"操作合理"；文中所有产品与数据均来自公开来源，作者测试均在 devnet 或小额样本上完成，存在样本偏差、服务方自测偏差与时效性问题，请自行核查并 DYOR。

原文链接

• @terminator_agent, The x402 bottleneck isn't buyers. It's the second call.（dev.to，2026-10-14）：https://dev.to/terminator_agent/the-x402-bottleneck-isnt-buyers-its-the-second-call-5dm9
• @mubaraqabba, From Prompt to Policy: How I Made a Solana Agent Safe Enough to Run Unattended（dev.to，2026-10-10）：https://dev.to/mubaraqabba/from-prompt-to-policy-how-i-made-a-solana-agent-safe-enough-to-run-unattended-1kd2
• @scriptmasterlabs01, The Aave MCP Prepares, the Agent Wallet Signs — But Who Judges?（dev.to，2026-10-10；canonical：https://scriptmasterlabs.com/aave-mcp-metamask-agent-wallet）：https://dev.to/scriptmasterlabs01/the-aave-mcp-prepares-the-agent-wallet-signs-but-who-judges-56j9
• @kurumi, Your AI agent finished the task. Who decides if it's good enough to pay for?（dev.to，2026-10-15）：https://dev.to/kurumi_82661ed12516efd1f7/your-ai-agent-finished-the-task-who-decides-if-its-good-enough-to-pay-for-4b5l
• Aave 官方 MCP server：https://mcp.aave.com

相关阅读

• x402 数据打假：AI Agent 一年支付 1.38 亿笔，但一半可能是刷量
• Agent 支付协议对比 2026：x402、AP2、MPP、ACP 到底有什么不一样
• 量化研究 Agent 化：Jump Trading 的 autoresearch 与本地 MCP 工具链
• 用 Claude Code 做加密交易：工作流、工具与风险边界
• 专题：Agent 支付 / x402 与稳定币支付完全指南

本文由 DefiPlot 翻译整理，转载请注明出处。

免责声明

本文仅用于学习与研究目的，不构成任何投资建议、财务建议或交易建议。文中数据、基准与产品能力描述均来自公开来源并已标注作者与口径，可能存在作者自测偏差、单一样本偏差与时效性问题；请自行核查并 DYOR（Do Your Own Research）。加密资产价格波动剧烈，DeFi 操作存在清算、合约与授权风险，任何策略与自动化均需自行评估并保留人工复核。

本文属于「Agent 支付 / x402」专题。查看专题全部文章 →

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。