跳到主要内容

FinBayes → Data Horizon 数据集成对齐入口

本文是给负责 Data Horizon（DH）的 Agent 会话 / 负责人的单页入口：把背景、分析、已定决策、方案、读物顺序、第一刀、以及「请 DH 确认/否决的对齐项」收在一处，方便 DH 直接与 FinBayes 对齐后快速落地。详细内容在下列文档，本文做导引 + 决策记录（决策细节以 ADR-0005 / 任务书为单一事实源，本文与其有偏差时以那两份为准）。

1. 一句话背景​

FinBayes（生态认知层金融 agent）团队问「BTC 多交易所盘口」时全交易所取不到数；根因是取数容错 + venue 感知层缺失（FinBayes 侧已自行整改、仅 crypto）。整改中确立了生态级数据边界口径：商品化行情消费方直连、DH 不路由；DH 承接 provider 注册表 + 差异化资产生产。现在请 DH 落地第一步，让 FinBayes 接入。

2. 已定决策（owner，2026-06-23）​

  1. 首个 vendor = CoinAnk 初级套餐（套餐1），由 DH 集成、经 DH Open API 供 FinBayes；凭据（CoinAnk key）DH 持有，FinBayes 不直配。后续升套餐（CVD=套餐3 / 清算热力图=套餐4）+ 加 provider。
  2. API 形态 = 并入 DH 现有宏观 Open API 同一表面（dh-api.topquant.org，X-API-Key，与 DH 交付的 handoff 契约一致），按 asset family 分命名空间：/macro/* 不动，crypto 走 /crypto/*（或 /assets/{asset_type}）。统一的是鉴权 + 出处信封契约，不是 URL；schema 各自独立。
  3. 不碰红线：DH 不路由商品化标准行情（OHLCV/OI/资金费率/订单簿/报价仍由 FinBayes 直连 ccxt）；DH 只产经增值的差异化资产（判据见 ADR-0005 §3）。
  4. 优先级诚实：这对 DH 是 R2 之后的候选、让位于 DH 自身 P0（KOL 总控室 / TM 信源）；不抢其 M0/M1 带宽。

3. 读物顺序（按此读即可对齐）​

  1. ADR-0005 生态级多市场数据边界口径 — 战略口径 + 「商品化↔差异化」判据 + 相对 ADR-030 的新增判断。先读这份。
  2. FinBayes ↔ DH 数据集成任务书 — 可执行工作包：分工边界（§3）、请 DH 承接事项（§4）、FinBayes 就绪度（§5）、vendor 尽调 + 可达性实测（§6）、接口契约 + 出处信封字段（§7）、推进节奏（§8）、验收（§9）、工作切分建议（§10）、待确认（§11）。
  3. FinBayes DataAcquisition 子系统设计 — FinBayes 取数现状（弹性链 / venue 模型 / 8 接口 / 出处信封）。
  4. DH 自己的红线（确认 FinBayes 没让你越界）：ADR-004 差异化价值原则 + 架构边界不变量 #4；承接载体 = Provider 配置中心 Review。
  5. FinBayes 侧双边契约（上位为 ADR-0005）：ADR-030 DH↔FinBayes 数据接口分工。

4. 第一刀（最小可落地，建议先做这个验证通路）​

  • DH：集成 CoinAnk 初级套餐 → 经统一 Open API 暴露**清算（aggregate 聚合面）**端点（/crypto/liquidations 或 /assets/liquidations），带 §7.2 出处信封（as_of / fetched_at / licenseScope / 质量标签；sources.upstream 按 §7.2 聚合 vendor 例外规则——CoinAnk 聚合面不暴露逐所来源时标聚合级、不伪造逐所 upstream）。首刀诚实定性 = 出处信封 + license 封装的单源透传 pilot；跨源校验（用 OI / 资金费率交叉印证）+ 资产化为 S2 后续、非首刀必达（与任务书 §8 一致）。
  • FinBayes：新增 dh_crypto.py（镜像现有 dh_macro.py）消费该端点；crypto 清算接口从当前 no_source → 真实数据带出处信封。
  • 验收：FinBayes 团队群里问「BTC 最近清算」能拿到带出处的真实清算数据、诚实降级链不被绕过。

打通这条最小通路后，再按套餐升级铺 CVD / 清算热力图 / 多空比，并把注册表（§7.1）+ 多市场（股 / 期 / 汇）按 §8 S3 推广。

5. 对齐项 — owner 2026-06-24 直接拍定（不走 DH 会签）​

2026-08-25 上位边界矫正：2026-06-24 “DH 是过渡桥、FinBayes 终局内化全部高阶数据并使 DH 用量下降”的候选判断已被 ecosystem ADR-0007 与 finbayes-arch-rewrite ADR-033 覆盖。CoinAnk 清算 pilot 等当前消费关系不因本次文档矫正迁移；商品化行情仍由 FinBayes 直连并自持容错。未来走 DH、FinBayes 内化或双轨，按 workload、rights、quality、latency、cost、resilience 与 ecosystem reuse evidence 决定。

整改仍保留的诚实标注（不因不会签而回退）：首刀清算 = 单源透传 pilot（非资产化闭环）；DH 透传链是清算运行单点、须配降级 + FinBayes 保留 coinank.py 直连兜底（这条兜底正与「FinBayes 自取 / 内化」方向一致）；license 多下游再分发待 CoinAnk 书面授权。

下列 6 条仍是现阶段 FinBayes↔DH 的对齐口径（DH 已 2026-06-23 非正式认可），保留作现状记录：

  1. 配置面定位：DH 做 provider 注册表 / 推荐配置源（非运行事实源），可用性责任留在消费方——认不认？
  2. 「商品化↔差异化」判据（ADR-0005 §3：仅转发 vendor 字段=商品化不进 DH；加校验 / 出处 / 质量标签 / 可回测=才进 DH）——认不认？
  3. 统一 Open API 表面 + asset-family 命名空间（§7.3）——可行不可行？
  4. 第一刀 = CoinAnk 套餐1 清算先行（§4 above / 任务书 §8 S2）——接不接？
  5. 出处信封字段（§7.2：request_id / 双时间戳 / sources.upstream）——DH 资产能不能产出这些？
  6. 优先级（R2 之后、让位 DH P0）——这个排序 DH 能不能接？

任一条否决 / 要改，回这份入口或任务书对应节标注，FinBayes 侧调整后再推进。

6. 边界​

本包是 FinBayes 发起的提案，不替 DH 排产、不替 DH 决定 agent 编制（§10 工作切分仅建议）。DH 评审 accept 后再拆任务。ADR-0005 的 accepted 以 DH 项目层会签为前置。