跳到主要内容

ADR-030 — DataHorizon ↔ FinBayes 数据接口分工

§0 决议简述​

决议（拟）：明确 Data Horizon（DH，生态内金融信息感知系统）与 FinBayes（金融认知 agent）在数据获取上的分工边界，使 FinBayes 的取数既享受生态内统一配置、又保留独立可达性与容错。

  • DH 负责：① 作为生态内provider 注册表 / 推荐配置源（非运行事实源）——维护 provider 元数据、凭据引用规范（不下发明文 key）、能力标签、可达性证据；推荐回退顺序与 runtime 可用性由消费方读注册表后本地合成、自持（对齐 ADR-0005 §3 与 DH provider 配置中心方向）；② 生产高价值衍生资产（私域职业信号 / 事件研判 / 跨源互证）。
  • FinBayes 负责：自持取数容错 + 缓存 + 出处信封。商品化数据（OHLCV / OI / 资金费率 / 订单簿）用 DH 管理的配置直连第三方（ccxt / vendor），不经 DH 转发；高价值资产经 DH Open API 消费。
  • 聚合 vendor（CoinAnk 等）：在 FinBayes 的弹性链里是回退源，不是默认主源；仅 ccxt 无统一接口的数据（清算）才主用 vendor。

§1 背景与根因​

FinBayes 团队真实问答暴露：一类 crypto 技术分析问题（多交易所订单簿深度）全交易所取不到数。根因不是单一故障，而是取数容错 + venue 感知这一层从未建立——可达性 / 品种 / 并发三类失败各需一种此前不存在的能力（详见 DataAcquisition 子系统设计）。

整改中浮现一个跨生态的边界问题：crypto 行情这类商品化数据该由谁取？owner 定调「整体架构、多市场，聚合源优先考虑生态内 DH」。但 DH 有差异化红线——不重复路由已商品化、第三方可自助获取的数据。两者如何不矛盾，即本 ADR 要固化的分工。

§2 决议详述​

§2.1 商品化数据：FinBayes 直连，DH 管配置​

OHLCV / OI / 资金费率 / 订单簿等已商品化、第三方 API 可自助获取的数据，不由 DH 中转（符合 DH 红线）。FinBayes 直连第三方（ccxt 各交易所、必要时 vendor），自持：

  • 弹性取数：多源重试 + 故障分类跳源（finbayes/data/acquisition.py）。
  • venue / 品种感知：进网络前跳过交易所没有的品种（finbayes/data/venues.py）。
  • 出处信封 + 缓存：每次取数带「哪来的 / 什么时点」，短 TTL 收敛同轮重复。

DH 在此处的角色是 provider 注册表 / 推荐配置源（非运行事实源）：提供「用哪些 provider、凭据引用规范（非明文 key）、被墙交易所代理出口建议、推荐回退顺序」的注册表元数据；FinBayes 读取后本地合成自己的 fallback / runtime policy 并自持取数可用性——可用性责任不外包给 DH。在 DH 暴露该注册表契约前，FinBayes 用本地静态默认（venue 模型 + 配置）兜住，不阻塞。

§2.2 高价值资产：DH 生产，FinBayes 消费​

私域职业信号 / 事件研判 / 跨源互证等 DH 差异化产出，由 DH 经 Open API 提供，FinBayes 作为消费方（沿用现有宏观 DH → FRED 消费模式扩展）。本 ADR 不改这条已有路径，仅确认它与 §2.1 的商品化直连是两条不同的数据流。2026-06-24 曾记录“DH 过渡、FinBayes 终局内化并降低 DH 依赖”的候选方向；该部分已由 ADR-033 覆盖。当前 sourcing 按 workload、rights、quality、latency、cost、resilience 与 ecosystem reuse evidence 演进，不预设 DH 用量方向。

§2.3 聚合 vendor 的定位（2026-06-22 据 CoinAnk 全貌重析）​

CoinAnk 经核实是完整的加密数据聚合站（套餐 1–4 付费，非单一报价端点）：覆盖八接口、且原生做跨交易所聚合 + 提供大量订单流 / 持仓结构信号（CVD / 主动买卖、清算地图 / 热力图、多空比、大额订单、资金流、订单流、ETF、新闻）。据此 vendor 定位按数据类别分工，非一刀切回退：

  • 商品化 + 可达（OHLCV / OI / 资金费率，ccxt 免费且能取）：ccxt 主、CoinAnk 回退。
  • ccxt 做不了 / 难做的（清算、原生跨所聚合、订单流 / CVD、清算热力图）：CoinAnk 主——这正是 ccxt 不做、且属 DH 红线「他处难自助获取、高杠杆」的类别。

范围扩展：owner（2026-06-22）拍定 crypto 数据层同步扩到 CoinAnk 这批高价值数据（八接口之外的 CVD / 订单流 / 清算热力图 / 多空比 / 大额订单等），作为「Phase 6」推进——这类数据比裸 EMA / RSI 对技术分析杠杆更高，且与 DH 差异化方向一致。

vendor 接入是 seam（finbayes/data/coinank.py 已建客户端骨架 + 配置位）：CoinAnk 全站 API 文档已确认，但具体端点按套餐 + key 就绪后逐个核对参数 / 响应再接，不预先臆造。激活路径已定（owner 2026-06-23，覆盖本 ADR 起草时的「二选一未定」）= 经 DH 整合：CoinAnk key 由 DH 持有、经 DH Open API（/crypto/liquidations aggregate 面）消费；FinBayes coinank.py 直连降为本地兜底。首刀已按此打通（透传 pilot，非资产化闭环，详见 ADR-0005 §5 + 任务书 §8/§11）。

§3 不变 / 变​

不变：

  • 出处信封（FetchResult / SourceRef）契约不动——所有取数仍产出它。
  • 诚实降级仍是地板——弹性链穷尽后才触发，绝不编造。
  • DH 边界红线（不路由商品化数据 / 不做认知结论 / 不做执行）不动。

变：

  • FinBayes 取数从「单源单次」升级为「弹性多源 + venue 感知」（代码侧已落地）。
  • 确立「商品化数据 FinBayes 直连 + DH 管配置」「高价值资产 DH 产 FinBayes 消费」的双流分工。

§4 落地状态与待办​

  • 已落地（代码仓本地，已部署）：弹性取数原语、venue 模型、8 个 crypto TA 接口（7 真做 + 清算诚实地板）、CoinAnk vendor seam、coinank_api_key 配置位。
  • 待办（需跨项目对接 / owner 决策）：① CoinAnk 套餐选型——已定套餐1（aggregate 清算，owner 2026-06-23）；套餐3（CVD / 订单本差值）、套餐4（清算地图热力图）留后续升级；② DH 整合激活清算——已打通（透传 pilot），被墙交易所原生聚合覆盖仍待；③ 高价值数据扩展（CVD / 订单流 / 清算热力图 / 多空比 / 大额单，owner 已拍同步扩）；④ DH provider 注册表契约对接（DH 侧暴露 + FinBayes 侧读取后本地合成）；⑤ 多市场（股票 / 外汇）复用同一弹性脊柱的推广。

§5 影响​

  • FinBayes：取数韧性显著提升；新增 coinank_api_key 配置位；无破坏性改动（弹性原语对既有宏观链字节等价）。
  • Data Horizon：本 ADR 不要求 DH 立即改动；但为 DH provider 配置中心明确了一个下游消费契约（FinBayes 读 DH 的 provider 配置来构建弹性链），可纳入 DH 后续接口设计。
  • 跨项目：本 ADR 触及 DH ↔ FinBayes 接口，属 L3；DH 侧采纳需经各自项目层评审。