Collection is not Callability: PubFi 为什么要为 AI Agent 建立可信的 Crypto Data Gateway

不是每个 API 都应该被 Agent 调用

Collection is not Callability: PubFi 为什么要为 AI Agent 建立可信的 crypto data gateway

AI Agent 真正接入外部世界以后，一个问题会变得越来越重要：当 agent 需要一条链上数据时，它到底应该调用谁？

比如它想查一个钱包余额、一个 token price、一组 governance proposals，或者某条链上的交易活动。表面看，这只是找一个 API。实际上一点也不简单。

Crypto data 的问题不是没有数据源，而是数据源太多了。Subscan、DeFiLlama、CoinGecko、Alchemy、QuickNode、Dune、Covalent、Bitquery、The Graph 这些名字对开发者并不陌生。问题在于，每个 provider 都有自己的文档、鉴权方式、价格、限额、返回结构、覆盖范围和数据新鲜度。

人类开发者可以慢慢读文档、申请 key、试接口、看返回、做 fallback。但 agent 不应该每次都重新完成这套判断。

PubFi 的切入点就在这里。它不是再做一个 API 大全，也不是给每个 provider 包一层看起来很酷的 tool。PubFi 真正关心的是：一个数据源从“被发现”到“可被 agent 安全调用”，中间到底缺了哪些证据。

一句话概括：Collection is not Callability。收集到，不等于可调用。

API 目录解决不了 Agent 的运行时问题

传统 API directory 关心的是“有没有”。有没有文档、有没有 endpoint、有没有 pricing page、有没有 SDK、有没有 status page。

这些当然有价值。但对 agent 来说，还不够。

Agent 的问题不是“世界上是否存在某个 API”。它的问题是：

这个 API 现在能不能被我调用？
调用它需要什么 key？
当前用户是否有权限？
是否会产生费用？
返回的数据是否足够新？
这个 provider 是否真的覆盖我要的 chain 和 data type？
如果失败，系统如何解释？
如果调用成功，谁来记录这次调用发生过？

一个 API 被发现，只说明它存在。一个文档被解析，只说明它有接口描述。一个 provider 进入 corpus，只说明它有公共信息价值。这些都不能自动推出“它现在可以被 agent 调用”。

从 collected candidate 到 callable route，中间还隔着 credential、policy、freshness、adapter certification、usage accounting 和 claim safety。

这就是 PubFi 和普通 API directory 的区别。普通目录把“存在”当成终点；PubFi 把“存在”当成起点。

PubFi 的三层结构

理解 PubFi，可以先把它拆成三层：Discovery、Gateway、Route Intelligence。

Discovery 是入口。

它面向人类、搜索引擎、answer engine 和 AI agent。这里有 source pages、category hubs、chain hubs、comparison pages，也有 llms.txt、agents.md、Markdown mirrors 和 OpenAPI exports。

但 Discovery 不只是 SEO。它更像需求传感器。当有人搜索 “MCP crypto data API”、“x402 crypto data API”、“Subscan vs SubSquid”、“Polkadot data API” 时，这些 query 不只是流量入口，也是在告诉 PubFi：市场正在问什么，哪些数据源需要被解释，哪些能力缺口值得进入下一步。

Gateway 是出口。

如果一个 route 真的可以调用，它应该通过 gateway 被调用。Gateway 负责 API key、credit、provider adapter、upstream credential injection、response normalization 和 usage facts。

这意味着 PubFi 不只是把请求转发给上游。它要知道谁在调用、有没有权限、消耗了什么、上游返回了什么状态、这次调用如何被记录。

Route Intelligence 是中间的判断层。

Agent 通常不会说“请调用 provider X 的 endpoint Y”。它更可能说：“给我 BTC spot price”“查一下这个钱包的 token balances”“我要某个治理提案的数据”。

Route Intelligence 要把这种自然语言需求变成结构化 intent，然后找候选、过滤、排名，最后决定：现在是否有可调用 route；是否需要更多信息；是否只能记录一个 demand signal；是否应该进入 procurement review；是否应该拒绝调用。

真正困难的是知道什么时候不该调用

很多 agent 产品会把“智能路由”讲成一个模型能力：把用户问题丢给 embedding、reranker 或 LLM，然后选一个最像的 API。

但真实系统里，语义相似远远不够。

一个 provider 的文档和用户需求很像，不代表它有可用 credential。一个 endpoint 名字看起来正确，不代表它覆盖目标 network。一个 route 在 corpus 里出现，不代表它已经通过 adapter certification。一个 API 支持付费调用，不代表系统可以自动采购或支付。一个页面写了 MCP 或 x402，不代表今天就有 live MCP tool 或 live x402 payment execution。

所以 PubFi 的 route intelligence 不是让模型自由发挥。它的顺序应该是：

先规范化需求；
再找候选；
先跑 hard filters；
再做 ranking；
模型分数只能作为透明输入；
证据不足时必须 abstain。

这是一种很基础但很重要的工程伦理：不能因为 agent 想要答案，系统就假装自己有能力。

在 agent infrastructure 里，错误的 available 比普通网页上的夸张文案危险得多。因为 agent 可能真的会拿它去调用、花钱、生成判断，甚至触发下一个自动流程。

Growth Loop：把“不能调用”变成下一步

如果一个 route 现在不能调用，PubFi 不应该只是失败。它可以把失败变成产品信号。

这就是 Gateway Growth Loop 的意义：外部 API discovery、docs parsing、API corpus、integration candidate queue、adapter certification、keyword growth、SEO/GEO recommendations、issue outbox。

一个 API 被发现，先只是 collected candidate。文档解析成功，变成 endpoint facts。进入 corpus，成为 public-safe profile evidence。进入 candidate queue，才可能被评估是否值得做 adapter。通过 certification，才有机会 runtime enabled。最后，在 credential、auth、usage、claim safety 都成立时，才可能被称为 gateway available。

这条路径很克制。它没有把“收集”包装成“能力”，也没有把“研究原型”包装成“生产可用”。

PubFi 文档里反复出现类似的边界：

corpus inclusion 不是 gateway availability；
crawler hit 不是 AI citation；
llms.txt 不是 agent callability；
x402 sandbox proof 不是 live payment execution；
source page 存在，不代表 PubFi 可以调用这个 source；
candidate queue 里的 provider，不代表已经被采购或授权。

这些句子看起来像限制，实际上是产品可信度的来源。

为什么这件事在 AI Agent 时代重要

Model Context Protocol 这类标准正在让 AI 应用更容易连接外部数据、工具和工作流。官方介绍见：https://modelcontextprotocol.io/docs/getting-started/intro

x402 这类协议则把 machine-to-machine payment 和 HTTP 402 重新带回讨论中心。官方网站见：https://www.x402.org/

这些趋势会让 agent 更容易调用外部系统，也会放大一个老问题：谁来判断一次调用是否真的安全、授权、可计量、可解释？

在传统应用里，API integration 通常由开发者完成。开发者会判断接口是否靠谱，key 是否有效，价格是否合理，失败是否可恢复。

但 agent-native 应用会把这些判断往运行时推。Agent 可能临时决定需要某类数据；可能要在多个 provider 之间选择；可能要根据成本、延迟、新鲜度、权限做权衡；也可能在证据不足时选择不调用。

这时，一个普通 API directory 就不够了。Agent 需要的是一个能表达“可发现、可解释、可调用、可拒绝、可审计”的数据层。

PubFi 要卖的不是“更多 API”

如果只看表层，PubFi 像是 crypto data gateway。但更准确地说，它在做的是 agent 时代的数据可信层。

这个可信层包括几件事：

让 agent 能发现数据源；
让 agent 能理解哪些数据源适合什么问题；
让真正可用的 route 通过统一 gateway 调用；
让每次调用留下 usage facts；
让不可调用的需求进入 demand 或 procurement 流程；
让 public claim 不超过真实能力。

这比“我们支持 100 个 provider”更难，也更有价值。

因为 AI Agent 时代的信息获取会变得越来越便宜。真正稀缺的是判断：什么可以信，什么可以调，什么应该停下来。

PubFi 的产品气质就在这里。它不是急着告诉你所有东西都能用，而是认真区分 found、documented、requestable、contract ready、gateway available、not supported。每个状态都有价值，但不能互相冒充。