当 crypto agent 跟不上链 — — 从一组数据 bug 说起

我们在 2026–04 跑了一轮对照测试：用主流某 GraphQL 数据 provider 的 Solana 接口拉 15 笔 DEX 交易的 Buy/Sell 标记，15 笔全错。这不是边缘情况 — — 是 schema 在源头把方向标反了，下游所有跟单类 agent 都会拿到一个镜像版本的世界。

这份报告讲三件事：crypto agent 跟不上链的真正瓶颈在哪里、我们在主流数据服务上看到的那些被忽略的硬伤、以及 ChainStream 给出的工程答案。

一、场景：一个跟单 agent 为什么会反向交易

去年底有个团队找我们，他们在做一个 smart money 跟单 agent。要做的事很直观：盯住一组高胜率钱包，在它们下单后 30 秒内跟上同样的方向。Testnet 上跑得很顺，搬到 Solana 主网，第二周开始出现一类奇怪的亏损 — — agent 经常在 smart money 卖出时跟着买入，反过来也是。

我们帮他们拆链路。Agent 自身的状态机没问题，决策逻辑也对。问题出在它订阅的数据源 — — 某主流 GraphQL provider 的 Solana DEX Trade 接口。我们抽样跑了 15 笔已知方向的真实成交，对账下来 15 笔 Buy/Sell 标记全错。Provider 的 schema 在源头把 in/out 两端的语义对调了，对 EVM 系列链能蒙混过去，到 Solana 的 AMM 结构上就完全反掉。

这种 bug 对人类分析师不致命 — — 分析师看图表会用其他信号校验。对 agent 致命，因为 agent 没有”其他信号”，它就是按 schema 字面意思在做决策。一条结构性反向的 schema，等于给 agent 装了一个反向的世界。

这个团队后来切到我们的实时数据订阅，重跑同一套逻辑，方向问题消失。但他们花在排查上的两周才是真实成本 — — 不是 agent 框架的成本，是上一代数据基建的债。

二、那些被忽略的数据硬伤

Solana Buy/Sell 全错只是其中一项。2026 年 Q1 我们对几家主流 crypto 数据服务做了一轮系统对账，下面几条是我们觉得最值得 agent 团队留意的：

• Token Symbol 覆盖率只有约 30%，其余 70% 直接返回空或合约地址

• Block.Time 字段在某段历史区间整段 null，跨度差不多有 11 天

• Changelog 真空近两个月 — — schema 改了不通知调用方

• 可查询历史深度只有 3.66 天，几乎跑不了任何像样的回测

• 多 cube join 在跨链查询时会静默丢行，没有任何错误返回

• 部分主流端点对 token-level 拆分查询会直接 P0 崩溃

这些 bug 单独看每一条都”可绕开”。叠起来看是另一件事 — — 它们共同定义了一个事实：现有的链上数据服务是为”给人类分析师看图表”设计的，不是为”给 agent 当 state machine 输入”设计的。

这两套目标在容错策略上的差别巨大。人类看到 Token Symbol 缺失会自己去 Solscan 查一下，agent 拿到空字段就直接当成”无 symbol token”做决策。人类看到 Block.Time null 会跳过那段时间，agent 不会，它会把 null 当 0 算到时间序列里。

要让 agent 跑起来，要么 agent 团队自己背 schema 修复的活，要么数据团队从底层重做。我们押的是后者。

三、ChainStream 的解法

我们把 ChainStream 在 2026 年初重构成了一套清晰的分层结构 — — 从底向上分别是数据采集、数据智能、风控、智能执行、支付结算。这是我们对”data 怎么交付给 agent”这件事的工程答案。

最直接的结果是 agent 代码的塌缩。前面那个跟单团队，原本他们自己写 indexer、写 diff 逻辑、写方向校验、写 fallback — — 大几千行。切到我们这边之后，整个跟单逻辑核心压到 200 多行，因为方向、symbol、时间、smart money 标记这些都已经在数据侧处理掉了。

接口层我们也按这个理念做。Agent 接进来的方式不是”让 agent 写 SQL”，是 agent 描述意图，背后由我们做 query 拼装、自动重试、结果解释。Agent 拿到的是 JSON，但走的是一条已经被多次校验过的路径。

四、我们围绕这一层做了什么业务

围绕这套数据层，我们已经在客户侧跑通几类场景：

• 早期 alpha 发现：把新合约部署、早期资金集中度、smart money 首次接触这几类事件复合成一条候选流，agent 在上面做二次过滤和告警

• 跟单类 agent：除了方向 / symbol 这种基础正确性，我们更看重把行为的因果上下文带出来 — — 同样是 smart money 买入，是在追 narrative、在 rebalance、还是被某个 oracle 触发，决定了 agent 该不该跟

• 组合风险监控：把若干钱包当成一个组合做风险监控，触发条件包括合约风险评分变化、流动性骤降、跨链桥接异常 — — 这是 fund / family office 类客户最先要的能力

这些都不是 demo，是已经在客户侧跑的形态。我们之所以把它们公开讲，是想让生态里要做 agent 的团队知道：你不一定要自己重做数据层；订阅其中一类，先把业务跑起来。

五、为什么我们做数据，而不是做 agent

2026 年 3 月我们做过一个对外定位的决策 — — 把 ChainStream 收口在”数据服务”，而不是”agent 平台”。内部当时有不同意见。后者听上去更新更性感，前者在今天的叙事里像上一代。

我们最终落地在前者，理由很工程。Agent 这层的形态还在快速变 — — 半年前所有人都在做 ReAct，现在又转回 explicit state machine；半年前主流是 multi-agent，现在又回到单 agent + 强工具。在 agent 形态没稳定下来之前，把自己的产品收口在”我是某种 agent 平台”会被形态绑架。

数据层不一样。无论 agent 形态怎么变，它对数据的要求是收敛的：实时、有语义、可订阅、可重放、可回测。这五件事在未来三年都不会变。把这五件事做扎实，agent 团队不管选哪条技术路线，都能在上面接出来。

我们的 bet 是：crypto agent 这一波的赢家不会是数据公司，但赢家几乎都会用到底层的某家数据服务。比起争”谁是赢家”，把”赢家都需要的输入”做对，长期回报更稳。

六、判断：这一波 agent 落地的胜负手在数据层

过去 18 个月行业里大量努力堆在 agent 层 — — 更好的 planner、更长的上下文、更聪明的 tool calling。这些是有价值的，但它们解决的不是 crypto agent 在主网上跑不动的核心问题。

核心问题在更下面两层。底层决定 agent 能不能在毫秒级看到链上正在发生的事，再上一层决定它看到的事是不是带正确语义。这两层不做好，再聪明的 planner 也只是在错误数据上做精致推理。

我们做 ChainStream 的赌注就是这个：crypto agent 这一波落地的胜负手在数据层，不在模型层。这个判断对错，未来会被链上数据基建公司的洗牌结果验证。

结尾

接下来 12 个月值得观察的，不是哪个 agent 框架名字更响，而是 crypto 数据基建会不会有人把摄取 + 语义这两层重做一遍。这件事不发生，所有跑在它上面的 agent 都会继承同一套错位的世界观。

如果你正在搭一个 crypto agent，三条问题可以做自检：

1. 你 agent 拿到的 Buy/Sell / amount / symbol / time 字段，是源头打标好的，还是你自己在 LLM 层 diff 出来的？

2. 你的数据源 schema 上次改动是什么时候，你是怎么知道的？

3. 你最坏一次因为数据 bug 反向交易，损失了多少？

这三个答案，比”用哪个 agent 框架”更决定你能不能跑到主网第二个月。

ChainStream — AI-native crypto infra。我们做实时 on-chain 数据 + agent 执行层，让 agent 能把链上事件当作 state machine 的输入。