AI Agents 不止会查询子图，还会创建子图

AI Agent 并不总能从现有数据集中找到所需的区块链数据。如果它们能检查合约、生成并部署自己的 subgraph，然后自行继续调查呢？

Subgraph 通常围绕一组已知的合约和查询来构建。在部署之前，需要有人决定索引什么、如何表示，以及可通过 GraphQL 查询的数据。

协议可以做一些细微调整，比如添加合约，或者前端可以添加字段，但数据模型很大程度上在应用开始使用之前就已经设计好了。

但 AI Agent 引入了一种更难以预测的数据访问方式。一个负责风险分析、调查异常 USDC 活动的 Agent，可能从转账量开始，然后追踪几个钱包进入借贷市场，最后查找原始数据集中从未包含的头寸或交易。它下一步需要什么取决于它发现了什么。

在某些情况下，可能没有现成的 subgraph 包含正确的合约、历史和关系。

目前的开发方式要求有人预先定义所需的数据。这意味着需要找到相关合约，检查它们的事件和 ABI，决定可以重建哪些状态，编写 schema 和 mappings，部署 subgraph，并等待所需的历史数据完成索引。

没有明显的理由表明这个流程必须完全由人工完成。

一个能够检查合约并编写代码的 Agent，同样可以生成自己所需的 subgraph，部署它，查询结果，并在工作完成后将其丢弃。

Subgraph 仍然可以支持长期运行的应用程序，但它们也可以为那些只有在调查开始后才逐渐清晰的问题而创建。

现有的 Schema 只能帮 Agent 走到这一步

让 AI Agent 能够访问 subgraph 已经很有用。GraphQL 为它们提供了可检查的结构化 schema，以及定义良好的实体和关系。MCP 和类似的工具让向 Agent 开放这些能力变得更加容易。

目前的限制是所需的数据不在 schema 中。

考虑一个针对以太坊上 USDC 转账增加的调查。转账历史可能回答第一个问题。Pool 数据也可能有助于判断流动性是否也在同步变动，钱包活动则可能指向借贷市场或其他协议。

在这种情况下，调查很可能会超出最初可用数据集的边界。

工程师可以修补这个问题，但每一次交接都会打断 Agent 的工作。如果每个新的数据需求最终都变成一张工程工单，自主系统的自主性就会大打折扣。

允许 Agent 创建缺失的数据集，是 subgraph 现有能力的自然延伸。

Subgraph 描述了哪些合约重要、应该处理哪些事件、这些事件如何改变存储的实体，以及如何查询生成的数据。这些定义大部分以结构化代码和配置来表达。

一个能够读取 ABI 的 Agent 可以识别相关事件，确定需要哪些实体，生成 schema 和 mappings，并提交部署。一旦请求的区块范围索引完成，Agent 就可以根据结果继续工作。

Agent 带来更难以预测的数据需求

应用程序开发者通常知道他们的产品会进行哪些主要查询。而 Agent 可能要等到当前查询返回后才知道下一个查询是什么。

交易调查可以说明这种差异。交易量升高可能导致对流动性的进一步审视。同样，流动性下降可能导致 LP 提款。几笔大额提款也可能指向一组钱包。这些钱包可能在别处有头寸，可以解释这些活动。

除非调查进行到那一步，否则这些后续数据集都不必存在。

预先索引所有可能的合约和关系组合会浪费存储和计算资源。而且也不可能预判 Agent 可能采取的每一个方向。

在需要时创建数据更适合这类工作。

协议状态、转账、Pool、头寸和其他高频使用的数据集更适合持续维护。Agent 工作负载只是增加了另一个类别：为特定任务创建、仅在有用期间保留的数据集。

为一个调查创建的 subgraph 可能在一小时后就不再重要，而另一个 subgraph 可能恰好回答了一个常见问题，从而保持在线。

使用情况可以决定哪些数据集值得保留。

编写 Subgraph 只是问题的一部分

与判断结果是否可信相比，生成 schema 和 mappings 相对简单直接。

合约并不总是发出重建其状态所需的全部信息。历史查询可能依赖于合约调用和事件。代理升级可能在请求的区块范围中途改变行为，重组也需要正确处理。一个看似微小的 schema 变更可能需要一次完整的历史重新索引。

回填所需的时间也很重要。如果一个 Agent 提出的问题只对接下来十分钟有意义，那么一个需要六小时构建的数据集对它来说几乎没有价值。

这些问题对手动构建 subgraph 的开发者来说已经存在。Agent 生成的部署使这些问题更加重要，因为可能没有工程师会足够密切地关注任务，及时找出错误的假设。

当另一个自动化系统使用这些结果时，影响也会不同。

因此，Agent 创建的 subgraph 需要对生成的代码及其产生的数据进行严格检查。索引状态、错误、链进度、源合约和部署版本都需要以软件可以解析的形式提供。

Agent 还需要知道数据来自哪里

缺少来源信息的结果，对自主系统来说很难评估。

如果 Agent 收到了稳定币流入的数据，它应该能够确定哪些合约被索引、覆盖了哪些区块范围、索引的新鲜度如何，以及应用了哪些转换。

来源信息必须随数据一起传递。

对于生成的 subgraph，这可能包括源链、合约地址、已处理的事件、已索引的区块范围、当前索引头、schema 版本、mapping 版本，以及计算中使用的任何外部数据。

面向 Agent 的按需区块链数据

当数据模型已知且相同的数据需要随时间保持索引时，Subgraph 仍然有意义。协议状态、头寸、转账、Pool 和其他生产数据集都受益于这种结构得到定义并持续维护。

更困难的问题是，当 Agent 需要没有人预先准备的数据时会发生什么。

在 Ormi，我们正在研究可以按需请求的区块链数据。并不要求在任务开始前每个数据集都已存在，Agent 可以请求它需要的数据，让相关合约和历史得到处理，然后根据结果继续工作。如果该数据集在原始任务之外变得有用，它可以保持可用，而不是每次都要重新构建。

这并不会取代 subgraph。它把同样的理念扩展到那些在工作进行中才发现数据需求的工作负载。

Subgraph 为应用程序提供了持久、可编程的区块链数据视图。按需数据为 Agent 提供了一种在现有视图不够用时创建新视图的方式。

我们正在同时推进这两方面的工作，未来还有更多内容。

• 原文链接： blog.ormilabs.com/ai-age...
• 鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～