项目起源

AgentQL 起源于 Tomo 内部反复出现的一个产品问题：无论是做加密应用，还是做 agent workflow，团队通常都会先需要链上读取、市场数据和实时流，但这条接入路径往往被拆散在多个不同 provider 和不同入口里。

与其把这些能力继续当作彼此割裂的基础设施采购项，AgentQL 更希望把第一批真正有用的公开能力收敛成一条产品路径，让它更容易解释、验证和接入。

项目背景

在真实的加密产品场景里，早期需求通常不会只停留在 RPC，或者只停留在 market data。团队往往很快就会同时需要链上读取、市场上下文和某种实时更新能力，才能支持监控、报价、研究、执行辅助或 agent 应用。

这也意味着如果依赖多套分散 provider，就很容易出现 contract 不一致、鉴权模型不一致、运维成本重复以及联调排障范围过大的问题，而第一条接入路径本来不该这么复杂。

AgentQL 刻意把公开故事保持得足够窄：先把最先会被用到的数据与传输方式做好，而不是在基础接入路径还不稳定时，先对外包装成一个过宽的平台。

产品围绕一个可理解的公开入口、一个 API key 访问模型，以及一套与当前已开放托管能力一致的文档和示例来组织。

它的目标不是抽象掉所有加密工作流，而是先减少第一条有用的 market-read 与 chain-read 路径上的不必要集成成本。

当前公开站点主要围绕托管 EVM RPC、市场数据、Market WebSocket 和 RPC WebSocket 展开，并提供对应的文档、节点清单、定价页面和 Dashboard 账户入口。

这个范围有意小于一个泛化的加密平台。AgentQL 当前的扩展方式是先验证清晰的公开 contract，再在公开路径稳定且真正有用之后逐步放宽边界。