解析 AI agent 真实支出：链上数据揭示智能体只需要这些 API

有一个 marketplace，AI Agent 会用稳定币为 API 调用付费。这里大约有 14,800 个 listing，分布在 1,062 个卖家钱包中，而且每个 listing 都会公开收款地址。

这意味着需求数据是公开的，谁都不必靠猜。

我遍历了整个 catalogue，提取出每个卖家的 payTo 地址，并读取了这些地址在 Base 上收到 USDC 的记录。下面就是 Agent 真正在购买的东西——而且并不是大多数人正在构建的那些产品。

我对 catalogue 规模最大的卖家进行了抽样，并按不同付款钱包的数量排序：

再读一遍这份列表。几乎全是乏味但通用的工具：地理编码、天气、搜索、随机数。它们是程序为了完成任务所需要的东西，而不是 crypto-native 受众想当然地认为链上 Agent 会需要的东西。

唯一真正获得市场采用、且与 crypto 沾边的产品，是 gas prices——而它其实也可以算作一种工具。它回答的是“现在哪条链最便宜”，这是一个路由决策，而不是交易决策。

我运营着一个多链 DEX 数据 API，提供价格、流动性、池子储备、路由、滑点以及跨市场套利数据——覆盖六条链，共有 43 个付费 endpoint，并且全部收录在同一个 marketplace 中。

真正的第三方查询，累计至今：实际上为零。

这并不是质量问题。所有 endpoint 都是正确的，我也有记录可以证明。问题在于需求：这个市场里进行交易的 Agent 并不需要 DEX 数据。我为一个自己想象中存在的受众打造了产品。

数字小得惊人，而这一点很重要

在我抽样的时间窗口内，排名第一的卖家拥有 56 个不同的付款方，总收入却只有 0.70 美元。我找到的单个卖家最高收入是 6.10 美元，提供的是文生图服务。

这是一个真实的市场，有真实、重复且并非伪造的付款。但它同时也是一个以不到一美分为单位的市场。任何告诉你 Agent 支付眼下正值淘金热的人，都没有真正去读链上数据。

它在实践中意味着：在交易量到来时，能否持续在线并正确运行，比如何定价更重要。每次调用收费 0.001～0.01 美元时，收一美分还是两美分之间的差异只是噪声。真正决定一切的，是产品能不能正常工作。

我两次掉进去的衡量陷阱

有两个数字差点把我引向错误的方向，而且它们看上去都非常权威。

首先，我自己的 dashboard 显示，大约有 8,762 个“Agent 触发了 paywall”。我基于这个数字制定了好几周的产品策略。直到最后正确地对 ledger 进行分类，我才发现：其中 82.7% 是我自己的监控请求，17.3% 是 catalogue crawler，它们会在不带 query string 的情况下遍历每条 route；真正的第三方查询为零。总共有 39 个不同的 user-agent，其中 37 个从未发送过任何参数。被收录，并不等于有人在选购。

其次，在写这篇文章时，我的 ledger 显示出现了 4 次自然结算——看起来是这个项目有史以来获得的第一笔收入。但它们并不是真的。只要请求中存在 payment-signature header，ledger 就会写入一条已付款记录，却从未检查结算是否成功。这四条记录的 transaction hash 都是 null，上游响应均为 4xx，而且根本没有任何 USDC 到账。header 只是一项付款声明，不是付款本身。

这两个 bug 有着相同的形态：HTTP 200、看似合理的数字、完全错误的结果。只断言 status code 和 response shape 的测试无法发现其中任何一个问题。现在，我会对数值量级进行断言，并通过不同来源交叉核验——这个数字是否能与另一个独立衡量同一件事的数据源相互印证？

discovery API 是公开的，不需要 key：

https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=100&offset=0

对它进行分页，收集每个 listing 中的 accepts[].payTo，然后读取 Base 上的 USDC Transfer log，将该地址作为收款方 topic。还要过滤掉自己向自己付款的记录——卖家为自己的 listing 预先制造交易很常见，但那并不代表真实需求。

有两个坑浪费了我不少时间：/resources endpoint 返回的字段是 items，而 /merchant 返回的是 resources。如果默默假设二者的数据结构相同，就会从 14,800 个 listing 中得到零个卖家。另外，大多数公共 Base RPC 会将 eth_getLogs 限制在最多 10,000 个区块的范围内，或者在没有付费 archive tier 的情况下完全拒绝日志查询。

有一项功能，我做完后又删掉了：category rollup。它显示每个类别都有 150～186 个付款方——地理位置、DEX、天气、体育，各类别之间的差异都在 20% 以内。这并不代表需求均匀，而是数据造成的假象：那些运营着 100～1,200 个 listing 的卖家会匹配到每一个关键词分类，并在每个分类中被统计一次。按 listing 进行归因可以解决这个问题，但链上只会显示款项支付给了哪个钱包，不会显示支付给了哪条 route——因此，这份数据里根本不存在这种归因信息。我宁愿删掉这个数字，也不愿把它发布出去。

我准备怎么做

去构建那些工具。研究结果表明，地理编码、内容提取、随机数和搜索如今已经有付费客户，而我的 DEX endpoint 没有。与这个事实争辩，代价会很高。

DEX 基础设施会继续保留——它是正确的，运行成本也很低，而且已经提前占据了位置，随时等待相关需求出现。但我接下来发布的产品，会是链上收款记录表明确实有人想要的东西。

如果你正在为 Agent 构建产品：动手之前，先读一读收款记录。数据就在那里，而且它讲述的事实与流行叙事并不一致。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。